Alexei Starovoitov <alexei.starovoi...@gmail.com> writes: > On Fri, Apr 11, 2025 at 5:30 PM Matteo Croce <technobo...@gmail.com> wrote: >> >> Il giorno sab 12 apr 2025 alle ore 02:19 Alexei Starovoitov >> <alexei.starovoi...@gmail.com> ha scritto: >> >> Similar to what I proposed here? >> >> https://lore.kernel.org/bpf/20211203191844.69709-2-mcr...@linux.microsoft.com/ > ... >> @@ -1346,6 +1346,8 @@ union bpf_attr { >> __aligned_u64 fd_array; /* array of FDs */ >> __aligned_u64 core_relos; >> __u32 core_relo_rec_size; /* sizeof(struct bpf_core_relo) */ >> + __aligned_u64 signature; /* instruction's signature */ >> + __u32 sig_len; /* signature size */ > > Well, yeah, two fields are obvious. > But not like that link from 2021. > KP proposed them a year later in 2022 on top of lskel > which was much closer to be acceptable. > We need to think it through and complete the work, > since there are various ways to do it. > For example, lskel has a map and a prog. > A signature in a prog may cover both, but > not necessary it's a good design. > A signature for the map plus a signature for the prog > that is tied to a map might be a better option. > At map creation time the contents can be checked, > the map is frozen, and then the verifier can proceed > with prog's signature checking. > lskel doesn't support all the bpf feature yet, so we need > to make sure that the signature verification process > is extensible when lskel gains new features. > > Attaching was also brought up at lsfmm. > Without checking the attach point the whole thing is quite > questionable from security pov.
That statement is quite questionable. Yes, IIRC you brought that up. And again, runtime policy enforcement has nothing to do with proving code provenance. They are completely independent concerns. That would be akin to saying that having locks on a door is questionable without having surveillance cameras installed.
