From: Dave Hansen <dave.hansen@intel.com>
To: Sean Christopherson <seanjc@google.com>
Cc: Kai Huang <kai.huang@intel.com>,
linux-sgx@vger.kernel.org, kvm@vger.kernel.org, x86@kernel.org,
jarkko@kernel.org, luto@kernel.org, haitao.huang@intel.com,
pbonzini@redhat.com, bp@alien8.de, tglx@linutronix.de,
mingo@redhat.com, hpa@zytor.com
Subject: Re: [RFC PATCH 11/23] x86/sgx: Add helpers to expose ECREATE and EINIT to KVM
Date: Wed, 6 Jan 2021 13:23:37 -0800 [thread overview]
Message-ID: <7df437ee-e1f3-440c-377b-dbe39820fd44@intel.com> (raw)
In-Reply-To: <X/Yl9UTLhYHg6AVi@google.com>
On 1/6/21 1:04 PM, Sean Christopherson wrote:
> On Wed, Jan 06, 2021, Dave Hansen wrote:
>> On 1/5/21 5:56 PM, Kai Huang wrote:
>>> From: Sean Christopherson <sean.j.christopherson@intel.com>
>>>
>>> Provide wrappers around __ecreate() and __einit() to hide the ugliness
>>> of overloading the ENCLS return value to encode multiple error formats
>>> in a single int. KVM will trap-and-execute ECREATE and EINIT as part
>>> of SGX virtualization, and on an exception, KVM needs the trapnr so that
>>> it can inject the correct fault into the guest.
>>
>> This is missing a bit of a step about how and why ECREATE needs to be
>> run in the host in the first place.
>
> There's (hopefully) good info in the KVM usage patch that can be borrowed:
>
> Add an ECREATE handler that will be used to intercept ECREATE for the
> purpose of enforcing and enclave's MISCSELECT, ATTRIBUTES and XFRM, i.e.
> to allow userspace to restrict SGX features via CPUID. ECREATE will be
> intercepted when any of the aforementioned masks diverges from hardware
> in order to enforce the desired CPUID model, i.e. inject #GP if the
> guest attempts to set a bit that hasn't been enumerated as allowed-1 in
> CPUID.
OK, so in plain language: the bare-metal kernel must intercept ECREATE
to be able to impose policies on guests. When it does this, the
bare-metal kernel runs ECREATE against the userspace mapping of the
virtualized EPC.
>>> diff --git a/arch/x86/include/asm/sgx.h b/arch/x86/include/asm/sgx.h
>>> new file mode 100644
>>> index 000000000000..0d643b985085
>>> --- /dev/null
>>> +++ b/arch/x86/include/asm/sgx.h
>>> @@ -0,0 +1,16 @@
>>> +/* SPDX-License-Identifier: GPL-2.0 */
>>> +#ifndef _ASM_X86_SGX_H
>>> +#define _ASM_X86_SGX_H
>>> +
>>> +#include <linux/types.h>
>>> +
>>> +#ifdef CONFIG_X86_SGX_VIRTUALIZATION
>>> +struct sgx_pageinfo;
>>> +
>>> +int sgx_virt_ecreate(struct sgx_pageinfo *pageinfo, void __user *secs,
>>> + int *trapnr);
>>> +int sgx_virt_einit(void __user *sigstruct, void __user *token,
>>> + void __user *secs, u64 *lepubkeyhash, int *trapnr);
>>> +#endif
>>> +
>>> +#endif /* _ASM_X86_SGX_H */
>>> diff --git a/arch/x86/kernel/cpu/sgx/virt.c b/arch/x86/kernel/cpu/sgx/virt.c
>>> index d625551ccf25..4e9810ba9259 100644
>>> --- a/arch/x86/kernel/cpu/sgx/virt.c
>>> +++ b/arch/x86/kernel/cpu/sgx/virt.c
>>> @@ -261,3 +261,58 @@ int __init sgx_virt_epc_init(void)
>>>
>>> return misc_register(&sgx_virt_epc_dev);
>>> }
>>> +
>>> +int sgx_virt_ecreate(struct sgx_pageinfo *pageinfo, void __user *secs,
>>> + int *trapnr)
>>> +{
>>> + int ret;
>>> +
>>> + __uaccess_begin();
>>> + ret = __ecreate(pageinfo, (void *)secs);
>>> + __uaccess_end();
>>
>> The __uaccess_begin/end() worries me. There are *very* few of these in
>> the kernel and it seems like something we want to use as sparingly as
>> possible.
>>
>> Why don't we just use the kernel mapping for 'secs' and not have to deal
>> with stac/clac?
>
> The kernel mapping isn't readily available.
Oh, duh. There's no kernel mapping for EPC... it's not RAM in the first
place.
> At this point, it's not even
> guaranteed that @secs points at an EPC page. Unlike the driver code, where the
> EPC page is allocated on-demand by the kernel, the pointer here is userspace
> (technically guest) controlled. The caller (KVM) is responsible for ensuring
> it's a valid userspace address, but the SGX/EPC specific checks are mostly
> deferred to hardware.
Ahh, got it. Kai, could we get some of this into comments or the changelog?
>> I'm also just generally worried about casting away an __user without
>> doing any checking. How is that OK?
>
> Short answer, KVM validates the virtual addresses.
>
> KVM validates the host virtual addresses (HVA) when creating a memslot (maps
> GPA->HVA). The HVAs that are passed to these helpers are generated/retrieved
> by KVM translating GVA->GPA->HVA; the GPA->HVA stage ensures the address is in a
> valid memslot, and thus a valid user address.
There is something a *bit* unpalatable about having KVM fill an
'unsigned long' only to cast it to a (void __user *), the to cast it
back to a (void *) to pass it to the SGX inlines.
I guess sparse would catch us in the window that it is __user if someone
tried to dereference it.
Adding access_ok()'s sounds like a good idea to me. Or, at *least*
commenting why they're not necessary.
next prev parent reply other threads:[~2021-01-06 21:24 UTC|newest]
Thread overview: 111+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-06 1:55 [RFC PATCH 00/23] KVM SGX virtualization support Kai Huang
2021-01-06 1:55 ` [RFC PATCH 01/23] x86/sgx: Split out adding EPC page to free list to separate helper Kai Huang
2021-01-11 22:38 ` Jarkko Sakkinen
2021-01-12 0:19 ` Kai Huang
2021-01-12 21:45 ` Sean Christopherson
2021-01-13 1:15 ` Kai Huang
2021-01-13 17:05 ` Jarkko Sakkinen
2021-01-06 1:55 ` [RFC PATCH 02/23] x86/sgx: Add enum for SGX_CHILD_PRESENT error code Kai Huang
2021-01-06 18:28 ` Dave Hansen
2021-01-06 21:40 ` Kai Huang
2021-01-12 0:26 ` Jarkko Sakkinen
2021-01-11 23:32 ` Jarkko Sakkinen
2021-01-12 0:16 ` Kai Huang
2021-01-12 1:46 ` Jarkko Sakkinen
2021-01-06 1:55 ` [RFC PATCH 03/23] x86/sgx: Introduce virtual EPC for use by KVM guests Kai Huang
2021-01-06 19:35 ` Dave Hansen
2021-01-06 20:35 ` Sean Christopherson
2021-01-07 0:47 ` Kai Huang
2021-01-07 0:52 ` Dave Hansen
2021-01-07 1:38 ` Kai Huang
2021-01-07 5:00 ` Dave Hansen
2021-01-07 1:42 ` Kai Huang
2021-01-07 5:02 ` Dave Hansen
2021-01-15 14:07 ` Kai Huang
2021-01-15 15:39 ` Dave Hansen
2021-01-15 21:33 ` Kai Huang
2021-01-15 21:45 ` Sean Christopherson
2021-01-15 22:30 ` Kai Huang
2021-01-11 23:38 ` Jarkko Sakkinen
2021-01-12 0:56 ` Kai Huang
2021-01-12 1:50 ` Jarkko Sakkinen
2021-01-12 2:03 ` Kai Huang
2021-01-06 1:55 ` [RFC PATCH 04/23] x86/cpufeatures: Add SGX1 and SGX2 sub-features Kai Huang
2021-01-06 19:39 ` Dave Hansen
2021-01-06 22:12 ` Kai Huang
2021-01-06 22:21 ` Dave Hansen
2021-01-06 22:56 ` Kai Huang
2021-01-06 23:19 ` Sean Christopherson
2021-01-06 23:33 ` Dave Hansen
2021-01-06 23:56 ` Kai Huang
2021-01-06 23:40 ` Kai Huang
2021-01-06 23:43 ` Dave Hansen
2021-01-06 23:56 ` Kai Huang
2021-01-06 22:15 ` Borislav Petkov
2021-01-06 23:09 ` Kai Huang
2021-01-07 6:41 ` Borislav Petkov
2021-01-08 2:00 ` Kai Huang
2021-01-08 5:10 ` Dave Hansen
2021-01-08 7:03 ` Kai Huang
2021-01-08 7:17 ` Borislav Petkov
2021-01-08 8:06 ` Kai Huang
2021-01-08 8:13 ` Borislav Petkov
2021-01-08 9:00 ` Kai Huang
2021-01-08 23:55 ` Sean Christopherson
2021-01-09 0:35 ` Borislav Petkov
2021-01-09 1:01 ` Sean Christopherson
2021-01-09 1:19 ` Borislav Petkov
2021-01-11 17:54 ` Sean Christopherson
2021-01-11 19:09 ` Borislav Petkov
2021-01-11 19:20 ` Sean Christopherson
2021-01-12 2:01 ` Kai Huang
2021-01-12 12:13 ` Borislav Petkov
2021-01-12 17:15 ` Sean Christopherson
2021-01-12 17:51 ` Borislav Petkov
2021-01-12 21:07 ` Kai Huang
2021-01-12 23:17 ` Sean Christopherson
2021-01-13 1:05 ` Kai Huang
2021-01-11 23:39 ` Jarkko Sakkinen
2021-01-06 1:55 ` [RFC PATCH 05/23] x86/cpu/intel: Allow SGX virtualization without Launch Control support Kai Huang
2021-01-06 19:54 ` Dave Hansen
2021-01-06 22:34 ` Kai Huang
2021-01-06 22:38 ` Dave Hansen
2021-01-06 1:56 ` [RFC PATCH 06/23] x86/sgx: Expose SGX architectural definitions to the kernel Kai Huang
2021-01-06 1:56 ` [RFC PATCH 07/23] x86/sgx: Move ENCLS leaf definitions to sgx_arch.h Kai Huang
2021-01-06 1:56 ` [RFC PATCH 08/23] x86/sgx: Add SGX2 ENCLS leaf definitions (EAUG, EMODPR and EMODT) Kai Huang
2021-01-06 1:56 ` [RFC PATCH 09/23] x86/sgx: Add encls_faulted() helper Kai Huang
2021-01-06 1:56 ` [RFC PATCH 10/23] x86/sgx: Add helper to update SGX_LEPUBKEYHASHn MSRs Kai Huang
2021-01-06 19:56 ` Dave Hansen
2021-01-06 1:56 ` [RFC PATCH 11/23] x86/sgx: Add helpers to expose ECREATE and EINIT to KVM Kai Huang
2021-01-06 20:12 ` Dave Hansen
2021-01-06 21:04 ` Sean Christopherson
2021-01-06 21:23 ` Dave Hansen [this message]
2021-01-06 22:58 ` Kai Huang
2021-01-06 1:56 ` [RFC PATCH 12/23] x86/sgx: Move provisioning device creation out of SGX driver Kai Huang
2021-01-06 1:56 ` [RFC PATCH 13/23] KVM: VMX: Convert vcpu_vmx.exit_reason to a union Kai Huang
2021-01-06 1:56 ` [RFC PATCH 14/23] KVM: x86: Export kvm_mmu_gva_to_gpa_{read,write}() for SGX (VMX) Kai Huang
2021-01-06 1:56 ` [RFC PATCH 15/23] KVM: x86: Define new #PF SGX error code bit Kai Huang
2021-01-06 1:56 ` [RFC PATCH 16/23] KVM: x86: Add SGX feature leaf to reverse CPUID lookup Kai Huang
2021-01-06 1:56 ` [RFC PATCH 17/23] KVM: VMX: Add basic handling of VM-Exit from SGX enclave Kai Huang
2021-01-06 1:56 ` [RFC PATCH 18/23] KVM: VMX: Frame in ENCLS handler for SGX virtualization Kai Huang
2021-01-06 1:56 ` [RFC PATCH 19/23] KVM: VMX: Add SGX ENCLS[ECREATE] handler to enforce CPUID restrictions Kai Huang
2021-01-06 1:56 ` [RFC PATCH 20/23] KVM: VMX: Add emulation of SGX Launch Control LE hash MSRs Kai Huang
2021-01-06 1:56 ` [RFC PATCH 21/23] KVM: VMX: Add ENCLS[EINIT] handler to support SGX Launch Control (LC) Kai Huang
2021-01-06 1:56 ` [RFC PATCH 22/23] KVM: VMX: Enable SGX virtualization for SGX1, SGX2 and LC Kai Huang
2021-01-06 1:58 ` [RFC PATCH 23/23] KVM: x86: Add capability to grant VM access to privileged SGX attribute Kai Huang
2021-01-06 2:22 ` [RFC PATCH 00/23] KVM SGX virtualization support Kai Huang
2021-01-06 17:07 ` Dave Hansen
2021-01-07 0:34 ` Kai Huang
2021-01-07 0:48 ` Dave Hansen
2021-01-07 1:50 ` Kai Huang
2021-01-07 16:14 ` Sean Christopherson
2021-01-08 2:16 ` Kai Huang
2021-01-11 17:20 ` Jarkko Sakkinen
2021-01-11 18:37 ` Sean Christopherson
2021-01-12 1:58 ` Jarkko Sakkinen
2021-01-12 1:14 ` Kai Huang
2021-01-12 2:02 ` Jarkko Sakkinen
2021-01-12 2:07 ` Kai Huang
2021-01-15 14:43 ` Kai Huang
2021-01-16 9:31 ` Jarkko Sakkinen
2021-01-16 9:50 ` Jarkko Sakkinen
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=7df437ee-e1f3-440c-377b-dbe39820fd44@intel.com \
--to=dave.hansen@intel.com \
--cc=bp@alien8.de \
--cc=haitao.huang@intel.com \
--cc=hpa@zytor.com \
--cc=jarkko@kernel.org \
--cc=kai.huang@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-sgx@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).