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:   Tue, 10 Jan 2023 09:26:44 +0000
From:   "Zhang, Chen" <chen.zhang@...el.com>
To:     "Christopherson,, Sean" <seanjc@...gle.com>,
        "Gao, Chao" <chao.gao@...el.com>
CC:     "x86@...nel.org" <x86@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "kvm@...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



> -----Original Message-----
> From: Sean Christopherson <seanjc@...gle.com>
> Sent: Friday, December 23, 2022 2:32 AM
> To: Gao, Chao <chao.gao@...el.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 Tue, Dec 20, 2022, Chao Gao wrote:
> > 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?
> 
> Work with other x86 hardware vendors to define a common interface?  Ask
> hypervisor developers to define a common, extensible interface?
> 
> Maybe it turns out that it's impossible to abstract anything away and
> everything ends up being vendor-specific anyways, but not even trying to
> provide a common interace is extremely frustrating, especially since all this
> mitigation stuff has been going on for ~5 years.  There's been plenty of time to
> establish relationships and points of contact.
> 
> > >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?
> 
> No, KVM doing its own thing would only exacerbate the issue.

Hi Sean,

Rethink about it and synced with Chao, we didn't think of a better solution than
Intel-defined interface. If you have no more suggestions/comments here,
please review the rest of patches from this series when you have time.
I will try to address comments and push this series to RFC V2.

Thanks
Chen

> 
> > 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.
> 
> Hence my frustration.