On Wed, Apr 23, 2025 at 10:12 AM James Bottomley <james.bottom...@hansenpartnership.com> wrote: > On Mon, 2025-04-21 at 13:12 -0700, Alexei Starovoitov wrote: > [...] > > Calling bpf_map_get() and > > map->ops->map_lookup_elem() from a module is not ok either. > > I don't understand this objection. The program just got passed in to > bpf_prog_load() as a set of attributes which, for a light skeleton, > directly contain the code as a blob and have the various BTF > relocations as a blob in a single element array map. I think everyone > agrees that the integrity of the program would be compromised by > modifications to the relocations, so the security_bpf_prog_load() hook > can't make an integrity determination without examining both. If the > hook can't use the bpf_maps.. APIs directly is there some other API it > should be using to get the relocations, or are you saying that the > security_bpf_prog_load() hook isn't fit for purpose and it should be > called after the bpf core has loaded the relocations so they can be > provided to the hook as an argument? > > The above, by the way, is independent of signing, because it applies to > any determination that might be made in the security_bpf_prog_load() > hook regardless of purpose.
I've also been worrying that some of the unspoken motivation behind the objection is simply that Hornet is not BPF. If/when we get to a point where Hornet is sent up to Linus and Alexei's objection to the Hornet LSM inspecting BPF maps stands, it seems as though *any* LSM, including BPF LSMs, would need to be prevented from accessing BPF maps. I'm fairly certain no one wants to see it come to that. -- paul-moore.com
