linux-kernel - Re: [PATCH 1/3] KVM: x86: use native MSR ops for 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: <7534bcd3-e21b-240c-9ed2-62026ba10301@redhat.com>
Date:   Fri, 23 Feb 2018 18:35:30 +0100
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
Cc:     linux-kernel@...r.kernel.org, kvm@...r.kernel.org, x86@...nel.org,
        Radim Krčmář <rkrcmar@...hat.com>,
        KarimAllah Ahmed <karahmed@...zon.de>,
        David Woodhouse <dwmw@...zon.co.uk>,
        Jim Mattson <jmattson@...gle.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...nel.org>, stable@...r.kernel.org
Subject: Re: [PATCH 1/3] KVM: x86: use native MSR ops for SPEC_CTRL

On 23/02/2018 18:22, Konrad Rzeszutek Wilk wrote:
> On Fri, Feb 23, 2018 at 10:37:49AM +0100, Paolo Bonzini wrote:
>> On 22/02/2018 18:07, Konrad Rzeszutek Wilk wrote:
>>>> Having a paravirt indirect call in the IBRS restore path is not a
>>>> good idea, since we are trying to protect from speculative execution
>>>> of bogus indirect branch targets.  It is also slower, so use
>>>> native_wrmsrl on the vmentry path too.
>>> But it gets replaced during patching. As in once the machine boots
>>> the assembler changes from:
>>>
>>> 	callq 	*0xfffflbah
>>>
>>> to
>>> 	wrmsr
>>>
>>> ? I don't think you need this patch.
>>
>> Why not be explicit?  According to the spec, PRED_CMD and SPEC_CTRL
> 
> Explicit is fine.
> 
> But I would recommend you change the commit message to say so, and
> perhaps remove 'It is also slower' - as that is incorrect.

Actually it is faster---that's why I made the change in the first place,
though later I noticed

> If it is detected to be Xen PV, then yes
> it will be a call to a function. But that won't help as Xen PV runs in
> ring 3, so it has a whole bunch of other issues.

Ok, I wasn't sure about PVH (which runs in ring 0 afair).

Paolo