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

[Alexei Starovoitov]

On Thu, Jan 11, 2018 at 10:57:51AM -0800, Dave Hansen wrote:
> On 01/11/2018 10:51 AM, Linus Torvalds wrote:
> > On Thu, Jan 11, 2018 at 10:38 AM, Dave Hansen
> > <dave.hansen@xxxxxxxxxxxxxxx> wrote:
> >> On 01/11/2018 10:32 AM, Josh Poimboeuf wrote:
> >>>> 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.
> >> Do tell.
> > One way to do it is to just run the attack, and see if you get something.
> 
> Not judging how trivial (or not) the attack is, I was hoping for
> something that was *not* the attack itself. :)

the attack can also be inconclusive.

I'm playing with an idea to conditionally switch into user cr3
after returning from syscall.
Like per task or per cpu counter or randomly tell syscall return to
keep kernel cr3 while next interrupt will bring task back to user cr3.
Public exploits use syscalls to keep kernel memory in L1 and
with such hack they see partial kernel reads and cannot really tell
which are the kernel bytes in the mix.
If there is a fast way for an attacker to know that after
syscall kpti is off for this task then such conditional kpti on/off
will be completely pointless.
It's not 100% secure obviously. Sort-of best effort to bring back
most of syscall performance without thinking which task should or
should not be allowed to toggle kpti flag.