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 linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <CALCETrVmFSVqDGrH1K+Qv=svPTP3E6maVb5T2feyDNRkKfDVKA@mail.gmail.com> Date: Tue, 12 Dec 2017 10:10:40 -0800 From: Andy Lutomirski <luto@...nel.org> To: Peter Zijlstra <peterz@...radead.org> Cc: Andy Lutomirski <luto@...nel.org>, Thomas Gleixner <tglx@...utronix.de>, LKML <linux-kernel@...r.kernel.org>, X86 ML <x86@...nel.org>, Linus Torvalds <torvalds@...ux-foundation.org>, Dave Hansen <dave.hansen@...el.com>, Borislav Petkov <bpetkov@...e.de>, Greg KH <gregkh@...uxfoundation.org>, Kees Cook <keescook@...gle.com>, Hugh Dickins <hughd@...gle.com>, Brian Gerst <brgerst@...il.com>, Josh Poimboeuf <jpoimboe@...hat.com>, Denys Vlasenko <dvlasenk@...hat.com>, Boris Ostrovsky <boris.ostrovsky@...cle.com>, Juergen Gross <jgross@...e.com>, David Laight <David.Laight@...lab.com>, Eduardo Valentin <eduval@...zon.com>, aliguori@...zon.com, Will Deacon <will.deacon@....com>, "linux-mm@...ck.org" <linux-mm@...ck.org> Subject: Re: [patch 11/16] x86/ldt: Force access bit for CS/SS On Tue, Dec 12, 2017 at 10:09 AM, Peter Zijlstra <peterz@...radead.org> wrote: > On Tue, Dec 12, 2017 at 10:03:02AM -0800, Andy Lutomirski wrote: >> On Tue, Dec 12, 2017 at 9:32 AM, Thomas Gleixner <tglx@...utronix.de> wrote: > >> > @@ -171,6 +172,9 @@ static void exit_to_usermode_loop(struct >> > /* Disable IRQs and retry */ >> > local_irq_disable(); >> > >> > + if (cached_flags & _TIF_LDT) >> > + ldt_exit_user(regs); >> >> Nope. To the extent that this code actually does anything (which it >> shouldn't since you already forced the access bit), > > Without this; even with the access bit set; IRET will go wobbly and > we'll #GP on the user-space side. Try it ;-) Maybe later. But that means that we need Intel and AMD to confirm WTF is going on before this blows up even with LAR on some other CPU. > >> it's racy against >> flush_ldt() from another thread, and that race will be exploitable for >> privilege escalation. It needs to be outside the loopy part. > > The flush_ldt (__ldt_install after these patches) would re-set the TIF > flag. But sure, we can move this outside the loop I suppose.
Powered by blists - more mailing lists