| Message ID | 20250321164537.16719-1-bboscaccy@linux.microsoft.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Introducing Hornet LSM | expand |
On Fri, Mar 21, 2025 at 12:45 PM Blaise Boscaccy <bboscaccy@linux.microsoft.com> wrote: > > This patch series introduces the Hornet LSM. > > Hornet takes a simple approach to light-skeleton-based eBPF signature > verification. Signature data can be easily generated for the binary > data that is generated via bpftool gen -L. This signature can be > appended to a skeleton executable via scripts/sign-ebpf. Hornet checks > the signature against a binary buffer containing the lskel > instructions that the loader maps use. Maps are frozen to prevent > TOCTOU bugs where a sufficiently privileged user could rewrite map > data between the calls to BPF_PROG_LOAD and > BPF_PROG_RUN. Additionally, both sparse-array-based and > fd_array_cnt-based map fd arrays are supported for signature > verification. > > Blaise Boscaccy (4): > security: Hornet LSM > hornet: Introduce sign-ebpf > hornet: Add an example lskel data extactor script > selftests/hornet: Add a selftest for the hornet LSM Thanks Blaise, I noticed a few minor things, but nothing critical. As I understand it, you'll be presenting Hornet at LSFMMBPF next week? Assuming that's the case, I'm going to hold off on reviewing this until we hear how that went next week; please report back after the conference. However, to be clear, the Hornet LSM proposed here seems very reasonable to me and I would have no conceptual objections to merging it upstream. Based on off-list discussions I believe there is a lot of demand for something like this, and I believe many people will be happy to have BPF signature verification in-tree.
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. > verification. Signature data can be easily generated for the binary s/easily// Useless word having no measure. > 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: 1. What is in exact terms "signature data"? 2. What does "bpftool gen -L" do? This feedback maps to other examples too in the cover letter. BR, Jarkko
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. 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. 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. 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 ;)
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? :) > 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 ;)
On Sat, Mar 22, 2025 at 04:44:13PM -0400, Paul Moore 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 :) Yeah, I don't think there is anything largely wrong in the feature itself but it speaks language that would fit to eBPF subsystem list, not here :-) I.e. assume only very basic knowledge of eBPF and explain what stuff mentioned actually does. Like bpftool statement should be opened up fully. > > 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. I got some grip but the term only should be used IMHO in the commit message, if it is defined at first :-) > > 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. 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. 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. When you speak about corresponding lskel program what does that program contain? Is it some kind of new version of the same program with modifications, or? I neither did not know what BPF CO-RE is but I googled it ;-) > > 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 ;) Sure... Thanks for the explanations! > > -- > paul-moore.com BR, Jarkko
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