On Thu, Jan 28, 2021 at 4:29 PM Andy Lutomirski <luto@xxxxxxxxxx> wrote: > > On Thu, Jan 28, 2021 at 4:26 PM Alexei Starovoitov > <alexei.starovoitov@xxxxxxxxx> wrote: > > > > On Thu, Jan 28, 2021 at 04:18:24PM -0800, Andy Lutomirski wrote: > > > On Thu, Jan 28, 2021 at 4:11 PM Alexei Starovoitov > > > <alexei.starovoitov@xxxxxxxxx> wrote: > > > > > > > > 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. > > > > > > That sounds like a verifier and/or JIT bug. If you have a pointer p > > > (doesn't matter whether p is what you call a or a->b) and you have not > > > confirmed that p points to the kernel range, you may not generate a > > > load from that pointer. > > > > Please read the explanation again. It's an inlined probe_kernel_read. > > Can you point me at the uninlined implementation? Does it still > exist? I see get_kernel_nofault(), which is currently buggy, and I > will fix it. I spoke too soon. get_kernel_nofault() is just fine. You have inlined something like __get_kernel_nofault(), which is incorrect. get_kernel_nofault() would have done the right thing.
