linux-kernel - Re: [RFC PATCH 5/9] x86/bugs: Use Virtual MSRs to request hardware mitigations

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, 19 Dec 2022 21:56:02 +0800
From:   Chao Gao <chao.gao@...el.com>
To:     Sean Christopherson <seanjc@...gle.com>
CC:     Zhang Chen <chen.zhang@...el.com>, <x86@...nel.org>,
        <linux-kernel@...r.kernel.org>, <kvm@...r.kernel.org>,
        Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Borislav Petkov <bp@...en8.de>, Ingo Molnar <mingo@...hat.com>,
        "Thomas Gleixner" <tglx@...utronix.de>
Subject: Re: [RFC PATCH 5/9] x86/bugs: Use Virtual MSRs to request hardware
 mitigations

On Wed, Dec 14, 2022 at 08:18:17PM +0000, Sean Christopherson wrote:
>On Sun, Dec 11, 2022, Zhang Chen wrote:
>> From: Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>
>> 
>> Guests that have different family/model than the host may not be aware
>> of hardware mitigations(such as RRSBA_DIS_S) available on host. This is
>> particularly true when guests migrate. To solve this problem Intel
>> processors have added a virtual MSR interface
>
>Is there any actual "processor" support here?

No.

>  To me, this looks like Intel is
>foisting a paravirt interface on KVM and other hypervisors without collaborating
>with said hypervisors' developers and maintainers.
>
>I get that some of the mitigations are vendor specific, but things like RETPOLINE
>aren't vendor specific.  I haven't followed all of the mitigation stuff very
>closely, but I wouldn't be surprised if there are mitigations now or in the future
>that are common across architectures, e.g. arm64 and x86-64.  Intel doing its own
>thing means AMD and arm64 will likely follow suit, and suddenly KVM is supporting
>multiple paravirt interfaces for very similar things, without having any control
>over the APIs.  That's all kinds of backwards.

But if the interface is defined by KVM rather than Intel, it will likely end up
with different interfaces for different VMMs, then Linux guest needs to support
all of them. And KVM needs to implement Hyper-V's and Xen's interface to support
Hyper-V enlightened and Xen enlightened guest. This is a _real_ problem and
complicates KVM/Linux in a similar way as multiple paravirt interfaces.

The use case of this paravirt interface is specific to Intel CPU microarchitecture.
Supporting multiple paravirt interfaces may not happen in the near future if there
is no use case for AMD and arm64.

>
>And having to wait for Intel to roll out new documentation when software inevitably
>comes up with some clever new mitigation doesn't exactly fill my heart with joy.

There should be some misunderstanding.

A bit for a software mitigation will be added if
1. the software mitigation works well on existing processors. And
2. there will be a new processor on which the software mitigation won't be
   fully effective (due to some microarchiecture change).

IOW, the new documentation comes along with a new microarchitecture (new
processor) rather than software mitigations.