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

Message-ID: <aKS5aUeP-X6eED-R@google.com>
Date: Tue, 19 Aug 2025 10:50:33 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Rick P Edgecombe <rick.p.edgecombe@...el.com>
Cc: Chao Gao <chao.gao@...el.com>, Weijiang Yang <weijiang.yang@...el.com>, 
	"mingo@...hat.com" <mingo@...hat.com>, "x86@...nel.org" <x86@...nel.org>, "bp@...en8.de" <bp@...en8.de>, 
	"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>, "hpa@...or.com" <hpa@...or.com>, 
	"john.allen@....com" <john.allen@....com>, 
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, 
	"minipli@...ecurity.net" <minipli@...ecurity.net>, "tglx@...utronix.de" <tglx@...utronix.de>, 
	"pbonzini@...hat.com" <pbonzini@...hat.com>, "kvm@...r.kernel.org" <kvm@...r.kernel.org>, 
	"xin@...or.com" <xin@...or.com>, "mlevitsk@...hat.com" <mlevitsk@...hat.com>
Subject: Re: [PATCH v12 15/24] KVM: VMX: Emulate read and write to CET MSRs

On Tue, Aug 19, 2025, Rick P Edgecombe wrote:
> On Tue, 2025-08-19 at 09:09 -0700, Sean Christopherson wrote:
> > 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.
> > 
> > Unless someone has a better idea, I'm inclined to take an erratum for this, i.e.
> > just sweep it under the rug.
> 
> Sounds ok to me. All I could think would be something like use the CR/EFER
> interceptions and just exit to userspace if (CR0.PE && !EFER.LM && CR4.CET). But
> this would require some rototilling and then likely remain un-exercised.

And a far worse experience if a guest did ever trip that combo.  Letting the guest
set bits 63:32 would only cause problems if the guest is being deliberately weird,
whereas exiting to userspace would terminate even well-behaved guests (though as
you note, the odds of a 32-bit guest using CET is quite small...).

> Not sure it's worth it.