Re: [intel-sgx-kernel-dev] [PATCH v5 06/11] intel_sgx: driver for Intel Software Guard Extensions

[Jarkko Sakkinen]

On Tue, 2017-12-19 at 18:52 +0000, Christopherson, Sean J wrote:
> > 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.

That's quite strong argument especially if you are making that for
systems running multiple independent workloads and not just a single
application.

> 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...

Leaving caching decisions to the kernel also gives more freedoms to
do global decisions.

> 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.

I'm not really convinced that your argument is sound if you consider the
whole range of x86 systems that can run enclaves especially if the
system is running multiple irrelated applications.

And you are ignoring everything else but the performance, which is does
not make any sense. The current design governs the Linux kernel to have
the ultimate power, which enclaves to run with the minimized proprietary
risk. I think that is something worth of emphasizing too.

Whether the token caching is left to kernel or user space will most
definitely introduce some non-trivial performance problems to solve
with some unexpected workloads that we cannot imagine right now. That's
why the governance should be the driver. Not the performance. Those
issues can and must be sorted out in any case.

/Jarkko