I always believe allowing any forms of JIT (in userspace programs) by default creates unnecessary security risks - only a handful of programs use it. The sysadmin should have a choice to enforce strict W^X on all programs and to whitelist JIT-enabled applications only when needed.
The kernel space BPF JIT in particular, is an huge attack vector and has been repeatably exploited (or facilitated other exploits) in the past. If you don't need BPF JIT, I recommend disabling it. Sure, tcpdump or nftable may be slower, but often it doesn't matter, unless it's a cutting edge production system which actually relies on BPF JIT. It can either be removed completely when building the kernel, setting "net.core.bpf_jit_enable" in sysctl to disable it globally, or setting "kernel.unprivileged_bpf_disabled" to disable it for unprivileged programs.
PaX's implementation of W^X (MPROTECT) is stricter - you can disallow any attempt to introduce new executable code, including writing to memory first and giving it executable status later.
That's not a fix, just a kinda assertion that nobody falls into that PoC. The real fix would in the compiler to correctly adjust its sizes and addr[] amongst its optimization paths.
The optimizer end condition also seems fishy to me, solely relying on the size. Optimized passes can still be better within the same size.
It feels like a BPF JIT would be a good candidate for "verifiable" development. Can anyone knowledgeable opine on whether it would be feasible or desirable to prove the correctness of this component? (I suppose this will necessitate writing in a suitable language/DSL too.)
A "direct" correctness proof of a BPF compiler written in C would be hard because C is hard to reason about. If you pulled it off, you could do this verification before compiling the kernel.
It would certainly be easier to implement an "indirect" approach using translation validation, i.e., taking the code generated by the compiler and checking that it is semantically equivalent to the input BPF code. The problem with this is that this would need to be done at run time, i.e., you would add a lot of verification time when the user is already waiting for the BPF program to run.
Overall: Yes, this is a good candidate, and people are on it.
"The patch produced by git format-patch is in UNIX mailbox format, with a fixed "magic" time stamp to indicate that the file is output from format-patch rather than a real mailbox".
The date "Mon Sep 17 00:00:00 2001" is that magic date.
The kernel space BPF JIT in particular, is an huge attack vector and has been repeatably exploited (or facilitated other exploits) in the past. If you don't need BPF JIT, I recommend disabling it. Sure, tcpdump or nftable may be slower, but often it doesn't matter, unless it's a cutting edge production system which actually relies on BPF JIT. It can either be removed completely when building the kernel, setting "net.core.bpf_jit_enable" in sysctl to disable it globally, or setting "kernel.unprivileged_bpf_disabled" to disable it for unprivileged programs.