netdev - Re: [PATCH bpf-next 1/4] xdp: Support specifying expected existing program when attaching XDP

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: <20200330121315.38349e95@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
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?