Re: [PATCH 04/11] KVM: VMX: Read 32-bit GPR values for ENCLS instructions outside of 64-bit mode

[Huang, Kai]

On Wed, 2026-04-15 at 14:37 -0700, Sean Christopherson wrote:
> On Mon, Apr 13, 2026, Kai Huang wrote:
> > On Thu, 2026-04-09 at 16:56 -0700, Sean Christopherson wrote:
> > > When getting register values for ENCLS emulation, use kvm_register_read()
> > > instead of kvm_<reg>_read() so that bits 63:32 of the register are dropped
> > > if the guest is in 32-bit mode.
> > > 
> > > Note, the misleading/surprising behavior of kvm_<reg>_read() being "raw"
> > > variants under the hood will be addressed once all non-benign bugs are
> > > fixed.
> > > 
> > > Fixes: 70210c044b4e ("KVM: VMX: Add SGX ENCLS[ECREATE] handler to enforce CPUID restrictions")
> > > Fixes: b6f084ca5538 ("KVM: VMX: Add ENCLS[EINIT] handler to support SGX Launch Control (LC)")
> > > Signed-off-by: Sean Christopherson <seanjc@xxxxxxxxxx>
> > > ---
> > >  arch/x86/kvm/vmx/sgx.c | 10 +++++-----
> > >  1 file changed, 5 insertions(+), 5 deletions(-)
> > > 
> > > diff --git a/arch/x86/kvm/vmx/sgx.c b/arch/x86/kvm/vmx/sgx.c
> > > index df1d0cf76947..4c61fc33f764 100644
> > > --- a/arch/x86/kvm/vmx/sgx.c
> > > +++ b/arch/x86/kvm/vmx/sgx.c
> > > @@ -225,8 +225,8 @@ static int handle_encls_ecreate(struct kvm_vcpu *vcpu)
> > >  	struct x86_exception ex;
> > >  	int r;
> > >  
> > > -	if (sgx_get_encls_gva(vcpu, kvm_rbx_read(vcpu), 32, 32, &pageinfo_gva) ||
> > > -	    sgx_get_encls_gva(vcpu, kvm_rcx_read(vcpu), 4096, 4096, &secs_gva))
> > > +	if (sgx_get_encls_gva(vcpu, kvm_register_read(vcpu, VCPU_REGS_RBX), 32, 32, &pageinfo_gva) ||
> > > +	    sgx_get_encls_gva(vcpu, kvm_register_read(vcpu, VCPU_REGS_RCX), 4096, 4096, &secs_gva))
> > >  		return 1;
> > >  
> > >  	/*
> > > @@ -302,9 +302,9 @@ static int handle_encls_einit(struct kvm_vcpu *vcpu)
> > >  	gpa_t sig_gpa, secs_gpa, token_gpa;
> > >  	int ret, trapnr;
> > >  
> > > -	if (sgx_get_encls_gva(vcpu, kvm_rbx_read(vcpu), 1808, 4096, &sig_gva) ||
> > > -	    sgx_get_encls_gva(vcpu, kvm_rcx_read(vcpu), 4096, 4096, &secs_gva) ||
> > > -	    sgx_get_encls_gva(vcpu, kvm_rdx_read(vcpu), 304, 512, &token_gva))
> > > +	if (sgx_get_encls_gva(vcpu, kvm_register_read(vcpu, VCPU_REGS_RBX), 1808, 4096, &sig_gva) ||
> > > +	    sgx_get_encls_gva(vcpu, kvm_register_read(vcpu, VCPU_REGS_RCX), 4096, 4096, &secs_gva) ||
> > > +	    sgx_get_encls_gva(vcpu, kvm_register_read(vcpu, VCPU_REGS_RDX), 304, 512, &token_gva))
> > >  		return 1;
> > > 
> > 
> > Is there any case where bits 63:32 can have non-zero value?
> 
> Yes, GPR values aren't modified on transitions to/from 64-bit mode.  E.g. if
> software loads 64-bit values in 64-bit mode, under the hood those values will
> still be there while the CPU is in 32-bit/compat mode.
> 
> Well, that's not strictly true, per the SDM.  Values are only preseverd for R8-R15
> on compat<=>64-bit transitions:
> 
>   Registers only available in 64-bit mode (R8-R15 and XMM8-XMM15) are preserved
>   across transitions from 64-bit mode into compatibility mode then back into
>   64-bit mode. However, values of R8-R15 and XMM8-XMM15 are unde- fined after
>   transitions from 64-bit mode through compatibility mode to legacy or real mode
>   and then back through compatibility mode to 64-bit mode.
> 
> And "legacy" GPRs are never preserved:
> 
>   Because the upper 32 bits of 64-bit general-purpose registers are undefined in
>   32-bit modes, the upper 32 bits of any general-purpose register are not preserved
>   when switching from 64-bit mode to a 32-bit mode (to protected mode or
>   compatibility mode). Software must not depend on these bits to maintain a value
>   after a 64-bit to 32-bit mode switch.

Yes.  I got the same from the SDM.

> 
> But IIRC, that's "just" the architectural behavior.  Hardware implementations may
> choose to preserve values.

That seems to be a violation to a "basic" architecture :-)

> 
> > If vCPU is in 32-bit mode then it should not be able to access 64-bit GPR?
> 
> Yes and no.  Mostly no.  Architecturally, they're all off limits.  But, again
> going from memory that's ~15 years old at this point, IIRC the behavior is that
> writes in 32-bit modes zero bits 63:32, same as 32-bit writes in 64-bit mode.
> 
> Take all of my memory with a huge grain of salt, it's very possible I'm
> mis-remembering hallway discussions from a long time ago.

I tend to think it's beyond the point we need to worry about.  It shouldn't
happen even the guest is buggy or malicious AFAICT, unless KVM somehow
messes things up itself, in which case a WARN() is more reasonable I
suppose.

This also made me look into whether how VMENTER handles GPRs when vCPU is
not in 64-bit mode.  I see nothing described in the SDM except VMENTRY
checks "guest's" RIP and RFLAGS.  Maybe KVM should explicitly clear high
bits of GPRs when going back to compatible mode from 64-bit mode, or maybe
hardware does it?