Jarkko Sakkinen jarkko@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:
- 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-jarkko@kernel...
Oooh. That would be very nice :)
- 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