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

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] [day] [month] [year] [list]

Message-ID: <aKXX1nOJb_q7GjQR@google.com>
Date: Wed, 20 Aug 2025 07:12:38 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Chao Gao <chao.gao@...el.com>
Cc: kvm@...r.kernel.org, linux-kernel@...r.kernel.org, mlevitsk@...hat.com, 
	rick.p.edgecombe@...el.com, weijiang.yang@...el.com, xin@...or.com, 
	Mathias Krause <minipli@...ecurity.net>, John Allen <john.allen@....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>
Subject: Re: [PATCH v12 15/24] KVM: VMX: Emulate read and write to CET MSRs

On Wed, Aug 20, 2025, Chao Gao wrote:
> >> +	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?

If the VMM configures the virtual CPU model to be a 32-bit CPU, i.e. a vCPU that
"does not support Intel 64 architecture", i.e. CPUID.0x80000001.EDX.LM = 0, then
the behavior of the "hardware" that the guest sees should be that the upper 32
bits do not exist and should always read '0'.  But because the actual harware on
which the virtual CPU is running _does_ support Intel 64, XRSTORS/XSAVES in the
guest could observe behavior that violates the architecture.