Linux-Sgx Archive on lore.kernel.org
 help / color / Atom feed
From: Andy Lutomirski <luto@kernel.org>
To: "Dr. Greg Wettstein" <greg@enjellic.com>
Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
	Andrew Lutomirski <luto@kernel.org>, X86 ML <x86@kernel.org>,
	Platform Driver <platform-driver-x86@vger.kernel.org>,
	linux-sgx@vger.kernel.org, Dave Hansen <dave.hansen@intel.com>,
	"Christopherson, Sean J" <sean.j.christopherson@intel.com>,
	nhorman@redhat.com, npmccallum@redhat.com, "Ayoun,
	Serge" <serge.ayoun@intel.com>,
	shay.katz-zamir@intel.com, haitao.huang@linux.intel.com,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	"Svahn, Kai" <kai.svahn@intel.com>,
	mark.shanahan@intel.com,
	Suresh Siddha <suresh.b.siddha@intel.com>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Darren Hart <dvhart@infradead.org>,
	Andy Shevchenko <andy@infradead.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v17 18/23] platform/x86: Intel SGX driver
Date: Mon, 26 Nov 2018 10:22:20 -0800
Message-ID: <CALCETrVdooOwt080-f-Sr92pnbRVchsffxWGnnEHmH40qLyCdA@mail.gmail.com> (raw)
In-Reply-To: <20181126110038.GA27609@wind.enjellic.com>

On Mon, Nov 26, 2018 at 3:00 AM Dr. Greg <greg@enjellic.com> wrote:
>
> On Sun, Nov 25, 2018 at 04:37:00PM -0800, Andy Lutomirski wrote:
>
> > Bah, I hit send on a partially written draft. I???ll try again soon.
> >
> > --Andy
>
> Your first issue seems to be complete so I will respond to that in
> order to make sure we are not talking past one another.

It wasn't, but your answer is enlightening!  I've read the SGX
*manual*, but I hadn't dug through the actual Intel-supplied enclaves.
So, when I said that the LE isn't an important part of the overall
trust model, I meant that it isn't *in hardware*.  It's certainly
possible to write SGX software that weakens the security of the
overall system, and Intel seems to have done so:

>
> The Intel supplied launch enclave (LE) specifically denies
> initialization of enclaves which have the PROVISION attribute set,
> with the exception of enclaves whose MRSIGNER values match those of
> the keys that Intel uses to sign the PCE and PVE enclaves.  See line
> 219 of psw/ae/le/launch_enclave.cpp in the Intel SDK.

This seems entirely reasonable.  (But see below...)

> This report, along with the PEK, is submitted to the PCE enclave in
> order to generate the Platform Provisioning IDentity (PPID), which is
> the privacy critical identifier.  The PCE verifies the report
> generated by the PVE and rejects the request to generate the PPID if
> the report was generated by an enclave that was not initialized with
> the PROVISION bit set, see line 109 of psw/ae/pce/pce.cpp.

...and this seems entirely unreasonable.  Your description does indeed
appear consistent with the code: the PCE will hand out the PPID to any
requesting enclave that has the PROVISION bit set, so you are correct
that:

> Once again, the important design factor in all of this is the premise
> that the launch enclave will not allow enclaves other then the PCE and
> PVE to access the PROVISION bit.

But here's where the whole thing goes off the rails.  I would argue
that the Intel-supplied (and Intel-signed, apparently!) PCE is just
straight-up buggy.  What Intel is *trying* to do is to hand out the
PPID to an appropriately signed enclave.  What they actually did is to
hand out the PPID to any enclave that has the PROVISION bit set.  This
is poor design because it overload the PROVISION bit.  That bit is
supposed to mean "may use EGETKEY to obtain provisioning and
provisioning seal keys", which is not actually what Intel wants here.
It's also poor design without FLC because it pointlessly relies on the
LE to enforce a restriction on the use of provisioning enclaves, when
the code could instead have checked MRSIGNER..  And it's just straight
up wrong with FLC because there is no guarantee whatsoever that the LE
being used is Intel's.  And, for that matter, there is no guarantee
that the requesting enclave doesn't have the DEBUG bit set.

