this is why eBPF is restricted to root in alpine. all distributions should do that.
Conversation
Replying to
unfortunately, that is not practical. many new kernel features are controlled through eBPF, such as VRFs, `ip vrf exec` depends on eBPF.
1
3
other examples include the newer performance tracing functionality, etc. all of it is unfortunately built on eBPF.
1
1
Replying to
yes, but when you enable some options, like CONFIG_BPF_SYSCALL, you have CONFIG_BPF_JIT=y automatically, and you can't get rid of it. and unfortunately, the bpf syscall is now a popular one for these new toys.
1
2
Replying to
Are you sure? There are plenty of archs with no JIT. JIT should be independent.
1
Replying to
apparently they turn it on as a "security mitigation" where its available, see CONFIG_BPF_JIT_ALWAYS_ON.
apparently this is because the interpreter does speculation
1
1
The issue is that the interpreter provides very useful Spectre 2 gadgets simply by existing.
git.kernel.org/pub/scm/linux/
There are gadgets all over the kernel so this mitigation is very questionable. It's comparable to removing/changing code to eliminate well known ROP gadgets...
Once an attacker has developed a scripting framework for finding Spectre 2 gadgets, then this accomplishes very little. It's not a real barrier but rather at most an inconvenience: a well known and useful set of gadgets isn't available. It's security through obscurity at best.
3
3
Since most distributions now enable BPF_JIT_ALWAYS_ON, any value it provides via obscurity is essentially already there.
If you configure your kernel without it, then sure, you have an easy source of useful Spectre 2 gadgets, but since hardly anyone else does, it's as obscure...
2
1
Show replies