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

From: Kirill A. Shutemov
Date: Sun Dec 17 2017 - 06:09:46 EST


On Sat, Dec 16, 2017 at 10:24:32PM +0100, Thomas Gleixner wrote:
> From: Andy Lutomirski <luto@xxxxxxxxxx>
>
> 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@xxxxxxxxxx>
> Signed-off-by: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
> Cc: Kees Cook <keescook@xxxxxxxxxxxx>
> Cc: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
> Cc: Brian Gerst <brgerst@xxxxxxxxx>
> Cc: Dave Hansen <dave.hansen@xxxxxxxxx>
> Cc: David Laight <David.Laight@xxxxxxxxxx>
> Cc: Borislav Petkov <bp@xxxxxxxxx>
> Cc: "Kirill A. Shutemov" <kirill@xxxxxxxxxxxxx>
>
> ---
> 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