Jarkko Sakkinen <jar...@kernel.org> writes: > 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? >
Yup, Exactly. > 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/ > > Oooh. That would be very nice :) >> >> > 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
