On Feb 15, 2019, at 4:19 PM, Steven Rostedt rostedt@goodmis.org wrote:
On Fri, 15 Feb 2019 15:49:35 -0800 Andy Lutomirski luto@amacapital.net wrote:
I’m missing most of the context here, but even probe_kernel_...() is unwise for a totally untrustworthy address. It could be MMIO, for example.
True, but kprobes are used like modules, and only allowed by root. They are used to poke literally anywhere one wants. That's the entire purpose of kprobes.
If needed, we could come up with a safe-ish helper for tracing. For direct-map addresses, probe_kernel_...() is probably okay. Same for the current stack. Otherwise we could walk the page tables and check that the address is cacheable, I suppose, although this is slightly dubious if we don’t also check MTRRs. We could also check that the PA is in main memory, I suppose, although this may have unfortunate interactions with the MCE code.
I added you just because I wanted help getting the change log correct, as that's what Linus was complaining about. I kept using "kernel address" when the sample bug used for the patch was really a non-canonical address (as Linus said, it's just garbage. Neither kernel or user space). But I pointed out that this can also bug if the address is canonical and in the kernel address space. The old code didn't complain about non-canonical or kernel address faulting before commit 9da3f2b7405, which only talks about kernel address space faulting (which is why I only mentioned that in my messages).
Would changing all the mention of "kernel address" to "non user space" be accurate?
I think “kernel address” is right. It’s illegal to access anything that isn’t known to be a valid kernel address while in KERNEL_DS.
The old __copy seems likely to have always been a bit bogus.
BTW, what is this probe_mem_read() thing? Some minimal inspection suggests it’s a buggy reimplementation of probe_kernel_read(). Can you delete it and just use probe_kernel_read() directly?
For reference:
http://lkml.kernel.org/r/20190215174945.557218316@goodmis.org http://lkml.kernel.org/r/20190215142015.860423791@goodmis.org
-- Steve