netdev - Re: [PATCH bpf 2/2] bpf: Update bpf_design_QA.rst to clarify that attaching to functions is not ABI

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: <Yt6JdYSitC6e2lLk@casper.infradead.org>
Date:   Mon, 25 Jul 2022 13:15:49 +0100
From:   Matthew Wilcox <willy@...radead.org>
To:     "Paul E. McKenney" <paulmck@...nel.org>
Cc:     Daniel Borkmann <daniel@...earbox.net>, bpf@...r.kernel.org,
        netdev@...r.kernel.org, linux-doc@...r.kernel.org, corbet@....net,
        ast@...nel.org, andrii@...nel.org, kafai@...com,
        songliubraving@...com, yhs@...com, john.fastabend@...il.com,
        kpsingh@...nel.org, kernel-team@...com
Subject: Re: [PATCH bpf 2/2] bpf: Update bpf_design_QA.rst to clarify that
 attaching to functions is not ABI

On Fri, Jul 22, 2022 at 02:23:46PM -0700, Paul E. McKenney wrote:
> On Fri, Jul 22, 2022 at 10:17:57PM +0200, Daniel Borkmann wrote:
> > Otherwise I think this could be a bit misunderstood, e.g. most of the networking
> > programs (e.g. XDP, tc, sock_addr) have a fixed framework around them where
> > attaching programs is part of ABI.
> 
> Excellent point, thank you!
> 
> Apologies for the newbie question, but does BTF_ID() mark a function as
> ABI from the viewpoing of a BPF program calling that function, attaching
> to that function, or both?  Either way, is it worth mentioning this
> in this QA entry?

Not necessarily.  For example, __filemap_add_folio has a BTF_ID(), but
it is not ABI (it's error injection).

> The updated patch below just adds the "arbitrary".
> 
> 							Thanx, Paul
> 
> ------------------------------------------------------------------------
> 
> commit 89659e20d11fc1350f5881ff7c9687289806b2ba
> Author: Paul E. McKenney <paulmck@...nel.org>
> Date:   Fri Jul 22 10:52:05 2022 -0700
> 
>     bpf: Update bpf_design_QA.rst to clarify that attaching to functions is not ABI
>     
>     This patch updates bpf_design_QA.rst to clarify that the ability to
>     attach a BPF program to an arbitrary function in the kernel does not
>     make that function become part of the Linux kernel's ABI.
>     
>     [ paulmck: Apply Daniel Borkmann feedback. ]
>     
>     Signed-off-by: Paul E. McKenney <paulmck@...nel.org>
> 
> diff --git a/Documentation/bpf/bpf_design_QA.rst b/Documentation/bpf/bpf_design_QA.rst
> index 2ed9128cfbec8..a06ae8a828e3d 100644
> --- a/Documentation/bpf/bpf_design_QA.rst
> +++ b/Documentation/bpf/bpf_design_QA.rst
> @@ -279,3 +279,15 @@ cc (congestion-control) implementations.  If any of these kernel
>  functions has changed, both the in-tree and out-of-tree kernel tcp cc
>  implementations have to be changed.  The same goes for the bpf
>  programs and they have to be adjusted accordingly.
> +
> +Q: Attaching to arbitrary kernel functions is an ABI?
> +-----------------------------------------------------
> +Q: BPF programs can be attached to many kernel functions.  Do these
> +kernel functions become part of the ABI?
> +
> +A: NO.
> +
> +The kernel function prototypes will change, and BPF programs attaching to
> +them will need to change.  The BPF compile-once-run-everywhere (CO-RE)
> +should be used in order to make it easier to adapt your BPF programs to
> +different versions of the kernel.