linux-kernel - Re: [PATCH 3/7] x86/enter: Use IBRS on syscall and interrupts

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:   Thu, 4 Jan 2018 16:08:33 -0800
From:   Dave Hansen <dave.hansen@...el.com>
To:     Peter Zijlstra <peterz@...radead.org>,
        Tim Chen <tim.c.chen@...ux.intel.com>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Andy Lutomirski <luto@...nel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Greg KH <gregkh@...uxfoundation.org>,
        Andrea Arcangeli <aarcange@...hat.com>,
        Andi Kleen <ak@...ux.intel.com>,
        Arjan Van De Ven <arjan.van.de.ven@...el.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/7] x86/enter: Use IBRS on syscall and interrupts

On 01/04/2018 02:33 PM, Peter Zijlstra wrote:
> On Thu, Jan 04, 2018 at 09:56:44AM -0800, Tim Chen wrote:
>> Set IBRS upon kernel entrance via syscall and interrupts. Clear it
>> upon exit.
> 
> So not only did we add a CR3 write, we're now adding an MSR write to the
> entry/exit paths. Please tell me that these are 'fast' MSRs? Given
> people are already reporting stupid numbers with just the existing
> PTI/CR3, what kind of pain are we going to get from adding this?

This "dynamic IBRS" that does runtime switching will not be on by
default and will be patched around by alternatives unless someone
explicitly opts in.

If you decide you want the additional protection that it provides, you
can take the performance hit.  How much is that?  We've been saying that
these new MSRs are roughly as expensive as the CR3 writes.  How
expensive are those?  Don't take my word for it, a few folks were
talking about it today:

Google says[1]: "We see negligible impact on performance."
Amazon says[2]: "We don’t expect meaningful performance impact."

I chopped a few qualifiers out of there, but I think that roughly
captures the sentiment.

1.
https://security.googleblog.com/2018/01/more-details-about-mitigations-for-cpu_4.html
2.
http://www.businessinsider.com/google-amazon-performance-hit-meltdown-spectre-fixes-overblown-2018-1