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]

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.