netdev - Re: [PATCH bpf-next 0/5] libbpf: error reporting changes for v1.0

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: <CAEf4BzbAt8uGaTp4zec=okUwZ00y9-SLH8ahEQJVRQ7tHb=QDA@mail.gmail.com>
Date:   Mon, 24 May 2021 14:25:36 -0700
From:   Andrii Nakryiko <andrii.nakryiko@...il.com>
To:     Stanislav Fomichev <sdf@...gle.com>
Cc:     John Fastabend <john.fastabend@...il.com>,
        Toke Høiland-Jørgensen <toke@...hat.com>,
        Andrii Nakryiko <andrii@...nel.org>, bpf <bpf@...r.kernel.org>,
        Networking <netdev@...r.kernel.org>,
        Alexei Starovoitov <ast@...com>,
        Daniel Borkmann <daniel@...earbox.net>,
        Kernel Team <kernel-team@...com>
Subject: Re: [PATCH bpf-next 0/5] libbpf: error reporting changes for v1.0

On Mon, May 24, 2021 at 1:35 PM Stanislav Fomichev <sdf@...gle.com> wrote:
>
> On Mon, May 24, 2021 at 12:19 PM Andrii Nakryiko
> <andrii.nakryiko@...il.com> wrote:
> >
> > On Sun, May 23, 2021 at 11:36 PM John Fastabend
> > <john.fastabend@...il.com> wrote:
> > >
> > > Andrii Nakryiko wrote:
> > > > Implement error reporting changes discussed in "Libbpf: the road to v1.0"
> > > > ([0]) document.
> > > >
> > > > Libbpf gets a new API, libbpf_set_strict_mode() which accepts a set of flags
> > > > that turn on a set of libbpf 1.0 changes, that might be potentially breaking.
> > > > It's possible to opt-in into all current and future 1.0 features by specifying
> > > > LIBBPF_STRICT_ALL flag.
> > > >
> > > > When some of the 1.0 "features" are requested, libbpf APIs might behave
> > > > differently. In this patch set a first set of changes are implemented, all
> > > > related to the way libbpf returns errors. See individual patches for details.
> > > >
> > > > Patch #1 adds a no-op libbpf_set_strict_mode() functionality to enable
> > > > updating selftests.
> > > >
> > > > Patch #2 gets rid of all the bad code patterns that will break in libbpf 1.0
> > > > (exact -1 comparison for low-level APIs, direct IS_ERR() macro usage to check
> > > > pointer-returning APIs for error, etc). These changes make selftest work in
> > > > both legacy and 1.0 libbpf modes. Selftests also opt-in into 100% libbpf 1.0
> > > > mode to automatically gain all the subsequent changes, which will come in
> > > > follow up patches.
> > > >
> > > > Patch #3 streamlines error reporting for low-level APIs wrapping bpf() syscall.
> > > >
> > > > Patch #4 streamlines errors for all the rest APIs.
> > > >
> > > > Patch #5 ensures that BPF skeletons propagate errors properly as well, as
> > > > currently on error some APIs will return NULL with no way of checking exact
> > > > error code.
> > > >
> > > >   [0] https://docs.google.com/document/d/1UyjTZuPFWiPFyKk1tV5an11_iaRuec6U-ZESZ54nNTY
> > > >
> > > > Andrii Nakryiko (5):
> > > >   libbpf: add libbpf_set_strict_mode() API to turn on libbpf 1.0
> > > >     behaviors
> > > >   selftests/bpf: turn on libbpf 1.0 mode and fix all IS_ERR checks
> > > >   libbpf: streamline error reporting for low-level APIs
> > > >   libbpf: streamline error reporting for high-level APIs
> > > >   bpftool: set errno on skeleton failures and propagate errors
> > > >
> > >
> > > LGTM for the series,
> > >
> > > Acked-by: John Fastabend <john.fastabend@...il.com>
> >
> > Thanks, John!
> >
> > Toke, Stanislav, you cared about these aspects of libbpf 1.0 (by
> > commenting on the doc itself), do you mind also taking a brief look
> > and letting me know if this works for your use cases? Thanks!
>
> I took a quick look earlier today and everything looks good, thanks!

Great, thanks for looking.

> I'll try to enable strict mode in our codebase in the coming weeks to
> see how it goes.

Keep in mind, if you do libbpf_set_strict_mode(LIBBPF_STRICT_ALL) you
are automatically opting in for all the future "features", so for
production you might want to go conservative and start with specifying
explicitly LIBBPF_STRICT_DIRECT_ERRS | LIBBPF_STRICT_CLEAN_PTRS, and
then add more as you check that your code will handle new changes.