On Fri, Jan 10, 2025 at 3:27 PM Blaise Boscaccy <bboscaccy@xxxxxxxxxxxxxxxxxxx> wrote: > > Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> writes: > > > On Thu, Jan 9, 2025 at 1:47 PM Blaise Boscaccy > > <bboscaccy@xxxxxxxxxxxxxxxxxxx> 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. > 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.
