From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg0-f72.google.com (mail-pg0-f72.google.com [74.125.83.72]) by kanga.kvack.org (Postfix) with ESMTP id 8EFE06B0038 for ; Tue, 12 Dec 2017 14:26:34 -0500 (EST) Received: by mail-pg0-f72.google.com with SMTP id e69so16403624pgc.15 for ; Tue, 12 Dec 2017 11:26:34 -0800 (PST) Received: from mail-sor-f65.google.com (mail-sor-f65.google.com. [209.85.220.65]) by mx.google.com with SMTPS id g10sor4947294pge.372.2017.12.12.11.26.33 for (Google Transport Security); Tue, 12 Dec 2017 11:26:33 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: [patch 11/16] x86/ldt: Force access bit for CS/SS From: Andy Lutomirski In-Reply-To: Date: Tue, 12 Dec 2017 11:26:30 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20171212173221.496222173@linutronix.de> <20171212173334.176469949@linutronix.de> Sender: owner-linux-mm@kvack.org List-ID: To: Linus Torvalds Cc: Thomas Gleixner , LKML , the arch/x86 maintainers , Andy Lutomirsky , Peter Zijlstra , Dave Hansen , Borislav Petkov , Greg KH , Kees Cook , Hugh Dickins , Brian Gerst , Josh Poimboeuf , Denys Vlasenko , Boris Ostrovsky , Juergen Gross , David Laight , Eduardo Valentin , "Liguori, Anthony" , Will Deacon , linux-mm > On Dec 12, 2017, at 11:05 AM, Linus Torvalds wrote: >=20 >> On Tue, Dec 12, 2017 at 9:32 AM, Thomas Gleixner wro= te: >>=20 >> There is one exception; IRET will immediately load CS/SS and unrecoverabl= y >> #GP. To avoid this issue access the LDT descriptors used by CS/SS before >> the IRET to userspace. >=20 > Ok, so the other patch made me nervous, this just makes me go "Hell no!". >=20 > This is exactly the kind of "now we get traps in random microcode > places that have never been tested" kind of thing that I was talking > about. >=20 > Why is the iret exception unrecoverable anyway? Does anybody even know? >=20 Weird microcode shit aside, a fault on IRET will return to kernel code with k= ernel GS, and then the next time we enter the kernel we're backwards. We co= uld fix idtentry to get this right, but the code is already tangled enough. This series is full of landmines, I think. My latest patch set has a fully f= unctional LDT with PTI on, and the only thing particularly scary about it is= that it fiddles with page tables. Other than that, there's no VMA magic, n= o RO magic, and no microcode magic. And the LDT is still normal kernel memo= ry, so we can ignore a whole pile of potential attacks.=20 Also, how does it make any sense to have a cached descriptor that's not acce= ssed? Xen PV does weird LDT page fault shit, and is works, so I suspect we'= re just misunderstanding something. The VMX spec kind of documents this... > Linus -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org