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]

Message-ID: <Y6G77CTIk8CvtTLn@gao-cwp>
Date:   Tue, 20 Dec 2022 21:43:08 +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 Mon, Dec 19, 2022 at 05:14:00PM +0000, Sean Christopherson wrote:
>On Mon, Dec 19, 2022, Chao Gao wrote:
>> On Wed, Dec 14, 2022 at 08:18:17PM +0000, Sean Christopherson wrote:
>> > 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.
>
>I never said the PV interfaces should be defined by KVM.  I 100% agree that any
>one hypervisor defining its own interface will suffer the same problem.

I am thinking there are only two options:

1. Intel defines the interface.
2. Every VMM defines its own interface.

Any middle ground between the two options?

>
>I think having a PV interface for coordinating mitigations between host and guest
>is a great idea.  What I don't like is tying the interface to "hardware" and defining

Do you think something below is better than the intel-defined interface?
add a new KVM_CAP_* and a KVM_FEATURE_* in hypervisor CPUID leaf to enumerate
the interface. And add a new virtual MSR 0x4b564dxx for guest to report in-use
software mitigations and assign one bit for each software mitigation. On MSR
write emulation, call into vmx code to enable some hardware mitigations if
the corresponding software mitigations are not effective on host.

I am afraid it is late to switch to above approach because e.g., if Hyper-V
decides to support the intel-defined interface, KVM probably needs to support it
for Hyper-V guests.

Can we emulate IA32_ARCH_CAPABILITIES for AMD guests so that AMD can re-use
intel-defined interface?

>the interface without even trying to collaborate with others.

I will pass on this to related Intel folks and ask them to collaborate with
KVM community on future PV interfaces.