Re: x86/sgx: v23-rc2

["Dr. Greg" <greg@enjellic.com>]

On Fri, Feb 21, 2020 at 09:41:24PM -0800, Andy Lutomirski wrote:

Good afternoon, I hope the weekend is going well for everyone.

> On Fri, Feb 21, 2020 at 7:16 PM Dr. Greg <greg@enjellic.com> wrote:
> > I should have been more precise, my apologies.
> >
> > When I was suggesting that DAC/MAC controls were not relevant, I was
> > referring to their relevance with respect to protecting the platform
> > from running code that does not have defined provenance or origin.

> Windows systems quite regularly get owned by code with "defined
> provenance or origin" in the sense that it was signed by a valid
> Authenticode certificate. :)

Excellent observation, signing is a metric of identity not
correctness.

Since the first HASP papers were published, Intel has been consistent
with respect to their guidance that buggy code inside of an enclave is
still buggy code.

Windows code signing is designed to provide a guarantee that code is
of known origin.  SGX signing serves the same purpose, the objective
of cryptographic launch control is to protect the platform from the
technology itself, through the use of cryptographic identity controls.

> > I'm certainly not argueing against defense in depth or the merits
> > of DAC/MAC controls.  I'm simply stating that they are irrelevant,
> > with respect to the concerns that you raised about code provenance
> > and origin, on flexible launch control platforms that support SGX2
> > and EDMM.  Platforms that by and large will be the primary target
> > for this driver.

> I have a little FLC platform on my desk.  What I don't have is an
> FLC platform with anything resembling a policy that helps here at
> all.

I believe you have a Gemini Lake SOC based NUC, presumably a NUC7CJYH
or NUC7PJYH.  In addition to FLC, that system has support for SGX2
instructions and thus EDMM.

So you have everything you need to demonstrate the ability to download
and execute code without the OS being able to pass judgement on the
code, other then the OS identity of the user accessing the device node
that loaded a bootstrap enclave.

> > I only bring up the issue in the interests of intellectual honesty
> > and the fact that I'm sure our exchanges will go down in the
> > annals of security history as being as important as the
> > Lincoln/Douglas debates.

> That would be amazing!

The driver initiative has hopefully benefited from a technically
honest discussion of the issues.

> > It is one of my jobs to follow the security literature closely.
> > Everyone who does so can easily envision a future abstract reading
> > something like the following:
> >
> > "Using an unmodified and stock DIST_OS kernel we were able to
> > demonstrate the download and execution of malicious code into an
> > enclave that bypasses all security controls in the Linux operating
> > system allowing us to recover XXXX information from the platform with
> > subsequent exfiltration of the information from the platform without
> > detection."

> Alas, the significance of this seems to depend on what XXXX is.  If
> XXXX is a detail of the specific machine (a derived provisioning key,
> a launch token, etc.), then the paper won't be terribly interesting.
> As root (or someone who can escalate to root or better) on a given
> system, I can extract *tons* of identifying details of the platform.
> If XXXX is a secret created by the user (a sealing key, something
> sealed by SGX, a private key or secret that allows one to pretend to
> be an enclave with MRSIGNER=YYY, etc), then launch control and DAC are
> essentially irrelevant to the discussion.  What actually happened is
> that some code signed by YYY screwed up.  And this is because launch
> control is not part of the SGX root of trust, nor is launch control
> even a necessary part of the SGX security model.  SGX with launch
> control deleted entirely would be just as useful, if potentially a bit
> more dangerous in terms of being able to make malware hard to
> analyze.

You are absolutely correct, cryptographic access control doesn't
influence the enclave security guarantees that SGX implements.  Launch
control is about imposing a cryptographic identity guarantee on the
origin of code executed in enclave context.

Windows Authenticode is about protecting the platform from an entity
attempting to execute malicious code on a platform.  SGX launch
control is about protecting a platform from malicious code running in
an enclave.

The challenge with an EDMM capable SGX platform is that anyone with
the ability to load, initialize and execute an enclave is capable of
bringing code that has potentially adversarial intent onto the
platform and to execute that code.  The executing code has full
visibility into the address space of the process that loaded the
enclave without the need for OCALL's.

I'm confident the security research community will come up with
interesting things that can be accomplished within the constraints of
this model.

The code being loaded onto the platform will be encrypted and
integrity protected so there will be no visibility into the code being
loaded.  By design, once loaded, the execution and functioning of the
code will also have no visibility by the platform, except possibly
through the use and analysis of various side channels.

These are all well understood issues.  Joanna Rutkowska was discussing
the implications of all this seven years ago:

https://blog.invisiblethings.org/2013/09/23/thoughts-on-intels-upcoming-software.html

Everyone seems to be in agreement that the LSM should be able to have
a 'look' at enclave code, although the initial driver implementation
won't have support for that.  If we pride ourselves on being
intellectually honest, we have to ask ourselves why we would even
spend time on adding LSM support given that it will largely amount to
security theater.

