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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1513725073.2206.13.camel@linux.intel.com>
Date:   Wed, 20 Dec 2017 01:11:13 +0200
From:   Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>
To:     "Christopherson, Sean J" <sean.j.christopherson@...el.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 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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