On Sat, Mar 22, 2025 at 04:48:14PM -0400, Paul Moore wrote:
On Sat, Mar 22, 2025 at 4:44 PM Paul Moore paul@paul-moore.com wrote:
On Sat, Mar 22, 2025 at 1:22 PM Jarkko Sakkinen jarkko@kernel.org wrote:
On Fri, Mar 21, 2025 at 09:45:02AM -0700, Blaise Boscaccy wrote:
This patch series introduces the Hornet LSM.
Hornet takes a simple approach to light-skeleton-based eBPF signature
Can you define "light-skeleton-based" before using the term.
This is the first time in my life when I hear about it.
I was in the same situation a few months ago when I first heard about it :)
Blaise can surely provide a much better answer that what I'm about to write, but since Blaise is going to be at LSFMMBPF this coming week I suspect he might not have a lot of time to respond to email in the next few days so I thought I would do my best to try and answer :)
An eBPF "light skeleton" is basically a BPF loader program and while I'm sure there are several uses for a light skeleton, or lskel for brevity, the single use case that we are interested in here, and the one that Hornet deals with, is the idea of using a lskel to enable signature verification of BPF programs as it seems to be the one way that has been deemed acceptable by the BPF maintainers.
Once again, skipping over a lot of details, the basic idea is that you take your original BPF program (A), feed it into a BPF userspace tool to encapsulate the original program A into a BPF map and generate a corresponding light skeleton BPF program (B), and then finally sign the resulting binary containing the lskel program (B) and map corresponding to the original program A.
Forgive me, I mixed up my "A" and "B" above :/
At runtime, the lskel binary is loaded into the kernel, and if Hornet is enabled, the signature of both the lskel program A and original program B is verified.
... and I did again here
If the signature verification passes, lskel program A performs the necessary BPF CO-RE transforms on BPF program A stored in the BPF map and then attempts to load the original BPF program B, all from within the kernel, and with the map frozen to prevent tampering from userspace.
... and once more here because why not? :)
No worries I was able to decipher this :-)
Hopefully that helps fill in some gaps until someone more knowledgeable can provide a better answer and/or correct any mistakes in my explanation above ;)
-- paul-moore.com
BR, Jarkko