| 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
| ||
|
Message-ID: <MWHPR11MB00315B3E8EFA05E62F37A41D9BF39@MWHPR11MB0031.namprd11.prod.outlook.com>
Date: Thu, 29 Dec 2022 09:56:29 +0000
From: "Zhang, Chen" <chen.zhang@...el.com>
To: "Yang, Weijiang" <weijiang.yang@...el.com>
CC: "Gao, Chao" <chao.gao@...el.com>,
Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>,
Paolo Bonzini <pbonzini@...hat.com>,
"Christopherson,, Sean" <seanjc@...gle.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>,
"x86@...nel.org" <x86@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>
Subject: RE: [RFC PATCH 6/9] kvm/x86: Add ARCH_CAP_VIRTUAL_ENUM for guest
MSR_IA32_ARCH_CAPABILITIES
> -----Original Message-----
> From: Yang, Weijiang <weijiang.yang@...el.com>
> Sent: Thursday, December 29, 2022 4:39 PM
> To: Zhang, Chen <chen.zhang@...el.com>
> Cc: Gao, Chao <chao.gao@...el.com>; Pawan Gupta
> <pawan.kumar.gupta@...ux.intel.com>; Paolo Bonzini
> <pbonzini@...hat.com>; Christopherson,, Sean <seanjc@...gle.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>; x86@...nel.org; linux-kernel@...r.kernel.org;
> kvm@...r.kernel.org
> Subject: Re: [RFC PATCH 6/9] kvm/x86: Add ARCH_CAP_VIRTUAL_ENUM for
> guest MSR_IA32_ARCH_CAPABILITIES
>
>
> On 12/29/2022 3:41 PM, Zhang, Chen wrote:
> >
> >> -----Original Message-----
> >> From: Yang, Weijiang <weijiang.yang@...el.com>
> >> Sent: Thursday, December 29, 2022 3:03 PM
> >> To: Zhang, Chen <chen.zhang@...el.com>
> >> Cc: Gao, Chao <chao.gao@...el.com>; Pawan Gupta
> >> <pawan.kumar.gupta@...ux.intel.com>; Paolo Bonzini
> >> <pbonzini@...hat.com>; Christopherson,, Sean <seanjc@...gle.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>;
> >> x86@...nel.org; linux-kernel@...r.kernel.org; kvm@...r.kernel.org
> >> Subject: Re: [RFC PATCH 6/9] kvm/x86: Add ARCH_CAP_VIRTUAL_ENUM for
> >> guest MSR_IA32_ARCH_CAPABILITIES
> >>
> >>
> >> On 12/29/2022 10:58 AM, Zhang, Chen wrote:
> >>
> >> [...]
> >>
> >>>> \
> >>>>> + ARCH_CAP_VIRTUAL_ENUM)
> >>>>>
> >>>>> static u64 kvm_get_arch_capabilities(void)
> >>>>> {
> >>>>> @@ -1607,6 +1611,13 @@ static u64 kvm_get_arch_capabilities(void)
> >>>>> */
> >>>>> data |= ARCH_CAP_PSCHANGE_MC_NO;
> >>>>>
> >>>>> + /*
> >>>>> + * Virtual MSRs can allow guests to notify VMM whether or not
> >>>>> + * they are using specific software mitigation, allowing a VMM
> >>>>> + * to enable there hardware control only where necessary.
> >>>>> + */
> >>>>> + data |= ARCH_CAP_VIRTUAL_ENUM;
> >>>> IMO, this is: data &= ARCH_CAP_VIRTUAL_ENUM; because it requires
> >>>> platform support.
> >>> Intel defined the virtual MSRs for software mitigations for all platforms.
> >>> KVM should be unconditionally opened it for the software mitigation
> >>> in
> >> migration pools.
> >>> For example migration from the old platform to the new platform.
> >>> Please check the Software Mitigations in Migration Pools section in
> >> documents:
> >>> https://www.intel.com/content/www/us/en/developer/articles/technical
> >>> /s
> >>> oftware-security-guidance/technical-documentation/branch-history-inj
> >>> ec
> >>> tion.html
> >> If this series running on old platforms, how VMM can set specific
> >> vmcs fields,
> >>
> >> e.g., “virtualize IA32_SPEC_CTRL” VM-execution control, to mitigate
> >> guest issues?
> > Enable the virtual MSRs does not means to enable the “virtualize
> IA32_SPEC_CTRL”.
> > KVM will check "cpu_has_virt_spec_ctrl()" before set specific VMCS.
>
>
> What I'm concerned is, if the feature is not supported on some platforms,
> unconditionally
>
> exposing to guest would make it wrongly "think" the feature is supported on
> HW, but actually
>
> WMM can do nothing to mitigate issues. Read through the patch set, looks like
> guest cannot
>
> even get any errors during feature configuration in this case. So I suggest add
> more
>
> sanity checks. Did I miss something?
Understand your concern, but I think no need to concern about it.
Although we have unconditionally turned on virtual MSRs in all platforms,
The detailed virtual MSR bits still can tell guest what feature is supported on HW.
QEMU will setup the MSR_VIRTUAL_MITIGATION_ENUM(0x50000001) bits
Like the BHB_CLEAR_SEQ_S_SUPPORT/RETPOLINE_S_SUPPORT before boot VMs.
Thanks
Chen
>
>
> >
> > Thanks
> > Chen
> >
> >>
> >>>>> +
> >>>>> /*
> >>>>> * If we're doing cache flushes (either "always" or "cond")
> >>>>> * we will do one whenever the guest does a
> vmlaunch/vmresume.
> >>>>> @@ -1657,6 +1668,9 @@ static int kvm_get_msr_feature(struct
> >>>> kvm_msr_entry *msr)
> >>>>> case MSR_IA32_UCODE_REV:
> >>>>> rdmsrl_safe(msr->index, &msr->data);
> >>>>> break;
> >>>>> + case MSR_VIRTUAL_ENUMERATION:
> >>>>> + msr->data = VIRT_ENUM_MITIGATION_CTRL_SUPPORT;
> >>>> Need to check bit 63 of host MSR_ARCH_CAPABILITIES before expose
> >>>> the feature.
> >>> Refer to the above comments.
> >>>
> >>> Thanks
> >>> Chen
> >>>
> >>>>> + break;
> >>>>> default:
> >>>>> return static_call(kvm_x86_get_msr_feature)(msr);
> >>>>> }
Powered by blists - more mailing lists