[v2] net/af_xdp: enable a sock path alongside use_cni

[Maryam Tahhan]

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