On Thu, Jan 11, 2018 at 10:21:49AM -0800, Alexei Starovoitov wrote: > On Thu, Jan 11, 2018 at 09:02:55AM -0800, Andy Lutomirski wrote: > > On Thu, Jan 11, 2018 at 7:51 AM, Dave Hansen > > <[email protected]> wrote: > > > On 01/11/2018 07:44 AM, Willy Tarreau wrote: > > >>> I think we also need to be able to dump the actual > > >>> CR3 value that we entered the kernel with before we start doing too much > > >>> other funky stuff with the entry code. > > >> When you say dump, you mean save it somewhere in a per_cpu variable ? > > > > > > Yeah, I think a per-cpu variable is fine for now. But, that only gives > > > you a dump from a single entry to the kernel. Ideally, it would be nice > > > to have a stack of them so you could do things like debug > > > syscall->fault->oops. Was it the syscall entry or the fault entry that > > > lead to the oops? > > > > > > But, the stack gets really fun because of NMIs. > > > > > > I'm sure Andy Lutomirski has some ideas too. > > > > I was thinking that maybe we should add a new field or two to pt_regs. > > They could store CR2 and maybe CR3 as well. I'd also like to expose > > the error code of exceptions in stack traces. We should get this > > integrated right into the unwinder. > > hmm. Exposing cr3 to user space will make it trivial for user process > to know whether kpti is active. Not sure how exploitable such > information leak.
It's already trivial to detect PTI from user space. -- Josh
