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
