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: <8e382c5a-1d8d-44e6-87f4-176305493a47@intel.com>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