From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 61493436C8; Mon, 11 Dec 2023 14:22:17 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 18D9640608; Mon, 11 Dec 2023 14:22:16 +0100 (CET) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mails.dpdk.org (Postfix) with ESMTP id 614A440289 for ; Mon, 11 Dec 2023 14:22:14 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1702300933; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=DVNoG+sxeznQbDigroP3siG+SFL00iqV4bo+mSQDK8Q=; b=gbHhintIL48DZy31/4PWeslpxfha9ZkaOD1GANlXWiUqOntfeTC20qU4ddGTXMCqGxwXeO t5AUisKBvB701tF6fWt9Ic+hgAHrFqGSjntXUOyce0SD+ecyIy8GnuuRXSJUZFTudNuc0P rWbgwCVWYo8GRrxXq99fib9vVucoUi4= Received: from mail-qt1-f197.google.com (mail-qt1-f197.google.com [209.85.160.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-696-6A0izKE-OWuKtlrc9lkrAw-1; Mon, 11 Dec 2023 08:22:12 -0500 X-MC-Unique: 6A0izKE-OWuKtlrc9lkrAw-1 Received: by mail-qt1-f197.google.com with SMTP id d75a77b69052e-42577ba9d93so62260961cf.2 for ; Mon, 11 Dec 2023 05:22:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702300932; x=1702905732; h=content-transfer-encoding:in-reply-to:cc:references:to:from :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=DVNoG+sxeznQbDigroP3siG+SFL00iqV4bo+mSQDK8Q=; b=rFWYwUHBd96H9OCRJnA/flsCTh8rsr1G7zefmcm8OJkxJpfVD1YSdAARWmVhyZkh7J Fqxp9ZyUkN7H92XbIJ3KYeXFXRZYOO64vtCMOFVjdQaQx7LeCzQoFc8IR3HHzX39tCHO Y/OgHB9zvE4sPhvfmicNNT7gGM5ah7xnFtL06imJ28/2G0XgXydwfqDucOsOTSUHzdS3 z9ny/TJkive+VE/dLN0c11WPww5sOqNwTS09VpXW6f5WTkq86hCObuaWLGBm/csWyUau Tu1X0zXHBPmVCzJzhJ46Y1VbYXOlWSeatx+eaO+k2DtSemF7J51ocwWsUVcDfbWjG9/i 2gaA== X-Gm-Message-State: AOJu0Yx+llcosts5k0/nGTjfiNMVlJfDTLxmVtfc8xIvoXZnfPVZ2TrI jMUaAOYnGutplJ+R0mV0kRKREUhKK5Ef4VloHcC26luU6koSHrCDU2bKFpSY9bIyg5YDaOYzARo /NVs= X-Received: by 2002:ac8:598e:0:b0:425:4043:1d8e with SMTP id e14-20020ac8598e000000b0042540431d8emr7398442qte.97.1702300932029; Mon, 11 Dec 2023 05:22:12 -0800 (PST) X-Google-Smtp-Source: AGHT+IH39oHMagoAIuPRwfiJQBVI9k4nuIimW//y2RC51C1mrSL82/+IeotmKHfhaZxImjpIfpe5bQ== X-Received: by 2002:ac8:598e:0:b0:425:4043:1d8e with SMTP id e14-20020ac8598e000000b0042540431d8emr7398433qte.97.1702300931751; Mon, 11 Dec 2023 05:22:11 -0800 (PST) Received: from [192.168.0.12] ([78.18.22.228]) by smtp.gmail.com with ESMTPSA id f21-20020ac84995000000b00423890096afsm3195310qtq.2.2023.12.11.05.22.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 Dec 2023 05:22:11 -0800 (PST) Message-ID: Date: Mon, 11 Dec 2023 13:22:08 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [v2] net/af_xdp: enable a sock path alongside use_cni From: Maryam Tahhan To: Stephen Hemminger References: <20231204103101.2124374-1-mtahhan@redhat.com> <20231208092334.674210eb@hermes.local> Cc: "ferruh.yigit@amd.com" , "lihuisong@huawei.com" , "fengchengwen@huawei.com" , "liuyonglong@huawei.com" , "Koikkara Reeny, Shibin" , "dev@dpdk.org" , Ciara Loftus In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On 08/12/2023 18:10, Maryam Tahhan wrote: > Thanks Stephen,  I will have a look. > > I've seen a few places mention that abstract sockets are attached to > the network namespace of a process. For our use case the 2 processes > (pods) will have separate network namespaces. So I'm not sure it will > work. However, it should be easy to validate and I can give it a try > in a k8s environment for completeness. Otherwise all the pods would > need to be host networked which is not what we want at all. > > I was able to find a case where abstract sockets were used by > containerd (CVE-2020-15257) [1]. Our AF_XDP DP Pod is also host > networked and so it seems that we would be opening ourselves up to > similar issues,  in that a bad acting container could block containers > that actually want to use afxdp_dp by simply connecting to the DP and > just failing to handshake on all the abstract sockets it finds in,the > host namespace. > > I will circle back on Mon re the first open, but considering that > containerd abandoned this approach, I'm not sure it's the way to go > for us. But let's cross that bridge after we have an answer to the > first issue. > Hi Stephen Circling back, I built a simple example here [1] using kind. The abstract sockets don't work across network namespaces (which is our scenario with the Pods) and so will not be usable for what we are trying to do here. The example creates a simple kind cluster. It builds a simple docker image that incorporates socat. Then it launches 2 pods: - The first pod is the server (it will use socat to create an abstract socket). - The second pod is the client (it will use socat to try to connect to the abstract socket). The connection attempt in the client fails. [1] https://github.com/maryamtahhan/ans-kind-example