linux-kernel - Re: [patch V163 27/51] x86/mm/pti: Populate user PGD

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: <CALCETrWgSRnp4FZ9Acpf+foUY6M8aRgM3ai2WB+i6zHsrUOq2Q@mail.gmail.com>
Date:   Mon, 18 Dec 2017 14:11:53 -0800
From:   Andy Lutomirski <luto@...nel.org>
To:     Dave Hansen <dave.hansen@...el.com>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        LKML <linux-kernel@...r.kernel.org>, X86 ML <x86@...nel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Andy Lutomirsky <luto@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Borislav Petkov <bpetkov@...e.de>,
        Greg KH <gregkh@...uxfoundation.org>,
        Kees Cook <keescook@...gle.com>,
        Hugh Dickins <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>,
        "Liguori, Anthony" <aliguori@...zon.com>,
        Will Deacon <will.deacon@....com>,
        Daniel Gruss <daniel.gruss@...k.tugraz.at>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Ingo Molnar <mingo@...nel.org>, Borislav Petkov <bp@...e.de>,
        "H. Peter Anvin" <hpa@...or.com>
Subject: Re: [patch V163 27/51] x86/mm/pti: Populate user PGD

On Mon, Dec 18, 2017 at 12:34 PM, Dave Hansen <dave.hansen@...el.com> wrote:
> On 12/18/2017 03:42 AM, Thomas Gleixner wrote:
>> --- a/arch/x86/include/asm/pgtable.h
>> +++ b/arch/x86/include/asm/pgtable.h
>> @@ -1120,6 +1120,11 @@ static inline void pmdp_set_wrprotect(st
>>  static inline void clone_pgd_range(pgd_t *dst, pgd_t *src, int count)
>>  {
>>         memcpy(dst, src, count * sizeof(pgd_t));
>> +#ifdef CONFIG_PAGE_TABLE_ISOLATION
>> +     /* Clone the user space pgd as well */
>> +     memcpy(kernel_to_user_pgdp(dst), kernel_to_user_pgdp(src),
>> +            count * sizeof(pgd_t));
>> +#endif
>>  }
>
> I was just thinking about this as I re-write the documentation about
> where the overhead of pti comes from.
>
> This obviously *works* for now.  But, we certainly have the pti-mapped
> stuff spread much less through the address space than when this was
> thrown in here.  It *seems* like we could probably do this with just 4 PGDs:
>
>>         pti_clone_user_shared();
>>         pti_clone_entry_text();
>>         pti_setup_espfix64();
>>         pti_setup_vsyscall();
>
> The vsyscall is just one page and the espfix is *sized* to be one PGD,
> so we know each of those only takes one entry.
>
> We surely don't have 512GB of entry_text, and I don't think KASLR can
> ever cause it to span two PGD entries.

This would definitely work and, long-term, I think we should get rid
of the entry text mapping entirely.  The tricky bit is that we need to
rearrange the whole memory map fairly radically for this.

We could make it more compact, too: the vsyscall page and the
cpu_entry_area stuff can share a PGD.  The LDT could go in there, too.
The only requirement the LDT PGD has is that all of the next-level
entries that will ever be allocated are allocated at boot time.