netdev - Re: [RESEND PATCH net-next v2 2/4] net/ipv6: create ipv6_fl_get

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aQpmVg6iLVZiI7hH@eidolon.nox.tf>
Date: Tue, 4 Nov 2025 21:47:18 +0100
From: David Lamparter <equinox@...c24.net>
To: Lorenzo Colitti <lorenzo@...gle.com>
Cc: netdev@...r.kernel.org, Jakub Kicinski <kuba@...nel.org>,
	Patrick Rohr <prohr@...gle.com>
Subject: Re: [RESEND PATCH net-next v2 2/4] net/ipv6: create ipv6_fl_get_saddr

On Tue, Nov 04, 2025 at 12:51:26PM -0500, Lorenzo Colitti wrote:
> On Tue, Nov 4, 2025 at 9:49 AM David Lamparter <equinox@...c24.net> wrote:
> > This adds passing the relevant flow information as well as selected
> > nexthop into the source address selection code, to allow the RFC6724
> > rule 5.5 code to look at its details.
> >
> > [...]
> >  struct ipv6_saddr_dst {
> > -       const struct in6_addr *addr;
> > +       const struct flowi6 *fl6;
> 
> Do you need an entire flowi6? In this patch I see that you only use
> saddr and daddr.
[quote reordered below]
> Similarly, do you need a sk? I don't think you use it in this patch.
> Is it used in future patches?

The answer is the same for both fields: the RFC6724 code (which I
haven't posted yet and really should) calls ip6_route_output() for
different source addresses, and that takes both the sk as well as the
fl6 as parameters.

> But flowi6 has lots of information in it that
> potentially duplicates other inputs to this function - for example,
> the ifindex could also be in flowi6->oif. Should you pass in a
> different object than flowi6? Or should, for example, flowi6->oif be
> updated with dst->ifindex?

The problem is that they're not subsets of each other; flowi6 doesn't
tell anything about the neighbor/router that has already been selected
(and is at the core of the 6724 r5.5 considerations) - that's in the
dst.  But the dst is missing all the other bits ip6_route_output wants
to be able to look at for various policy things.

I agree there are a few bits that the function can get at in multiple
ways, but that's because we've already partially but not entirely
processed things at this point.  The flowi6 with a whole bunch of raw
input data is "still" there but being halfway done kinda naturally means
we have some object pointers around at the same time.