Re: [PATCH v17 18/23] platform/x86: Intel SGX driver

[Andy Lutomirski]

On Thu, Nov 22, 2018 at 3:12 AM Dr. Greg <greg@xxxxxxxxxxxx> wrote:
>
> On Tue, Nov 20, 2018 at 02:04:42PM +0200, Jarkko Sakkinen wrote:
>
> Good morning to everyone, Happy Thanksgiving to those who are
> celebrating the holiday.
>
> > On Mon, Nov 19, 2018 at 08:59:24AM -0800, Andy Lutomirski wrote:
> > > The idea here is that, under normal circumstances, provisioning only
> > > runs once, or at least only runs rarely.  So, rather than the SDK
> > > running provisioning whenever it feels like doing so (which is the
> > > current behavior, I imagine, although I haven't looked), there would
> > > be a privileged program, perhaps a systemd unit that runs when needed,
> > > that produces the key material needed for remote attestation, and
> > > non-root users that need attestation would get the keying material
> > > from the provisioning service.  And the provisioning service could
> > > implement its own policy.  Ideally, the service wouldn't give the
> > > sealed keys to users at all but would, instead, just provide the
> > > entire attestation service over a UNIX socket, which would make
> > > provisioning capabilities revocable.
> > >
> > > Does this make sense?
>
> > Yes, it does for me at least now that you brought some context.
>
> Let me see if I can add a bit of additional context to the above to
> frame further discussion regarding two major needs of the driver
> before it lands.
>
> What Andy is describing is how the current system already works.  The
> driver is at the root of a fairly complex eco-system of code,
> cryptography and protocols that implement SGX functionality.  This
> software stack is known as the SGX Platform SoftWare (PSW) or SGX
> runtime.
>
> The Intel provided runtime is implemented in C++ and, depending on how
> you count it, clocks in at around 50+ KLOC.  All of this ends up as a
> single 1.8 megabyte binary named aesm_service that links against 35
> shared libraries and is run by systemd.
>
> This binary implements the functionality needed to load, initialize,
> run and attest enclaves.  It also implements communications with the
> Intel provisioning and attestation services which is needed to
> provision a private EPID key to the platform and to verify the status
> of an enclave attestation quote from a remote platform.
>
> In order to achieve the SGX/IAGO security model, a lot of this
> functionality is implemented by choreographing exchanges between six
> Intel supplied and signed enclaves.  Intel supplies source code to
> these enclaves and understanding how all of this works requires an
> understanding of that codebase as well.  To top if off there is also a
> 50K hunk of signed Java bytecode that gets stuffed into the Management
> Engine if you are interested in platform services.
>

It's very nice of Intel to supply source. Also, yikes, they wrote
their ME blob in Java?

> All of the above is what we wrote an independent implementation of, in
> straight C, that is capable of linking against the MUSL C library with
> only libelf and OpenSSL as dependencies.  We developed all of this to
> support a reasonably sophisticated multi-enclave SGX security
> application that implements modeling the runtime behavior of
> applications running on the Linux kernel.  That application uses an
> alternate enclave attestation and communications architecture that we
> independently developed.

How do you generate your root of trust for attestation if you don't
use Intel's service?  If I understand right, Intel's mechanism boils
down to Intel possessing something that is functionally equivalent to
a list of valid provisioning keys associated with genuine Intel chips.
(It could be literal provisioning keys, or keying material from which
the provisioning keys are derived, or even public keys for which the
private parts are derived from the provisioning keys.  But all of this
boils down to the CPU, via some enclaves, proving knowledge of the
provisioning key that is available when MRSIGNER is Intel.

I could imagine replacing this by running Intel's mechanism once to
generate a new root of trust for your own mechanism, or even by buying
a bunch of CPUs, determining their provisioning keys with MRSIGNER=Dr.
Greg, and enrolling those.  But I don't see any way to bootstrap an
attestation service on a CPU you've never physically possessed without
running *something* with MRSIGNER=Intel.

> Based on this experience, if the proposed driver lands in its current
> state, Linux mainline will have, at least from a privacy perspective,
> an inferior implementation of SGX.  In addition, we are not confident
> the driver will be useful to anything other then server class hardware
> and will be incapable of supporting virtually all of the existing SGX
> hardware in the field.

I'm a little bit puzzled by your privacy claims.  If an attacker
controls the kernel, then the secrets in your enclave may still be
secure, but you have very little privacy in terms of trying to prevent
the attacker from tying your communication to your physical machine.

> At a high level, addressing these issues is straight forward.  First,
> the driver needs to support authorization equivalent to that which is
> implemented in the current Intel Launch Enclave, ie. control over the
> SGX_FLAGS_PROVISION_KEY attribute.

I agree, hence my email :)

> Secondly, the driver needs to drop
> its prohibition against launch enclaves, ie. returning EINVAL when a
> request is made to initialize enclaves which have the
> SGX_FLAGS_EINITTOKEN_KEY attribute set.
>

Can you explain your use case for a launch enclave?  The current
driver won't allow you to supply an EINITTOKEN, so I'm not immediately
seeing what you would do with a launch token.  If you really do need
it, I suppose we could have 'unprivileged', 'provisioning', and
'launch' nodes, and maybe even 'launch_and_provision', but that's
starting to have some combinatorial issues.