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. 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'. Also there were prototype patches to add signature checking on top of the light skeleton, and long discussions on the list and conferences about 'gate keeper' concept.
