On Thu, Mar 28, 2019 at 12:18:40PM -0700, Andy Lutomirski wrote:
> Finally, why does the vDSO code bother checking whether the leaf is valid?
To sanity check the input to ensure the caller is attempting to enter an
enclave, i.e. the function is named __vdso_sgx_enter_enclave(), not
On Fri, Mar 29, 2019 at 11:48:14AM +0200, Jarkko Sakkinen wrote:
Good morning to everyone, I hope the weekend is going well.
> Not gonna make it to v20. I'm aiming to send it early next week and have
> already closed the content.
What is the status of your jarkko-sgx/next and jarkko-sgx/master
On Thu, Mar 28, 2019 at 11:19:25PM +, Xing, Cedric wrote:
> > 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
> 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
On Wed, Mar 27, 2019 at 9:23 PM Xing, Cedric wrote:
>
> 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
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 9:53 PM Xing, Cedric wrote:
>
> > 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
> 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 average developers. Instead,
> > >
> 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
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 average developers. Instead,
> > host/enclave
On Sun, Mar 24, 2019 at 1:59 AM Xing, Cedric wrote:
>
> 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.
I think you're misunderstanding me. I'm
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 average developers. Instead,
> host/enclave communications are expected to be handled by SDKs and
> those developers will be
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
> On Mar 23, 2019, at 10:36 AM, Xing, Cedric wrote:
>
> 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
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
On Wed, Mar 20, 2019 at 01:38:04PM -0700, Xing, Cedric wrote:
> > > 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
> > >
On Wed, Mar 20, 2019 at 05:17:53PM -0700, Xing, Cedric wrote:
> > 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
> > > >
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 PM 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:
> >
> > - It prevents using a normal function to wrap enclave entry (as we're
> >
> 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:
> > >
> > > - It prevents using a normal function to wrap
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:
> >
> > - It prevents using a normal function to wrap enclave entry (as
> > 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
On Wed, Mar 20, 2019 at 11:30:26AM -0700, Xing, Cedric wrote:
> > +/**
> > + * __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
On 2019-03-20 11:30, Xing, Cedric wrote:
+/**
+ * __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
On Wed, Mar 20, 2019 at 11:30 AM Xing, Cedric wrote:
>
> > +/**
> > + * __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
> +/**
> + * __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
28 matches
Mail list logo
