From nobody Mon Jan 27 16:09:04 2025 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4YhYJN64Xmz5lskc for ; Mon, 27 Jan 2025 16:09:08 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4YhYJN0PgRz3SVC for ; Mon, 27 Jan 2025 16:09:08 +0000 (UTC) (envelope-from markjdb@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=eDF32JAw; spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::72c as permitted sender) smtp.mailfrom=markjdb@gmail.com; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=freebsd.org (policy=none) Received: by mail-qk1-x72c.google.com with SMTP id af79cd13be357-7b6ea711805so661555685a.1 for ; Mon, 27 Jan 2025 08:09:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1737994147; x=1738598947; darn=freebsd.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:from:to:cc:subject:date:message-id :reply-to; bh=b7K1rpDQYa5VWoN/uarxKE98PA9iyBEFBetvtLawxrk=; b=eDF32JAwRVbqJIwXfj4Uycmr8AEOyd3z5FoZwIA8ZUbaTznXrSN1P5vRFhKjg8tfGI fV5Qn4+Tyrmdf11dEo3eMjbHNRg+f3dNxil624shPHwaqWYd+vceGPJ15zwNJZBNt34D gTUSU718W7mnJcyNnZpHMW0vKdUz0eZNSVgu4pOcptm8DX1kw1XQh7+eXA+jaD/qsTvJ zlY2rxsDhs3Rifx6L21EOCHroSeHKJfpaRJqgdapKzkLs2puwIm2KNxokE7H5ti9Ys1v zAcF0GRZNIYZJUFMftbDHPpamA+D6DikhPBYIJhBl1N45Gw+p3KMjP4177W4Rap2Hs8u 0/3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737994147; x=1738598947; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=b7K1rpDQYa5VWoN/uarxKE98PA9iyBEFBetvtLawxrk=; b=TAFelOun38G1YIBAv6q3TL7ds/sCbYTQL9E9IXVV+a7NUiacgA9dbsJ7o62QV2lo8E AXu6StWmcI9AVZzKfpX2T+1DJGincN95DH5BUjLDLNNcRie253J/9qe0HUppVNh3GUGy i5I99sepmNzvM49Spxk4dZODIBqByAXY7tVBi8LvmOUP1gF4ECRktrjKOl+BQZ8rvJQ6 WItmB3XvkjABCvEs+PrhCVbpve8JNOqogScbZ2uFynMXac3UN8R9B3WvgbOFn35nvvsn ZrgcOeQBjAjOpPD4Eu8aM8Br3RryETF39zGMmhy2WBNVe25iJdNgMAigbGBxQqHZdvKK +Qng== X-Gm-Message-State: AOJu0YxZ1t6JJMpmoq84C+St7ZE1c856yg9/Ya5GU/FupcWS4AN2Hu0s GiFxHlmXMgaXUAXJFHMNtxN0TCMyS8JNv/PYCVQVULsGwbZz8SL0la1E7w== X-Gm-Gg: ASbGncv9doJRYHiAI9olFR+s1zMJQUbmwnPCRMbmrojiUEHNxi4Ih13vGt3uD2pmvmK xiaqbEUm9UjETyHeq7T+z8WGr3u3EdDpK8FdX0bL6D6lsa7e8WUS3cb12q5EdfS0p7XhWZH7gw+ cqaxwdw4CD2DVzg30dNXDWUQskk+9p4acmqqF1ltPk7fzhtghnBsnGirUIk27s+9Ayqp6PNTCY0 iyOgGLarsSFEi2EYteS6Ljq9IaOTRaIonX57GYGxRrj2u0Eq2K6+N9+q6fOSQjGEgfqFJNyb5Wf A1J9wd7QuiaR59uftLo= X-Google-Smtp-Source: AGHT+IETXI/XGsAafDyXPdWF9qlDFV6dlEuVf4P6DBCIY8vaGiAulMUd77ObBuyGWMsqjkdKP9EPzg== X-Received: by 2002:a05:622a:34c:b0:467:864b:dd79 with SMTP id d75a77b69052e-46e12bc60camr673247411cf.49.1737994147046; Mon, 27 Jan 2025 08:09:07 -0800 (PST) Received: from nuc (192-0-220-237.cpe.teksavvy.com. [192.0.220.237]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-6e2058c303dsm35730866d6.113.2025.01.27.08.09.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 27 Jan 2025 08:09:06 -0800 (PST) Date: Mon, 27 Jan 2025 11:09:04 -0500 From: Mark Johnston To: Paul Vixie Cc: "freebsd-net@freebsd.org" Subject: Re: per-FIB socket binding Message-ID: References: <7772475.EvYhyI6sBW@dhcp-151.access.rits.tisf.net> <2841433.BEx9A2HvPv@localhost> <2223592.Mh6RI2rZIc@localhost> List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2223592.Mh6RI2rZIc@localhost> X-Spamd-Result: default: False [-2.18 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.58)[-0.580]; MID_RHS_NOT_FQDN(0.50)[]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : SPF not aligned (relaxed), DKIM not aligned (relaxed),none]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_TWO(0.00)[2]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_DN_EQ_ADDR_SOME(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TO_DN_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::72c:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com]; DKIM_TRACE(0.00)[gmail.com:+]; PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; MLMMJ_DEST(0.00)[freebsd-net@freebsd.org]; MISSING_XM_UA(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-Spamd-Bar: -- X-Rspamd-Queue-Id: 4YhYJN0PgRz3SVC 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.