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

Message-ID: <CAFnufp2_vwyCR95Z=Dkd9XXRO8CTQ5NZtNPdJL+1oPRurv-feQ@mail.gmail.com>
Date:   Thu, 16 Jul 2020 20:47:36 +0200
From:   Matteo Croce <mcroce@...ux.microsoft.com>
To:     Alexei Starovoitov <alexei.starovoitov@...il.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 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?

Regards,
-- 
per aspera ad upstream