lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 11 Jan 2018 11:38:16 -0800 From: Alexei Starovoitov <alexei.starovoitov@...il.com> To: Dave Hansen <dave.hansen@...ux.intel.com> Cc: Linus Torvalds <torvalds@...ux-foundation.org>, Josh Poimboeuf <jpoimboe@...hat.com>, Andy Lutomirski <luto@...nel.org>, Willy Tarreau <w@....eu>, Peter Zijlstra <peterz@...radead.org>, LKML <linux-kernel@...r.kernel.org>, X86 ML <x86@...nel.org>, Borislav Petkov <bp@...en8.de>, Brian Gerst <brgerst@...il.com>, Ingo Molnar <mingo@...nel.org>, Thomas Gleixner <tglx@...utronix.de>, "H. Peter Anvin" <hpa@...or.com>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Kees Cook <keescook@...omium.org> Subject: Re: [RFC PATCH v2 6/6] x86/entry/pti: don't switch PGD on when pti_disable is set 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@...ux.intel.com> 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.
Powered by blists - more mailing lists