Date: Fri, 8 Dec 2017 15:06:54 +0100
From: Peter Zijlstra <peterz@infradead.org>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@kernel.org>,
        Andy Lutomirski <luto@kernel.org>, Borislav Petkov <bp@alien8.de>,
        X86 ML <x86@kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Brian Gerst <brgerst@gmail.com>,
        David Laight <David.Laight@aculab.com>,
        Kees Cook <keescook@chromium.org>
Subject: Re: [PATCH] LDT improvements
Message-ID: <20171208140654.bths5fx2yxmndm42@hirez.programming.kicks-ass.net>
References: <48fe5cf1382d6a95c7b1837415882edcc81a9781.1512631324.git.luto@kernel.org>
 <20171207124347.p7kdj7q4qqs3ivri@pd.tnic>
 <CALCETrVrQRUn6PoBBGSD8+-wRrWp3mQtKY1sYnCRFyDBte5usA@mail.gmail.com>
 <alpine.DEB.2.20.1712071814200.1835@nanos>
 <665F1CA8-D012-4465-B5F7-E81E088847DB@amacapital.net>
 <20171208073454.dicyefwncsihq7sm@gmail.com>
 <alpine.DEB.2.20.1712081033040.1840@nanos>
 <6363C18D-D84A-40E4-8ED4-FE996609467B@amacapital.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <6363C18D-D84A-40E4-8ED4-FE996609467B@amacapital.net>
User-Agent: NeoMutt/20170609 (1.8.3)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1015
Lines: 21

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.