linux-kernel - Re: [PATCH 0/6] Intel Secure 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]

Date:	Wed, 27 Apr 2016 07:05:53 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	Greg KH <gregkh@...uxfoundation.org>,
	Mathias Krause <minipli@...glemail.com>,
	"open list:STAGING SUBSYSTEM" <devel@...verdev.osuosl.org>,
	Pavel Machek <pavel@....cz>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Boris Ostrovsky <boris.ostrovsky@...cle.com>,
	Borislav Petkov <bp@...e.de>,
	Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>,
	Wan Zongshun <Vincent.Wan@....com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Kristen Carlson Accardi <kristen@...ux.intel.com>,
	open list <linux-kernel@...r.kernel.org>,
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [PATCH 0/6] Intel Secure Guard Extensions

On Apr 27, 2016 1:18 AM, "Ingo Molnar" <mingo@...nel.org> wrote:
>
>
> * Andy Lutomirski <luto@...capital.net> wrote:
>
> > > What new syscalls would be needed for ssh to get all this support?
> >
> > This patchset or similar, plus some user code and an enclave to use.
> >
> > Sadly, on current CPUs, you also need Intel to bless the enclave.  It looks like
> > new CPUs might relax that requirement.
>
> That looks like a fundamental technical limitation in my book - to an open source
> user this is essentially a very similar capability as tboot: it only allows the
> execution of externally blessed static binary blobs...
>
> I don't think we can merge any of this upstream until it's clear that the hardware
> owner running open-source user-space can also freely define/start his own secure
> enclaves without having to sign the enclave with any external party. I.e.
> self-signed enclaves should be fundamentally supported as well.

Certainly, if this were a *graphics* driver, airlied would refuse to
merge it without open source userspace available.

We're all used to Intel sending patches that no one outside Intel can
test without because no one has the hardware.  Heck, I recently sent a
vdso patch that *I* can't test.  But in this case I have the hardware
and there is no way that I can test it, and I don't like this at all.

See my earlier comments about not allowing user code to provide
EINITTOKEN.  Implementing that would mostly solve this problem, with
the big caveat that it may be impossible to implement that suggestion
until Intel changes its stance (which is clearly in progress, given
the recent SDM updates).

This could easily end up bring a CNL-only feature in Linux.  (Or
whatever generation that change is in.)

--Andy