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]

Date:   Fri, 22 Jul 2022 14:23:46 -0700
From:   "Paul E. McKenney" <paulmck@...nel.org>
To:     Daniel Borkmann <daniel@...earbox.net>
Cc:     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 10:17:57PM +0200, Daniel Borkmann wrote:
> On 7/22/22 8:06 PM, Paul E. McKenney wrote:
> > This patch updates bpf_design_QA.rst to clarify that the ability to
> > attach a BPF program to a given function in the kernel does not make
> > that function become part of the Linux kernel's ABI.
> > 
> > Signed-off-by: Paul E. McKenney <paulmck@...nel.org>
> > ---
> >   Documentation/bpf/bpf_design_QA.rst | 12 ++++++++++++
> >   1 file changed, 12 insertions(+)
> > 
> > diff --git a/Documentation/bpf/bpf_design_QA.rst b/Documentation/bpf/bpf_design_QA.rst
> > index 2ed9128cfbec8..46337a60255e9 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 kernel functions is an ABI?
> 
> small nit, I'd change to: Attaching to arbitrary kernel functions [...]
> 
> 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?

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.