Re: [RFC PATCH v2 6/6] x86/entry/pti: don't switch PGD on when pti_disable is set

[Josh Poimboeuf]

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
> > <dave.hansen@xxxxxxxxxxxxxxx> 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