On Mon, Apr 21, 2025 at 4:13 PM Alexei Starovoitov <alexei.starovoi...@gmail.com> wrote: > On Wed, Apr 16, 2025 at 10:31 AM Blaise Boscaccy > <bbosca...@linux.microsoft.com> wrote: > > > > > Hacking into bpf internal objects like maps is not acceptable. > > > > We've heard your concerns about kern_sys_bpf and we agree that the LSM > > should not be calling it. The proposal in this email should meet both of > > our needs > > https://lore.kernel.org/bpf/874iypjl8t....@microsoft.com/
... > Calling bpf_map_get() and > map->ops->map_lookup_elem() from a module is not ok either. A quick look uncovers code living under net/ which calls into these APIs. > lskel doing skel_map_freeze is not solving the issue. > It is still broken from TOCTOU pov. > freeze only makes a map readonly to user space. > Any program can still read/write it. When you say "any program" you are referring to any BPF program loaded into the kernel, correct? At least that is my understanding of "freezing" a BPF map, while userspace is may be unable to modify the map's contents, it is still possible for a BPF program to modify it. If I'm mistaken, I would appreciate a pointer to a correct description of map freezing. Assuming the above is correct, that a malicious bit of code running in kernel context could cause mischief, isn't a new concern, and in fact it is one of the reasons why Hornet is valuable. Hornet allows admins/users to have some assurance that the BPF programs they load into their system come from a trusted source (trusted not to intentionally do Bad Things in the kernel) and haven't been modified to do Bad Things (like modify lskel maps). > One needs to think of libbpf equivalent loaders in golang and rust. ... > systemd is also using an old style bpf progs written in bpf assembly. I've briefly talked with Blaise about the systemd issue in particular, and I believe there are some relatively easy ways to work around the ELF issue in the current version of Hornet. I know Blaise is tied up for the next couple of days on another fire, but I'm sure the next revision will have a solution for this. > Introduction of lskel back in 2021 was the first step towards signing > (as the commit log clearly states). > lskel approach is likely a solution for a large class of bpf users, > but not for all. It won't work for bpftrace and bcc. As most everyone on the To/CC line already knows, Linux kernel development is often iterative. Not only is it easier for the kernel devs to develop and review incremental additions to functionality, it also enables a feedback loop where users can help drive the direction of the functionality as it is built. I view Hornet as an iterative improvement, building on the lskel concept, that helps users towards their goal of load time verification of code running inside the kernel. Hornet, as currently described, may not be the solution for everything, but it can be the solution for something that users are desperately struggling with today and as far as I'm concerned, that is a good thing worth supporting. -- paul-moore.com
