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
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
We don't have dynamically loaded kernel module support enabled in GrapheneOS primarily to improve Control Flow Integrity (CFI). BPF_JIT depends on having that enabled, so we don't even have the option. Also, CFI essentially acts as Spectre 2 mitigation. CPU won't predict failure.