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@xxxxxxxxxxxxxx> wrote: > > > > On Sat, Mar 22, 2025 at 1:22 PM Jarkko Sakkinen <jarkko@xxxxxxxxxx> 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
