On Thu, Jan 28, 2021 at 03:51:13PM -0800, Andy Lutomirski wrote: > > Okay, so I guess you're trying to inline probe_read_kernel(). But > that means you have to inline a valid implementation. In particular, > you need to check that you're accessing *kernel* memory. Just like That check is on the verifier side. It only does it for kernel pointers with known types. In a sequnce a->b->c the verifier guarantees that 'a' is valid kernel pointer and it's also !null. Then it guarantees that offsetof(b) points to valid kernel field which is also a pointer. What it doesn't check that b != null, so that users don't have to write silly code with 'if (p)' after every dereference. > how get_user() validates that the pointer points into user memory, > your helper should bounds check the pointer. On x86, you could check > the high bit. > > As an extra complication, we should really add logic to > get_kernel_nofault() to verify that the pointer points into actual > memory as opposed to MMIO space (or future incoherent MKTME space or > something like that, sigh). This will severely complicate inlining > it. And we should *really* make the same fix to get_kernel_nofault() > -- it should validate that the pointer is a kernel pointer. > > Is this really worth inlining instead of having the BPF JIT generate > an out of line call to a real C function? That would let us put in a > sane implementation. It's out of the question. JIT cannot generate a helper call for single bpf insn without huge overhead. All registers are used. It needs full save/restore, stack increase, etc. Anyhow I bet the bug we're discussing has nothing to do with bpf and jit. Something got changed and now probe_kernel_read(NULL) warns on !SMAP. This is something to debug.
