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:	Sun, 8 May 2016 18:32:10 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	"Dr. Greg Wettstein" <greg@...ellic.com>
Cc:	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Mathias Krause <minipli@...glemail.com>,
	"open list:STAGING SUBSYSTEM" <devel@...verdev.osuosl.org>,
	"Austin S. Hemmelgarn" <ahferroin7@...il.com>,
	Pavel Machek <pavel@....cz>, Ingo Molnar <mingo@...nel.org>,
	Greg KH <gregkh@...uxfoundation.org>,
	Boris Ostrovsky <boris.ostrovsky@...cle.com>,
	Borislav Petkov <bp@...e.de>,
	Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>,
	Wan Zongshun <Vincent.Wan@....com>,
	Kristen Carlson Accardi <kristen@...ux.intel.com>,
	open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/6] Intel Secure Guard Extensions

On May 8, 2016 2:59 AM, "Dr. Greg Wettstein" <greg@...ellic.com> wrote:
>
>
> This now means the security of SGX on 'unlocked' platforms, at least
> from a trust perspective, will be dependent on using TXT so as to
> provide a hardware root of trust on which to base the SGX trust model.

Can you explain what you mean by "trust"?  In particular, what kind of
"trust" would you have with a verified or trusted boot plus verified
SGX launch root key that you would not have in the complete absence of
hardware launch control.

I've heard multiple people say they want launch control but I've never
heard a cogent explanation of a threat model in which it's useful.

> I would assume that everyone is using signed Launch Control Policies
> (LCP) as we are.  This means that TXT/tboot already has access to the
> public key which is used for the LCP data file signature.  It would
> seem logical to have tboot compute the signature on that public key
> and program that signature into the module signature registers.  That
> would tie the hardware root of trust to the SGX root of trust.

Now I'm confused.  TXT, in theory*, lets you establish a good root of
trust for TPM PCR measurements.  So, with TXT, if you had one-shop
launch control MSRs, you could attest that you've locked the launch
control policy.

But what do you gain by doing such a thing?  All you're actually
attesting is that you locked it until the next reboot.  Someone who
subsequently compromises you can reboot you, bypass TXT on the next
boot, and launch any enclave they want.  In any event, SGX is supposed
to make it so that your enclaves remain secure regardless of what
happens to the kernel, so I'm at a loss for what you're trying to do.

* There are some serious concerns about the security of TXT.  SGX is
supposed to be better.

--Andy