Add kfunc/helper <-> program type exceptions

[dylandreimerink]

For both helper functions and kfuncs we try to model the kernels approach of which functions can be used from which program types. Usually you start with no functions allowed and gradually add more. However, the verifier can also implement logic to effectively block the usage of helpers / kfuncs for certain program types. This PR add notation to our data files so we can model this same sort of exception on top of the normal mapping and applies this to all cases defined in check_map_prog_compatibility

[dylandreimerink]

@AliGhaffarian please check if this matches what you had in mind

[AliGhaffarian]

Can we exclude program types from helper functions too?
Currently, BPF_PROG_TYPE_TRACING is still in the bpf_spin_lock.md.

Or instead of having a exclude field for functions themselves, maybe can go through each helper function and for each one, check which program types have the current helper function excluded, this will remove the need to have exclusion for both program types and functions in the data file.
This approach looks something like this

for helper_function in helper_funcs:
	exclusions = []
	for prog_type in prog_types:
		if helper_function in prog_type.exclusions:
			exclusions.append(prog_type)

I can put the time to implement it, using your patches as reference. it would take some time as i'm not very familiar with golang though.

[dylandreimerink]

Currently, BPF_PROG_TYPE_TRACING is still in the bpf_spin_lock.md

Yes. But oddly enough BPF_PROG_TYPE_TRACING is not considered a tracing program according to is_tracing_prog_type and so would be allowed as far as I can see? Unless there is yet another bit of logic somewhere that blocks it.

I have not yet tried using spinlocks in fentry/fexit programs yet to see what happens.

[dylandreimerink]

Just tried it, seems like you can.

#include "vmlinux.h"
#include "bpf_helpers.h"
#include "bpf_tracing.h"

struct data
{
    int data;
    struct bpf_spin_lock lock;
};

struct
{
    __uint(type, BPF_MAP_TYPE_HASH);
    __uint(max_entries, 1024);
    __type(key, __u32);
    __type(value, struct data);
} test_map SEC(".maps");

SEC("fentry/security_inode_getattr")
int BPF_PROG(d_path_check_rdonly_mem, struct path *path, struct kstat *stat,
             __u32 request_mask, unsigned int query_flags)
{
    __u32 zero = 0;
    struct data *elem = bpf_map_lookup_elem(&test_map, &zero);

    if (!elem)
        return 0;

    bpf_spin_lock(&elem->lock);
    bpf_spin_unlock(&elem->lock);
    return 0;
}

char __license[] SEC("license") = "GPL";

$ sudo bpftool prog show id 17592
17592: tracing  name d_path_check_rdonly_mem  tag 7e7ebeefb37c74d9  gpl
	loaded_at 2026-02-05T10:41:41+0100  uid 0
	xlated 144B  jited 89B  memlock 4096B  map_ids 4639
	btf_id 12836

$ sudo bpftool prog dump xlated id 17592
int d_path_check_rdonly_mem(unsigned long long * ctx):
; int BPF_PROG(d_path_check_rdonly_mem, struct path *path, struct kstat *stat,
   0: (b7) r1 = 0
; __u32 zero = 0;
   1: (63) *(u32 *)(r10 -4) = r1
   2: (bf) r2 = r10
; 
   3: (07) r2 += -4
; struct data *elem = bpf_map_lookup_elem(&test_map, &zero);
   4: (18) r1 = map[id:4639]
   6: (85) call __htab_map_lookup_elem#294448
   7: (15) if r0 == 0x0 goto pc+1
   8: (07) r0 += 56
   9: (bf) r6 = r0
; if (!elem)
  10: (15) if r6 == 0x0 goto pc+5
; bpf_spin_lock(&elem->lock);
  11: (07) r6 += 4
; bpf_spin_lock(&elem->lock);
  12: (bf) r1 = r6
  13: (85) call bpf_spin_lock#253520
; bpf_spin_unlock(&elem->lock);
  14: (bf) r1 = r6
  15: (85) call bpf_spin_unlock#256064
; int BPF_PROG(d_path_check_rdonly_mem, struct path *path, struct kstat *stat,
  16: (b7) r0 = 0
  17: (95) exit

$ uname -srv
Linux 6.8.0-52-generic #53~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Wed Jan 15 19:18:46 UTC 2

[AliGhaffarian]

Yes. But oddly enough BPF_PROG_TYPE_TRACING is not considered a tracing program according to is_tracing_prog_type and so would be allowed as far as I can see

Oh, that was a misunderstanding on my part, guess they had a hard time naming things.

[dylandreimerink]

There are 2 hard problems in computer science: cache invalidation, naming things, and off-by-1 errors

😄

[AliGhaffarian]

@AliGhaffarian please check if this matches what you had in mind

My suggestion was more complex, it would need to port parts of check_map_prog_compatibility to [helper-fer/kfunc]-gen tools, your approach is more maintainable in my opinion.