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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <37306EFA9975BE469F115FDE982C075BCDEE4742@ORSMSX114.amr.corp.intel.com>
Date:   Tue, 19 Dec 2017 23:24:55 +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 Tuesday, December 19, 2017 Jarkko Sakkinen wrote:
> 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.

Exposing the token generated by the in-kernel LE doesn't affect the
kernel's power in the slightest, e.g. the kernel doesn't need a LE
to refuse to run an enclave and a privileged user can always load
an out-of-tree driver if they really want to circumvent the kernel's
policies, which is probably easier than stealing the LE's private key.

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