netdev - Re: [PATCH bpf 0/3] xsk: require XDP_UMEM_TX_METADATA_LEN to actuate tx_metadata

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]

Message-ID: <f30e6532-28e3-dca8-1274-e6b31531b84e@iogearbox.net>
Date: Thu, 25 Jul 2024 12:06:22 +0200
From: Daniel Borkmann <daniel@...earbox.net>
To: Maciej Fijalkowski <maciej.fijalkowski@...el.com>,
 Stanislav Fomichev <sdf@...ichev.me>
Cc: bpf@...r.kernel.org, netdev@...r.kernel.org, ast@...nel.org,
 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 0/3] xsk: require XDP_UMEM_TX_METADATA_LEN to actuate
 tx_metadata_len

On 7/24/24 5:23 PM, Maciej Fijalkowski wrote:
> On Fri, Jul 12, 2024 at 06:52:50PM -0700, Stanislav Fomichev wrote:
>> Julian reports that commit 341ac980eab9 ("xsk: Support tx_metadata_len")
>> can break existing use cases which don't zero-initialize xdp_umem_reg
>> padding. Fix it (while still breaking a minority of new users of tx
>> metadata), update the docs, update the selftest and sprinkle some
>> BUILD_BUG_ONs to hopefully catch similar issues in the future.
>>
>> Thank you Julian for the report and for helping to chase it down!
>>
>> Reported-by: Julian Schindel <mail@...tic-alpaca.de>
>> Cc: Magnus Karlsson <magnus.karlsson@...il.com>
> 
> For the content series,
> 
> Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@...el.com>
> 
> However I was not sure about handling patch 3/3.

Ok, then I'm taking in the first two for now as they seem to actually
address the fix and the 3rd seems like an improvement which could also
get routed via bpf-next. In either case, if one of you could follow-up
on the latter, that would be great.

Thanks,
Daniel