netdev - Re: [PATCH bpf 3/3] xsk: Try to make xdp_umem_reg extension a bit more future-proof

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] [day] [month] [year] [list]

Message-ID: <ZqKS7QAH54vTnJ2z@mini-arch>
Date: Thu, 25 Jul 2024 11:01:17 -0700
From: Stanislav Fomichev <sdf@...ichev.me>
To: Maciej Fijalkowski <maciej.fijalkowski@...el.com>
Cc: bpf@...r.kernel.org, netdev@...r.kernel.org, ast@...nel.org,
	daniel@...earbox.net, andrii@...nel.org, martin.lau@...ux.dev,
	song@...nel.org, yhs@...com, john.fastabend@...il.com,
	kpsingh@...nel.org, sdf@...gle.com, haoluo@...gle.com,
	jolsa@...nel.org, Julian Schindel <mail@...tic-alpaca.de>,
	Magnus Karlsson <magnus.karlsson@...il.com>
Subject: Re: [PATCH bpf 3/3] xsk: Try to make xdp_umem_reg extension a bit
 more future-proof

On 07/24, Maciej Fijalkowski wrote:
> On Fri, Jul 12, 2024 at 06:52:53PM -0700, Stanislav Fomichev wrote:
> > Add a couple of things:
> > 1. Remove xdp_umem_reg_v2 since its sizeof is the same as xdp_umem_reg
> 
> So thing here is that adding __attribute__((packed)) on kernel side
> wouldn't help because we wouldn't fix old uapi with this, correct? old
> uapi would still yield 32 bytes for xdp_umem_reg without tx_metadata_len.
> 
> Just explaining here to myself.

Yea :-(

> > 2. Add BUILD_BUG_ON that checks that the size of xdp_umem_reg_v1 is less
> >    than xdp_umem_reg; presumably, when we get to v2, there is gonna
> >    be a similar line to enforce that sizeof(v2) > sizeof(v1)
> > 3. Add BUILD_BUG_ON to make sure the last field plus its size matches
> >    the overall struct size. The intent is to demonstrate that we don't
> >    have any lingering padding.
> 
> This is good stuff but I wonder wouldn't it be more feasible to squash
> this with 1/3 ? And have it backported. Regarding the patch logistics, you
> did not provide fixes tag here for some reason, but still include the
> patch routed via bpf tree.

SG, will resend this against bpf-next.