linux-kernel - Re: Kernel 5.5.4 build fail for BPF-selftests with latest LLVM

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] [day] [month] [year] [list]

Message-ID: <20200220191845.u62nhohgzngbrpib@ast-mbp>
Date:   Thu, 20 Feb 2020 11:18:46 -0800
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     "Bird, Tim" <Tim.Bird@...y.com>
Cc:     Jesper Dangaard Brouer <brouer@...hat.com>,
        shuah <shuah@...nel.org>,
        Daniel Díaz <daniel.diaz@...aro.org>,
        Andrii Nakryiko <andrii.nakryiko@...il.com>,
        Andrii Nakryiko <andriin@...com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        BPF-dev-list <bpf@...r.kernel.org>,
        Daniel Borkmann <borkmann@...earbox.net>,
        David Miller <davem@...emloft.net>,
        LKML <linux-kernel@...r.kernel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Anders Roxell <anders.roxell@...aro.org>,
        Toke Høiland-Jørgensen <toke@...hat.com>,
        "open list:KERNEL SELFTEST FRAMEWORK" 
        <linux-kselftest@...r.kernel.org>
Subject: Re: Kernel 5.5.4 build fail for BPF-selftests with latest LLVM

On Thu, Feb 20, 2020 at 05:41:51PM +0000, Bird, Tim wrote:
> 
> So - do the BPF developers add new instructions to the virtual machine, that then
> have to be added to both the compiler and the executor (VM implementation)?

Right. New instructions are added to the kernel and llvm at the same time. The
kernel and llvm release cadence and process are different which complicates it
for us.

> It sounds like the compiler support and executor support is done in concert, and
> that patches are at least accepted upstream (but possibly are not yet available in
> a compiler release) for the compiler side.  What about the Linux kernel side?  Is the
> support for a new instruction only in non-released kernels (say, in the BPF development
> tree), or could it potentially be included in a released kernel, before the compiler
> with matching support is released?  What would happen if a bug was found, and
> compiler support for the instruction was delayed?  

As with all chicken-and-egg problems the feature has to land in one of the
repos first. That was one of the reasons llvm community switched to mono repo
to avoid clang vs llvm conflicts. The kernel and llvm are not going to be in a
single repo, so we have to orchestrate the landing. Most of the time it's easy,
because we maintain both kernel and llvm components. But in some cases it's
very difficult. For example we've delayed landing kernel and libbpf patches by
about six month, since we couldn't get an agreement on how the feature has to
be implemented in clang.

> I suppose that this would only
> mean that the executor supported an instruction that never appeared in a compiled
> BPF program? Is that right?

The answer is yes. It is the case that the kernel supports certain bpf
instructions, but llvm doesn't know how to emit them. But it has nothing to do
with landing of features and release cadence.