(It's also poor design because the PCE doesn't appear to verify that
the report passed in is actually intended to be associated with a call
to get_ppid().  There appear to be reports associated with provision
"msg1" and "msg3".  If it's possible to get a valid report for msg3 to
be accepted as a msg1 report of vice versa, then it might be game
over.)

Sorry, but this is not Linux's problem.  The right fix is, in my
opinion, entirely clear: the PCE should check MRSIGNER and possibly
even MRENCLAVE in the report it receives.  Intel needs to fix their
PCE, sign a fixed version, and find some way to revoke, to the extent
possible, the old one.  And the SGX enclave authors need to understand
something that is apparently subtle: THE LAUNCH POLICY IS NOT PART OF
THE TCB AND SHOULD NOT BE RELIED UPON.  Enclaves can and should be
written to remain secure even in the complete absence of any form of
launch control.

I went and filed a bug on github.  Let's see what happens:

https://github.com/intel/linux-sgx/issues/345

Also, the whole SGX report mechanism seems to be misused in the SDK.
An SGX report is a cryptographic primitive that essentially acts like
a signed blob.  Building a secure protocol on top of signed messages
or on top of reports takes more than just making up ad hoc blob
formats and signing them.  There needs to be domain separation between
different messages, and this seems to be entirely missing.  Do you
know if Intel has had a serious audit of their platform enclave code
done?

>
> > No, I have no clue why Intel did it this way.  I consider it to be a
> > mistake.
>
> Are you referring to there being a mistake in the trust relationships
> that the provisioning protocol implements or the overall concept of a
> provisioning key?

I'm referring to the hardware's policy as to when keys that don't
depend on OWNEREPOCH can be obtained.  As far as I know, the only real
need for such keys is to verify that the running platform is a real
Intel platform, which means that access to the provisioning key is
only useful to Intel-approved services.  Why didn't Intel enforce this
in hardware or microcode?  I see no reason that EGETKEY should hand
out those key types of the enclave is not signed by Intel.  For that
matter, I also don't see why the provisioning seal key needs to exist
-- the regular seal key could be used instead and, if OWNEREPOCH
changes, the platform could just re-certify itself.

> > >> The driver should establish the equivalent of three linked lists,
> > >> maintainable via /sysfs pseudo-files or equivalent plumbing.  The
> > >> lists are referenced by the kernel to enforce the following policies.
> > >>
> > >> 1.) The right to initialize an enclave without special attributes.
> > >>
> > >> 2.) The right to initialize an enclave with the PROVISION_KEY attribute set.
> > >>
> > >> 3.) The right to initialize an enclave with the LICENSE_KEY attribute set.
> > >>
> > >> The lists are populated with MRSIGNER values of enclaves that are
> > >> allowed to initialize under the specified conditions.
>
> > NAK because this is insufficient.  You're thinking of a model in
> > which SGX-like protection is all that's needed.  This is an
> > inadequate model of the real world.  The attack I'm most concerned
> > about wrt provisioning is an attack in which an unauthorized user is
> > permitted.
>
> We will be interested in your comments as to why the proposal is
> insufficient in the real world of FLC.

That's what you get for reading my unfinished email :)

Your proposal fails to protect against SGX malware.  Here's an SGX
malware use case: the attacker writes a malicious enclave and gets a
victim machine to run it as a non-root user.  They bundle it with a
valid Intel-signed copy of the relevant platform enclaves and use them
to bootstrap the attestation process.  The malicious enclave attests
its identity to a command-and-control server and obtains malicious
code to run.  The good guys can't reverse engineer the malware
enclave, because they can't pass the attestation check and therefore
can't obtain the encrypted code.

This isn't prevented by your proposed solution: the provisioning
enclaves are all signed by Intel.  What's needed is a check that
prevents unauthorized *users* from running them.

--Andy

  reply index

