linux-kernel - Re: [PATCH] LDT improvements

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <6363C18D-D84A-40E4-8ED4-FE996609467B@amacapital.net>
Date:   Fri, 8 Dec 2017 05:20:00 -0800
From:   Andy Lutomirski <luto@...capital.net>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     Ingo Molnar <mingo@...nel.org>, Andy Lutomirski <luto@...nel.org>,
        Borislav Petkov <bp@...en8.de>, X86 ML <x86@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Brian Gerst <brgerst@...il.com>,
        David Laight <David.Laight@...lab.com>,
        Kees Cook <keescook@...omium.org>,
        Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH] LDT improvements



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