linux-kernel - Re: [PATCH 12/30] x86, kaiser: map GDT into user page tables

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]

Date:   Tue, 21 Nov 2017 15:46:05 -0700
From:   Andy Lutomirski <luto@...capital.net>
To:     Dave Hansen <dave.hansen@...ux.intel.com>
Cc:     Andy Lutomirski <luto@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        moritz.lipp@...k.tugraz.at,
        Daniel Gruss <daniel.gruss@...k.tugraz.at>,
        michael.schwarz@...k.tugraz.at, richard.fellner@...dent.tugraz.at,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Kees Cook <keescook@...gle.com>,
        Hugh Dickins <hughd@...gle.com>, X86 ML <x86@...nel.org>
Subject: Re: [PATCH 12/30] x86, kaiser: map GDT into user page tables

> On Nov 21, 2017, at 2:19 PM, Dave Hansen <dave.hansen@...ux.intel.com> wrote:
> 
> On 11/20/2017 12:46 PM, Andy Lutomirski wrote:
>>>> +     /*
>>>> +      * We could theoretically do this in setup_fixmap_gdt().
>>>> +      * But, we would need to rewrite the above page table
>>>> +      * allocation code to use the bootmem allocator.  The
>>>> +      * buddy allocator is not available at the time that we
>>>> +      * call setup_fixmap_gdt() for CPU 0.
>>>> +      */
>>>> +     kaiser_add_user_map_early(get_cpu_gdt_ro(0), PAGE_SIZE,
>>>> +                               __PAGE_KERNEL_RO | _PAGE_GLOBAL);
>>> This one is needs to stay.
>> When you rebase on to my latest version, this should change to mapping
>> the entire cpu_entry_area.
> 
> I did this, but unfortunately it ends up having to individually map all
> four pieces of cpu_entry_area.  They all need different permissions and
> while theoretically we could do TSS+exception-stacks in the same call,
> they're not next to each other:
> 
> GDT: R/O
> TSS: R/W at least because of trampoline stack
> entry code: EXEC+R/O
> exception stacks: R/W

Can you avoid code duplication by adding some logic right after the kernel cpu_entry_area is set up to iterate page by page over the PTEs in the cpu_entry_area for that CPU and just install exactly the same PTEs into the kaiser table?  E.g. just call kaiser_add_mapping once per page but with the parameters read out from the fixmap PTEs instead of hard coded?

As a fancier but maybe better option, we could fiddle with the fixmap indices so that the whole cpu_entry_area range is aligned to a PMD boundary or higher.  We'd preallocate all the page tables for this range before booting any APs.  Then the kaiser tables could just reference the same page tables, and we don't need any AP kaiser setup at all.

This should be a wee bit faster, too, since we reduce the number of cache lines needed to refill the TLB when needed.

I'm really hoping we can get rid of kaiser_add_mapping entirely.