lkml.org 
[lkml]   [2017]   [Dec]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [intel-sgx-kernel-dev] [PATCH v5 06/11] intel_sgx: driver for Intel Software Guard Extensions
Date
On Friday, 2017-12-15, Jarkko Sakkinen wrote:
> > Resurrecting this thread now that I have a system with launch control
> > and have been able to measure the performance impact...
> >
> > Regenerating the EINIT token every time adds somewhere in the vicinity
> > of ~5% overhead to creating an enclave, versus generating a token once
> > and reusing it in each EINIT call. This isn't a huge issue since real
> > world usage models likely won't be re-launching enclaves at a high rate,
> > but it is measurable.
>
> We can cache tokens in future in the kernel space, can't we?

Yes, but why? Deferring to userspace is less complex and likely
more performant.

Tokens are large enough that there would need to be some form of
limit on the number of tokens, which brings up questions about
how to account tokens, the cache eviction scheme, whether or not
the size of the cache should be controllable from userspace, etc...

Userspace caching can likely provide better performance because
the user/application knows the usage model and life expectancy of
its tokens, i.e. userspace can make informed decisions about when
to discard a token, how much memory to dedicate to caching tokens,
etc... And in the case of VMs, userspace can reuse tokens across
reboots (of the VM), e.g. by saving tokens to disk.

\
 
 \ /
  Last update: 2017-12-19 19:53    [W:0.101 / U:1.400 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site