Re: [PATCH v12 15/24] KVM: VMX: Emulate read and write to CET MSRs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>> +	case MSR_IA32_PL0_SSP ... MSR_IA32_INT_SSP_TAB:
>> +		if (!guest_cpu_cap_has(vcpu, X86_FEATURE_SHSTK))
>> +			return KVM_MSR_RET_UNSUPPORTED;
>> +		if (is_noncanonical_msr_address(data, vcpu))
>
>This emulation is wrong (in no small part because the architecture sucks).  From
>the SDM:
>
>  If the processor does not support Intel 64 architecture, these fields have only
>  32 bits; bits 63:32 of the MSRs are reserved.
>
>  On processors that support Intel 64 architecture this value cannot represent a
>  non-canonical address.
>
>  In protected mode, only 31:0 are loaded.
>
>That means KVM needs to drop bits 63:32 if the vCPU doesn't have LM or if the vCPU
>isn't in 64-bit mode.  The last one is especially frustrating, because software
>can still get a 64-bit value into the MSRs while running in protected, e.g. by
>switching to 64-bit mode, doing WRMSRs, then switching back to 32-bit mode.
>
>But, there's probably no point in actually trying to correctly emulate/virtualize
>the Protected Mode behavior, because the MSRs can be written via XRSTOR, and to
>close that hole KVM would need to trap-and-emulate XRSTOR.  No thanks.

I don't get why we need to trap-and-emulate XRSTOR. if XRSTOR instruction in
protection mode can change higher 32 bits of CET MSRs, it is the hardware
behavior. why KVM needs to clear the higher 32 bits?

>
>Unless someone has a better idea, I'm inclined to take an erratum for this, i.e.
>just sweep it under the rug.
>
>> +			return 1;
>> +		/* All SSP MSRs except MSR_IA32_INT_SSP_TAB must be 4-byte aligned */
>> +		if (index != MSR_IA32_INT_SSP_TAB && !IS_ALIGNED(data, 4))
>> +			return 1;
>> +		break;
>>  	}
>>  
>>  	msr.data = data;
>
>...
>
>> diff --git a/arch/x86/kvm/x86.h b/arch/x86/kvm/x86.h
>> index f8fbd33db067..d5b039addd11 100644
>> --- a/arch/x86/kvm/x86.h
>> +++ b/arch/x86/kvm/x86.h
>> @@ -733,4 +733,27 @@ static inline void kvm_set_xstate_msr(struct kvm_vcpu *vcpu,
>>  	kvm_fpu_put();
>>  }
>>  
>> +#define CET_US_RESERVED_BITS		GENMASK(9, 6)
>> +#define CET_US_SHSTK_MASK_BITS		GENMASK(1, 0)
>> +#define CET_US_IBT_MASK_BITS		(GENMASK_ULL(5, 2) | GENMASK_ULL(63, 10))
>> +#define CET_US_LEGACY_BITMAP_BASE(data)	((data) >> 12)
>> +
>> +static inline bool is_cet_msr_valid(struct kvm_vcpu *vcpu, u64 data)
>
>This name is misleading, e.g. it reads "is this CET MSR valid", whereas the helper
>is checking "is this value for U_CET or S_CET valid".  Maybe kvm_is_valid_u_s_cet()?

Will do.




[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux