Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1762600AbdLSMK1 convert rfc822-to-8bit (ORCPT ); Tue, 19 Dec 2017 07:10:27 -0500 Received: from smtp-out6.electric.net ([192.162.217.185]:63498 "EHLO smtp-out6.electric.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751583AbdLSMKX (ORCPT ); Tue, 19 Dec 2017 07:10:23 -0500 From: David Laight To: "'Andy Lutomirski'" , 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" , Eduardo Valentin , "Liguori, Anthony" , Will Deacon , linux-mm Subject: RE: [patch 11/16] x86/ldt: Force access bit for CS/SS Thread-Topic: [patch 11/16] x86/ldt: Force access bit for CS/SS Thread-Index: AQHTc38ugfFGfbdQf06UrEpZQ+4L96NKmksQ Date: Tue, 19 Dec 2017 12:10:34 +0000 Message-ID: <2956b9271ecf4a859ef8eb112940cd3b@AcuMS.aculab.com> References: <20171212173221.496222173@linutronix.de> <20171212173334.176469949@linutronix.de> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.202.205.33] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-Outbound-IP: 156.67.243.126 X-Env-From: David.Laight@ACULAB.COM X-Proto: esmtps X-Revdns: X-HELO: AcuMS.aculab.com X-TLS: TLSv1.2:ECDHE-RSA-AES256-SHA384:256 X-Authenticated_ID: X-PolicySMART: 3396946, 3397078 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1166 Lines: 29 From: Andy Lutomirski > Sent: 12 December 2017 19:27 ... > > 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. ... Notwithstanding a readonly LDT, the iret (and pop %ds, pop %es that probably precede it) are all likely to fault in kernel if the segment registers are invalid. (Setting %fs and %gs for 32 bit processes is left to the reader.) Unlike every other fault in the kernel code segment, gsbase will contain the user value, not the kernel one. The kernel code must detect this somehow and correct everything before (probably) generating a SIGSEGV and returning to the user's signal handler with the invalid segment registers in the signal context. Assuming this won't happen (because the segment registers are always valid) is likely to be a recipe for disaster (or an escalation). I guess the problem with a readonly LDT is that you don't want to fault setting the 'accesses' bit. David