Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752299AbdLLT0f (ORCPT ); Tue, 12 Dec 2017 14:26:35 -0500 Received: from mail-pg0-f65.google.com ([74.125.83.65]:38947 "EHLO mail-pg0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751577AbdLLT0d (ORCPT ); Tue, 12 Dec 2017 14:26:33 -0500 X-Google-Smtp-Source: ACJfBotsAsbDZh0cRIXOqYkpp42cpA5Omx3sc4Qjj9w+G6uqSYMZ64ULdykfOTzc3OYiDIgDvmmxQw== 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 X-Mailer: iPhone Mail (15C114) In-Reply-To: Date: Tue, 12 Dec 2017 11:26:30 -0800 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 Message-Id: References: <20171212173221.496222173@linutronix.de> <20171212173334.176469949@linutronix.de> To: Linus Torvalds Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nfs id vBCJQdXu005381 Content-Length: 1515 Lines: 26 > On Dec 12, 2017, at 11:05 AM, Linus Torvalds wrote: > >> On Tue, Dec 12, 2017 at 9:32 AM, Thomas Gleixner wrote: >> >> There is one exception; IRET will immediately load CS/SS and unrecoverably >> #GP. To avoid this issue access the LDT descriptors used by CS/SS before >> the IRET to userspace. > > Ok, so the other patch made me nervous, this just makes me go "Hell no!". > > 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. > > Why is the iret exception unrecoverable anyway? Does anybody even know? > Weird microcode shit aside, a fault on IRET will return to kernel code with kernel GS, and then the next time we enter the kernel we're backwards. We could 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 functional 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, no RO magic, and no microcode magic. And the LDT is still normal kernel memory, so we can ignore a whole pile of potential attacks. Also, how does it make any sense to have a cached descriptor that's not accessed? 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