[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1553602654.17255.15.camel@intel.com>
Date: Tue, 26 Mar 2019 12:17:40 +0000
From: "Huang, Kai" <kai.huang@...el.com>
To: "jarkko.sakkinen@...ux.intel.com" <jarkko.sakkinen@...ux.intel.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-sgx@...r.kernel.org" <linux-sgx@...r.kernel.org>,
"x86@...nel.org" <x86@...nel.org>
CC: "Svahn, Kai" <kai.svahn@...el.com>,
"nhorman@...hat.com" <nhorman@...hat.com>,
"Christopherson, Sean J" <sean.j.christopherson@...el.com>,
"josh@...htriplett.org" <josh@...htriplett.org>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"Ayoun, Serge" <serge.ayoun@...el.com>,
"Huang, Haitao" <haitao.huang@...el.com>,
"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
"npmccallum@...hat.com" <npmccallum@...hat.com>,
"rientjes@...gle.com" <rientjes@...gle.com>,
"luto@...nel.org" <luto@...nel.org>,
"Katz-zamir, Shay" <shay.katz-zamir@...el.com>,
"Hansen, Dave" <dave.hansen@...el.com>,
"bp@...en8.de" <bp@...en8.de>,
"andriy.shevchenko@...ux.intel.com"
<andriy.shevchenko@...ux.intel.com>
Subject: Re: [PATCH v19,RESEND 08/27] x86/cpu/intel: Detect SGX support and
update caps appropriately
On Wed, 2019-03-20 at 18:21 +0200, Jarkko Sakkinen wrote:
> From: Sean Christopherson <sean.j.christopherson@...el.com>
>
> Similar to other large Intel features such as VMX and TXT, SGX must be
> explicitly enabled in IA32_FEATURE_CONTROL MSR to be truly usable.
> Clear all SGX related capabilities if SGX is not fully enabled in
> IA32_FEATURE_CONTROL or if the SGX1 instruction set isn't supported
> (impossible on bare metal, theoretically possible in a VM if the VMM is
> doing something weird).
>
> Like SGX itself, SGX Launch Control must be explicitly enabled via a
> flag in IA32_FEATURE_CONTROL. Clear the SGX_LC capability if Launch
> Control is not fully enabled (or obviously if SGX itself is disabled).
>
> Note that clearing X86_FEATURE_SGX_LC creates a bit of a conundrum
> regarding the SGXLEPUBKEYHASH MSRs, as it may be desirable to read the
> MSRs even if they are not writable, e.g. to query the configured key,
> but clearing the capability leaves no breadcrum for discerning whether
> or not the MSRs exist. But, such usage will be rare (KVM is the only
> known case at this time) and not performance critical, so it's not
> unreasonable to require the use of rdmsr_safe(). Clearing the cap bit
> eliminates the need for an additional flag to track whether or not
> Launch Control is truly enabled, which is what we care about the vast
> majority of the time.
[Resend. Somehow my last reply doesn't show up in my mailbox so not sure whether I sent it
successfully or not. Sorry if you receving duplicated mails.]
However this is not consistent with HW behavior. If LC feature flag is not present, then MSRs should
have hash of Intel's key, which is not always the case here, when you expose SGX to KVM. Enclave in
KVM guest will get unexpected EINIT error when launing Intel enclave, if on HW MSRs are configured
to 3rd party value but locked to readonly.
My opition is we already have enough cases that violates HW behavior in SGX virtualization, let's
not have one more.
Besides, why do we "need an additional flag to track whether or not Launch Control is truly
enabled"? Doesn't driver only need to know whether MSRs are writable?
Thanks,
-Kai
>
> Signed-off-by: Sean Christopherson <sean.j.christopherson@...el.com>
> Co-developed-by: Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>
> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>
> ---
> arch/x86/kernel/cpu/intel.c | 39 +++++++++++++++++++++++++++++++++++++
> 1 file changed, 39 insertions(+)
>
> diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
> index fc3c07fe7df5..702497f34a96 100644
> --- a/arch/x86/kernel/cpu/intel.c
> +++ b/arch/x86/kernel/cpu/intel.c
> @@ -596,6 +596,42 @@ static void detect_tme(struct cpuinfo_x86 *c)
> c->x86_phys_bits -= keyid_bits;
> }
>
> +static void __maybe_unused detect_sgx(struct cpuinfo_x86 *c)
> +{
> + unsigned long long fc;
> +
> + rdmsrl(MSR_IA32_FEATURE_CONTROL, fc);
> + if (!(fc & FEATURE_CONTROL_LOCKED)) {
> + pr_err_once("sgx: The feature control MSR is not locked\n");
> + goto err_unsupported;
> + }
> +
> + if (!(fc & FEATURE_CONTROL_SGX_ENABLE)) {
> + pr_err_once("sgx: SGX is not enabled in IA32_FEATURE_CONTROL MSR\n");
> + goto err_unsupported;
> + }
> +
> + if (!cpu_has(c, X86_FEATURE_SGX1)) {
> + pr_err_once("sgx: SGX1 instruction set is not supported\n");
> + goto err_unsupported;
> + }
> +
> + if (!(fc & FEATURE_CONTROL_SGX_LE_WR)) {
> + pr_info_once("sgx: The launch control MSRs are not writable\n");
> + goto err_msrs_rdonly;
> + }
> +
> + return;
> +
> +err_unsupported:
> + setup_clear_cpu_cap(X86_FEATURE_SGX);
> + setup_clear_cpu_cap(X86_FEATURE_SGX1);
> + setup_clear_cpu_cap(X86_FEATURE_SGX2);
> +
> +err_msrs_rdonly:
> + setup_clear_cpu_cap(X86_FEATURE_SGX_LC);
> +}
> +
> static void init_intel_energy_perf(struct cpuinfo_x86 *c)
> {
> u64 epb;
> @@ -763,6 +799,9 @@ static void init_intel(struct cpuinfo_x86 *c)
> if (cpu_has(c, X86_FEATURE_TME))
> detect_tme(c);
>
> + if (IS_ENABLED(CONFIG_INTEL_SGX) && cpu_has(c, X86_FEATURE_SGX))
> + detect_sgx(c);
> +
> init_intel_energy_perf(c);
>
> init_intel_misc_features(c);
Powered by blists - more mailing lists