[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [PATCH 08/15] xen: x86: add SGX cpuid handling support.
On 7/12/2017 10:56 PM, Andrew Cooper wrote:
On 09/07/17 10:10, Kai Huang wrote:
This patch adds SGX to cpuid handling support. In init_guest_cpuid, for
raw_policy and host_policy, physical EPC info is reported, but for
pv_max_policy
and hvm_max_policy EPC is hidden, as for particular domain, it's EPC
base and
size are from tookstack, and it is meaningless to contain physical EPC
info in
them. Before domain's EPC base and size are properly configured,
guest's SGX
cpuid should report invalid EPC, which is also consistent with HW
behavior.
Currently all EPC pages are fully populated for domain when it is
created.
Xen gets domain's EPC base and size from toolstack via
XEN_DOMCTL_set_cpuid,
so domain's EPC pages are also populated in XEN_DOMCTL_set_cpuid, after
receiving valid EPC base and size. Failure to populate EPC (such as
there's
no enough free EPC pages) results in domain creation failure by making
XEN_DOMCTL_set_cpuid return error.
Signed-off-by: Kai Huang <kai.huang@xxxxxxxxxxxxxxx>
---
xen/arch/x86/cpuid.c | 87
++++++++++++++++++++++++++++++++++++++++++++-
xen/arch/x86/domctl.c | 47 +++++++++++++++++++++++-
xen/include/asm-x86/cpuid.h | 26 +++++++++++++-
3 files changed, 157 insertions(+), 3 deletions(-)
diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
index d359e090f3..db896be2e8 100644
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -9,6 +9,7 @@
#include <asm/paging.h>
#include <asm/processor.h>
#include <asm/xstate.h>
+#include <asm/hvm/vmx/sgx.h>
const uint32_t known_features[] = INIT_KNOWN_FEATURES;
const uint32_t special_features[] = INIT_SPECIAL_FEATURES;
@@ -158,6 +159,44 @@ static void recalculate_xstate(struct
cpuid_policy *p)
}
}
+static void recalculate_sgx(struct cpuid_policy *p, bool_t hide_epc)
Across the entire series, please use bool rather than bool_t.
Hi Andrew,
Thank you very much for comments.
Will do.
Why do we need this hide_epc parameter? If we aren't providing any epc
resource to the guest, the entire sgx union should be zero and the SGX
feature bit should be hidden.
My intention was to hide physical EPC info for pv_max_policy and
hvm_max_policy (recalculate_sgx is also called by
calculate_pv_max_policy and calculate_hvm_max_policy), as they are for
guest and don't need physical EPC info. But keeping physical EPC info in
them does no harm so I think we can simply remove hide_epc.
IMO we cannot check whether EPC is valid and zero sgx union in
recalculate_sgx, as it is called for each CPUID. For example, it is
called for SGX subleaf 0, and 1, and then 2, and when subleaf 0 and 1
are called, the EPC resource is 0 (hasn't been configured).
+{
+ if ( !p->feat.sgx )
+ {
+ memset(&p->sgx, 0, sizeof (p->sgx));
+ return;
+ }
+
+ if ( !p->sgx.sgx1 )
+ {
+ memset(&p->sgx, 0, sizeof (p->sgx));
+ return;
+ }
These two clauses can be combined.
Will do.
+
+ /*
+ * SDM 42.7.2.1 SECS.ATTRIBUTE.XFRM:
+ *
+ * Legal value for SECS.ATTRIBUTE.XFRM conform to these
requirements:
+ * - XFRM[1:0] must be set to 0x3;
+ * - If processor does not support XSAVE, or if the system
software has not
+ * enabled XSAVE, then XFRM[63:2] must be 0.
+ * - If the processor does support XSAVE, XFRM must contain a
value that
+ * would be legal if loaded into XCR0.
+ */
+ p->sgx.xfrm_low = 0x3;
+ p->sgx.xfrm_high = 0;
+ if ( p->basic.xsave )
+ {
+ p->sgx.xfrm_low |= p->xstate.xcr0_low;
+ p->sgx.xfrm_high |= p->xstate.xcr0_high;
+ }
There is a bug here, but it will disappear with my CPUID work. At the
moment, the job of this function is to sanitise values handed by the
toolstack, which includes zeroing all the reserved bits. This is
because there is currently no way to signal a failure.
When I fix the toolstack interface, the toolstack will propose a new
CPUID policy, and Xen will have a function to check it against the
architectural requirements. At that point, we will be applying checks,
but not modifying the contents.
I think I need to look at your design first and then I should be able to
understand your comment. :)
+
+ if ( hide_epc )
+ {
+ memset(&p->sgx.raw[0x2], 0, sizeof (struct cpuid_leaf));
+ }
+}
+
/*
* Misc adjustments to the policy. Mostly clobbering reserved
fields and
* duplicating shared fields. Intentionally hidden fields are
annotated.
@@ -239,7 +278,7 @@ static void __init calculate_raw_policy(void)
{
switch ( i )
{
- case 0x4: case 0x7: case 0xd:
+ case 0x4: case 0x7: case 0xd: case 0x12:
/* Multi-invocation leaves. Deferred. */
continue;
}
@@ -299,6 +338,19 @@ static void __init calculate_raw_policy(void)
}
}
+ if ( p->basic.max_leaf >= SGX_CPUID )
+ {
+ /*
+ * For raw policy we just report native CPUID. For EPC on
native it's
+ * possible that we will have multiple EPC sections (meaning
subleaf 3,
+ * 4, ... may also be valid), but as the policy is for guest
so we only
+ * need one EPC section (subleaf 2).
+ */
+ cpuid_count_leaf(SGX_CPUID, 0, &p->sgx.raw[0]);
+ cpuid_count_leaf(SGX_CPUID, 0, &p->sgx.raw[0]);
+ cpuid_count_leaf(SGX_CPUID, 0, &p->sgx.raw[0]);
Copy & paste error? I presume you meant to use leaves 1 and 2 here,
rather than leaf 0 each time?
Oh sorry. Yes indeed I meant zero out subleaf 1 and 2.
+ }
+
/* Extended leaves. */
cpuid_leaf(0x80000000, &p->extd.raw[0]);
for ( i = 1; i < min(ARRAY_SIZE(p->extd.raw),
@@ -324,6 +376,8 @@ static void __init calculate_host_policy(void)
cpuid_featureset_to_policy(boot_cpu_data.x86_capability, p);
recalculate_xstate(p);
recalculate_misc(p);
+ /* For host policy we report physical EPC */
+ recalculate_sgx(p, 0);
if ( p->extd.svm )
{
@@ -357,6 +411,11 @@ static void __init calculate_pv_max_policy(void)
sanitise_featureset(pv_featureset);
cpuid_featureset_to_policy(pv_featureset, p);
recalculate_xstate(p);
+ /*
+ * For PV policy we don't report physical EPC. Actually for PV
policy
+ * currently SGX will be disabled.
+ */
+ recalculate_sgx(p, 1);
p->extd.raw[0xa] = EMPTY_LEAF; /* No SVM for PV guests. */
}
@@ -413,6 +472,13 @@ static void __init calculate_hvm_max_policy(void)
sanitise_featureset(hvm_featureset);
cpuid_featureset_to_policy(hvm_featureset, p);
recalculate_xstate(p);
+ /*
+ * For HVM policy we don't report physical EPC. Actually cpuid
policy
+ * should report VM's virtual EPC base and size. However VM's
virtual
+ * EPC info will come from toolstack, and only after Xen is notified
+ * VM's cpuid policy should report invalid EPC.
+ */
+ recalculate_sgx(p, 1);
}
void __init init_guest_cpuid(void)
@@ -528,6 +594,12 @@ void recalculate_cpuid_policy(struct domain *d)
if ( p->basic.max_leaf < XSTATE_CPUID )
__clear_bit(X86_FEATURE_XSAVE, fs);
+ if ( p->basic.max_leaf < SGX_CPUID )
+ {
+ __clear_bit(X86_FEATURE_SGX, fs);
+ __clear_bit(X86_FEATURE_SGX_LAUNCH_CONTROL, fs);
Because you filled in the feature dependency graph for SGX_LAUNCH
depending on SGX, this second clear bit isn't necessary. Clearing SGX
will cause sanitise_featureset() to automatically clear SGX_LAUNCH (and
any future feature bits).
Yes you are right. I'll just clear SGX in next version.
+ }
+
sanitise_featureset(fs);
/* Fold host's FDP_EXCP_ONLY and NO_FPU_SEL into guest's view. */
@@ -550,6 +622,12 @@ void recalculate_cpuid_policy(struct domain *d)
recalculate_xstate(p);
recalculate_misc(p);
+ /*
+ * recalculate_cpuid_policy is also called for domain's cpuid
policy,
+ * which is from toolstack via XEN_DOMCTL_set_cpuid, therefore we
cannot
+ * hide domain's virtual EPC from toolstack.
+ */
+ recalculate_sgx(p, 0);
for ( i = 0; i < ARRAY_SIZE(p->cache.raw); ++i )
{
@@ -645,6 +723,13 @@ void guest_cpuid(const struct vcpu *v, uint32_t
leaf,
*res = p->xstate.raw[subleaf];
break;
+ case SGX_CPUID:
+ if ( !p->feat.sgx )
+ return;
|| subleaf >= ARRAY_SIZE(p->sgx.raw)
Otherwise, a guest CPUID query can walk read off the end of raw[].
Oh yes. Thanks for pointing out.
+
+ *res = p->sgx.raw[subleaf];
+ break;
+
default:
*res = p->basic.raw[leaf];
break;
diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index f40e989fd8..7d49947a3e 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -53,6 +53,7 @@ static int update_domain_cpuid_info(struct domain *d,
struct cpuid_policy *p = d->arch.cpuid;
const struct cpuid_leaf leaf = { ctl->eax, ctl->ebx, ctl->ecx,
ctl->edx };
int old_vendor = p->x86_vendor;
+ int ret = 0;
/*
* Skip update for leaves we don't care about. This avoids the
overhead
@@ -74,6 +75,7 @@ static int update_domain_cpuid_info(struct domain *d,
if ( ctl->input[0] == XSTATE_CPUID &&
ctl->input[1] != 1 ) /* Everything else automatically
calculated. */
return 0;
+
break;
case 0x40000000: case 0x40000100:
@@ -104,6 +106,10 @@ static int update_domain_cpuid_info(struct domain
*d,
p->xstate.raw[ctl->input[1]] = leaf;
break;
+ case SGX_CPUID:
+ p->sgx.raw[ctl->input[1]] = leaf;
+ break;
You also need to modify the higher switch statement so the toolstack
can't cause Xen to write beyond the end of .raw[].
Yes I understand your point now. Will do.
+
default:
p->basic.raw[ctl->input[0]] = leaf;
break;
@@ -255,6 +261,45 @@ static int update_domain_cpuid_info(struct domain
*d,
}
break;
+ case 0x12:
+ {
+ uint64_t base_pfn, npages;
+
+ if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL )
+ break;
+
+ if ( ctl->input[1] != 2 )
+ break;
+
+ /* SGX has not enabled */
+ if ( !p->feat.sgx || !p->sgx.sgx1 )
+ break;
+
+ /*
+ * If SGX is enabled in CPUID, then we are expecting valid
EPC resource
+ * in sub-leaf 0x2. Return -EFAULT to notify toolstack that
there's
+ * something wrong.
+ */
+ if ( !p->sgx.base_valid || !p->sgx.size_valid )
Is there any plausible usecase where only one of these is valid? If
not, why are they split?
You mean why are they split in SDM? I don't think there's any usecase
where only one is valid. In reality, either they both valid, or they
both invalid, otherwise there's bug in either CPU ucode or BIOS. This is
just the definition in SDM.
+ {
+ ret = -EINVAL;
+ break;
+ }
+
+ base_pfn = (((uint64_t)(p->sgx.base_pfn_high)) << 20) |
+ (uint64_t)p->sgx.base_pfn_low;
+ npages = (((uint64_t)(p->sgx.npages_high)) << 20) |
+ (uint64_t)p->sgx.npages_low;
+
+ if ( !hvm_epc_populated(d) )
+ ret = hvm_populate_epc(d, base_pfn, npages);
+ else
+ if ( base_pfn != to_sgx(d)->epc_base_pfn ||
+ npages != to_sgx(d)->epc_npages )
+ ret = -EINVAL;
+
+ break;
+ }
case 0x80000001:
if ( is_pv_domain(d) && ((levelling_caps & LCAP_e1cd) ==
LCAP_e1cd) )
{
@@ -299,7 +344,7 @@ static int update_domain_cpuid_info(struct domain *d,
break;
}
- return 0;
+ return ret;
}
void arch_get_domain_info(const struct domain *d,
diff --git a/xen/include/asm-x86/cpuid.h b/xen/include/asm-x86/cpuid.h
index ac25908eca..326f267263 100644
--- a/xen/include/asm-x86/cpuid.h
+++ b/xen/include/asm-x86/cpuid.h
@@ -61,10 +61,11 @@ extern struct cpuidmasks cpuidmask_defaults;
/* Whether or not cpuid faulting is available for the current
domain. */
DECLARE_PER_CPU(bool, cpuid_faulting_enabled);
-#define CPUID_GUEST_NR_BASIC (0xdu + 1)
+#define CPUID_GUEST_NR_BASIC (0x12u + 1)
#define CPUID_GUEST_NR_FEAT (0u + 1)
#define CPUID_GUEST_NR_CACHE (5u + 1)
#define CPUID_GUEST_NR_XSTATE (62u + 1)
+#define CPUID_GUEST_NR_SGX (0x2u + 1)
#define CPUID_GUEST_NR_EXTD_INTEL (0x8u + 1)
#define CPUID_GUEST_NR_EXTD_AMD (0x1cu + 1)
#define CPUID_GUEST_NR_EXTD MAX(CPUID_GUEST_NR_EXTD_INTEL, \
@@ -169,6 +170,29 @@ struct cpuid_policy
} comp[CPUID_GUEST_NR_XSTATE];
} xstate;
+ union {
+ struct cpuid_leaf raw[CPUID_GUEST_NR_SGX];
+
+ struct {
+ /* Subleaf 0. */
+ uint32_t sgx1:1, sgx2:1, :30;
Please use bool bitfields for these.
Something like:
bool sgx1:1 sgx2:2;
uint32_t :30;
should be fine.
OK. Will do. Thanks.
+ uint32_t miscselect, /* c */ :32;
+ uint32_t maxenclavesize_n64:8, maxenclavesize_64:8, :16;
uint8_t for these please, rather than an 8 bit bitfield.
Can we use clearer names, such as maxsize_legacy and maxsize_long? They
will be accessed via p->sgx. anyway, so the "enclave" bit of context is
already present.
Sure. I'll change to the name you suggested.
+
+ /* Subleaf 1. */
+ uint32_t init:1, debug:1, mode64:1, /*reserve*/:1,
provisionkey:1,
+ einittokenkey:1, :26;
bools as well please here.
Will do.
+ uint32_t /* reserve */:32;
+ uint32_t xfrm_low, xfrm_high;
uint64_t xfrm ?
The XSAVE words are apart because they are not adjacent in the
architectural layout, but these are.
I think the reason I chose xfrm_low and xfrm_high is in recalculate_sgx,
I need to reference them:
if ( p->basic.xsave )
{
p->sgx.xfrm_low |= p->xstate.xcr0_low;
p->sgx.xfrm_high |= p->xstate.xcr0_high;
}
But I have no problem change to xfrm.
+
+ /* Subleaf 2. */
+ uint32_t base_valid:1, :11, base_pfn_low:20;
+ uint32_t base_pfn_high:20, :12;
+ uint32_t size_valid:1, :11, npages_low:20;
+ uint32_t npages_high:20, :12;
+ };
Are the {base,size}_valid fields correct? The manual says the are 4-bit
fields rather than single bit fields.
They are 4 bits in SDM but actually currently only bit 1 is valid (other
values are reserved). I think for now bool base_valid should be enough.
We can extend when new values come out. What's your suggestion?
I would also drop the _pfn from the base names. The fields still need
shifting to get a sensible value.
OK. Will do.
~Andrew
+ } sgx;
+
/* Extended leaves: 0x800000xx */
union {
struct cpuid_leaf raw[CPUID_GUEST_NR_EXTD];
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel
|
