Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753882AbdLHNzJ convert rfc822-to-8bit (ORCPT ); Fri, 8 Dec 2017 08:55:09 -0500 Received: from smtp-out6.electric.net ([192.162.217.185]:65464 "EHLO smtp-out6.electric.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753408AbdLHNzH (ORCPT ); Fri, 8 Dec 2017 08:55:07 -0500 From: David Laight To: "'Andy Lutomirski'" , Thomas Gleixner CC: Ingo Molnar , Andy Lutomirski , Borislav Petkov , X86 ML , "linux-kernel@vger.kernel.org" , Brian Gerst , Kees Cook , Peter Zijlstra Subject: RE: [PATCH] LDT improvements Thread-Topic: [PATCH] LDT improvements Thread-Index: AQHTcCdTe6xr1j6KOk+0Um5AEfZn3aM5dgSg Date: Fri, 8 Dec 2017 13:55:24 +0000 Message-ID: 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> In-Reply-To: <6363C18D-D84A-40E4-8ED4-FE996609467B@amacapital.net> 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: 1044 Lines: 23 From: Andy Lutomirski > Sent: 08 December 2017 13:20 ... > >> - It would also be a cleaner approach all around, and would avoid the fixmap > >> complications and the scheduler muckery. > > > > The error code of such an access is always 0x03. So I added a special > > handler, which checks whether the address is in the LDT map range and > > verifies that the access bit in the descriptor is 0. If that's the case it > > sets it and returns. If not, the thing dies. That works. > > What if you are in kernel mode and try to return to a context with SS or CS pointing to a non-accessed > segment? > Or what if you try to schedule to a context with fs or, worse, gs pointing to such a segment? Well, the cpu will fault in kernel on the 'pop %xs' or 'iret' instruction. These all (probably) happen on the kernel stack with the usergs loaded. So the fault handler has to look at the opcodes and/or %pc value, sort out the stack (etc) and then generate SIGSEGV. I'm not sure the kernel needs to know why the segment selector is invalid. David