Message-ID: <20190418171059.GA20819@wind.enjellic.com>
Date:   Thu, 18 Apr 2019 12:10:59 -0500
From:   "Dr. Greg" <greg@...ellic.com>
To:     Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>
Cc:     torvalds@...ux-foundation.org, linux-kernel@...r.kernel.org,
        x86@...nel.org, linux-sgx@...r.kernel.org,
        akpm@...ux-foundation.org, dave.hansen@...el.com,
        sean.j.christopherson@...el.com, nhorman@...hat.com,
        npmccallum@...hat.com, serge.ayoun@...el.com,
        shay.katz-zamir@...el.com, haitao.huang@...el.com,
        andriy.shevchenko@...ux.intel.com, tglx@...utronix.de,
        kai.svahn@...el.com, bp@...en8.de, josh@...htriplett.org,
        luto@...nel.org, kai.huang@...el.com, rientjes@...gle.com
Subject: Re: [PATCH v20 00/28] Intel SGX1 support

On Wed, Apr 17, 2019 at 01:39:10PM +0300, Jarkko Sakkinen wrote:

Good morning, I hope this note finds the impending end of the work
week going well for everyone.

First of all, a thank you to Jarkko for his efforts in advancing this
driver, a process that can be decidedly thankless.  Our apologies in
advance for contributing to this phenomenon.

> Intel(R) SGX is a set of CPU instructions that can be used by
> applications to set aside private regions of code and data. The code
> outside the enclave is disallowed to access the memory inside the
> enclave by the CPU access control.  In a way you can think that SGX
> provides inverted sandbox. It protects the application from a
> malicious host.

Unfortunately, in its current implementation, the driver will not
protect a host from malicious enclaves.  If it advances in its current
form, the mainline Linux kernel will be implementing a driver with
known and documented security issues.

In addition, the driver breaks all existing SGX software by breaking
compatibility with what is a 3+ year ABI provided by the existing
driver.  This seems to contravene the well understood philosophy that
Linux doesn't, if at all possible, break existing applications,
something that we believe can be easily prevented if those interested
in these issues choose to read on.

The following reflections and code come from a team that has been
active in SGX development, since before hardware was even publically
available.  A team that has authored a complete re-implementation of
all of the SGX runtime infrastructure, which is the only consumer of
the services provided by an SGX driver.  A team that has also authored
and maintains a significant cohort of SGX based applications.  So I
believe we speak from a vantage point of experience with respect to
these issues and not from a 'bike-shedding' or political perspective.

The fundamental problem is that the proposed driver lacks an enclave
initialization policy mechanism consistent with the security
guarantees that SGX hardware is designed to deliver.  SGX is designed
to provide system architects a framework for building IAGO resistent
security architectures through the use of cryptographically defined
identities.

Other then an attempt to limit acccess to the PROVISION attribute, the
driver makes no attempt to regulate, in a cryptographically secure
fashion, what enclaves can be initialized, who can initialize them or
what characteristics they can be initialized with.  The security
implications of this were recently documented in a paper by
researchers at Graz, here is the link for those interested:

https://arxiv.org/pdf/1702.08719.pdf

Both the current controls for enclave access to the PROVISION
attribute and the security controls that are being proposed to emerge
for the driver, sometime in the future, suffer from being dependent on
discretionary access controls, ie. file privileges, that can be
defeated by a privilege escalation attack.  Those of us building
architectures on top of this technology have a need to certify that an
application will provide security contracts robust in the face of a
privilege escalation event or platform compromise.

To be very blunt, and my apologies for doing so, the design for this
driver has been driven by idealogy rather then by technology.  Our
focus with this e-mail and proposed driver modification is an attempt
to satisfy both technical requirements and political idealogy, if that
is even possible.

When we raised these issues six months ago, we were told that we were
handwaving bloat into the kernel.  We take a criticism like that very
seriously so we are returning with code, in what we believe is
'bloat-free' form.

The attached patch, against the jarkko-sgx/master branch of Jarkko's
driver repository, provides a framework that implements
cryptographically secure enclave initialization policies.  The patch
and it's signature are also available from the following URL's:

ftp://ftp.idfusion.net/pub/idfusion/jarkko-master-SFLC.patch

ftp://ftp.idfusion.net/pub/idfusion/jarkko-master-SFLC.patch.asc

The modification, in series form, is also available in the following
GIT repository:

git://git.idfusion.net/src/linux-sgx/in-tree jarkko-master-SFLC

The driver modification implements cryptographically secure enclave
initialization only if the platform owner chooses to do so and does
not limit the development of alternative strategies in the future.  It
also allows the platform owner to choose the ability to remain
compatible with existing runtimes and applications.

