linux-kernel - Re: [PATCH v5] af_packet: Handle outgoing VLAN packets without hardware offloading

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: Windows password security audit tool. GUI, reports in PDF.

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

Date: Wed, 5 Jun 2024 15:22:52 -0400
From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
To: alexandre.ferrieux@...nge.com
Cc: Chengen Du <chengen.du@...onical.com>, davem@...emloft.net, edumazet@...gle.com, 
	kuba@...nel.org, pabeni@...hat.com, kaber@...sh.net, 
	linux-kernel@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH v5] af_packet: Handle outgoing VLAN packets without
 hardware offloading

> > > This adds some parsing overhead in the datapath. SOCK_RAW does not
> > > need it, as it can see the whole VLAN tag. Perhaps limit the new
> > > branches to SOCK_DGRAM cases? Then the above can also be simplified.
> >
> > I considered this approach before, but it would result in different
> > metadata for SOCK_DGRAM and SOCK_RAW scenarios. This difference makes
> > me hesitate because it might be better to provide consistent metadata
> > to describe the same packet, regardless of the receiver's approach.
> > These are just my thoughts and I'm open to further discussion.
>
> FWIW, I vote for Willem's approach here: there is no problem with having
> different metadata in SOCK_DGRAM and SOCK_RAW, as the underlying parsing efforts
> are different anyway, along with the start offset for BPF.
> (No, I'm not super happy to see BPF code reaching out to offset -4096 or so to
> get VLAN as metadata. That just smells like a horrendous kludge.)
> To me, it makes plenty of sense to have:
>   - SOCK_DGRAM for compatibility (used by everyone today), doing all historical
> shenanigans with VLANs and metadata
>   - SOCK_RAW for a modern, new API, making no assumption on encapsulation, and
> presenting an untouched linear frame
>   - yes this means different BPF code for the same filter between the two modes
>
> Again, my .02c

Thanks for chiming in. Generally agreed.

We cannot modify established SOCK_RAW behavior in arbitrary ways
either. But there are already two forms in which VLAN data may arrive.
And with SOCK_RAW in-band VLAN tags can be parsed as is.

(fyi, your message was dropped by the list's plaintext filter)