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]
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