lkml.org 
[lkml]   [2017]   [Dec]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] LDT improvements
From
Date


> On Dec 8, 2017, at 1:34 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
>
>> 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.

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

\
 
 \ /
  Last update: 2017-12-08 14:20    [W:0.280 / U:0.292 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site