linux-kernel - Re: [tip:x86/mm] x86/boot/compressed/64: Describe the logic behind the LA57 check

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] [day] [month] [year] [list]

Message-ID: <1248489e-6776-7731-0dad-36f8b62b1925@intel.com>
Date:   Mon, 12 Mar 2018 10:21:01 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     Andy Lutomirski <luto@...nel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
        Ingo Molnar <mingo@...nel.org>,
        "Kirill A. Shutemov" <kirill@...temov.name>,
        Peter Zijlstra <peterz@...radead.org>,
        Cyrill Gorcunov <gorcunov@...nvz.org>,
        Kees Cook <keescook@...omium.org>,
        Matthew Wilcox <willy@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Borislav Petkov <bp@...e.de>,
        Andy Shevchenko <andy.shevchenko@...il.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Peter Anvin <hpa@...or.com>,
        "Eric W. Biederman" <ebiederm@...ssion.com>,
        Jürgen Groß <jgross@...e.com>,
        linux-tip-commits@...r.kernel.org
Subject: Re: [tip:x86/mm] x86/boot/compressed/64: Describe the logic behind
 the LA57 check

On 03/12/2018 10:06 AM, Andy Lutomirski wrote:
> I'd be surprised if there's a noticeable performance hit on anything
> except the micro-est of benchmarks.  We're talking one extra
> intermediate paging structure cache entry in use, maybe a few data
> cache lines, and (wild guess) 0 extra cycles on a TLB miss in the
> normal case.  This is because the walks are almost never going to
> start at the root.

The hardware guys are keenly aware of the concerns about the extra
latency that the extra level might cause us.  I frankly expect that
we'll see the overhead in *software* via get_user_pages() and friends
before we ever see a practical bump in TLB fill latency.

I'm also super in favor of enabling LA57 everywhere that we can, up
front, and only disabling selectively it if it has real-world problems.
It makes our lives (as Intel software people) massively easier because
we don't have to go tell everyone how to turn it on in the first place
to test it.