Userspace networking to dodge kernelspace ping pong RTT overhead? This looks like it has the potential to be awesome. At the very least, it's a great quick talk on how "kernelspace/userspace RTTs are not fast mkaaaay?" and it's exciting that some folks are trying to think outside the box on this.
So, questions: Am I correct in thinking this approach would be limited to advisory-only sorts of networking help, and cannot be used as a security boundary? It seems like anything running within a container's network namespace would still need a host interface exposed for its own virtualized packets, and obviously LD_PRELOAD hijinx remain freely ignorable by any program that decides not to go with the libc flow. Maybe it's possible to pick up the host interface, and then jump into the container's limited network namespace and thus be able to give no other options to the other contained processes?
Alternatively, I wonder if this approach could also be plugged in via seccomp filters, as well as LD_PRELOAD hooks? The docs at https://github.com/torvalds/linux/blob/5634347dee31373a8faf0... seem to suggest syscall capture and reroute might be capable of this. This would still be causing a kernel/userspace bounce, which we were trying to avoid, but it would still cut out the unnecessary trips through the host networking stack that we're going to ignore anyway... and more importantly, would actually be strong enough to be relied upon as a security constraint.
Good luck, ZeroTier folks! Looking forward to watching this continue to develop.
Depends on what kind of security boundary. You could only allow zerotier traffic, in which case the container only lives on the virtual net and no "real" traffic flows. You could also have the preloaded intercept library forbid any other traffic, isolating the process network wise. It's a total socket API takeover.
And yes there are other mechanisms than LD PRELOAD. It can also be explicitly linked into a binary if you do want to rebuild, or linked into libc, or linked into everything via the dynamic linker configuration files. The latter us how an entire container as opposed to a process can be placed into a virtual net.
Comments
Userspace networking to dodge kernelspace ping pong RTT overhead? This looks like it has the potential to be awesome. At the very least, it's a great quick talk on how "kernelspace/userspace RTTs are not fast mkaaaay?" and it's exciting that some folks are trying to think outside the box on this.
So, questions: Am I correct in thinking this approach would be limited to advisory-only sorts of networking help, and cannot be used as a security boundary? It seems like anything running within a container's network namespace would still need a host interface exposed for its own virtualized packets, and obviously LD_PRELOAD hijinx remain freely ignorable by any program that decides not to go with the libc flow. Maybe it's possible to pick up the host interface, and then jump into the container's limited network namespace and thus be able to give no other options to the other contained processes?
Alternatively, I wonder if this approach could also be plugged in via seccomp filters, as well as LD_PRELOAD hooks? The docs at https://github.com/torvalds/linux/blob/5634347dee31373a8faf0... seem to suggest syscall capture and reroute might be capable of this. This would still be causing a kernel/userspace bounce, which we were trying to avoid, but it would still cut out the unnecessary trips through the host networking stack that we're going to ignore anyway... and more importantly, would actually be strong enough to be relied upon as a security constraint.
Good luck, ZeroTier folks! Looking forward to watching this continue to develop.
Depends on what kind of security boundary. You could only allow zerotier traffic, in which case the container only lives on the virtual net and no "real" traffic flows. You could also have the preloaded intercept library forbid any other traffic, isolating the process network wise. It's a total socket API takeover.
And yes there are other mechanisms than LD PRELOAD. It can also be explicitly linked into a binary if you do want to rebuild, or linked into libc, or linked into everything via the dynamic linker configuration files. The latter us how an entire container as opposed to a process can be placed into a virtual net.
Couldn't this be used together with microkernels, too, since you're taking the networking out of the kernel anyway?