Date: Fri, 8 Dec 2017 10:34:15 +0100 (CET)
From: Thomas Gleixner <tglx@linutronix.de>
To: Ingo Molnar <mingo@kernel.org>
cc: Andy Lutomirski <luto@amacapital.net>,
        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>,
        Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH] LDT improvements
In-Reply-To: <20171208073454.dicyefwncsihq7sm@gmail.com>
Message-ID: <alpine.DEB.2.20.1712081033040.1840@nanos>
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>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1396
Lines: 35

On Fri, 8 Dec 2017, Ingo Molnar wrote:
> * Andy Lutomirski <luto@amacapital.net> wrote:
> > I don't love mucking with user address space.  I'm also quite nervous about 
> > putting it in our near anything that could pass an access_ok check, since we're 
> > totally screwed if the bad guys can figure out how to write to it.
> 
> Hm, robustness of the LDT address wrt. access_ok() is a valid concern.
> 
> Can we have vmas with high addresses, in the vmalloc space for example?
> IIRC the GPU code has precedents in that area.
> 
> Since this is x86-64, limitation of the vmalloc() space is not an issue.
> 
> I like Thomas's solution:
> 
>  - have the LDT in a regular mmap space vma (hence per process ASLR randomized), 
>    but with the system bit set.
> 
>  - That would be an advantage even for non-PTI kernels, because mmap() is probably 
>    more randomized than kmalloc().

Randomization is pointless as long as you can get the LDT address in user
space, i.e. w/o UMIP.

>  - 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.

Thanks,

	tglx