On Tue, Jan 14, 2025 at 10:24 AM Blaise Boscaccy <bboscaccy@xxxxxxxxxxxxxxxxxxx> wrote: > > 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? Looks like you're reading the code without actually trying to run it. > >> 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? Correct. > Ancillary, would there be opposition to passing the symbol table into > the kernel via the light skeleton? Yes, if by "symbol table" you mean ELF symbol table. > 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? gate keeper concept is the sign verification by 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. The idea was to add LSM-like hook in the prog loading path where "gate keeper" bpf program loaded early during the boot (without any user space) would validate the signature attached to lskel and whatever other prog attributes it might need. KP proposed: https://lore.kernel.org/bpf/CACYkzJ6xSk_DHO+3JoCYpGrXjFkk9v-LOSWW0=0KLwAj1Gc0SA@xxxxxxxxxxxxxx/ iirc John had the whole design proposal written somewhere, but I cannot find it now. John, can you summarize how gate keeper bpf prog would work?
