From: "Huang, Kai" <kai.huang@intel.com>
To: "pbonzini@redhat.com" <pbonzini@redhat.com>, "Christopherson,,
Sean" <seanjc@google.com>
Cc: "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/3] KVM: x86: SGX vs. XCR0 cleanups
Date: Wed, 5 Apr 2023 03:05:10 +0000 [thread overview]
Message-ID: <40904e94edbb5af41d21ec9fe1d32b6bfb118b0f.camel@intel.com> (raw)
In-Reply-To: <20230405005911.423699-1-seanjc@google.com>
On Tue, 2023-04-04 at 17:59 -0700, Sean Christopherson wrote:
> *** WARNING *** ABI breakage.
>
> Stop adjusting the guest's CPUID info for the allowed XFRM (a.k.a. XCR0)
> for SGX enclaves. Past me didn't understand the roles and responsibilities
> between userspace and KVM with respect to CPUID leafs, i.e. I thought I was
> being helpful by having KVM adjust the entries.
>
> This is clearly an ABI breakage, but QEMU (tries to) do the right thing,
> and AFAIK no other VMMs support SGX (yet), so I'm hoping we can excise the
> ugly before userspace starts depending on the bad behavior.
>
> Compile tested only (don't have an SGX system these days).
I'll look into this, and at the meantime ...
>
> Note, QEMU commit 301e90675c ("target/i386: Enable support for XSAVES
> based features") completely broke SGX by using allowed XSS instead of
> XCR0, and no one has complained. That gives me hope that this one will
> go through as well.
...
Actually we got complain around half year ago:
https://github.com/gramineproject/gramine/issues/955#issuecomment-1272829510
>
> I belive the QEMU fix is below. I'll post a patch at some point unless
> someone wants to do the dirty work and claim the patch as their own.
>
> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> index 6576287e5b..f083ff4335 100644
> --- a/target/i386/cpu.c
> +++ b/target/i386/cpu.c
> @@ -5718,8 +5718,8 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, uint32_t count,
> } else {
> *eax &= env->features[FEAT_SGX_12_1_EAX];
> *ebx &= 0; /* ebx reserve */
> - *ecx &= env->features[FEAT_XSAVE_XSS_LO];
> - *edx &= env->features[FEAT_XSAVE_XSS_HI];
> + *ecx &= env->features[FEAT_XSAVE_XCR0_LO];
> + *edx &= env->features[FEAT_XSAVE_XCR0_HI];
>
> /* FP and SSE are always allowed regardless of XSAVE/XCR0. */
> *ecx |= XSTATE_FP_MASK | XSTATE_SSE_MASK;
And since then Yang posted a patch to Qemu mailing list to fix:
https://lists.nongnu.org/archive/html/qemu-devel/2022-10/msg04990.html
I thought it had been merged, but it seems it hasn't :)
>
> Sean Christopherson (3):
> KVM: VMX: Don't rely _only_ on CPUID to enforce XCR0 restrictions for
> ECREATE
> KVM: x86: Don't adjust guest's CPUID.0x12.1 (allowed SGX enclave XFRM)
> KVM: x86: Open code supported XCR0 calculation in
> kvm_vcpu_after_set_cpuid()
>
> arch/x86/kvm/cpuid.c | 43 ++++++++++--------------------------------
> arch/x86/kvm/vmx/sgx.c | 3 ++-
> 2 files changed, 12 insertions(+), 34 deletions(-)
>
>
> base-commit: 27d6845d258b67f4eb3debe062b7dacc67e0c393
> --
> 2.40.0.348.gf938b09366-goog
>
next prev parent reply other threads:[~2023-04-05 3:05 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-05 0:59 [PATCH 0/3] KVM: x86: SGX vs. XCR0 cleanups Sean Christopherson
2023-04-05 0:59 ` [PATCH 1/3] KVM: VMX: Don't rely _only_ on CPUID to enforce XCR0 restrictions for ECREATE Sean Christopherson
2023-04-05 10:52 ` Huang, Kai
2023-04-06 1:44 ` Sean Christopherson
2023-04-06 3:02 ` Huang, Kai
2023-04-06 19:12 ` Sean Christopherson
2023-04-12 10:12 ` Huang, Kai
2023-04-20 10:55 ` Huang, Kai
2023-04-05 0:59 ` [PATCH 2/3] KVM: x86: Don't adjust guest's CPUID.0x12.1 (allowed SGX enclave XFRM) Sean Christopherson
2023-04-05 0:59 ` [PATCH 3/3] KVM: x86: Open code supported XCR0 calculation in kvm_vcpu_after_set_cpuid() Sean Christopherson
2023-04-05 3:05 ` Huang, Kai [this message]
2023-04-05 9:44 ` [PATCH 0/3] KVM: x86: SGX vs. XCR0 cleanups Huang, Kai
2023-04-06 2:10 ` Sean Christopherson
2023-04-06 10:01 ` Zhi Wang
2023-04-12 12:07 ` Huang, Kai
2023-04-12 15:22 ` Sean Christopherson
2023-04-13 0:20 ` Huang, Kai
2023-04-13 22:48 ` Sean Christopherson
2023-04-14 13:42 ` Huang, Kai
2023-04-16 6:36 ` Zhi Wang
2023-04-13 6:07 ` Zhi Wang
2023-04-12 12:15 ` Huang, Kai
2023-04-12 14:57 ` Sean Christopherson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=40904e94edbb5af41d21ec9fe1d32b6bfb118b0f.camel@intel.com \
--to=kai.huang@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox