Date:   Sun, 26 Apr 2020 11:57:53 -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, 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,
        cedric.xing@...el.com, puiterwijk@...hat.com
Subject: Re: [PATCH v29 00/20] Intel SGX foundations

On Wed, Apr 22, 2020 at 12:52:56AM +0300, Jarkko Sakkinen wrote:

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

> 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.
>
> ... [ elided ] ..
> 
> The current implementation requires that the firmware sets
> IA32_SGXLEPUBKEYHASH* MSRs as writable so that ultimately the kernel can
> decide what enclaves it wants run. The implementation does not create
> any bottlenecks to support read-only MSRs later on.

It seems highly unlikely that a driver implementation with any type of
support for read-only launch control registers would ever get into the
kernel.  All one needs to do is review the conversations that Matthew
Garrett's lockdown patches engender to get a sense of that, ie:

https://lwn.net/Articles/818277/

As a result, the proposed SGX driver needs support for cryptographic
policy management before it goes into the kernel.  Either the patch
that we have offered or something equivalent.

Absent that, the driver won't address the full needs of the
development community implementing runtimes.  In addition it also
poses security and privacy issues that are well documented in the
literature.

As an aside, for those who haven't spent the last 5+ years of their
life working with this technology.  SGX2 hardware platforms have the
ability to allow unrestricted code execution in enclave context.  No
amount of LSM or IMA interventions can provide any control over that.

In fact, the Confidential Computing Consortium, sponsored by none
other then the Linux Foundation, has at its fundamental tenant, the
notion of developing an eco-system that allows the execution of code
and processing of data, over which, the owner or administrator of the
platform has no visibility or control.  It would seem only logical
that adversarial interests would indulge themseleves in those
capabilities as well.

With respect to SGX and these issues, cryptographic policy management
is important for the same reason that 2-factor authentication is now
considered standard practice in the security industry.

We appreciate, Jarkko, that you feel that such infrastructure is
optional, like virtualization support, and is something that can go in
after the driver is mainlined.  As the diffstat for our patch points
out, the proposed support has virtually no impact on the driver, the
same cannot be said for virtualization capabilities.

Moreover, adding support for key based policy management later would
require the addition of another ioctl in order to avoid ABI
compatibility issues.  The current initialization ioctl is best
suited, from an engineering perspective, to support this type of
infrastructure.  In fact, the necessary support was removed from the
ioctl for political reasons rather then for any valid engineering
rationale on flexible launch control platforms, particularly with our
patch or an equivalent approach.

For the benefit of the kernel community at large, I will follow up this
e-mail with a copy of our patch for review.  In case anyone misses it,
or it is corrupted, the patch can be pulled from the following URL:

ftp://ftp.enjellic.com/pub/sgx/kernel/SFLC-current.patch

We believe the patch or an equivalent approach deserves consideration
for the following reasons:

1.) It does not modify the default behavior of the driver. ie. any
enclave will be initialized that is presented.

2.) It enables needed functionality only at the discretion and control
of the platform owner/administrator.

3.) The impact on the architecture of the driver is negligible.

In closing, it is important to note that the proposed SGX driver is
not available as a module.  This effectively excludes any alternative
implementations of the driver without replacement of the kernel at
large.  It also means that any platform, with SGX hardware support,
running a kernel with this driver, has the potential for the
security/privacy issues noted above.

If key based policy management is not allowed, then the driver needs
to be re-architected to have modular support so that alternative
implementations or the absence of any driver support are at least
tenable.

Hopefully this is a reasoned technical approach to what has been a
long standing issue surrounding this technology.

Best wishes for a productive week.

Dr. Greg

As always,
Dr. Greg Wettstein, Ph.D, Worker      SGX secured infrastructure and
Enjellic Systems Development, LLC     autonomously self-defensive
4206 N. 19th Ave.                     platforms.
Fargo, ND  58102
PH: 701-281-1686                      EMAIL: greg@...ellic.com
------------------------------------------------------------------------------
"Opportunity is missed by most people because it is dressed in overalls
 and looks like work."
                                -- Thomas Edison

Powered by blists - more mailing lists