Re: [PATCH 1/3] conf: Introduce --no-bindtodevice option for testing

On Sun, Jan 11, 2026 at 12:33:14AM +0100, Stefano Brivio wrote:

On Mon, 5 Jan 2026 19:28:48 +1100 David Gibson wrote:

...

We need to support (as best we can) older kernels which don't allow unprivilieged processes to use the SO_BINDTODEVICE socket option.

Nit: unprivileged

...

Fallcaks for that case are controlled by the c->no_bindtodevice variable.

Fallbacks

Oops & oops. Fixed.

...

Currently testing behaviour of those fallbacks requires setting up a test system with a kernel that doesn't support the option, which is pretty awkward. We can test it almost as well and much more easily by adding a command line option to explicitly disable use of SO_BINDTODEVICE.

It's kind of hard to understand if this patch entirely does that, I think.

Well, it forces c->no_bindtodevice to be true. If we attempt to use SO_BINDTODEVICE in that case, it's a bug elsewhere.

We still have a separate, implicit probing of SO_BINDTODEVICE in sock_l4_(), which is perhaps excluded by c->no_bindtodevice (but then the comment is misleading?).

It should indeed be excluded because we should never call sock_l4_() with a non-empty ifname if !c->no_bindtodevice. It's not really probing, because we outright fail sock_l4_(), there's no fallback there. The error path is there: * As a backstop if there is a bug elsewhere meaning we do call this with non-empty ifname * If the SO_BINDTODEVICE call fails for a reason other than being globally unavailable (non existent interface, out of memory, sufficiently perverse selinux module). Given the above, probably should be an err(), and the comment there is no longer accurate / helpful (we already moved it to sock_probe_features()). I've made those changes for the next spin.

...

Like --no-splice this is envisaged as something for developers' and testers' convenience, not a supported option for end users. The man page text reflects that.

I never really understood the point of --no-splice, as there was no user request whatsoever behind it, but fine, the argument was that it added some needed functionality, even though I couldn't quite grasp which one it was.

That was never the argument from _me_ for --no-splice. For me it was always that it was useful for development / testing / debugging, not that it was (directly) useful to end users. That's true in at least two ways: * Allows testing non-splice functionality without having to either use passt or create some non-loopback addresses * Lets us ask a user reporting a problem to try --no-splice if we suspect, but aren't sure that it's specific to the splice logic My case for --no-bindtodevice is the same: it's useful to me (and therefore I'm guessing to other developers and testers). The man page update is pretty explicit about that.

However, with this, the question is where we draw the line. There are probably other options we could use to make debugging or testing slightly simpler, but if they don't offer actual functionality, we always kept them out so far.

I mean, maybe, none are immediately occurring to me. If they do in future, I think we should consider adding them. Note that --no-splice, and especially --no-bindtodevice are extremely simple to implement. I would not be arguing for them if they were more complex.

That's because we already have a long list of options and making it unnecessarily longer is a disservice to users, I think.

That's a valid point. Would it be more palatable to you if we made these suboptions of some explicit "developer hacks" option? (--hacks? --debugopt? --devtest?)

Would using something like this:

sed -i 's/(\(setsockopt([a-z]*, SOL_SOCKET, SO_BINDTODEVICE\)/((errno = EPERM) || \1/g' *.c

be totally outrageous, for testing purposes?

Totally outrageous, no. A bit more hassle, yes.

It has the advantage of making it easier to verify if we're really disabling the usage of SO_BINDTODEVICE on all the paths (together with grep / git / editors), and not introducing additional command line options.

Another trick I use sometimes to selectively disable or enable kernel features is to handle system calls via seitan, in this case the (simple) recipe would something like:

[ { "match": [ { "setsockopt": { "level": socket", "name": "bindtodevice" } } ], "return": { "value": "EPERM", "error": -1 } } ]

but I haven't implemented setsockopt() yet. :(

...

Signed-off-by: David Gibson --- conf.c | 2 ++ passt.1 | 6 ++++++ 2 files changed, 8 insertions(+)

diff --git a/conf.c b/conf.c index ceb9aa55..70ea168c 100644 --- a/conf.c +++ b/conf.c @@ -962,6 +962,7 @@ static void usage(const char *name, FILE *f, int status) " --no-ndp Disable NDP responses\n" " --no-dhcpv6 Disable DHCPv6 server\n" " --no-ra Disable router advertisements\n" + " --no-bindtodevice Disable SO_BINDTODEVICE\n" " --freebind Bind to any address for forwarding\n" " --no-map-gw Don't map gateway address to host\n" " -4, --ipv4-only Enable IPv4 operation only\n" @@ -1454,6 +1455,7 @@ void conf(struct ctx *c, int argc, char **argv) {"no-dhcpv6", no_argument, &c->no_dhcpv6, 1 }, {"no-ndp", no_argument, &c->no_ndp, 1 }, {"no-ra", no_argument, &c->no_ra, 1 }, + {"no-bindtodevice", no_argument, &c->no_bindtodevice, 1}, {"no-splice", no_argument, &c->no_splice, 1 }, {"freebind", no_argument, &c->freebind, 1 }, {"no-map-gw", no_argument, &no_map_gw, 1 }, diff --git a/passt.1 b/passt.1 index db0d6620..4859d9e5 100644 --- a/passt.1 +++ b/passt.1 @@ -348,6 +348,12 @@ namespace will be silently dropped. Disable Router Advertisements. Router Solicitations coming from guest or target namespace will be ignored.

+.TP +.BR \-\-no-bindtodevice +Development/testing option, do not use. Disables use of +SO_BINDTODEVICE socket option. Implicitly enabled on older kernels +which don't permit unprivileged use of SO_BINDTODEVICE. + .TP .BR \-\-freebind Allow any binding address to be specified for \fB-t\fR and \fB-u\fR

The change looks otherwise good to me... I just hope we can avoid it somehow, but if not, so be it.

I mean, it's not essential to anything that follows, but it was useful to me during testing. If you really don't want it, well, I'll cope. -- David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson