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: <alpine.DEB.2.20.1712081033040.1840@nanos>
Date:   Fri, 8 Dec 2017 10:34:15 +0100 (CET)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Ingo Molnar <mingo@...nel.org>
cc:     Andy Lutomirski <luto@...capital.net>,
        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 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.

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