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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <37306EFA9975BE469F115FDE982C075BCDEE4562@ORSMSX114.amr.corp.intel.com>
Date:   Tue, 19 Dec 2017 18:52:02 +0000
From:   "Christopherson, Sean J" <sean.j.christopherson@...el.com>
To:     Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "intel-sgx-kernel-dev@...ts.01.org" 
        <intel-sgx-kernel-dev@...ts.01.org>,
        "platform-driver-x86@...r.kernel.org" 
        <platform-driver-x86@...r.kernel.org>
Subject: RE: [intel-sgx-kernel-dev] [PATCH v5 06/11] intel_sgx: driver for
 Intel Software Guard Extensions

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.