Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754273AbdLHQeQ (ORCPT ); Fri, 8 Dec 2017 11:34:16 -0500 Received: from mail.kernel.org ([198.145.29.99]:47192 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754015AbdLHQeK (ORCPT ); Fri, 8 Dec 2017 11:34:10 -0500 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9BE5A2199D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=luto@kernel.org X-Google-Smtp-Source: AGs4zMa0s1aqs86LwsMH6lhnKSn3UkWUlq2JumOh9FW2bY4uUYpauDCDVqlxn9BJmx+3AjX73OeOZdj6xF46tcdoZAA= MIME-Version: 1.0 In-Reply-To: <20171208140654.bths5fx2yxmndm42@hirez.programming.kicks-ass.net> 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> From: Andy Lutomirski Date: Fri, 8 Dec 2017 08:33:48 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] LDT improvements To: Peter Zijlstra Cc: Thomas Gleixner , Ingo Molnar , Andy Lutomirski , Borislav Petkov , X86 ML , "linux-kernel@vger.kernel.org" , Brian Gerst , David Laight , Kees Cook Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1353 Lines: 27 On Fri, Dec 8, 2017 at 6:06 AM, Peter Zijlstra wrote: > On Fri, Dec 08, 2017 at 05:20:00AM -0800, Andy Lutomirski wrote: >> > >> > 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? > > How would that be different from setting a 'crap' GS in modify_ldt() and > then returning from the syscall? That is something we should be able to > deal with already, no? > > Is this something ldt_gdt.c already tests? The current "Test GS" is in > test_gdt_invalidation() which seems to suggest not. > > Could we get a testcase for the exact situation you worry about? I'm not > sure I'd trust myself to get it right, all this LDT magic is new to me. #GP on IRET is a failure, and we have disgusting code to handle it. #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.