linux-kernel - Re: [patch V149 38/50] x86/pti: Put the LDT in its own PGD if PTI is on

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] [day] [month] [year] [list]

Message-ID: <20171217110934.f34h6i6yht5vpe4f@node.shutemov.name>
Date:   Sun, 17 Dec 2017 14:09:34 +0300
From:   "Kirill A. Shutemov" <kirill@...temov.name>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     LKML <linux-kernel@...r.kernel.org>, x86@...nel.org,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Andy Lutomirsky <luto@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Dave Hansen <dave.hansen@...el.com>,
        Borislav Petkov <bpetkov@...e.de>,
        Greg KH <gregkh@...uxfoundation.org>, keescook@...gle.com,
        hughd@...gle.com, Brian Gerst <brgerst@...il.com>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Denys Vlasenko <dvlasenk@...hat.com>,
        Rik van Riel <riel@...hat.com>,
        Boris Ostrovsky <boris.ostrovsky@...cle.com>,
        Juergen Gross <jgross@...e.com>,
        David Laight <David.Laight@...lab.com>,
        Eduardo Valentin <eduval@...zon.com>, aliguori@...zon.com,
        Will Deacon <will.deacon@....com>, daniel.gruss@...k.tugraz.at,
        Kees Cook <keescook@...omium.org>,
        Borislav Petkov <bp@...en8.de>
Subject: Re: [patch V149 38/50] x86/pti: Put the LDT in its own PGD if PTI is
 on

On Sat, Dec 16, 2017 at 10:24:32PM +0100, Thomas Gleixner wrote:
> From: Andy Lutomirski <luto@...nel.org>
> 
> With PTI enabled, the LDT must be mapped in the usermode tables somewhere.
> The LDT is per process, i.e. per mm.
> 
> An earlier approach mapped the LDT on context switch into a fixmap area,
> but that's a big overhead and exhausted the fixmap space when NR_CPUS got
> big.
> 
> Take advantage of the fact that there is an address space hole which
> provides a completely unused pgd. Use this pgd to manage per-mm LDT
> mappings.
> 
> This has a down side: the LDT isn't (currently) randomized, and an attack
> that can write the LDT is instant root due to call gates (thanks, AMD, for
> leaving call gates in AMD64 but designing them wrong so they're only useful
> for exploits).  This can be mitigated by making the LDT read-only or
> randomizing the mapping, either of which is strightforward on top of this
> patch.
> 
> This will significantly slow down LDT users, but that shouldn't matter for
> important workloads -- the LDT is only used by DOSEMU(2), Wine, and very
> old libc implementations.
> 
> [ tglx: Decrapified it ]
> 
> Signed-off-by: Andy Lutomirski <luto@...nel.org>
> Signed-off-by: Thomas Gleixner <tglx@...utronix.de>
> Cc: Kees Cook <keescook@...omium.org>
> Cc: Peter Zijlstra <peterz@...radead.org>
> Cc: Brian Gerst <brgerst@...il.com>
> Cc: Dave Hansen <dave.hansen@...el.com>
> Cc: David Laight <David.Laight@...lab.com>
> Cc: Borislav Petkov <bp@...en8.de>
> Cc: "Kirill A. Shutemov" <kirill@...temov.name>
> 
> ---
>  Documentation/x86/x86_64/mm.txt         |    3 
>  arch/x86/include/asm/mmu_context.h      |   55 +++++++++++-
>  arch/x86/include/asm/pgtable_64_types.h |    4 
>  arch/x86/include/asm/processor.h        |   23 +++--
>  arch/x86/kernel/ldt.c                   |  139 +++++++++++++++++++++++++++++++-
>  arch/x86/mm/dump_pagetables.c           |   12 ++
>  6 files changed, 219 insertions(+), 17 deletions(-)
> 
> --- a/Documentation/x86/x86_64/mm.txt
> +++ b/Documentation/x86/x86_64/mm.txt
> @@ -12,6 +12,7 @@ ffffea0000000000 - ffffeaffffffffff (=40
>  ... unused hole ...
>  ffffec0000000000 - fffffbffffffffff (=44 bits) kasan shadow memory (16TB)
>  ... unused hole ...
> +fffffe8000000000 - fffffeffffffffff (=39 bits) LDT remap for PTI
>  ffffff0000000000 - ffffff7fffffffff (=39 bits) %esp fixup stacks
>  ... unused hole ...
>  ffffffef00000000 - fffffffeffffffff (=64 GB) EFI region mapping space
> @@ -28,7 +29,7 @@ ffffffffffe00000 - ffffffffffffffff (=2
>  hole caused by [56:63] sign extension
>  ff00000000000000 - ff0fffffffffffff (=52 bits) guard hole, reserved for hypervisor
>  ff10000000000000 - ff8fffffffffffff (=55 bits) direct mapping of all phys. memory
> -ff90000000000000 - ff9fffffffffffff (=52 bits) hole
> +ff90000000000000 - ff9fffffffffffff (=49 bits) LDT remap for PTI

  +ff90000000000000 - ff9fffffffffffff (=52 bits) LDT remap for PTI

-- 
 Kirill A. Shutemov