On Fri, Apr 4, 2025 at 2:56 PM Blaise Boscaccy
<bbosca...@linux.microsoft.com> wrote:
> +
> +static int hornet_find_maps(struct bpf_prog *prog, struct hornet_maps *maps)
> +{
> + struct bpf_insn *insn = prog->insnsi;
> + int insn_cnt = prog->len;
> + int i;
> + int err;
> +
> + for (i = 0; i < insn_cnt; i++, insn++) {
> + if (insn[0].code == (BPF_LD | BPF_IMM | BPF_DW)) {
> + switch (insn[0].src_reg) {
> + case BPF_PSEUDO_MAP_IDX_VALUE:
> + case BPF_PSEUDO_MAP_IDX:
> + err = add_used_map(maps, insn[0].imm);
> + if (err < 0)
> + return err;
> + break;
> + default:
> + break;
> + }
> + }
> + }
...
> + if (!map->frozen) {
> + attr.map_fd = fd;
> + err = kern_sys_bpf(BPF_MAP_FREEZE, &attr,
> sizeof(attr));
Sorry for the delay. Still swamped after conferences and the merge window.
Above are serious layering violations.
LSMs should not be looking that deep into bpf instructions.
Calling into sys_bpf from LSM is plain nack.
The verification of module signatures is a job of the module loading process.
The same thing should be done by the bpf system.
The signature needs to be passed into sys_bpf syscall
as a part of BPF_PROG_LOAD command.
It probably should be two new fields in union bpf_attr
(signature and length),
and the whole thing should be processed as part of the loading
with human readable error reported back through the verifier log
in case of signature mismatch, etc.
What LSM can do in addition is to say that if the signature is not
specified in the prog_load command then deny such request outright.
bpf syscall itself will deny program loading if signature is incorrect.
