On Thu, Sep 12, 2024 at 04:02:53PM +0000, Maxwell Bland wrote: > operated on around 0.1188 MB). But most importantly, third, without some degree > of provenance, I have no way of telling if someone has injected malicious code > into the kernel, and unfortunately even knowing the correct bytes is still > "iffy", as in order to prevent JIT spray attacks, each of these filters is > offset by some random number of uint32_t's, making every 4-byte shift of the > filter a "valid" codepage to be loaded at runtime. I wanted to focus this thread on the problem, rather than potential solutions. I think we risk losing sight of getting a complete description of what is needed if we dive into solutions too quickly. So, let's start here. What I've seen from the thread is that there isn't a way to verify that a given JIT matches the cBPF. Is validating the cBPF itself also needed? This reminds me of two related topics, which might help either better define the problem or help find some other folks with similar needs. - The IMA subsystem has wanted a way to measure (and validate) seccomp filters. We could get more details from them for defining this need more clearly. - The JIT needs to be verified against the cBPF that it was generated from. We currently do only a single pass and don't validate it once the region has been set read-only. We have a standing feature request for improving this: https://github.com/KSPP/linux/issues/154 For solutions, I didn't see much discussion around the "orig_prog" copy of the cBPF. Under CHECKPOINT_RESTORE, the original cBPF remains associated with the JIT. struct seccomp_filter's struct bpf_prog prog's orig_prog member. If it has value outside of CHECKPOINT_RESTORE, then we could do it for those conditions too. -Kees -- Kees Cook