There is a high probability that taking advantage of this
functionality will be popular, given the fact that due to user demand,
Intel has implemented support for Protected Code Loading (PCL) in
their SDK.  Anyone that is interested, can look at the implementation
in the following directory of the Intel SGX SDK:

SampleCode/SampleEnclavePCL

The current model involves encrypting the enclave .so file with
subsequent decryption by a loader enclave.  An EDMM based solution
will be both more straight forward and secure from tampering.

There is a great deal of interest in a model where the system
administrators and/or platform deployers have no visibility into the
code or data being executed on the platform.  The Confidential
Computing Consortium (CCC), composed of all the 'bigs - The Linux
Foundation, IBM, Microsoft, GOOGLE, Tencent, Alibaba et.al', has been
put together to support this model.

I suspect a lot of the push to ship code and worry about some of these
pesky security details later arises from a desire to support this
initiative.

Russinovich, the CTO of Microsoft, has a discussion about all of this
on his blob, including a link to the CCC site:

https://cloudblogs.microsoft.com/opensource/2019/08/21/microsoft-partners-linux-foundation-announce-confidential-computing-consortium/

If you check the CCC site itself you will see a reference to the
possibility of this technology being used for nefarious purposes and
that there are research initiatives and best practices that will be
promoted to address this.

All of this dovetails, somewhat, with the 'Zero-Trust' initiative that
is all the rage these days.  All of this is ultimately converging on
the notion that trust needs to be based on a cryptographically secured
expression of identity.

> > > (Don't forget that, no matter how carefully your system might lock
> > > down the SGXPUBKEYHASH MSRs and control the associated keys, that
> > > lockdown is being done by non-enclave *software*, and a bad guy who
> > > gets root is quite likely to be able to unlock the registers by
> > > upgrading their root access to control the firmware.  Or get a launch
> > > token that can't be revoked because SGX doesn't have a token
> > > expiration mechanism.)
> >
> > Dispassionate observers would note that you make the case for locked
> > launch control registers.... :-)
> >
> > At an SGX engineering meeting in Israel last summer, we made the case
> > for the fact that locked vs. unlocked platforms should be a BIOS
> > configurable option.  With an additional option that specifying locked
> > also allows specification of what the identity modulus signature
> > should be.  That would seem to be the best of all worlds, we will see
> > what happens.
> >
> > One of the pushbacks we received, is that SGX is supposed to be immune
> > from firmware manipulation, which our suggested approach would open
> > the door for, which we noted was irrelevant given the trajectory that
> > the Linux kernel driver is on, ie. no cryptographic controls over code
> > origin and provenance.

> I don't believe I have ever said that Linux shouldn't support
> cryptographic verification of SGX code provenance or that Linux
> shouldn't eventually support locked launch control MSRs.  What I've
> said is that the initial upstream version of the driver doesn't need
> this, and that adding support for locked MSRs is tricky and needs
> some design work.

It would seem the consensus of opinion is to ship the driver and then
worry about the security details later.

By now everyone has seen a full discussion on the issues involved,
hopefully it will help to provide a framework for future refinements
to the driver.

In the meantime we will be announcing patches to add cryptographic
trust controls for the driver, so that will be an option for those who
have concerns about the issue until when and if there is consensus on
how to address these issues in the mainline driver.

> FWIW, I didn't expect upstreaming to take anywhere near this long.

I don't think anyone did.

> > Just to provide a frame of reference, our interest in SGX is with
> > respect to its guarantee of integrity of execution, for the
> > purposes of verifying that the kernel could not have executed code
> > that was outside a desired behavioral definition for the platform.

> SGX cannot and will never prevent the kernel from executing normal
> CPL0 code of any sort.  I'm not really sure what you're getting at
> here.  If you have magically trustworthy firmware and locked launch
> control registers, you can prevent the kernel from executing
> unapproved *enclave* code.  It's not entirely clear to me why you
> consider unapproved enclave code to be worse than any other sort of
> unapproved code.

I believe we have a full implementation and demonstration of the
ability of SGX to control what the kernel chooses to execute or
actions it conducts, at least within the framework of the controls
that the LSM provides.  I replied to the KRSI post with a brief
description of our work.

The ultimate future of an initiative such as the CCC is going to
depend on cloud clients being able to have some indication of what
trust to afford to the entire platform.  That will ultimately come
down to the ability to have a cryptographic statement, within modeling
limits, of what behaviors the platform has been allowed to express.

Given the implications of SGX2/EDMM, that will also include a
statement of what cryptographic identities have been able to execute
code in enclave context.

But we won't go down that rathole now.

Best wishes for a productive week.

Dr. Greg

As always,
Dr. Greg Wettstein, Ph.D    Worker / Principal Engineer
IDfusion, LLC
4206 19th Ave N.            Specialists in SGX secured infrastructure.
Fargo, ND  58102
PH: 701-281-1686            CELL: 701-361-2319
EMAIL: gw@idfusion.org
------------------------------------------------------------------------------
"It would appear that we have reached the limits of what it is
 possible to achieve with computer technology, although one should be
 careful with such statements, as they tend to sound pretty silly in 5
 years."
                                -- John Von Neumann (ca. 1949)