Thread overview: 161+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20181116010412.23967-1-jarkko.sakkinen@linux.intel.com>
2018-11-16  1:01 ` [PATCH v17 01/23] x86/sgx: Update MAINTAINERS Jarkko Sakkinen
2018-11-16 14:22   ` Borislav Petkov
2018-11-16 15:07     ` Jarkko Sakkinen
2018-11-16 20:24       ` Borislav Petkov
2018-11-18  8:20         ` Jarkko Sakkinen
2018-11-16  1:01 ` [PATCH v17 02/23] x86/cpufeatures: Add Intel-defined SGX feature bit Jarkko Sakkinen
2018-11-16 14:28   ` Borislav Petkov
2018-11-16 15:13     ` Jarkko Sakkinen
2018-11-16 15:18       ` Jarkko Sakkinen
2018-11-16 20:53         ` Borislav Petkov
2018-11-16  1:01 ` [PATCH v17 03/23] x86/cpufeatures: Add SGX sub-features (as Linux-defined bits) Jarkko Sakkinen
2018-11-16 14:37   ` Borislav Petkov
2018-11-16 15:38     ` Sean Christopherson
2018-11-16 23:31   ` Dave Hansen
2018-11-18  8:36     ` Jarkko Sakkinen
2018-11-16  1:01 ` [PATCH v17 04/23] x86/msr: Add IA32_FEATURE_CONTROL.SGX_ENABLE definition Jarkko Sakkinen
2018-11-16  1:01 ` [PATCH v17 05/23] x86/cpufeatures: Add Intel-defined SGX_LC feature bit Jarkko Sakkinen
2018-11-16  1:01 ` [PATCH v17 06/23] x86/cpu/intel: Detect SGX support and update caps appropriately Jarkko Sakkinen
2018-11-16 23:32   ` Dave Hansen
2018-11-18  8:37     ` Jarkko Sakkinen
2018-11-21 18:17   ` Borislav Petkov
2018-11-24 13:54     ` Jarkko Sakkinen
2018-11-16  1:01 ` [PATCH v17 07/23] x86/mm: x86/sgx: Add new 'PF_SGX' page fault error code bit Jarkko Sakkinen
2018-11-16 23:33   ` Dave Hansen
2018-11-18  8:38     ` Jarkko Sakkinen
2018-11-16  1:01 ` [PATCH v17 08/23] x86/mm: x86/sgx: Signal SIGSEGV for userspace #PFs w/ PF_SGX Jarkko Sakkinen
2018-11-16  1:01 ` [PATCH v17 09/23] x86/sgx: Define SGX1 and SGX2 ENCLS leafs Jarkko Sakkinen
2018-11-16  1:01 ` [PATCH v17 10/23] x86/sgx: Add ENCLS architectural error codes Jarkko Sakkinen
2018-11-16  1:01 ` [PATCH v17 11/23] x86/sgx: Add SGX1 and SGX2 architectural data structures Jarkko Sakkinen
2018-11-16  1:01 ` [PATCH v17 12/23] x86/sgx: Add definitions for SGX's CPUID leaf and variable sub-leafs Jarkko Sakkinen
2018-11-16  1:01 ` [PATCH v17 13/23] x86/msr: Add SGX Launch Control MSR definitions Jarkko Sakkinen
2018-11-16 17:29   ` Sean Christopherson
2018-11-18  8:19     ` Jarkko Sakkinen
2018-11-16  1:01 ` [PATCH v17 14/23] x86/sgx: Add wrappers for ENCLS leaf functions Jarkko Sakkinen
2018-11-16  1:01 ` [PATCH v17 15/23] x86/sgx: Enumerate and track EPC sections Jarkko Sakkinen
2018-11-16  1:01 ` [PATCH v17 16/23] x86/sgx: Add functions to allocate and free EPC pages Jarkko Sakkinen
2018-11-16  1:01 ` [PATCH v17 17/23] x86/sgx: Add sgx_einit() for initializing enclaves Jarkko Sakkinen
2018-11-16  1:01 ` [PATCH v17 18/23] platform/x86: Intel SGX driver Jarkko Sakkinen
2018-11-16  1:37   ` Randy Dunlap
2018-11-16 11:23     ` Jarkko Sakkinen
2018-11-19 15:06   ` Jarkko Sakkinen
2018-11-19 16:22     ` Jethro Beekman
2018-11-19 17:19       ` Jarkko Sakkinen
2018-11-19 17:39         ` Jethro Beekman
2018-11-20 10:58           ` Jarkko Sakkinen
2018-11-21 15:24             ` Jarkko Sakkinen
2018-11-19 18:18         ` Andy Lutomirski
2018-11-20 11:00           ` Jarkko Sakkinen
2018-11-19 15:29   ` Andy Lutomirski
2018-11-19 16:19     ` Jarkko Sakkinen
2018-11-19 16:59       ` Andy Lutomirski
2018-11-20 12:04         ` Jarkko Sakkinen
2018-11-22 11:12           ` Dr. Greg
2018-11-22 15:21             ` Andy Lutomirski
2018-11-24 17:21               ` Jarkko Sakkinen
2018-11-24 20:13                 ` Dr. Greg
2018-11-26 21:15                   ` Jarkko Sakkinen
2018-11-25 14:53                 ` Jarkko Sakkinen
2018-11-25 16:22                   ` Andy Lutomirski
2018-11-25 18:55                     ` Dr. Greg
2018-11-25 23:51                       ` Jarkko Sakkinen
     [not found]                       ` <D45BC005-5064-4C75-B486-4E43C454E2F6@amacapital.net>
