linux-kernel - Re: [PATCH bpf-next] bpf: allow loading instructions from a fd

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: <20200720203326.z4jtrjv7gmtlzz57@ast-mbp.dhcp.thefacebook.com>
Date:   Mon, 20 Jul 2020 13:33:26 -0700
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     Matteo Croce <mcroce@...ux.microsoft.com>
Cc:     bpf@...r.kernel.org, linux-kernel@...r.kernel.org,
        Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Deven Bowers <deven.desai@...ux.microsoft.com>
Subject: Re: [PATCH bpf-next] bpf: allow loading instructions from a fd

On Thu, Jul 16, 2020 at 08:47:36PM +0200, Matteo Croce wrote:
> On Tue, Jul 14, 2020 at 7:31 PM Alexei Starovoitov
> <alexei.starovoitov@...il.com> wrote:
> >
> > On Mon, Jul 13, 2020 at 03:05:11PM +0200, Matteo Croce wrote:
> > > From: Matteo Croce <mcroce@...rosoft.com>
> > >
> > > Allow to load the BPF instructons from a file descriptor,
> > > other than a pointer.
> > >
> > > This is required by the Integrity Subsystem to validate the source of
> > > the instructions.
> > >
> > > In bpf_attr replace 'insns', which is an u64, to a union containing also
> > > the file descriptor as int.
> > > A new BPF_F_LOAD_BY_FD flag tells bpf_prog_load() to load
> > > the instructions from file descriptor and ignore the pointer.
> > >
> > > As BPF files usually are regular ELF files, start reading from the
> > > current file position, so the userspace can skip the ELF header and jump
> > > to the right section.
> >
> > That is not the case at all.
> > Have you looked at amount of work libbpf is doing with elf file before
> > raw instructions become suitable to be loaded by the kernel?
> 
> I see now what bpf_object__relocate() and all the *reloc* functions
> do, so it can't be done this way, I see.
> 
> A malicious BPF file can be as bad as a malicious binary. Let's say I
> want to assert code integrity for BPF files, what could be a viable
> option?
> Perhaps a signature in the object file as we do with modules?

It's a hard problem to solve.
Signing bpf programs was proposed in the past. It may work, but challenging
to implement, since even simplest programs are being modified by the user
space loader before kernel sees them. The signature would have to skip
all such instructions which makes the signature verification 'best effort'.
Some instructions won't be covered by signature (like ld_imm64 that points
to a map).