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. 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? -blaise > > 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.
