From mboxrd@z Thu Jan 1 00:00:00 1970 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 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f198.google.com (mail-wr0-f198.google.com [209.85.128.198]) by kanga.kvack.org (Postfix) with ESMTP id 3499B6B0261 for ; Tue, 19 Dec 2017 07:10:23 -0500 (EST) Received: by mail-wr0-f198.google.com with SMTP id y15so11242896wrc.6 for ; Tue, 19 Dec 2017 04:10:23 -0800 (PST) Received: from smtp-out6.electric.net (smtp-out6.electric.net. [192.162.217.184]) by mx.google.com with ESMTPS id q6si3588452edg.489.2017.12.19.04.10.21 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Dec 2017 04:10:21 -0800 (PST) From: David Laight Subject: RE: [patch 11/16] x86/ldt: Force access bit for CS/SS 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: Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-linux-mm@kvack.org List-ID: 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 From: Andy Lutomirski > Sent: 12 December 2017 19:27 ... > > 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 wi= th 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 probabl= y 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 (pro= bably) 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 -- 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