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.
