linux-kernel - Re: [PATCH] x86: vmx: Allow direct access to MSR_IA32_SPEC

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: <8bed4a5a-afc6-1569-d9bf-a3e1103e92f8@amazon.com>
Date:   Mon, 29 Jan 2018 10:43:23 +0100
From:   KarimAllah Ahmed <karahmed@...zon.com>
To:     David Woodhouse <dwmw2@...radead.org>,
        Liran Alon <liran.alon@...cle.com>
CC:     <konrad.wilk@...cle.com>, <luto@...nel.org>, <tglx@...utronix.de>,
        <torvalds@...ux-foundation.org>, <gregkh@...uxfoundation.org>,
        <asit.k.mallick@...el.com>, <dave.hansen@...el.com>,
        <karahmed@...zon.de>, <jun.nakajima@...el.com>,
        <dan.j.williams@...el.com>, <ashok.raj@...el.com>,
        <daniel.kiper@...cle.com>, <arjan.van.de.ven@...el.com>,
        <tim.c.chen@...ux.intel.com>, <pbonzini@...hat.com>,
        <linux-kernel@...r.kernel.org>, <ak@...ux.intel.com>,
        <kvm@...r.kernel.org>, <aarcange@...hat.com>
Subject: Re: [PATCH] x86: vmx: Allow direct access to MSR_IA32_SPEC_CTRL

On 01/29/2018 09:46 AM, David Woodhouse wrote:
> On Sun, 2018-01-28 at 16:39 -0800, Liran Alon wrote:
>>
>> Windows use IBRS and Microsoft don't have any plans to switch to retpoline.
>> Running a Windows guest should be a pretty common use-case no?
>>
>> In addition, your handle of the first WRMSR intercept could be different.
>> It could signal you to start doing the following:
>> 1. Disable intercept on SPEC_CTRL MSR.
>> 2. On VMEntry, Write vCPU SPEC_CTRL value into physical MSR.
>> 3. On VMExit, read physical MSR into vCPU SPEC_CTRL value.
>> (And if IBRS is used at host, also set physical SPEC_CTRL MSR here to 1)
>>
>> That way, you will both have fastest option as long as guest don't use IBRS
>> and also won't have the 3% performance hit compared to Konrad's proposal.
>>
>> Am I missing something?
> 
> Reads from the SPEC_CTRL MSR are strangely slow. I suspect a large part
> of the 3% speedup you observe is because in the above, the vmentry path
> doesn't need to *read* the host's value and store it; the host is
> expected to restore it for itself anyway?
> 
> I'd actually quite like to repeat the benchmark on the new fixed
> microcode, if anyone has it yet, to see if that read/swap slowness is
> still quite as excessive. I'm certainly not ruling this out, but I'm
> just a little wary of premature optimisation, and I'd like to make sure
> we have everything *else* in the KVM patches right first.
> 
> The fact that the save-and-restrict macros I have in the tip of my
> working tree at the moment are horrid and causing 0-day nastygrams,
> probably doesn't help persuade me to favour the approach ;)
> 
> ... hm, the CPU actually has separate MSR save/restore lists for
> entry/exit, doesn't it? Is there any way to sanely make use of that and
> do the restoration manually on vmentry but let it be automatic on
> vmexit, by having it *only* in the guest's MSR-store area to be saved
> on exit and restored on exit, but *not* in the host's MSR-store area?
> 
> Reading the code and comparing with the SDM, I can't see where we're
> ever setting VM_EXIT_MSR_STORE_{ADDR,COUNT} except in the nested
> case...

Hmmm ... you are probably right! I think all users of this interface
always trap + update save area and never passthrough the MSR. That is
why only LOAD is needed *so far*.

Okay, let me sort this out in v3 then.

> 
Amazon Development Center Germany GmbH
Berlin - Dresden - Aachen
main office: Krausenstr. 38, 10117 Berlin
Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger
Ust-ID: DE289237879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B