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
| ||
|
Date: Mon, 30 Mar 2020 12:13:15 -0700 From: Jakub Kicinski <kuba@...nel.org> To: Edward Cree <ecree@...arflare.com> Cc: Andrii Nakryiko <andrii.nakryiko@...il.com>, Toke Høiland-Jørgensen <toke@...hat.com>, Alexei Starovoitov <alexei.starovoitov@...il.com>, John Fastabend <john.fastabend@...il.com>, "Alexei Starovoitov" <ast@...nel.org>, Daniel Borkmann <daniel@...earbox.net>, "Martin KaFai Lau" <kafai@...com>, Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>, Andrii Nakryiko <andriin@...com>, "David S. Miller" <davem@...emloft.net>, Jesper Dangaard Brouer <brouer@...hat.com>, "Lorenz Bauer" <lmb@...udflare.com>, Andrey Ignatov <rdna@...com>, Networking <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org> Subject: Re: [PATCH bpf-next 1/4] xdp: Support specifying expected existing program when attaching XDP On Mon, 30 Mar 2020 16:41:46 +0100 Edward Cree wrote: > On 29/03/2020 21:23, Andrii Nakryiko wrote: > > But you can't say the same about other XDP applications that do not > > use libxdp. So will your library come with a huge warning > What about a system-wide policy switch to decide whether replacing/ > removing an XDP program without EXPECTED_FD is allowed? That way > the sysadmin gets to choose whether it's the firewall or the packet > analyser that breaks, rather than baking a policy into the design. > Then libxdp just needs to say in the README "you might want to turn > on this switch". Or maybe it defaults to on, and the other program > has to talk you into turning it off if it wants to be 'ill-behaved'. > Either way, affected users will be driven to the kernel's > documentation for the policy switch, where we can tell them whatever > we think they need to know. I had the same thought. But then again all samples specify IF_NOEXIST AFAICS, and users will file bugs for replacing other apps. IMHO it's kind of a responsibility of the distro to make sure that apps it packages don't break each other. The mechanism to be well behaved exists, it's the sad reality of backward compatibility that we can't just make it enforced by default (IF_NOEXIST vs ALLOW_REPLACE). So adding a knob seems perfectly reasonable, but perhaps we should see one or two examples of apps actually getting it wrong before adding a knob?
Powered by blists - more mailing lists