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.
Conversation
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.
2
1
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
The commit message introducing it is talking about a case where it was being used for Spectre 2 gadgets: git.kernel.org/pub/scm/linux/.
It's similar to code being used as a ROP/JOP gadget. I think it's quite strange to address this through the hopeless approach of removing gadgets.
1
In the case they're talking about, the attacker couldn't use eBPF. I doubt that it's ever going to be usable by an unprivileged process on AOSP.
By the way, a real argument increasingly being used by upstream maintainers in these areas is that securing Linux is a lost cause...
They genuinely try to shut down discussions about attack surface or potential mitigations by simply portraying it as a lost cause. Why bother caring if it makes things worse when things are already so bad?
I'm increasingly seeing that looking through threads about this stuff...