netdev - Re: [PATCH bpf] xdp: use flags field to disambiguate broadcast redirect

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: <ce9252ef-21e2-4b09-9797-590f5eaa2869@linux.dev>
Date: Mon, 22 Apr 2024 11:21:18 -0700
From: Martin KaFai Lau <martin.lau@...ux.dev>
To: Toke Høiland-Jørgensen <toke@...hat.com>
Cc: syzbot+af9492708df9797198d6@...kaller.appspotmail.com,
 Alexei Starovoitov <ast@...nel.org>, Daniel Borkmann <daniel@...earbox.net>,
 Andrii Nakryiko <andrii@...nel.org>, Eduard Zingerman <eddyz87@...il.com>,
 Song Liu <song@...nel.org>, Yonghong Song <yonghong.song@...ux.dev>,
 John Fastabend <john.fastabend@...il.com>, KP Singh <kpsingh@...nel.org>,
 Stanislav Fomichev <sdf@...gle.com>, Hao Luo <haoluo@...gle.com>,
 Jiri Olsa <jolsa@...nel.org>, "David S. Miller" <davem@...emloft.net>,
 Jakub Kicinski <kuba@...nel.org>, Jesper Dangaard Brouer <hawk@...nel.org>,
 Hangbin Liu <liuhangbin@...il.com>, Eric Dumazet <edumazet@...gle.com>,
 Paolo Abeni <pabeni@...hat.com>, bpf@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH bpf] xdp: use flags field to disambiguate broadcast
 redirect

On 4/20/24 3:24 AM, Toke Høiland-Jørgensen wrote:
>>   From reading the "waits for...NAPI being the relevant context here..." comment
>> in dev_map_free(), I wonder if moving synchronize_rcu() before
>> bpf_clear_redirect_map() would also work? Actually, does it need to call
>> bpf_clear_redirect_map(). The on-going xdp_do_redirect() should be the last one
>> using the map in ri->map anyway and no xdp prog can set it again to
>>   ri->map.
> I think we do need to retain the current behaviour, because of the
> decoupling between the helper and the return code. Otherwise, you could

Forgot there could be a disconnect here.

Applied. Thanks.

> have a program that calls the bpf_redirect_map() helper, but returns a
> different value (say, XDP_DROP). In this case, the map pointer will
> stick around in struct bpf_redirect_info, and if a subsequent XDP
> program then returns XDP_REDIRECT (*without*  calling
> bpf_redirect_map()), it will use the stale pointer value and cause a