On 5/14/21 2:36 AM, Alexei Starovoitov wrote: [...]
This is a first step towards signed bpf programs and the third approach of that kind. The first approach was to bring libbpf into the kernel as a user-mode-driver. The second approach was to invent a new file format and let kernel execute that format as a sequence of syscalls that create maps and load programs. This third approach is using new type of bpf program instead of inventing file format. 1st and 2nd approaches had too many downsides comparing to this 3rd and were discarded after months of work. To make it work the following new concepts are introduced: 1. syscall bpf program type A kind of bpf program that can do sys_bpf and sys_close syscalls. It can only execute in user context. 2. FD array or FD index. Traditionally BPF instructions are patched with FDs. What it means that maps has to be created first and then instructions modified which breaks signature verification if the program is signed. Instead of patching each instruction with FD patch it with an index into array of FDs. That makes the program signature stable if it uses maps. 3. loader program that is generated as "strace of libbpf". When libbpf is loading bpf_file.o it does a bunch of sys_bpf() syscalls to load BTF, create maps, populate maps and finally load programs. Instead of actually doing the syscalls generate a trace of what libbpf would have done and represent it as the "loader program". The "loader program" consists of single map and single bpf program that does those syscalls. Executing such "loader program" via bpf_prog_test_run() command will replay the sequence of syscalls that libbpf would have done which will result the same maps created and programs loaded as specified in the elf file. The "loader program" removes libelf and majority of libbpf dependency from program loading process.
More of a general question since afaik from prior discussion it didn't came up. I think conceptually, it's rather weird to only being able to execute the loader program which is later also supposed to do signing through the BPF_PROG_TEST_RUN aka our _testing_ infrastructure. Given it's not mentioned in future steps, is there anything planned before it becomes uapi and fixed part of skeleton (in particular the libbpf bpf_load_and_run() helper officially calling into the skel_sys_bpf(BPF_PROG_TEST_RUN, &attr, sizeof(attr))) on this regard or is the BPF_PROG_TEST_RUN really supposed to be the /main/ interface going forward; what's the plan on this?
4. light skeleton Instead of embedding the whole elf file into skeleton and using libbpf to parse it later generate a loader program and embed it into "light skeleton". Such skeleton can load the same set of elf files, but it doesn't need libbpf and libelf to do that. It only needs few sys_bpf wrappers. Future steps: - support CO-RE in the kernel. This patch set is already too big, so that critical feature is left for the next step. - generate light skeleton in golang to allow such users use BTF and all other features provided by libbpf - generate light skeleton for kernel, so that bpf programs can be embeded in the kernel module. The UMD usage in bpf_preload will be replaced with such skeleton, so bpf_preload would become a standard kernel module without user space dependency. - finally do the signing of the loader program. The patches are work in progress with few rough edges.
Thanks a lot, Daniel
