linux-kernel - Re: [RFC PATCH v2 06/11] KVM: x86: Advertise ARCH_CAP_VIRTUAL

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:   Fri, 19 May 2023 17:57:21 +0800
From:   Chao Gao <chao.gao@...el.com>
To:     Xiaoyao Li <xiaoyao.li@...el.com>
CC:     <kvm@...r.kernel.org>, Jiaan Lu <jiaan.lu@...el.com>,
        Zhang Chen <chen.zhang@...el.com>,
        Sean Christopherson <seanjc@...gle.com>,
        "Paolo Bonzini" <pbonzini@...hat.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        "Ingo Molnar" <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>, <x86@...nel.org>,
        "H. Peter Anvin" <hpa@...or.com>, <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH v2 06/11] KVM: x86: Advertise ARCH_CAP_VIRTUAL_ENUM
 support

On Thu, May 18, 2023 at 06:14:40PM +0800, Xiaoyao Li wrote:
>>   static u32 msr_based_features[ARRAY_SIZE(msr_based_features_all)];
>> @@ -1591,7 +1593,8 @@ static unsigned int num_msr_based_features;
>>   	 ARCH_CAP_SKIP_VMENTRY_L1DFLUSH | ARCH_CAP_SSB_NO | ARCH_CAP_MDS_NO | \
>>   	 ARCH_CAP_PSCHANGE_MC_NO | ARCH_CAP_TSX_CTRL_MSR | ARCH_CAP_TAA_NO | \
>>   	 ARCH_CAP_SBDR_SSDP_NO | ARCH_CAP_FBSDP_NO | ARCH_CAP_PSDP_NO | \
>> -	 ARCH_CAP_FB_CLEAR | ARCH_CAP_RRSBA | ARCH_CAP_PBRSB_NO)
>> +	 ARCH_CAP_FB_CLEAR | ARCH_CAP_RRSBA | ARCH_CAP_PBRSB_NO | \
>> +	 ARCH_CAP_VIRTUAL_ENUM)
>
>We cannot do it.
>
>Otherwise, an AMD L1 with X86_FEATURE_ARCH_CAPABILITIES configured is
>possible to expose MSR_VIRTUAL_ENUMERATION to L2 while no support for it.

How does AMD L1 see the ARCH_CAP_VIRTUAL_ENUM feature in the first
place? because ...

>
>>   static u64 kvm_get_arch_capabilities(void)
>>   {
>> @@ -1610,6 +1613,17 @@ static u64 kvm_get_arch_capabilities(void)
>>   	 */
>>   	data |= ARCH_CAP_PSCHANGE_MC_NO;
>> +	/*
>> +	 * Virtual enumeration is a paravirt feature. The only usage for now
>> +	 * is to bridge the gap caused by microarchitecture changes between
>> +	 * different Intel processors. And its usage is linked to "virtualize
>> +	 * IA32_SPEC_CTRL" which is a VMX feature. Whether AMD SVM can benefit
>> +	 * from the same usage and how to implement it is still unclear. Limit
>> +	 * virtual enumeration to VMX.
>> +	 */
>> +	if (static_call(kvm_x86_has_emulated_msr)(NULL, MSR_VIRTUAL_ENUMERATION))
>> +		data |= ARCH_CAP_VIRTUAL_ENUM;

the feature is exposed on Intel CPUs only.

Do you mean AMD L1 created on Intel L0? and Intel L0 even emulates
nested (SVM) support for the L1? This sounds a very contrived case.

>> +
>>   	/*
>>   	 * If we're doing cache flushes (either "always" or "cond")
>>   	 * we will do one whenever the guest does a vmlaunch/vmresume.
>