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 12:26:43 -0800
From:   Tim Chen <tim.c.chen@...ux.intel.com>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Andy Lutomirski <luto@...nel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Dave Hansen <dave.hansen@...el.com>,
        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 12:00 PM, Greg KH wrote:
> On Thu, Jan 04, 2018 at 09:56:44AM -0800, Tim Chen wrote:
>>
>> That is a minor inefficiency only, but we can eliminate it by saving
>> the MSR when entering the NMI in save_paranoid and restoring it when
>> exiting the NMI.
> 
> Any hints as to what exactly "minor" means in cycles here?  :)
> 

The current implementation does not have this inefficiency.  The
comment is to explain why we need to save the IBRS state in save_paranoid.

The issue is if we don't save the IBRS state for NMI,
For nested interrupts, it is hard to
figure out when we are returning from NMI, whether we are
returning to user space or kernel space.  And if we do the safe
thing by leaving IBRS on, there is a possibility that we may
return to user space with IBRS enabled, which will affect performance.

The possibility of hitting this is minor, but still we want
to eliminate it.

Thanks.

Tim
 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