diff mbox series

[1/3] KVM: VMX: Don't rely _only_ on CPUID to enforce XCR0 restrictions for ECREATE

Message ID 20230405005911.423699-2-seanjc@google.com
State New
Headers
Series [1/3] KVM: VMX: Don't rely _only_ on CPUID to enforce XCR0 restrictions for ECREATE |

Commit Message

Sean Christopherson April 5, 2023, 12:59 a.m. UTC 
  Explicitly check the vCPU's supported XCR0 when determining whether or not
the XFRM for ECREATE is valid.  Checking CPUID works because KVM updates
guest CPUID.0x12.1 to restrict the leaf to a subset of the guest's allowed
XCR0, but that is rather subtle and KVM should not modify guest CPUID
except for modeling true runtime behavior (allowed XFRM is most definitely
not "runtime" behavior).

Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 arch/x86/kvm/vmx/sgx.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

Comments

Kai Huang April 5, 2023, 10:52 a.m. UTC | #1 
On Tue, 2023-04-04 at 17:59 -0700, Sean Christopherson wrote:
> Explicitly check the vCPU's supported XCR0 when determining whether or not
> the XFRM for ECREATE is valid.  Checking CPUID works because KVM updates
> guest CPUID.0x12.1 to restrict the leaf to a subset of the guest's allowed
> XCR0, but that is rather subtle and KVM should not modify guest CPUID
> except for modeling true runtime behavior (allowed XFRM is most definitely
> not "runtime" behavior).
> 
> Signed-off-by: Sean Christopherson <seanjc@google.com>
> ---
>  arch/x86/kvm/vmx/sgx.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/kvm/vmx/sgx.c b/arch/x86/kvm/vmx/sgx.c
> index aa53c98034bf..362a31b19b0e 100644
> --- a/arch/x86/kvm/vmx/sgx.c
> +++ b/arch/x86/kvm/vmx/sgx.c
> @@ -175,7 +175,8 @@ static int __handle_encls_ecreate(struct kvm_vcpu *vcpu,
>  	    (u32)attributes & ~sgx_12_1->eax ||
>  	    (u32)(attributes >> 32) & ~sgx_12_1->ebx ||
>  	    (u32)xfrm & ~sgx_12_1->ecx ||
> -	    (u32)(xfrm >> 32) & ~sgx_12_1->edx) {
> +	    (u32)(xfrm >> 32) & ~sgx_12_1->edx ||
> +	    xfrm & ~vcpu->arch.guest_supported_xcr0) {

Perhaps this change is needed even without patch 2?

This is because when CPUID 0xD doesn't exist, guest_supported_xcr0 is 0.  But
when CPUID 0xD doesn't exist, IIUC currently KVM doesn't clear SGX in CPUID, and
sgx_12_1->ecx is always set to 0x3.  

__handle_encls_ereate() doesn't check CPUID 0xD either, so w/o above explicit
check xfrm against guest_supported_xcr0, it seems guest can successfully run
ECREATE when it doesn't have CPUID 0xD?


>  		kvm_inject_gp(vcpu, 0);
>  		return 1;
>  	}
> -- 
> 2.40.0.348.gf938b09366-goog
>
Sean Christopherson April 6, 2023, 1:44 a.m. UTC | #2 
On Wed, Apr 05, 2023, Huang, Kai wrote:
> On Tue, 2023-04-04 at 17:59 -0700, Sean Christopherson wrote:
> > Explicitly check the vCPU's supported XCR0 when determining whether or not
> > the XFRM for ECREATE is valid.  Checking CPUID works because KVM updates
> > guest CPUID.0x12.1 to restrict the leaf to a subset of the guest's allowed
> > XCR0, but that is rather subtle and KVM should not modify guest CPUID
> > except for modeling true runtime behavior (allowed XFRM is most definitely
> > not "runtime" behavior).
> > 
> > Signed-off-by: Sean Christopherson <seanjc@google.com>
> > ---
> >  arch/x86/kvm/vmx/sgx.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/arch/x86/kvm/vmx/sgx.c b/arch/x86/kvm/vmx/sgx.c
> > index aa53c98034bf..362a31b19b0e 100644
> > --- a/arch/x86/kvm/vmx/sgx.c
> > +++ b/arch/x86/kvm/vmx/sgx.c
> > @@ -175,7 +175,8 @@ static int __handle_encls_ecreate(struct kvm_vcpu *vcpu,
> >  	    (u32)attributes & ~sgx_12_1->eax ||
> >  	    (u32)(attributes >> 32) & ~sgx_12_1->ebx ||
> >  	    (u32)xfrm & ~sgx_12_1->ecx ||
> > -	    (u32)(xfrm >> 32) & ~sgx_12_1->edx) {
> > +	    (u32)(xfrm >> 32) & ~sgx_12_1->edx ||
> > +	    xfrm & ~vcpu->arch.guest_supported_xcr0) {
> 
> Perhaps this change is needed even without patch 2?
> 
> This is because when CPUID 0xD doesn't exist, guest_supported_xcr0 is 0.  But
> when CPUID 0xD doesn't exist, IIUC currently KVM doesn't clear SGX in CPUID, and
> sgx_12_1->ecx is always set to 0x3.

Hrm, that's a bug in this patch.  Drat.  More below.

> __handle_encls_ereate() doesn't check CPUID 0xD either, so w/o above explicit
> check xfrm against guest_supported_xcr0, it seems guest can successfully run
> ECREATE when it doesn't have CPUID 0xD?

ECREATE doesn't have a strict dependency on CPUID 0xD or XSAVE.  This exact scenario
is called out in the SDM:

  Legal values for SECS.ATTRIBUTES.XFRM conform to these requirements:
    * XFRM[1:0] must be set to 0x3.
    * If the processor does support XSAVE, XFRM must contain a value that would
      be legal if loaded into XCR0.
    * If the processor does not support XSAVE, or if the system software has not
      enabled XSAVE, then XFRM[63:2] must be zero.

So the above needs to be either

	xfrm & ~(vcpu->arch.guest_supported_xcr0 | XFEATURE_MASK_FPSSE)

or

	(xfrm & ~XFEATURE_MASK_FPSSE & ~vcpu->arch.guest_supported_xcr0)


I think I prefer the first one as I find it slightly more obvious that FP+SSE are
allowed in addition to the XCR0 bits.
Kai Huang April 6, 2023, 3:02 a.m. UTC | #3 
On Wed, 2023-04-05 at 18:44 -0700, Sean Christopherson wrote:
> On Wed, Apr 05, 2023, Huang, Kai wrote:
> > On Tue, 2023-04-04 at 17:59 -0700, Sean Christopherson wrote:
> > > Explicitly check the vCPU's supported XCR0 when determining whether or not
> > > the XFRM for ECREATE is valid.  Checking CPUID works because KVM updates
> > > guest CPUID.0x12.1 to restrict the leaf to a subset of the guest's allowed
> > > XCR0, but that is rather subtle and KVM should not modify guest CPUID
> > > except for modeling true runtime behavior (allowed XFRM is most definitely
> > > not "runtime" behavior).
> > > 
> > > Signed-off-by: Sean Christopherson <seanjc@google.com>
> > > ---
> > >  arch/x86/kvm/vmx/sgx.c | 3 ++-
> > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/arch/x86/kvm/vmx/sgx.c b/arch/x86/kvm/vmx/sgx.c
> > > index aa53c98034bf..362a31b19b0e 100644
> > > --- a/arch/x86/kvm/vmx/sgx.c
> > > +++ b/arch/x86/kvm/vmx/sgx.c
> > > @@ -175,7 +175,8 @@ static int __handle_encls_ecreate(struct kvm_vcpu *vcpu,
> > >  	    (u32)attributes & ~sgx_12_1->eax ||
> > >  	    (u32)(attributes >> 32) & ~sgx_12_1->ebx ||
> > >  	    (u32)xfrm & ~sgx_12_1->ecx ||
> > > -	    (u32)(xfrm >> 32) & ~sgx_12_1->edx) {
> > > +	    (u32)(xfrm >> 32) & ~sgx_12_1->edx ||
> > > +	    xfrm & ~vcpu->arch.guest_supported_xcr0) {
> > 
> > Perhaps this change is needed even without patch 2?
> > 
> > This is because when CPUID 0xD doesn't exist, guest_supported_xcr0 is 0.  But
> > when CPUID 0xD doesn't exist, IIUC currently KVM doesn't clear SGX in CPUID, and
> > sgx_12_1->ecx is always set to 0x3.
> 
> Hrm, that's a bug in this patch.  Drat.  More below.
> 
> > __handle_encls_ereate() doesn't check CPUID 0xD either, so w/o above explicit
> > check xfrm against guest_supported_xcr0, it seems guest can successfully run
> > ECREATE when it doesn't have CPUID 0xD?
> 
> ECREATE doesn't have a strict dependency on CPUID 0xD or XSAVE.  This exact scenario
> is called out in the SDM:
> 
>   Legal values for SECS.ATTRIBUTES.XFRM conform to these requirements:
>     * XFRM[1:0] must be set to 0x3.
>     * If the processor does support XSAVE, XFRM must contain a value that would
>       be legal if loaded into XCR0.
>     * If the processor does not support XSAVE, or if the system software has not
>       enabled XSAVE, then XFRM[63:2] must be zero.
> 
> So the above needs to be either
> 
> 	xfrm & ~(vcpu->arch.guest_supported_xcr0 | XFEATURE_MASK_FPSSE)
> 
> or
> 
> 	(xfrm & ~XFEATURE_MASK_FPSSE & ~vcpu->arch.guest_supported_xcr0)
> 
> 
> I think I prefer the first one as I find it slightly more obvious that FP+SSE are
> allowed in addition to the XCR0 bits.

The above check doesn't verify xfrm is a super set of 0x3.  I think we verify
that per SDM:

39.7.3 Processor Extended States and ENCLS[ECREATE]

The ECREATE leaf function of the ENCLS instruction enforces a number of
consistency checks described earlier. The execution of ENCLS[ECREATE] leaf
function results in a #GP(0) in any of the following cases:
  • SECS.ATTRIBUTES.XFRM[1:0] is not 3.
  • The processor does not support XSAVE and any of the following is true:
	— SECS.ATTRIBUTES.XFRM[63:2] is not 0.
	— SECS.SSAFRAMESIZE is 0.
  • The processor supports XSAVE and any of the following is true:
	— XSETBV would fault on an attempt to load XFRM into XCR0.
	— XFRM[63]=1.
	— The SSAFRAME is too small to hold required, enabled states ...


And in the ECREATE pseudo code, the relevant parts seem to be:

	(* Check lower 2 bits of XFRM are set *)
	IF ( ( DS:TMP_SECS.ATTRIBUTES.XFRM BitwiseAND 03H) ≠ 03H)
		THEN #GP(0); FI;

	IF (XFRM is illegal)
		THEN #GP(0); FI;

The first part is clear, but the second part is vague. 

I am not sure in hardware behaviour, whether XCR0 is actually checked in
ECREATE.  It's more likely XCRO is actually checked in EENTER.  

But I think it's just fine to also check against XCR0 here.
Sean Christopherson April 6, 2023, 7:12 p.m. UTC | #4 
On Thu, Apr 06, 2023, Huang, Kai wrote:
> On Wed, 2023-04-05 at 18:44 -0700, Sean Christopherson wrote:
> > On Wed, Apr 05, 2023, Huang, Kai wrote:
> > > On Tue, 2023-04-04 at 17:59 -0700, Sean Christopherson wrote:
> > > > Explicitly check the vCPU's supported XCR0 when determining whether or not
> > > > the XFRM for ECREATE is valid.  Checking CPUID works because KVM updates
> > > > guest CPUID.0x12.1 to restrict the leaf to a subset of the guest's allowed
> > > > XCR0, but that is rather subtle and KVM should not modify guest CPUID
> > > > except for modeling true runtime behavior (allowed XFRM is most definitely
> > > > not "runtime" behavior).
> > > > 
> > > > Signed-off-by: Sean Christopherson <seanjc@google.com>
> > > > ---
> > > >  arch/x86/kvm/vmx/sgx.c | 3 ++-
> > > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/arch/x86/kvm/vmx/sgx.c b/arch/x86/kvm/vmx/sgx.c
> > > > index aa53c98034bf..362a31b19b0e 100644
> > > > --- a/arch/x86/kvm/vmx/sgx.c
> > > > +++ b/arch/x86/kvm/vmx/sgx.c
> > > > @@ -175,7 +175,8 @@ static int __handle_encls_ecreate(struct kvm_vcpu *vcpu,
> > > >  	    (u32)attributes & ~sgx_12_1->eax ||
> > > >  	    (u32)(attributes >> 32) & ~sgx_12_1->ebx ||
> > > >  	    (u32)xfrm & ~sgx_12_1->ecx ||
> > > > -	    (u32)(xfrm >> 32) & ~sgx_12_1->edx) {
> > > > +	    (u32)(xfrm >> 32) & ~sgx_12_1->edx ||
> > > > +	    xfrm & ~vcpu->arch.guest_supported_xcr0) {
> > > 
> > > Perhaps this change is needed even without patch 2?
> > > 
> > > This is because when CPUID 0xD doesn't exist, guest_supported_xcr0 is 0.  But
> > > when CPUID 0xD doesn't exist, IIUC currently KVM doesn't clear SGX in CPUID, and
> > > sgx_12_1->ecx is always set to 0x3.
> > 
> > Hrm, that's a bug in this patch.  Drat.  More below.
> > 
> > > __handle_encls_ereate() doesn't check CPUID 0xD either, so w/o above explicit
> > > check xfrm against guest_supported_xcr0, it seems guest can successfully run
> > > ECREATE when it doesn't have CPUID 0xD?
> > 
> > ECREATE doesn't have a strict dependency on CPUID 0xD or XSAVE.  This exact scenario
> > is called out in the SDM:
> > 
> >   Legal values for SECS.ATTRIBUTES.XFRM conform to these requirements:
> >     * XFRM[1:0] must be set to 0x3.
> >     * If the processor does support XSAVE, XFRM must contain a value that would
> >       be legal if loaded into XCR0.
> >     * If the processor does not support XSAVE, or if the system software has not
> >       enabled XSAVE, then XFRM[63:2] must be zero.
> > 
> > So the above needs to be either
> > 
> > 	xfrm & ~(vcpu->arch.guest_supported_xcr0 | XFEATURE_MASK_FPSSE)
> > 
> > or
> > 
> > 	(xfrm & ~XFEATURE_MASK_FPSSE & ~vcpu->arch.guest_supported_xcr0)
> > 
> > 
> > I think I prefer the first one as I find it slightly more obvious that FP+SSE are
> > allowed in addition to the XCR0 bits.
> 
> The above check doesn't verify xfrm is a super set of 0x3.  I think we verify
> that per SDM:

Oooh, right.  It's not that FP+SSE are always allowed, it's that FP+SSE must always
be _set_.  So this?

		xfrm & ~(vcpu->arch.guest_supported_xcr0 | XFEATURE_MASK_FPSSE) ||
		(xfrm & XFEATURE_MASK_FPSSE) != XFEATURE_MASK_FPSSE

> 39.7.3 Processor Extended States and ENCLS[ECREATE]
> 
> The ECREATE leaf function of the ENCLS instruction enforces a number of
> consistency checks described earlier. The execution of ENCLS[ECREATE] leaf
> function results in a #GP(0) in any of the following cases:
>   • SECS.ATTRIBUTES.XFRM[1:0] is not 3.
>   • The processor does not support XSAVE and any of the following is true:
> 	— SECS.ATTRIBUTES.XFRM[63:2] is not 0.
> 	— SECS.SSAFRAMESIZE is 0.
>   • The processor supports XSAVE and any of the following is true:
> 	— XSETBV would fault on an attempt to load XFRM into XCR0.
> 	— XFRM[63]=1.
> 	— The SSAFRAME is too small to hold required, enabled states ...
> 
> 
> And in the ECREATE pseudo code, the relevant parts seem to be:
> 
> 	(* Check lower 2 bits of XFRM are set *)
> 	IF ( ( DS:TMP_SECS.ATTRIBUTES.XFRM BitwiseAND 03H) ≠ 03H)
> 		THEN #GP(0); FI;
> 
> 	IF (XFRM is illegal)
> 		THEN #GP(0); FI;
> 
> The first part is clear, but the second part is vague. 
> 
> I am not sure in hardware behaviour, whether XCR0 is actually checked in
> ECREATE.  It's more likely XCRO is actually checked in EENTER.  
> 
> But I think it's just fine to also check against XCR0 here.

ECREATE doesn't check XCR0, it checks that XFRM represents a legal XCR0 values
for the platform, which in KVM is tracked as guest_supported_xcr0.
Kai Huang April 12, 2023, 10:12 a.m. UTC | #5 
On Thu, 2023-04-06 at 12:12 -0700, Sean Christopherson wrote:
> On Thu, Apr 06, 2023, Huang, Kai wrote:
> > On Wed, 2023-04-05 at 18:44 -0700, Sean Christopherson wrote:
> > > On Wed, Apr 05, 2023, Huang, Kai wrote:
> > > > On Tue, 2023-04-04 at 17:59 -0700, Sean Christopherson wrote:
> > > > > Explicitly check the vCPU's supported XCR0 when determining whether or not
> > > > > the XFRM for ECREATE is valid.  Checking CPUID works because KVM updates
> > > > > guest CPUID.0x12.1 to restrict the leaf to a subset of the guest's allowed
> > > > > XCR0, but that is rather subtle and KVM should not modify guest CPUID
> > > > > except for modeling true runtime behavior (allowed XFRM is most definitely
> > > > > not "runtime" behavior).
> > > > > 
> > > > > Signed-off-by: Sean Christopherson <seanjc@google.com>
> > > > > ---
> > > > >  arch/x86/kvm/vmx/sgx.c | 3 ++-
> > > > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > > > 
> > > > > diff --git a/arch/x86/kvm/vmx/sgx.c b/arch/x86/kvm/vmx/sgx.c
> > > > > index aa53c98034bf..362a31b19b0e 100644
> > > > > --- a/arch/x86/kvm/vmx/sgx.c
> > > > > +++ b/arch/x86/kvm/vmx/sgx.c
> > > > > @@ -175,7 +175,8 @@ static int __handle_encls_ecreate(struct kvm_vcpu *vcpu,
> > > > >  	    (u32)attributes & ~sgx_12_1->eax ||
> > > > >  	    (u32)(attributes >> 32) & ~sgx_12_1->ebx ||
> > > > >  	    (u32)xfrm & ~sgx_12_1->ecx ||
> > > > > -	    (u32)(xfrm >> 32) & ~sgx_12_1->edx) {
> > > > > +	    (u32)(xfrm >> 32) & ~sgx_12_1->edx ||
> > > > > +	    xfrm & ~vcpu->arch.guest_supported_xcr0) {
> > > > 
> > > > Perhaps this change is needed even without patch 2?
> > > > 
> > > > This is because when CPUID 0xD doesn't exist, guest_supported_xcr0 is 0.  But
> > > > when CPUID 0xD doesn't exist, IIUC currently KVM doesn't clear SGX in CPUID, and
> > > > sgx_12_1->ecx is always set to 0x3.
> > > 
> > > Hrm, that's a bug in this patch.  Drat.  More below.
> > > 
> > > > __handle_encls_ereate() doesn't check CPUID 0xD either, so w/o above explicit
> > > > check xfrm against guest_supported_xcr0, it seems guest can successfully run
> > > > ECREATE when it doesn't have CPUID 0xD?
> > > 
> > > ECREATE doesn't have a strict dependency on CPUID 0xD or XSAVE.  This exact scenario
> > > is called out in the SDM:
> > > 
> > >   Legal values for SECS.ATTRIBUTES.XFRM conform to these requirements:
> > >     * XFRM[1:0] must be set to 0x3.
> > >     * If the processor does support XSAVE, XFRM must contain a value that would
> > >       be legal if loaded into XCR0.
> > >     * If the processor does not support XSAVE, or if the system software has not
> > >       enabled XSAVE, then XFRM[63:2] must be zero.
> > > 
> > > So the above needs to be either
> > > 
> > > 	xfrm & ~(vcpu->arch.guest_supported_xcr0 | XFEATURE_MASK_FPSSE)
> > > 
> > > or
> > > 
> > > 	(xfrm & ~XFEATURE_MASK_FPSSE & ~vcpu->arch.guest_supported_xcr0)
> > > 
> > > 
> > > I think I prefer the first one as I find it slightly more obvious that FP+SSE are
> > > allowed in addition to the XCR0 bits.
> > 
> > The above check doesn't verify xfrm is a super set of 0x3.  I think we verify
> > that per SDM:
> 
> Oooh, right.  It's not that FP+SSE are always allowed, it's that FP+SSE must always
> be _set_.  So this?
> 
> 		xfrm & ~(vcpu->arch.guest_supported_xcr0 | XFEATURE_MASK_FPSSE) ||
> 		(xfrm & XFEATURE_MASK_FPSSE) != XFEATURE_MASK_FPSSE

Looks good.

I'll try to get some test done with this code change.

> 
> > 39.7.3 Processor Extended States and ENCLS[ECREATE]
> > 
> > The ECREATE leaf function of the ENCLS instruction enforces a number of
> > consistency checks described earlier. The execution of ENCLS[ECREATE] leaf
> > function results in a #GP(0) in any of the following cases:
> >   • SECS.ATTRIBUTES.XFRM[1:0] is not 3.
> >   • The processor does not support XSAVE and any of the following is true:
> > 	— SECS.ATTRIBUTES.XFRM[63:2] is not 0.
> > 	— SECS.SSAFRAMESIZE is 0.
> >   • The processor supports XSAVE and any of the following is true:
> > 	— XSETBV would fault on an attempt to load XFRM into XCR0.
> > 	— XFRM[63]=1.
> > 	— The SSAFRAME is too small to hold required, enabled states ...
> > 
> > 
> > And in the ECREATE pseudo code, the relevant parts seem to be:
> > 
> > 	(* Check lower 2 bits of XFRM are set *)
> > 	IF ( ( DS:TMP_SECS.ATTRIBUTES.XFRM BitwiseAND 03H) ≠ 03H)
> > 		THEN #GP(0); FI;
> > 
> > 	IF (XFRM is illegal)
> > 		THEN #GP(0); FI;
> > 
> > The first part is clear, but the second part is vague. 
> > 
> > I am not sure in hardware behaviour, whether XCR0 is actually checked in
> > ECREATE.  It's more likely XCRO is actually checked in EENTER.  
> > 
> > But I think it's just fine to also check against XCR0 here.
> 
> ECREATE doesn't check XCR0, it checks that XFRM represents a legal XCR0 values
> for the platform, which in KVM is tracked as guest_supported_xcr0.

Yes agreed.
Kai Huang April 20, 2023, 10:55 a.m. UTC | #6 
> > 
> > Oooh, right.  It's not that FP+SSE are always allowed, it's that FP+SSE must always
> > be _set_.  So this?
> > 
> > 		xfrm & ~(vcpu->arch.guest_supported_xcr0 | XFEATURE_MASK_FPSSE) ||
> > 		(xfrm & XFEATURE_MASK_FPSSE) != XFEATURE_MASK_FPSSE
> 
> Looks good.
> 
> I'll try to get some test done with this code change.
> 

Tested this series with your above code change by running simple SGX app in the
guest.

For this particular case, tested with ECREATE with xfrm = 0x1 in the guest, and
guest can receive #GP. 

So for the entire series:

Reviewed-by: Kai Huang <kai.huang@intel.com>
Tested-by: Kai Huang <kai.huang@intel.com>


>
diff mbox series

Patch

diff --git a/arch/x86/kvm/vmx/sgx.c b/arch/x86/kvm/vmx/sgx.c
index aa53c98034bf..362a31b19b0e 100644
--- a/arch/x86/kvm/vmx/sgx.c
+++ b/arch/x86/kvm/vmx/sgx.c
@@ -175,7 +175,8 @@  static int __handle_encls_ecreate(struct kvm_vcpu *vcpu,
 	    (u32)attributes & ~sgx_12_1->eax ||
 	    (u32)(attributes >> 32) & ~sgx_12_1->ebx ||
 	    (u32)xfrm & ~sgx_12_1->ecx ||
-	    (u32)(xfrm >> 32) & ~sgx_12_1->edx) {
+	    (u32)(xfrm >> 32) & ~sgx_12_1->edx ||
+	    xfrm & ~vcpu->arch.guest_supported_xcr0) {
 		kvm_inject_gp(vcpu, 0);
 		return 1;
 	}