Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752582AbdLHR2u (ORCPT ); Fri, 8 Dec 2017 12:28:50 -0500 Received: from smtp-out4.electric.net ([192.162.216.181]:51305 "EHLO smtp-out4.electric.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752165AbdLHR2t (ORCPT ); Fri, 8 Dec 2017 12:28:49 -0500 From: David Laight To: "'Andy Lutomirski'" CC: Peter Zijlstra , 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+0Um5AEfZn3aM5peBggAACGQCAAAagYA== Date: Fri, 8 Dec 2017 17:29:08 +0000 Message-ID: <77ea98ade5ee40788c0a1b5d62b2d3e2@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> <34ab84c5fbb849209c9d3877e89cab23@AcuMS.aculab.com> 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 vB8HSucf019277 Content-Length: 357 Lines: 13 From: Andy Lutomirski > Sent: 08 December 2017 16:48 ... > I mean: if the user CS or SS is not accessed and the LDT is RO, then > we get #PF on the IRET instruction, I think. Dealing with that is > truly awful. Any fault in-kernel on the IRET is horrid. Doesn't really matter which one. Same goes for the 'pop %ds' (etc) that tend to precede it. David