On Mon, Mar 31, 2025 at 01:57:15PM -0700, Blaise Boscaccy wrote: > There are two flavors of skeletons, normal skeletons, and light > skeletons. Normal skeletons utilize relocation logic that lives in > libbpf, and the relocations/instruction rewriting happen in userspace. > The second flavor, light skeletons, uses a small eBPF program that > contains the relocation lookup logic. As it's running in in the kernel, > it unpacks the target program, peforms the instruction rewriting, and > loads the target program. Light skeletons are currently utilized for > some drivers, and BPF_PRELOAD functionionality since they can operate > without userspace. > > Light skeletons were recommended on various mailing list discussions as > the preffered path to performing signature verification. There are some > PoCs floating around that used light-skeletons in concert with > fs-verity/IMA and eBPF LSMs. We took a slightly different approach to > Hornet, by utilizing the existing PCKS#7 signing scheme that is used for > kernel modules.
Right, because in the normal skeletons relocation logic remains unsigned? I have to admit I don't fully cope how the relocation process translates into eBPF program but I do get how it is better for signatures if it does :-) > > >> verification. Signature data can be easily generated for the binary > > > > s/easily// > > > > Useless word having no measure. > > > > Ack, thanks. > > > >> data that is generated via bpftool gen -L. This signature can be > > > > I have no idea what that command does. > > > > "Signature data can be generated for the binary data as follows: > > > > bpftool gen -L > > > > <explanation>" > > > > Here you'd need to answer to couple of unknowns: > > > > 1. What is in exact terms "signature data"? > > That is a PKCS#7 signature of a data buffer containing the raw > instructions of an eBPF program, followed by the initial values of any > maps used by the program. Got it, thanks. This motivates to refine my TPM2 asymmetric keys series so that TPM2 could anchor these :-) https://lore.kernel.org/linux-integrity/20240528210823.28798-1-jar...@kernel.org/ > > > 2. What does "bpftool gen -L" do? > > > > eBPF programs often have 2 parts. An orchestrator/loader program that > provides load -> attach/run -> i/o -> teardown logic and the in-kernel > program. > > That command is used to generate a skeleton which can be used by the > orchestrator prgoram. Skeletons get generated as a C header file, that > contains various autogenerated functions that open and load bpf programs > as decribed above. That header file ends up being included in a > userspace orchestrator program or possibly a kernel module. I did read the man page now too, but thanks for the commentary! > > > This feedback maps to other examples too in the cover letter. > > > > BR, Jarkko > > > I'll rework this with some definitions of the eBPF subsystem jargon > along with your suggestions. Yeah, you should be able to put the gist a factor better to nutshell :-) > > -blaise BR, Jarkko
