On Fri, Nov 17, 2017 at 03:07:05PM -0800, Darren Hart wrote:
> No incremental cleanup here - appears to all be handled through
> sgx_le_stop - do I have that right?
Yes. This is correct.
/Jarkko
On Fri, Nov 17, 2017 at 03:07:05PM -0800, Darren Hart wrote:
> No incremental cleanup here - appears to all be handled through
> sgx_le_stop - do I have that right?
Yes. This is correct.
/Jarkko
On Fri, Nov 17, 2017 at 03:07:05PM -0800, Darren Hart wrote:
> On Mon, Nov 13, 2017 at 09:45:27PM +0200, Jarkko Sakkinen wrote:
> > Glue code for hosting in-kernel Launch Enclave (LE) by using the user
> > space helper framework.
> >
> > Tokens for launching enclaves are generated with by the
On Fri, Nov 17, 2017 at 03:07:05PM -0800, Darren Hart wrote:
> On Mon, Nov 13, 2017 at 09:45:27PM +0200, Jarkko Sakkinen wrote:
> > Glue code for hosting in-kernel Launch Enclave (LE) by using the user
> > space helper framework.
> >
> > Tokens for launching enclaves are generated with by the
On Mon, Nov 13, 2017 at 09:45:27PM +0200, Jarkko Sakkinen wrote:
> Glue code for hosting in-kernel Launch Enclave (LE) by using the user
> space helper framework.
>
> Tokens for launching enclaves are generated with by the following
> protocol:
>
> 1. The driver sends a SIGSTRUCT blob to the LE
On Mon, Nov 13, 2017 at 09:45:27PM +0200, Jarkko Sakkinen wrote:
> Glue code for hosting in-kernel Launch Enclave (LE) by using the user
> space helper framework.
>
> Tokens for launching enclaves are generated with by the following
> protocol:
>
> 1. The driver sends a SIGSTRUCT blob to the LE
On Tue, Nov 14, 2017 at 10:31:15PM +0200, Jarkko Sakkinen wrote:
> On Tue, Nov 14, 2017 at 10:16:43AM -0800, Sean Christopherson wrote:
> > This semaphore approach is broken due to the LE process using an anon inode
> > for
> > /dev/sgx, which results in sgx_release being called without an
On Tue, Nov 14, 2017 at 10:31:15PM +0200, Jarkko Sakkinen wrote:
> On Tue, Nov 14, 2017 at 10:16:43AM -0800, Sean Christopherson wrote:
> > This semaphore approach is broken due to the LE process using an anon inode
> > for
> > /dev/sgx, which results in sgx_release being called without an
On Tue, Nov 14, 2017 at 10:16:43AM -0800, Sean Christopherson wrote:
> This semaphore approach is broken due to the LE process using an anon inode
> for
> /dev/sgx, which results in sgx_release being called without an accompanying
> call
> to sgx_open. This causes deadlocks due to a semaphore
On Tue, Nov 14, 2017 at 10:16:43AM -0800, Sean Christopherson wrote:
> This semaphore approach is broken due to the LE process using an anon inode
> for
> /dev/sgx, which results in sgx_release being called without an accompanying
> call
> to sgx_open. This causes deadlocks due to a semaphore
On Mon, 2017-11-13 at 21:45 +0200, Jarkko Sakkinen wrote:
> --- a/drivers/platform/x86/intel_sgx/sgx_main.c
> +++ b/drivers/platform/x86/intel_sgx/sgx_main.c
> @@ -88,6 +88,37 @@ u64 sgx_encl_size_max_64;
> u64 sgx_xfrm_mask = 0x3;
> u32 sgx_misc_reserved;
> u32 sgx_xsave_size_tbl[64];
> +bool
On Mon, 2017-11-13 at 21:45 +0200, Jarkko Sakkinen wrote:
> --- a/drivers/platform/x86/intel_sgx/sgx_main.c
> +++ b/drivers/platform/x86/intel_sgx/sgx_main.c
> @@ -88,6 +88,37 @@ u64 sgx_encl_size_max_64;
> u64 sgx_xfrm_mask = 0x3;
> u32 sgx_misc_reserved;
> u32 sgx_xsave_size_tbl[64];
> +bool
Glue code for hosting in-kernel Launch Enclave (LE) by using the user
space helper framework.
Tokens for launching enclaves are generated with by the following
protocol:
1. The driver sends a SIGSTRUCT blob to the LE hosting process
to the input pipe.
2. The LE hosting process reads the
Glue code for hosting in-kernel Launch Enclave (LE) by using the user
space helper framework.
Tokens for launching enclaves are generated with by the following
protocol:
1. The driver sends a SIGSTRUCT blob to the LE hosting process
to the input pipe.
2. The LE hosting process reads the
14 matches
Mail list logo
