Why is that so complicated?

Posted Oct 27, 2025 23:28 UTC (Mon) by muase (subscriber, #178466)
Parent article: BPF signing LSM hook change rejected

That is probably a stupid question, and there are most-certainly good reasons for that, but: why is that so complicated?

After all, at least in the beginning, BPF programs are just bytes? So why can't we just read the program from disk into (kernel) memory, validate the signature over this blob, and then do the magic afterwards (per-version translation, relocation, ...)?

AFAIK the problem is probably not new – with dylibs, relocatable linkage, jar-files or other jittery stuff, and app-bundles, you already have payloads that are modified during runtime in ways the signature cannot cover. The solution is usually that you sign the precursor, because every runtime modification is either done by the OS (=trusted), or by the executed code from the precursor itself (=trusted).

So – what am I missing here? Where is my error? :D

Why is that so complicated?

Posted Oct 28, 2025 8:37 UTC (Tue) by taladar (subscriber, #68407) [Link] (1 responses)

I would assume that the per version and relocation code is implemented in user space only at this point and they do not want that complexity in kernel.

But yes, that was my first thought too, your approach seems much simpler as far as signature verification is concerned.

Why is that so complicated?

Posted Oct 28, 2025 11:55 UTC (Tue) by daroc (editor, #160859) [Link]

Yes, that's more or less correct. Depending on exactly what your criteria for "in the kernel" are, it could be argued that the loader programs are what you're proposing — they do the relocations "in the kernel" using BPF.

But there has also been some work toward doing relocations in the kernel without using BPF; this is still an evolving area, and I would not be terribly surprised to see more related patch sets (and arguments) in the future.

Why is that so complicated?

Posted Oct 28, 2025 16:11 UTC (Tue) by aszs (subscriber, #50252) [Link] (5 responses)

AFAICT the complexity exists because the BPF folks want to support BPF programs dynamically generated at runtime by trusted user-space tools, e.g for tracing and networking (bpffilter, cilium). My impression is their resistance to this patchset is at least partially motivated by the unstated assumption that it would make it too easy and tempting for admins to configure their systems in a way that prevents these use-cases.

Why is that so complicated?

Posted Oct 28, 2025 18:47 UTC (Tue) by mathstuf (subscriber, #69389) [Link] (1 responses)

Isn't that an decision for an administrator to make though?

Why is that so complicated?

Posted Oct 28, 2025 20:21 UTC (Tue) by aszs (subscriber, #50252) [Link]

yeah, I think that's why it's unstated :)

Why is that so complicated?

Posted Oct 29, 2025 12:33 UTC (Wed) by hailfinger (subscriber, #76962) [Link] (1 responses)

Oooh, I see potential for regulation here, e.g. by cybersecurity insurance.
"You may only run or load code which is part of the SBOM. The SBOM must be complete and signed off in advance." Admins may be obliged to desist from any ad-hoc patching of the kernel or userspace, including dynamically generated code.
Dynamically generated code also is very valuable for attackers because there is no guarantee that all such code is preserved (including timestamps for when the code was active) for forensic purposes. That may also be a strong motivation to prevent such use-cases.

Why is that so complicated?

Posted Oct 30, 2025 10:00 UTC (Thu) by taladar (subscriber, #68407) [Link]

That would probably run into the issue of JIT compilers again.

Why is that so complicated?

Posted Oct 30, 2025 10:32 UTC (Thu) by jbarns231 (subscriber, #152627) [Link]

Pretty much 99% of use cases in eBPF need relocations which are done by a loader, for example, even just using a BPF map in a program cannot work if the signature validation is purely over static bytecode. This means the entire ecosystem will not be able to make use of this facility if the validation were entirely static. So this has nothing to do with admin or not.

Why is that so complicated?

Posted Oct 30, 2025 12:24 UTC (Thu) by jejb (guest, #6654) [Link]

> So – what am I missing here? Where is my error? :D

Nothing ... that's how both proposed patch sets validate the code.. The complexity of light skeletons is that they consist of two sets of bpf instructions: a loader and a program the loader relocates. Once the loader has run, the program is fully relocated and can be executed. Both patches produce separate hashes of the loader and program and then sign that combined hash. The only difference, and the crux of the argument is what information the security_bpf_prog_load, which is called before any bpf code executes, LSM hook receives to make the policy determination. In KP's scheme the signature is over the loader which contains the hash of the program and which verifies that hash at loader run time, so the security hook knows if the loader signature verifies but not if the program hash matches. With the other patch set both hashes are checked before the hook is called.