Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753053AbdLHQqf (ORCPT ); Fri, 8 Dec 2017 11:46:35 -0500 Received: from smtp-out4.electric.net ([192.162.216.187]:50280 "EHLO smtp-out4.electric.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752484AbdLHQqe (ORCPT ); Fri, 8 Dec 2017 11:46:34 -0500 From: David Laight To: "'Andy Lutomirski'" , Peter Zijlstra CC: Thomas Gleixner , Ingo Molnar , Borislav Petkov , X86 ML , "linux-kernel@vger.kernel.org" , Brian Gerst , Kees Cook Subject: RE: [PATCH] LDT improvements Thread-Topic: [PATCH] LDT improvements Thread-Index: AQHTcEJSe6xr1j6KOk+0Um5AEfZn3aM5peBg Date: Fri, 8 Dec 2017 16:46:51 +0000 Message-ID: <34ab84c5fbb849209c9d3877e89cab23@AcuMS.aculab.com> References: <48fe5cf1382d6a95c7b1837415882edcc81a9781.1512631324.git.luto@kernel.org> <20171207124347.p7kdj7q4qqs3ivri@pd.tnic> <665F1CA8-D012-4465-B5F7-E81E088847DB@amacapital.net> <20171208073454.dicyefwncsihq7sm@gmail.com> <6363C18D-D84A-40E4-8ED4-FE996609467B@amacapital.net> <20171208140654.bths5fx2yxmndm42@hirez.programming.kicks-ass.net> 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="utf-8" 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-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by nfs id vB8GkeHc003191 Content-Length: 789 Lines: 23 From: Andy Lutomirski > Sent: 08 December 2017 16:34 > #GP on IRET is a failure, and we have disgusting code to handle it. Is that the trap in kernel space when the on-stack segment registers are invalid? Definitely needs horrid code... > #PF on IRET would not be a failure -- it's a case where IRET should be > retried. Our crap that fixes up #GP would get that wrong and leave us > with the wrong GSBASE. If the user code page isn't present then the fault happens after the return to user mode, not on the IRET instruction in kernel mode. So it is not really any different to returning to a NOP at the end of a resident page when the page following is absent. (Or any other invalid %ip value.) SWAPGS is a PITA, should have been SAVEGS, LOAD_KERNEL_GS, and READ_SAVED_GS. David