2018-11-26  0:37                         ` Andy Lutomirski
2018-11-26 11:00                           ` Dr. Greg
2018-11-26 18:22                             ` Andy Lutomirski [this message]
2018-11-26 22:16                             ` Jarkko Sakkinen
2018-11-26 21:51                     ` Jarkko Sakkinen
2018-11-26 23:04                       ` Jarkko Sakkinen
2018-11-27  8:55                         ` Dr. Greg
2018-11-27 16:41                           ` Jarkko Sakkinen
2018-11-27 17:55                             ` Andy Lutomirski
2018-11-28 10:49                               ` Dr. Greg
2018-11-28 19:22                                 ` Jarkko Sakkinen
2018-12-10 10:49                                   ` Dr. Greg
2018-12-12 18:00                                     ` Jarkko Sakkinen
2018-12-14 23:59                                       ` Dr. Greg
2018-12-15  0:06                                         ` Sean Christopherson
2018-12-15 23:22                                           ` Dr. Greg
2018-12-17 14:27                                             ` Sean Christopherson
2018-12-17 13:28                                           ` Jarkko Sakkinen
2018-12-17 13:39                                             ` Jarkko Sakkinen
2018-12-17 14:08                                               ` Jarkko Sakkinen
2018-12-17 14:13                                                 ` Jarkko Sakkinen
2018-12-17 16:34                                                   ` Dr. Greg
2018-12-17 17:31                                                 ` Sean Christopherson
2018-12-17 17:49                                                   ` Jarkko Sakkinen
2018-12-17 18:09                                                     ` Sean Christopherson
2018-12-17 18:23                                                       ` Jarkko Sakkinen
2018-12-17 18:46                                                         ` Sean Christopherson
2018-12-17 19:36                                                           ` Jarkko Sakkinen
2018-11-27 16:46                           ` Jarkko Sakkinen
2018-11-28 21:52                           ` Andy Lutomirski
2018-11-27  7:46                       ` Jethro Beekman
2018-11-27 16:36                         ` Jarkko Sakkinen
2018-11-22 20:56             ` Andy Lutomirski
2018-11-23 10:39               ` Dr. Greg
2018-11-24 16:45                 ` Jarkko Sakkinen
2018-11-28  5:08                   ` Jarkko Sakkinen
2018-11-28  5:38                     ` Jethro Beekman
2018-12-09 17:01         ` Pavel Machek
2018-11-20 11:15     ` Dr. Greg
2018-11-24 16:15       ` Jarkko Sakkinen
2018-11-24 19:24         ` Dr. Greg
2018-11-26 19:39           ` Jarkko Sakkinen
2018-12-09 17:01     ` Pavel Machek
2018-12-10 14:46       ` Dr. Greg
2018-12-17 17:45   ` Dave Hansen
2018-12-17 18:01     ` Jarkko Sakkinen
2018-12-17 18:07       ` Dave Hansen
2018-12-17 18:31         ` Jarkko Sakkinen
2018-12-17 18:36       ` Sean Christopherson
2018-12-17 18:43         ` Jarkko Sakkinen
2018-12-17 18:47           ` Dave Hansen
2018-12-17 19:12             ` Andy Lutomirski
2018-12-17 19:17               ` Dave Hansen
2018-12-17 19:25                 ` Andy Lutomirski
2018-12-17 19:54                   ` Jarkko Sakkinen
2018-12-17 19:49                 ` Jarkko Sakkinen
2018-12-17 19:53                   ` Dave Hansen
2018-12-17 19:55                     ` Andy Lutomirski
2018-12-17 20:03                       ` Dave Hansen
2018-12-17 20:10                         ` Andy Lutomirski
2018-12-17 20:15                           ` Dave Hansen
2018-12-17 22:36                             ` Sean Christopherson
2018-12-18  1:40                           ` Jarkko Sakkinen
2018-12-17 22:20               ` Sean Christopherson
2018-12-18  1:39                 ` Jarkko Sakkinen
2018-12-18  3:27                   ` Jarkko Sakkinen
2018-12-18  5:02                     ` Andy Lutomirski
2018-12-18 13:27                       ` Jarkko Sakkinen
2018-12-18  4:55                   ` Andy Lutomirski
2018-12-18 13:18                     ` Jarkko Sakkinen
2018-12-18  4:59                 ` Andy Lutomirski
2018-12-18 13:11                   ` Jarkko Sakkinen
2018-12-18 15:44                   ` Sean Christopherson
2018-12-18 18:53                     ` Sean Christopherson
2018-12-19  5:00                       ` Jarkko Sakkinen
2018-12-19  5:13                         ` Jarkko Sakkinen
2018-12-21 18:28                         ` Sean Christopherson
2018-12-22  0:01                           ` Jarkko Sakkinen
2018-12-19  4:47                     ` Jarkko Sakkinen
2018-12-19  5:24                       ` Jarkko Sakkinen
2018-12-18  1:17               ` Jarkko Sakkinen
2018-12-18  1:31                 ` Jarkko Sakkinen
2018-12-17 18:48           ` Sean Christopherson
2018-12-17 19:09             ` Dave Hansen
2018-12-17 19:37               ` Jarkko Sakkinen
2018-12-17 19:40                 ` Dave Hansen
2018-12-17 19:33             ` Jarkko Sakkinen
2018-12-17 20:21               ` Jarkko Sakkinen
2018-12-18 13:13                 ` Jarkko Sakkinen
2018-12-18 15:46                   ` Sean Christopherson
2018-12-18  5:55   ` Andy Lutomirski
2018-12-19  5:22     ` Jarkko Sakkinen
2018-11-16  1:01 ` [PATCH v17 19/23] platform/x86: sgx: Add swapping functionality to the " Jarkko Sakkinen
2018-11-16  1:01 ` [PATCH v17 20/23] x86/sgx: Add a simple swapper for the EPC memory manager Jarkko Sakkinen
2018-11-16  1:01 ` [PATCH v17 21/23] platform/x86: ptrace() support for the SGX driver Jarkko Sakkinen
2018-11-16  1:01 ` [PATCH v17 22/23] x86/sgx: SGX documentation Jarkko Sakkinen
2018-12-03  3:28   ` Randy Dunlap
2018-12-03  9:32     ` Jarkko Sakkinen
2018-11-16  1:01 ` [PATCH v17 23/23] selftests/x86: Add a selftest for SGX Jarkko Sakkinen
2018-11-16 11:17 ` [PATCH v17 00/23] Intel SGX1 support Jarkko Sakkinen

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CALCETrVdooOwt080-f-Sr92pnbRVchsffxWGnnEHmH40qLyCdA@mail.gmail.com \
    --to=luto@kernel.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=andy@infradead.org \
    --cc=bp@alien8.de \
    --cc=dave.hansen@intel.com \
    --cc=dvhart@infradead.org \
    --cc=greg@enjellic.com \
    --cc=haitao.huang@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=jarkko.sakkinen@linux.intel.com \
    --cc=kai.svahn@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sgx@vger.kernel.org \
    --cc=mark.shanahan@intel.com \
    --cc=mingo@redhat.com \
    --cc=nhorman@redhat.com \
    --cc=npmccallum@redhat.com \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=sean.j.christopherson@intel.com \
    --cc=serge.ayoun@intel.com \
    --cc=shay.katz-zamir@intel.com \
    --cc=suresh.b.siddha@intel.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-Sgx Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-sgx/0 linux-sgx/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-sgx linux-sgx/ https://lore.kernel.org/linux-sgx \
		linux-sgx@vger.kernel.org linux-sgx@archiver.kernel.org
	public-inbox-index linux-sgx


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-sgx


AGPL code for this site: git clone https://public-inbox.org/ public-inbox