Finer-grained BPF tokens

Posted Oct 12, 2023 22:27 UTC (Thu) by bluca (subscriber, #118303)
In reply to: Finer-grained BPF tokens by tohojo
Parent article: Finer-grained BPF tokens

Well, my former colleague Matteo had a working and simple patchset that treated precompiled co-re bpf programs like kernel modules: https://lore.kernel.org/bpf/20211203191844.69709-1-mcroce...
Sure, it doesn't help with the jit-compiled ones, but one can conceivably restrict that and be limited to pre-compiled programs only. But it was rejected in favour of a different bpf-native approach, that after 2 years sadly hasn't happened yet.

to post comments

Finer-grained BPF tokens

Posted Oct 13, 2023 9:48 UTC (Fri) by tohojo (subscriber, #86756) [Link]

Ah yes, now that you mention it, I vaguely remember that discussion. Yeah, sadly nothing comprehensive has materialised yet. I would have liked to have a mechanism that just delegates the policy decisions to userspace (similar to seccomp-notify, but bpf-specific so the kernel can ensure consistency and make sure we avoid TOCTOU races), but that didn't fly with upstream either.

For container deployments we are also experimenting with just doing everything in userspace: https://bpfd.dev/
This uses a "system daemon will load BPF on your behalf" model, and will allow arbitrary verification (including through signatures). But of course it requires you to trust the system daemon, and it precludes some of the dynamic code generation stuff that John was talking about in that thread you linked. So again, tradeoffs...