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]

Date:   Mon, 29 Jan 2018 11:47:22 +0100
From:   Paolo Bonzini <pbonzini@...hat.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, 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 29/01/2018 09:46, David Woodhouse wrote:
> 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?

Right now we don't even use the store-on-vmexit list at all, so the
Simplest Patch That Can Possibly Work is definitely the one using
rdmsr/wrmsr.  It's not really premature optimization---though it doesn't
hurt that it isn't awfully slow.

Paolo