Adding BPF. On 2023/12/19 18:10, Alfred Piccioni wrote: >> I didn't do an audit but does anything need to be updated for the BPF >> LSM or does it auto-magically pick up new hooks? > > I'm unsure. I looked through the BPF LSM and I can't see any way it's > picking up the file_ioctl hook to begin with. It appears to me > skimming through the code that it automagically picks it up, but I'm > not willing to bet the kernel on it. If BPF LSM silently picks up security_file_ioctl_compat() hook, I worry that some existing BPF programs which check ioctl() using BPF LSM fail to understand that such BPF programs need to be updated. We basically don't care about out-of-tree kernel code. But does that rule apply to BPF programs? Since BPF programs are out-of-tree, are BPF programs which depend on BPF LSM considered as "we don't care about" rule? Or is breakage of existing BPF programs considered as a regression? (Note that this patch is CC:ed for stable kernels.) Maybe BPF LSM should at least emit warning if the loaded BPF program defined security_file_ioctl() hook and did not define security_file_ioctl_compat() hook? We could use a struct where undefined hooks needs to be manually filled with a dummy pointer, so that we can catch erroneously undefined hooks (detected by being automatically filled with a NULL pointer) at load time?
