linux-kernel - Re: [PATCH PTI v2 0/6] Clean up pgd handling and fix VSYSCALL and LDT

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: <CALCETrV8gJW39GeiK=ejuB1yDyo1DhcKFYR5qzUNQkAYTQa=8w@mail.gmail.com>
Date:   Sun, 10 Dec 2017 22:54:38 -0800
From:   Andy Lutomirski <luto@...nel.org>
To:     Andy Lutomirski <luto@...nel.org>
Cc:     X86 ML <x86@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Borislav Petkov <bp@...en8.de>,
        Brian Gerst <brgerst@...il.com>,
        David Laight <David.Laight@...lab.com>,
        Kees Cook <keescook@...omium.org>,
        Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH PTI v2 0/6] Clean up pgd handling and fix VSYSCALL and LDT

On Sun, Dec 10, 2017 at 10:47 PM, Andy Lutomirski <luto@...nel.org> wrote:
> I'm getting reasonably happy with this.  It still needs more testing,
> but I want to get it out there.
>
> The main things that need testing are the 5-level case for the both
> vsyscalls and the LDT.  I'm getting a double-fault in ldt_gdt_64,
> but I haven't checked whether it's a bug in this series, and it
> kind of looks like it isn't.  I'll figure it out in the morning.
> The docs also want updating for the 5 level case.
>

The actual failure looks a lot like the ESPFIX stacks aren't mapped in
the usermode tables, which reinforces my old belief that this bit of
code is bogus:

    /*
     * Just copy the top-level PGD that is mapping the espfix area to
     * ensure it is mapped into the user page tables.
     *
     * For 5-level paging, the espfix pgd was populated when
     * pti_init() pre-populated all the pgd entries.  The above
     * p4d_alloc() would never do anything and the p4d_populate() would
     * be done to a p4d already mapped in the userspace pgd.
     */
#ifdef CONFIG_PAGE_TABLE_ISOLATION
    if (CONFIG_PGTABLE_LEVELS <= 4) {
        set_pgd(kernel_to_user_pgdp(pgd),
            __pgd(_KERNPG_TABLE | (p4d_pfn(*p4d) << PAGE_SHIFT)));
    }
#endif

Of course, the comment is even more wrong with this series applied,
but I think it's been wrong all along.

I'll fix it in the morning if no one beats me to it.

(Hint: this can be tested in QEMU with -machine accel=tcg -cpu qemu64,+la57)

> Changes from v1:
>  - vsyscalls actually work.
>  - Added the "Warn and fail" patch to prevent the testing goof I had on v1.
>  - Lots of cleanups
>
> Andy Lutomirski (6):
>   x86/pti: Vastly simplify pgd synchronization
>   Revert "x86/mm/pti: Disable native VSYSCALL"
>   x86/vsyscall/64: Explicitly set _PAGE_USER in the pagetable hierarchy
>   x86/vsyscall/64: Warn and fail vsyscall emulation in NATIVE mode
>   x86/pti: Map the vsyscall page if needed
>   x86/pti: Put the LDT in its own PGD if PTI is on
>
>  Documentation/x86/x86_64/mm.txt         |  11 ++-
>  arch/x86/Kconfig                        |   8 --
>  arch/x86/entry/vsyscall/vsyscall_64.c   |  37 ++++++++-
>  arch/x86/include/asm/mmu_context.h      |  33 +++++++-
>  arch/x86/include/asm/pgtable.h          |   6 +-
>  arch/x86/include/asm/pgtable_64.h       |  77 ++++++++----------
>  arch/x86/include/asm/pgtable_64_types.h |   2 +
>  arch/x86/include/asm/processor.h        |  23 ++++--
>  arch/x86/include/asm/vsyscall.h         |   1 +
>  arch/x86/kernel/ldt.c                   | 138 +++++++++++++++++++++++++++++---
>  arch/x86/mm/pti.c                       | 115 ++++++++++++++++----------
>  11 files changed, 331 insertions(+), 120 deletions(-)
>
> --
> 2.13.6
>