The policy architecture allows just about any conceivable
initialization policy to be implemented and in any combination.  It
supports both a plurality of launch enclaves as well as support for
multiple signing keys if a token-less approach is desired.  It also
provides cryptographically secure control of access to the PROVISION
attribute and the ability to completely block access to the attribute
if that is desired.

The driver modification has been extensively tested in all of these
scenarios, including combinations thereof.  We just completed a major
round of development that was based on Flexible Launch Control
platforms and deployed onto fixed launch control platforms using the
out-of-tree driver, without a need to maintain disparate runtimes.

On that note, given that the new driver API is completely incompatible
with all of the existing runtime software in the field, we believe the
issue of proper testing of this driver is an open problem.  I'm assuming
that Intel has a yet to be released PSW/SDK that supports the driver,
otherwise our enhancements to the driver is the only way that it can
experience legitimate field testing.

The interface for using the policy management framework is straight
forward.  The following three pseudo-files are available:

/sys/kernel/security/sgx/launch_keys

/sys/kernel/security/sgx/provisioning_keys

/sys/kernel/security/sgx/signing_keys

The SHA256 hashes of the cryptographic keys used to sign enclaves
(MRSIGNER values) are written into these files, ie, the following
command:

echo "SHA256_HASH" >| /sys/kernel/security/sgx/signing_keys

Would only allow enclaves to be initialized whose MRSIGNER value
matches the SHA256_HASH value.

The 'launch_keys' file maintains a list of signer signatures that are
allowed to initialize enclaves with the EINITTOKEN attribute set.

The 'provisioning_keys' file maintains a list of signer signatures
that are allowed to initialize enclaves with the PROVISION attribute
set.

Writing the 'lock' keyword to a file permanently blocks any further
directives from being recognized.  At that point, a very targeted
ring-0 attack would need to be conducted to circumvent the enclave
initialization policies.  This provides a framework that allows a
flexible launch control platform to attain the approximate security
guarantees offered by a fixed launch control platform.

If the platform owner chooses to do nothing, the driver will
initialize any enclave that is presented to it.  FWIW, we have close
to a century of enterprise system's administration experience on our
team and we could not envision any competent system's administrator,
concerned about security, who would allow such a configuration.

So that is how it all works, the changelogs in the GIT repository have
much more extensive documentation.  We fit the entire architecture
into approximately one page of memory, which seems to be a minor
amount of bloat for everyone getting to do whatever they want to do,
including leaving Linux mainline with a secure driver implementation.

Here is the diffstat:

---------------------------------------------------------------------------
 arch/x86/include/uapi/asm/sgx.h         |   2 +
 arch/x86/kernel/cpu/sgx/driver/Makefile |   1 +
 arch/x86/kernel/cpu/sgx/driver/driver.h |   7 +
 arch/x86/kernel/cpu/sgx/driver/ioctl.c  |  88 ++++-
 arch/x86/kernel/cpu/sgx/driver/main.c   |   5 +
 arch/x86/kernel/cpu/sgx/driver/policy.c | 584 ++++++++++++++++++++++++++++++++
 arch/x86/kernel/cpu/sgx/main.c          |  27 +-
 arch/x86/kernel/cpu/sgx/sgx.h           |   3 +-
 8 files changed, 704 insertions(+), 13 deletions(-)
---------------------------------------------------------------------------

With respect to a mainline Linux driver at large, an issue that we
believe needs clarification is whether or not a mandate will be issued
by Intel to OEM's that Flexible Launch Control is mandatory on all
platforms that are henceforth shipped.  Otherwise the mainline Linux
driver will be in the unenviable position of only working sporadically
and will not be a universal solution for all hardware.

We have a solution for that as well, but the above is probably enough
cannon fodder for debate so we will leave that sleeping dog lie for
the time being.

Hopefully all of the above is helpful for enhancing the quality of the
Linux SGX eco-system.

Best wishes for a productive weekend.

Dr. Greg

As always,
Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
4206 N. 19th Ave.           Specializing in information infra-structure
Fargo, ND  58102            development.
PH: 701-281-1686
FAX: 701-281-3949           EMAIL: greg@...ellic.com
------------------------------------------------------------------------------
"I can only provide the information, I can't make you hear it."
                                -- Shelley Bainter

View attachment "jarkko-master-SFLC.patch" of type "text/plain" (23667 bytes)

View attachment "jarkko-master-SFLC.patch.asc" of type "text/plain" (456 bytes)

Powered by blists - more mailing lists