On 9/26/2020 12:05 PM, Andy Lutomirski wrote:
On Fri, Sep 25, 2020 at 3:29 PM Sean Christopherson
wrote:
On Fri, Sep 25, 2020 at 01:20:03PM -0700, Andy Lutomirski wrote:
On Fri, Sep 25, 2020 at 12:09 PM Sean Christopherson
wrote:
But where would the vDSO get memory for that little data
On 7/13/2019 10:08 AM, Jarkko Sakkinen wrote:
Add a selftest for SGX. It is a trivial test where a simple enclave
copies one 64-bit word of memory between two memory locations given to
the enclave as arguments.
Signed-off-by: Jarkko Sakkinen
---
tools/testing/selftests/x86/Makefile
On 7/13/2019 10:07 AM, Jarkko Sakkinen wrote:
From: Sean Christopherson
Intel Software Guard Extensions (SGX) introduces a new CPL3-only enclave
mode that runs as a sort of black box shared object that is hosted by an
untrusted normal CPL3 process.
Skipping over a great deal of gory
On 7/13/2019 8:15 AM, Jarkko Sakkinen wrote:
On Sat, 2019-07-13 at 18:10 +0300, Jarkko Sakkinen wrote:
On Fri, 2019-07-12 at 23:51 -0700, Cedric Xing wrote:
The original x86/sgx/Makefile didn't work when "x86/sgx" was specified as the
test target, nor did it work with "run_tests" as the make
On 7/11/2019 8:25 PM, Jarkko Sakkinen wrote:
On Tue, Apr 23, 2019 at 11:26:23PM -0700, Cedric Xing wrote:
This patch augments SGX selftest with two new tests.
The first test exercises the newly added callback interface, by marking the
whole enclave range as PROT_READ, then calling mprotect()
On 7/11/2019 8:19 PM, Jarkko Sakkinen wrote:
On Tue, Apr 23, 2019 at 11:26:21PM -0700, Cedric Xing wrote:
The original x86/sgx/Makefile doesn't work when 'x86/sgx' is specified as the
test target. This patch fixes that problem, along with minor changes to the
dependencies between 'x86' and
On 7/11/2019 8:54 AM, Sean Christopherson wrote:
On Thu, Jun 27, 2019 at 01:32:58PM -0700, Xing, Cedric wrote:
Just a reminder that #DB/#BP shall be treated differently because they are
used by debuggers. So instead of branching to the fixup address, the kernel
shall just signal the process
On 7/11/2019 2:38 AM, Jarkko Sakkinen wrote:
On Wed, Jul 10, 2019 at 04:37:41PM -0700, Xing, Cedric wrote:
On 7/10/2019 4:15 PM, Jarkko Sakkinen wrote:
On Thu, Jul 11, 2019 at 01:46:28AM +0300, Jarkko Sakkinen wrote:
On Wed, Jul 10, 2019 at 11:08:37AM -0700, Xing, Cedric wrote
On 7/11/2019 2:36 AM, Jarkko Sakkinen wrote:
On Wed, Jul 10, 2019 at 03:54:20PM -0700, Xing, Cedric wrote:
On 7/10/2019 3:46 PM, Jarkko Sakkinen wrote:
On Wed, Jul 10, 2019 at 11:08:37AM -0700, Xing, Cedric wrote:
With these conclusions I think the current vDSO API is sufficient for
Linux
On 7/10/2019 4:15 PM, Jarkko Sakkinen wrote:
On Thu, Jul 11, 2019 at 01:46:28AM +0300, Jarkko Sakkinen wrote:
On Wed, Jul 10, 2019 at 11:08:37AM -0700, Xing, Cedric wrote:
With these conclusions I think the current vDSO API is sufficient for
Linux.
The new vDSO API is to support data
On 7/10/2019 3:46 PM, Jarkko Sakkinen wrote:
On Wed, Jul 10, 2019 at 11:08:37AM -0700, Xing, Cedric wrote:
With these conclusions I think the current vDSO API is sufficient for
Linux.
The new vDSO API is to support data exchange on stack. It has nothing to do
with debugging. BTW
On 7/10/2019 4:17 AM, Jarkko Sakkinen wrote:
On Tue, Apr 23, 2019 at 11:26:20PM -0700, Cedric Xing wrote:
The current proposed __vdso_sgx_enter_enclave() requires enclaves to preserve
%rsp, which prohibits enclaves from allocating space on the untrusted stack.
However, there are existing
> From: linux-sgx-ow...@vger.kernel.org [mailto:linux-sgx-
> ow...@vger.kernel.org] On Behalf Of Jarkko Sakkinen
> Sent: Tuesday, June 25, 2019 8:44 AM
>
> I went through the vDSO changes just to revisit couple of details that I
> had forgotten. Sean, if you don't mind I'd squash this and
> From: Christopherson, Sean J
> Sent: Thursday, June 13, 2019 5:46 PM
>
> On Thu, Jun 13, 2019 at 01:02:17PM -0400, Stephen Smalley wrote:
> > On 6/11/19 6:02 PM, Sean Christopherson wrote:
> > >On Tue, Jun 11, 2019 at 09:40:25AM -0400, Stephen Smalley wrote:
> > >>I haven't looked at this code
> From: Christopherson, Sean J
> Sent: Thursday, June 13, 2019 4:18 PM
>
> On Thu, Jun 13, 2019 at 04:03:24PM -0700, Xing, Cedric wrote:
> > > From: Stephen Smalley [mailto:s...@tycho.nsa.gov]
> > > Sent: Thursday, June 13, 2019 10:02 AM
> > >
>
> From: Stephen Smalley [mailto:s...@tycho.nsa.gov]
> Sent: Thursday, June 13, 2019 10:02 AM
>
> On 6/11/19 6:02 PM, Sean Christopherson wrote:
> > On Tue, Jun 11, 2019 at 09:40:25AM -0400, Stephen Smalley wrote:
> >> I haven't looked at this code closely, but it feels like a lot of
> >>
> From: Christopherson, Sean J
> Sent: Thursday, June 13, 2019 12:49 PM
>
> > >By "SGX", did you mean the SGX subsystem being upstreamed? It doesn’t
> > >track that state. In practice, there's no way for SGX to track it
> > >because there's no vm_ops->may_mprotect() callback. It doesn't follow
>
> From: linux-sgx-ow...@vger.kernel.org [mailto:linux-sgx-
> ow...@vger.kernel.org] On Behalf Of Stephen Smalley
>
> On 6/11/19 6:55 PM, Xing, Cedric wrote:
> >> From: linux-sgx-ow...@vger.kernel.org [mailto:linux-sgx-
> >> ow...@vger.kernel.org] On Behalf Of Step
> From: Christopherson, Sean J
> Sent: Wednesday, June 12, 2019 3:03 PM
>
> > I think this model works quite well in an SGX1 world. The main thing
> > that makes me uneasy about this model is that, in SGX2, it requires
> > that an SGX2-compatible enclave loader must pre-declare to the kernel
> >
> From: Christopherson, Sean J
> Sent: Wednesday, June 12, 2019 3:03 PM
>
> > I think this model works quite well in an SGX1 world. The main thing
> > that makes me uneasy about this model is that, in SGX2, it requires
> > that an SGX2-compatible enclave loader must pre-declare to the kernel
> >
gt; > > On Jun 5, 2019, at 8:17 AM, Jarkko Sakkinen
> wrote:
> > > >
> > > >> On Tue, Jun 04, 2019 at 10:10:22PM +, Xing, Cedric wrote:
> > > >> A bit off topic here. This mmap()/mprotect() discussion reminds
> > > >> me a ques
> From: Christopherson, Sean J
> Sent: Wednesday, June 12, 2019 7:34 AM
>
> On Tue, Jun 11, 2019 at 05:09:28PM -0700, Andy Lutomirski wrote:
> >
> > On Jun 10, 2019, at 3:28 PM, Xing, Cedric
> wrote:
> >
> > >> From: Andy Lutomirski [mailto:l...@kern
> From: linux-sgx-ow...@vger.kernel.org [mailto:linux-sgx-
> ow...@vger.kernel.org] On Behalf Of Stephen Smalley
> Sent: Tuesday, June 11, 2019 6:40 AM
>
> >
> > +#ifdef CONFIG_INTEL_SGX
> > + rc = sgxsec_mprotect(vma, prot);
> > + if (rc <= 0)
> > + return rc;
>
> Why are you
> From: Andy Lutomirski [mailto:l...@kernel.org]
> Sent: Monday, June 10, 2019 12:15 PM
>
> On Mon, Jun 10, 2019 at 11:29 AM Xing, Cedric
> wrote:
> >
> > > From: Christopherson, Sean J
> > > Sent: Wednesday, June 05, 2019 7:12 PM
> > >
> From: Christopherson, Sean J
> Sent: Monday, June 10, 2019 12:50 PM
>
> On Mon, Jun 10, 2019 at 10:47:52AM -0700, Xing, Cedric wrote:
> > > From: Christopherson, Sean J
> > > Sent: Monday, June 10, 2019 8:56 AM
> > >
> > > > > As a re
> From: Christopherson, Sean J
> Sent: Wednesday, June 05, 2019 7:12 PM
>
> +/**
> + * sgx_map_allowed - check vma protections against the associated
> enclave page
> + * @encl:an enclave
> + * @start: start address of the mapping (inclusive)
> + * @end: end address of the mapping
> From: Christopherson, Sean J
> Sent: Monday, June 10, 2019 8:56 AM
>
> > > As a result, LSM policies cannot be meaningfully applied, e.g. an
> > > LSM can deny access to the EPC as a whole, but can't deny PROT_EXEC
> > > on page that originated in a non-EXECUTE file (which is long gone by
> > >
> From: linux-sgx-ow...@vger.kernel.org [mailto:linux-sgx-
> ow...@vger.kernel.org] On Behalf Of Andy Lutomirski
> Sent: Tuesday, June 04, 2019 1:16 PM
>
> On Tue, Jun 4, 2019 at 4:50 AM Jarkko Sakkinen
> wrote:
> >
> > On Fri, May 31, 2019 at 04:31:52PM -0700, Sean Christopherson wrote:
> > >
> From: Andy Lutomirski [mailto:l...@kernel.org]
> Sent: Tuesday, June 04, 2019 1:18 PM
>
> On Mon, Jun 3, 2019 at 1:39 PM Sean Christopherson
> wrote:
> >
> > On Mon, Jun 03, 2019 at 01:08:04PM -0700, Sean Christopherson wrote:
> > > On Sun, Jun 02, 2019 at
> From: Andy Lutomirski [mailto:l...@kernel.org]
> Sent: Tuesday, June 04, 2019 1:25 PM
> To: Jarkko Sakkinen
>
> On Tue, Jun 4, 2019 at 9:26 AM Jarkko Sakkinen
> wrote:
> >
> > On Fri, May 31, 2019 at 04:31:57PM -0700, Sean Christopherson wrote:
> > > Do not allow an enclave page to be mapped
> From: Christopherson, Sean J
> Sent: Tuesday, June 04, 2019 1:37 PM
>
> On Tue, Jun 04, 2019 at 01:29:10PM -0700, Andy Lutomirski wrote:
> > On Fri, May 31, 2019 at 4:32 PM Sean Christopherson
> > wrote:
> > > static int sgx_encl_add_page(struct sgx_encl *encl, unsigned long
> > > addr, diff
Hi Stephen,
> From: linux-sgx-ow...@vger.kernel.org [mailto:linux-sgx-
> ow...@vger.kernel.org] On Behalf Of Stephen Smalley
> Sent: Tuesday, June 04, 2019 8:34 AM
>
> On 6/3/19 2:30 PM, Xing, Cedric wrote:
> >> From: Christopherson, Sean J
> >> Sen
> -Original Message-
> From: Christopherson, Sean J
> Sent: Monday, June 03, 2019 1:37 PM
> To: Hansen, Dave
> Cc: Jarkko Sakkinen ; Andy Lutomirski
> ; Xing, Cedric ; Stephen Smalley
> ; James Morris ; Serge E . Hallyn
> ; LSM List ;
> Paul
> From: Christopherson, Sean J
> Sent: Monday, June 03, 2019 1:40 PM
>
> On Mon, Jun 03, 2019 at 01:08:04PM -0700, Sean Christopherson wrote:
> > On Sun, Jun 02, 2019 at 11:26:09PM -0700, Xing, Cedric wrote:
> > > > From: Christopherson, Sean J
> > &g
> From: Christopherson, Sean J
> Sent: Monday, June 03, 2019 10:16 AM
>
> On Sun, Jun 02, 2019 at 12:29:35AM -0700, Xing, Cedric wrote:
> > Hi Sean,
> >
> > Generally I agree with your direction but think ALLOW_* flags are
> > completely internal to L
> From: linux-sgx-ow...@vger.kernel.org [mailto:linux-sgx-
> ow...@vger.kernel.org] On Behalf Of Stephen Smalley
> Sent: Monday, June 03, 2019 10:47 AM
>
> On 6/2/19 3:29 AM, Xing, Cedric wrote:
> > Hi Sean,
> >
> >> From: Christopherson, Sean J
>
> From: Christopherson, Sean J
> Sent: Friday, May 31, 2019 4:32 PM
>
> Do not allow an enclave page to be mapped with PROT_EXEC if the source page
> is backed by a
> file on a noexec file system.
>
> Signed-off-by: Sean Christopherson
> ---
> arch/x86/kernel/cpu/sgx/driver/ioctl.c | 26
> From: Christopherson, Sean J
> Sent: Friday, May 31, 2019 4:32 PM
>
> ...to support (the equivalent) of existing Linux Security Module
> functionality.
>
> Because SGX manually manages EPC memory, all enclave VMAs are backed by the
> same vm_file,
> i.e. /dev/sgx/enclave, so that SGX can
> From: Christopherson, Sean J
> Sent: Friday, May 31, 2019 4:32 PM
>
> To support LSM integration, SGX will require userspace to explicitly specify
> the allowed
> protections for each page. The allowed protections will be supplied to and
> modified by
> LSMs (based on their policies).
> To
> From: Christopherson, Sean J
> Sent: Friday, May 31, 2019 4:32 PM
>
> diff --git a/include/linux/security.h b/include/linux/security.h index
> 659071c2e57c..2f7925eeef7e 100644
> --- a/include/linux/security.h
> +++ b/include/linux/security.h
> @@ -392,6 +392,8 @@ void
> From: Christopherson, Sean J
> Sent: Friday, May 31, 2019 4:32 PM
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h index
> 0e8834ac32b7..50a42364a885
> 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -458,6 +458,8 @@ struct vm_operations_struct {
> void
> From: Christopherson, Sean J
> Sent: Friday, May 31, 2019 4:32 PM
>
> +/**
> + * sgx_ioc_enclave_add_pages - handler for %SGX_IOC_ENCLAVE_ADD_PAGES
> + *
> + * @filep: open file to /dev/sgx
> + * @cmd: the command value
> + * @arg: pointer to an _enclave_add_page instance
> + *
> + *
Hi Sean,
> From: Christopherson, Sean J
> Sent: Friday, May 31, 2019 4:32 PM
>
> This series is the result of a rather absurd amount of discussion over how to
> get SGX to play
> nice with LSM policies, without having to resort to evil shenanigans or put
> undue burden on
> userspace. The
Hi Andy,
I'm just curious how Sean convinced you that "MAXPERM doesn't work". More
specifically, I'm objecting to the statement of "the enclave loader won't know
at load time whether a given EAUG-ed page will ever be executed".
I'm still new to LSM so my understanding may not be correct. But I
> From: linux-sgx-ow...@vger.kernel.org
> [mailto:linux-sgx-ow...@vger.kernel.org] On Behalf
> Of Stephen Smalley
> Sent: Wednesday, May 29, 2019 7:08 AM
>
> On 5/28/19 4:24 PM, Sean Christopherson wrote:
> > On Sat, May 25, 2019 at 11:09:38PM -0700, Xing, Cedric
> From: Christopherson, Sean J
> Sent: Tuesday, May 28, 2019 2:41 PM
>
> On Tue, May 28, 2019 at 01:48:02PM -0700, Andy Lutomirski wrote:
> > On Tue, May 28, 2019 at 1:24 PM Sean Christopherson
> > wrote:
> > >
> > > Actually, I think we do have everything we need from an LSM perspective.
> > >
> From: Andy Lutomirski [mailto:l...@kernel.org]
> Sent: Saturday, May 25, 2019 5:58 PM
>
> On Sat, May 25, 2019 at 3:40 PM Xing, Cedric wrote:
> >
> > > From: Andy Lutomirski [mailto:l...@amacapital.net]
> > > Sent: Friday, May 24, 2019 4:42 PM
> > &
, May 24, 2019 at 1:03 PM Sean Christopherson
> >> wrote:
> >>>
> >>>> On Fri, May 24, 2019 at 12:37:44PM -0700, Andy Lutomirski wrote:
> >>>>> On Fri, May 24, 2019 at 11:34 AM Xing, Cedric
> >>>>> wrote:
> >>&
> From: linux-sgx-ow...@vger.kernel.org [mailto:linux-sgx-
> ow...@vger.kernel.org] On Behalf Of Sean Christopherson
> Sent: Friday, May 24, 2019 1:04 PM
>
> On Fri, May 24, 2019 at 12:37:44PM -0700, Andy Lutomirski wrote:
> > On Fri, May 24, 2019 at 11:34 AM
> From: linux-sgx-ow...@vger.kernel.org [mailto:linux-sgx-
> ow...@vger.kernel.org] On Behalf Of Sean Christopherson
> Sent: Friday, May 24, 2019 12:14 PM
>
> My point is that enclaves have different properties than shared objects.
>
> Normal LSM behavior with regard to executing files is to
> From: linux-sgx-ow...@vger.kernel.org [mailto:linux-sgx-
> ow...@vger.kernel.org] On Behalf Of Sean Christopherson
> Sent: Friday, May 24, 2019 10:55 AM
>
> On Fri, May 24, 2019 at 10:42:43AM -0700, Sean Christopherson wrote:
> > Hmm, I've been thinking more about pulling permissions from the
Hi Stephen,
> On 5/24/19 3:24 AM, Xing, Cedric wrote:
> >
> > When we talk about EPC page permissions with SGX2 in mind, I think we
> should distinguish between initial permissions and runtime permissions.
> Initial permissions refer to the page permissions set at EADD. They
Hi Andy,
> From: Andy Lutomirski [mailto:l...@kernel.org]
> Sent: Thursday, May 23, 2019 6:18 PM
>
> On Thu, May 23, 2019 at 4:40 PM Sean Christopherson
>
> wrote:
> >
> > On Thu, May 23, 2019 at 08:38:17AM -0700, Andy Lutomirski wrote:
> > > On Thu, May 23, 2019 at 7:17 AM Sean Christopherson
> From: Andy Lutomirski [mailto:l...@kernel.org]
>
> On Thu, May 16, 2019 at 3:23 PM Xing, Cedric
> wrote:
> >
> > Hi Andy,
> >
> > > > SIGSTRUCT isn't necessarily stored on disk so may not always have
> a fd.
> > > How about the following?
&
> > > There is a problem here though. Usually the enclave itself is just a
> > > loader that then loads the application from outside source and
> > > creates the executable pages from the content.
> > >
> > > A great example of this is Graphene that bootstraps unmodified Linux
> > > applications
Hi Andy,
> > SIGSTRUCT isn't necessarily stored on disk so may not always have a fd.
> How about the following?
> > void *ss_pointer = mmap(sigstruct_fd, PROT_READ,...);
> > ioctl(enclave_fd, SGX_INIT_THE_ENCLAVE, ss_pointer);
> >
> > The idea here is SIGSTRUCT will still be passed in memory so
Hi Andy,
> From: Andy Lutomirski [mailto:l...@kernel.org]
>
> On Wed, May 15, 2019 at 3:46 PM James Morris wrote:
> >
> > On Wed, 15 May 2019, Andy Lutomirski wrote:
> >
> > > > Why not just use an xattr, like security.sgx ?
> > >
> > > Wouldn't this make it so that only someone with
Hi Andy,
> Let me make sure I'm understanding this correctly: when an enclave tries
> to execute code, it only works if *both* the EPCM and the page tables
> grant the access, right? This seems to be that 37.3 is trying to say.
> So we should probably just ignore SECINFO for these purposes.
>
>
; >>> On Fri, 10 May 2019 14:22:34 -0500, Andy Lutomirski
> >>>
> >>> wrote:
> >>>
> >>> > On Fri, May 10, 2019 at 12:04 PM Jethro Beekman
> >>> >
> >>> > wrote:
> >>> >>
> >>&
Hi Andy and Jethro,
> > > You have probably misread my email. By mmap(), I meant the enclave
> file would be mapped via *multiple* mmap() calls, in the same way as
> what dlopen() would do in loading regular shared object. The intention
> here is to make the enclave file subject to the same
Hi Jethro,
> ELF files are explicitly designed such that you can map them (with mmap)
> in 4096-byte chunks. However, sometimes there's overlap and you will
> sometimes see that a particular offset is mapped twice because the first
> half of the page in the file belongs to an RX range and the
Hi Dave,
> On 5/10/19 10:37 AM, Jethro Beekman wrote:
> > It does assume a specific format, namely, that the memory layout
> > (including page types/permissions) of the enclave can be represented
> in
> > a "flat file" on disk, or at least that the enclave memory contents
> > consist of 4096-byte
Hi Andy,
> So I think we need a better EADD ioctl that explicitly does work on
> PROT_READ|PROT_EXEC enclave memory but makes up for by validating the
> *source* of the data. The effect will be similar to mapping a
> labeled, appraised, etc file as PROT_EXEC. Maybe, in extreme
> pseudocode:
>
Hi Sean,
> AIUI, you and Andy had an off-list discussion regarding rewriting
> __vdso_sgx_enter_enclave() vs. providing a second vDSO function. Can
> you
> please summarize the discussion so that it's clear why you're pursuing a
> single function?
>
> In the end I probably agree that's it's
and #BP at ENCLU, the unwind
test cannot run to completion. I assume Sean will revise the fixup code soon.
Thanks!
-Cedric
> -Original Message-
> From: Andy Lutomirski [mailto:l...@kernel.org]
> Sent: Monday, April 22, 2019 6:26 PM
> To: Xing, Cedric
> Cc: LKML ; X86
> It's certainly making progress. I like the fact that the callback is
> now unconditional (if non-NULL) rather than being used just in case of
> certain exit types. But, if we go down this route, let's name and
> document it appropriately -- just call the function "callback" and
> document it
Hi Andy,
> From: linux-sgx-ow...@vger.kernel.org [mailto:linux-sgx-
> ow...@vger.kernel.org] On Behalf Of Andy Lutomirski
>
> I suppose the real question is: are there a significant number of
> users who will want to run enclaves created using an old SDK on Linux?
> And will there actually be
> On Mon, Mar 25, 2019 at 11:03 AM Sean Christopherson
> wrote:
> >
> > On Sun, Mar 24, 2019 at 01:59:48AM -0700, Xing, Cedric wrote:
> > > As said in my previous email, this vDSO API isn't even compliant to
> > > x86_64 ABI and is absolutely NOT for ave
> I think you're misunderstanding me. I'm not talking about security at
> all here. SGX isn't a sandbox, full stop. I'm talking about the degree
> to which an SGX enclave acts like a well-behaved black box.
Any meaningful communication requires an agreement in place. The host and the
enclave
Hi Andy,
Thank you for your valuable feedbacks!
Per what you have been saying, your feedbacks come from different angles - i.e.
functionality vs. security, but they are mixed up somehow. As an effort to make
the discussion more constructive going forward, I'd like you to acknowledge
that, in
Hi Sean,
> Although its just 9 LOC, consider its impact on someone who is looking
> at
> the kernel's SGX support for the first time. Questions they may have
> when
> looking at the vDSO code/documentation:
>
> - What's an exit handler?
> - Why is an exit handler optional? Don't I always
Hi Andy,
> > > - It will make it quite unpleasant to call into an enclave in a
> > > coroutine depending on how the host untrusted runtime implements
> > > coroutines.
> >
> > I'm not sure what you are referring to by "coroutine". But this vDSO
> API will be (expected to be) the only routine
> On Wed, Mar 20, 2019 at 12:57:52PM -0700, Xing, Cedric wrote:
> > > Using the untrusted stack as a way to exchange data is very
> > > convenient, but that doesn't mean it's a good idea. Here are some
> > > problems it
> > > causes:
> > >
>
> > By requiring preservation of RSP at both AEX and EEXIT, this precludes
> > the possibility of using the untrusted stack as temporary storage by
> > enclaves. While that looks reasonable at first glance, I'm afraid it
> > isn't the case in reality. The untrusted stack is inarguably the most
> >
> > By requiring preservation of RSP at both AEX and EEXIT, this precludes
> the possibility of using the untrusted stack as temporary storage by
> enclaves. While that looks reasonable at first glance, I'm afraid it
> isn't the case in reality. The untrusted stack is inarguably the most
>
> Using the untrusted stack as a way to exchange data is very convenient,
> but that doesn't mean it's a good idea. Here are some problems it
> causes:
>
> - It prevents using a normal function to wrap enclave entry (as we're
> seeing with this patch set).
It doesn't prevent. It's all about
> +/**
> + * __vdso_sgx_enter_enclave() - Enter an SGX enclave
> + *
> + * %eax:ENCLU leaf, must be EENTER or ERESUME
> + * %rbx:TCS, must be non-NULL
> + * %rcx:Optional pointer to 'struct sgx_enclave_exception'
> + *
> + * Return:
> + * 0 on a clean entry/exit to/from
77 matches
Mail list logo
