Re: [POC][RFC][PATCH] bpf: in-kernel bpf relocations on raw elf files

[Blaise Boscaccy <bboscaccy@linux.microsoft.com>]

Alexei Starovoitov <alexei.starovoitov@gmail.com> writes:

> On Fri, Jan 10, 2025 at 3:27 PM Blaise Boscaccy
> <bboscaccy@linux.microsoft.com> wrote:
>>
>> Alexei Starovoitov <alexei.starovoitov@gmail.com> writes:
>>
>> > On Thu, Jan 9, 2025 at 1:47 PM Blaise Boscaccy
>> > <bboscaccy@linux.microsoft.com> wrote:
>> >>
>> >>
>> >> This is a proof-of-concept, based off of bpf-next-6.13. The
>> >> implementation will need additional work. The goal of this prototype was
>> >> to be able load raw elf object files directly into the kernel and have
>> >> the kernel perform all the necessary instruction rewriting and
>> >> relocation calculations. Having a file descriptor tied to a bpf program
>> >> allowed us to have tighter integration with the existing LSM
>> >> infrastructure. Additionally, it opens the door for signature and provenance
>> >> checking, along with loading programs without a functioning userspace.
>> >>
>> >> The main goal of this RFC is to get some feedback on the overall
>> >> approach and feasibility of this design.
>> >
>> > It's not feasible.
>> >
>> > libbpf.a is mainly a loader of bpf ELF files.
>> > There is a specific format of ELF files, a convention on section names,
>> > a protocol between LLVM and libbpf, etc.
>> > These things are stable api from libbpf 1.x pov.
>> > There is a chance that they will change in libbpf 2.x.
>> > There are no plans to do so now, but because it's all user space
>> > there is room for changes.
>> > The kernel doesn't have such luxury.
>> > Hence we cannot copy paste libbpf into the kernel and make
>> > it parse the same ELF data, since it will force us to support
>> > this exact format forever.
>> > Hence the design is not feasible.
>> >
>>
>> Noted.
>>
>> > This was discussed multiple times on the list and at LSFMMBPF, LPC
>> > conferences over the years.
>> >
>> > But if the real goal of these patches to:
>> >
>> >> open the door for signature and provenance
>> >> checking, along with loading programs without a functioning userspace.
>> >
>> > then please take a look at the light skeleton.
>> > There is an existing mechanism to load bpf ELF files without libbpf
>> > and without user space.
>> > Search for 'bpftool gen skeleton -L'.
>>
>> Our goal is to have verifiable ebpf programs that are portable across
>> multiple kernels. I looked into light skels, it appears that all the
>> instruction relocations are calculated during skeleton generation and a
>> static instruction buffer containing those fixed relocation results is
>> passed into the kernel? For some relocs, those values would be
>> deterministic, making that a non-issue. For others that rely on btf data
>> or kernel symbols those might not be portable anymore.
>
> Specifically?
> lskel preservers CORE. BTF based relocations are done by the kernel.
>

It looks like they are done in the kernel and not necessarily by the
kernel? The relocation logic is emitted by emit_relo* functions during
skeleton generation and the ebpf program is responsible for relocating
itself at runtime, correct? Meaning that the same program is going to
appear very different to the kernel if it's loaded via lskel or libbpf?

>> Would it be amenable to possibly alter the light skeleton generation
>> code to pass btf and some other metadata into the kernel along with
>> instructions or are you trying to avoid any sort of fixed dependencies
>> on anything in the kernel other than the bpf instrucion set itself?
>
> BTF is passed in the lskel.
> There are few relocation-like things that lskel doesn't support.
> One example is __kconfig, but so far there was no request to support that.
> This can be added when needs arise.

Yes, I ran into the lskel generator doing fun stuff like:

libbpf: extern (kcfg) 'LINUX_KERNEL_VERSION': set to 0x6080c

Which caused some concern. Is the feature set for the light skeleton
generator and the feature set for libbpf is expected to drift, whereas
new features will get added to libbpf but they will get added to the
lskel generator if and only if someone requests support for it?
Ancillary, would there be opposition to passing the symbol table into
the kernel via the light skeleton?

I couldn't find anything tangible related to a 'gate keeper' on the bpf
mailing list and haven't attended the conferences.  Are you going to
shoot down all attempts at code signing of eBPF programs in the kernel?
Internally, we want to cryptographically verify all running kernel code
with a proper root of trust. Additionally we've been looking into
NIST-800-172 requirements. That's currently making eBPF a no-go.  Root
and userspace are not trusted either in these contexts, making userspace
gate-keeper daemons unworkable.