Or better, omit CONFIG_BPF_JIT or whatever it's called.
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...
1
2
6
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
CONFIG_BPF_JIT_ALWAYS_ON is a config switch you can switch off though, no?
1
It forces the JIT to always be enabled at compile-time in order to avoid compiling the interpreter into the kernel. You can build the kernel without it. If the kernel is built with it, then there's no option to use the interpreter. It's how most distributions build Linux now.
Yes, this thread is about what distros should do, though. My position is they should not build kernel with any ability for dynamic code generation in kernel space.
1
1
1
in general, i agree, but with XDP interacting with eBPF, not having the JIT would make that basically useless
1
2
Show replies
It was implemented as what I consider to be a misguided security mitigation. Most people are prone to following very subjective advice like this without questioning it.
Attacker can simply use the same Spectre 2 vulnerability with different gadgets...
CFI actually helps a lot.
1
1
Is this a Spectre 2, or a Spectre 1 timing your own code running in kernelspace put there via eBPF? I think it may be the latter.
1
Show replies