linux-kernel - Re: [PATCHv1, RFC 5/8] x86/mm: Fold p4d page table layer at runtime

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: <CAMzpN2gqK-QKwMh-tzXvU-tCKGWuhRdA6BFswsSQpT+YVuQyQQ@mail.gmail.com>
Date:   Sat, 27 May 2017 18:56:54 -0400
From:   Brian Gerst <brgerst@...il.com>
To:     "Kirill A. Shutemov" <kirill@...temov.name>
Cc:     "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        "the arch/x86 maintainers" <x86@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>, Andi Kleen <ak@...ux.intel.com>,
        Dave Hansen <dave.hansen@...el.com>,
        Andy Lutomirski <luto@...capital.net>,
        linux-arch <linux-arch@...r.kernel.org>,
        Linux-MM <linux-mm@...ck.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCHv1, RFC 5/8] x86/mm: Fold p4d page table layer at runtime

On Sat, May 27, 2017 at 6:46 PM, Kirill A. Shutemov
<kirill@...temov.name> wrote:
> On Sat, May 27, 2017 at 11:09:54AM -0400, Brian Gerst wrote:
>> >  static inline int pgd_none(pgd_t pgd)
>> >  {
>> > +       if (p4d_folded)
>> > +               return 0;
>> >         /*
>> >          * There is no need to do a workaround for the KNL stray
>> >          * A/D bit erratum here.  PGDs only point to page tables
>>
>> These should use static_cpu_has(X86_FEATURE_LA57), so that it gets
>> patched by alternatives.
>
> Right, eventually we would likely need something like this. But at this
> point I'm more worried about correctness than performance. Performance
> will be the next step.
>
> And I haven't tried it yet, but I would expect direct use of alternatives
> wouldn't be possible. If I read code correctly, we enable paging way
> before we apply alternatives. But we need to have something functional in
> between.

static_cpu_has() does the check dynamically before alternatives are
applied, so using it early isn't a problem.

--
Brian Gerst