Date: Mon, 27 Jan 2025 11:09:04 -0500 From: Mark Johnston <markj@freebsd.org> To: Paul Vixie <paul@redbarn.org> Cc: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org> Subject: Re: per-FIB socket binding Message-ID: <Z5evoIzSUty8qyUY@nuc> In-Reply-To: <2223592.Mh6RI2rZIc@localhost> References: <7772475.EvYhyI6sBW@dhcp-151.access.rits.tisf.net> <2841433.BEx9A2HvPv@localhost> <Z4ViiO1LsAIvD2Mu@nuc> <2223592.Mh6RI2rZIc@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Jan 25, 2025 at 08:44:25PM +0000, Paul Vixie wrote: > On Monday, January 13, 2025 6:59:20 PM UTC Mark Johnston wrote: > > On Sun, Jan 12, 2025 at 07:17:48AM +0000, Paul Vixie wrote: > > > On Saturday, January 11, 2025 4:51:07 PM UTC Mark Johnston wrote: > > > > On Sat, Jan 11, 2025 at 06:25:22AM +0000, Paul Vixie wrote: > > > > > > this is exactly my understanding of that code. the FIB for the SYN|ACK > > > will be the one from the interface who received the SYN. > > > > What I'm saying is that today, the FIB for the SYN|ACK will be that of > > the listening socket, not that of the receiving interface. > > sc->sc_inc.inc_fibnum comes from the listening socket, not the SYN. > > thanks for beating me over the head with the facts of the case. i'd simply > forgotten that my earliest patch preferred the SYN's FIB number over the > listener socket's FIB number if only the former was nonzero. > > > > ... > > > i've begun to wish for a setfib_fd(2) which would let sshd promote the FIB > > > from an inbound connection to be process-wide (after fork() before > > > exec().) > > > that way "netstat -rn" would show the routing table actually being used by > > > the stdin and stdout of that shell. or perhaps we could just rename > > > SO_SETFIB to be SO_FIB and allow getsockopt() to return the FIB? (i'm not > > > sure why it was "set only" in the current implementation.) opinions > > > welcomed, as before. > > ... > > I think the second option is fine, given that we have setfib(2) already: > > ... > > i think i would do it a little differently, making SO_FIB both gettable and > settable, and leaving SO_SETFIB as an alias for SO_FIB that is set-only, and > documenting SO_SETFIB as an alias for backward compatibility. That's basically what my patch does, but it should be more explicit about deprecating SO_SETFIB. > and if we're > going to do this for sockets, we need a getfib() syscall to do it for > processes. In fact we already have something equivalent - see below. > however, before doing this, i'd want to know why there was never an SO_GETFIB > since its absence may be deliberate (for some security related purpose.) in > such case my setfib_fd() proposal would propagate a socket's FIB to be > process-wide without revealing the FIB itself to the calling process. > > does anyone remember why the FIB of a socket or process cannot be discovered > from user mode? lack of motivation -- or deliberate design decision? I can't say for certain as I wasn't involved in the original design, but I do see that we already have a net.my_fibnum sysctl which is effectively the same as a hypothetical getfib(2) system call. This was part of the original FIB implementation from commit 8b07e49a008c8. I have no idea why this was implemented as a sysctl instead of a syscall when setfib(2) exists. So, an application already knows the FIB number of any given socket, since it can find its own FIB number, and new sockets always inherit the FIB number of the process or the listening socket. Therefore, I believe there's no reason not to provide an explicit mechanism to query the FIB number.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Z5evoIzSUty8qyUY>