On Tue, Jul 14, 2020 at 7:31 PM Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > > On Mon, Jul 13, 2020 at 03:05:11PM +0200, Matteo Croce wrote: > > From: Matteo Croce <mcroce@xxxxxxxxxxxxx> > > > > 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
