Re: [PATCH] LDT improvements

[Andy Lutomirski]

> On Dec 8, 2017, at 1:34 AM, Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote:
> 
>> On Fri, 8 Dec 2017, Ingo Molnar wrote:
>> * Andy Lutomirski <luto@xxxxxxxxxxxxxx> 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.

You only get the LDT selector, not the address.

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

> 
> Thanks,
> 
>    tglx