public inbox for passt-dev@passt.top
 help / color / mirror / code / Atom feed
From: David Gibson <david@gibson.dropbear.id.au>
To: Stefano Brivio <sbrivio@redhat.com>
Cc: passt-dev@passt.top
Subject: Re: [PATCH v4 9/9] tcp, udp: Bind outbound listening sockets by interface instead of address
Date: Wed, 26 Nov 2025 16:42:22 +1100	[thread overview]
Message-ID: <aSaTPr2TutaJ0p1_@zatzit> (raw)
In-Reply-To: <20251121045601.021b1793@elisabeth>

[-- Attachment #1: Type: text/plain, Size: 2279 bytes --]

On Fri, Nov 21, 2025 at 04:56:01AM +0100, Stefano Brivio wrote:
> The series looks good to me in general, except that:
> 
> On Wed, 19 Nov 2025 16:22:57 +1100
> David Gibson <david@gibson.dropbear.id.au> wrote:
> 
> > Currently, outbound forwards (-T, -U) are handled by sockets bound to the
> > loopback address.  Typically we create two sockets, one for 127.0.0.1 and
> > one for ::1.
> > 
> > This has some disadvantages:
> >  * The guest can't connect via 127.0.0.0/8 addresses other than 127.0.0.1
> >  * We can't use dual-stack sockets, we have to have separate sockets for
> >    IPv4 and IPv6.
> > 
> > The restriction exists for a reason though.  If the guest has any
> > interfaces other than pasta (e.g. a VPN tunnel) external hosts could reach
> > the host via the forwards.  Especially combined with -T auto / -U auto this
> > would make it very easy to make a mistake with nasty security implications.
> > 
> > We can achieve this a different way, however.  Don't bind to a specific
> > address, but _do_ use SO_BINDTODEVICE to restrict the sockets to the "lo"
> > interface.
> 
> ...this means, as I pointed out on:
> 
>   https://archives.passt.top/passt-dev/20251022105916.53925523@elisabeth/
> 
> that we might break functionality for a number of pasta(1) users.
> 
> I don't have a complete version of the SO_BINDTODEVICE fallback I
> sketched there, so I can't just add one on top of this series at the
> moment, but we need something like that before I can merge this.

I re-examined your proposed approach, but realised it doesn't quite
work.  The problem is that to complete it, sock_l4_sa() would need to
create both an IPv4 and IPv6.  That works right now, but it breaks the
assumption that tcp_sock_init() and udp_sock_init() create (at most) a
single socket.  That wasn't the case until 8/9 in this series, but
part of the reason for 8/9 is because establishing that invariant
makes a bunch of stuff in the works much saner.

So, I'm working to figure out a different approach for an
SO_BINDTODEVICE fallback.

-- 
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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

      parent reply	other threads:[~2025-11-26  5:42 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-19  5:22 [PATCH v4 0/9] Reduce differences between inbound and outbound socket binding David Gibson
2025-11-19  5:22 ` [PATCH v4 1/9] flow: Remove bogus @path field from flowside_sock_args David Gibson
2025-11-19  5:22 ` [PATCH v4 2/9] inany: Let length of sockaddr_inany be implicit from the family David Gibson
2025-11-19  5:22 ` [PATCH v4 3/9] util, flow, pif: Simplify sock_l4_sa() interface David Gibson
2025-11-19  5:22 ` [PATCH v4 4/9] tcp: Merge tcp_ns_sock_init[46]() into tcp_sock_init_one() David Gibson
2025-11-19  5:22 ` [PATCH v4 5/9] udp: Unify some more inbound/outbound parts of udp_sock_init() David Gibson
2025-11-19  5:22 ` [PATCH v4 6/9] udp: Move udp_sock_init() special case to its caller David Gibson
2025-11-19  5:22 ` [PATCH v4 7/9] util: Fix setting of IPV6_V6ONLY socket option David Gibson
2025-11-19  5:22 ` [PATCH v4 8/9] tcp, udp: Remove fallback if creating dual stack socket fails David Gibson
2025-11-19  5:22 ` [PATCH v4 9/9] tcp, udp: Bind outbound listening sockets by interface instead of address David Gibson
2025-11-21  3:56   ` Stefano Brivio
2025-11-21  5:24     ` David Gibson
2025-11-21  5:39       ` Stefano Brivio
2025-11-26  5:42     ` David Gibson [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aSaTPr2TutaJ0p1_@zatzit \
    --to=david@gibson.dropbear.id.au \
    --cc=passt-dev@passt.top \
    --cc=sbrivio@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://passt.top/passt

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for IMAP folder(s).