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.
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.
I don't describe the above to hype or promote what we do. Everyone
discussing these issues is a professional software engineer or
architect. As such, you will know that by the time you get done doing
all of the above, to the point where you are willing to take it to
Washington, DC to do live technology demonstrations to government
agencies with seven minutes of setup time, you are going to have to be
pretty confident that you know how all of the pieces are supposed to
go together.
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.
This is NOT a criticism of Jarkko's work or the overall technical
implementation and quality of the driver. We actually use and test a
modified version of the proposed driver, along with the out of tree
driver in our platforms.
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. 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.
There will be some devil in the details with respect to both of these
issues, but those discussions can follow later. Addressing these two
issues will at least create an environment where the proposed in-tree
driver is equivalent in privacy and functionality to the out of tree
driver.
SGX is a remarkably complex piece of machinery. Producing a useful
driver requires the consideration of a lot of issues which, in our
opinion, have not been fully represented in the discussions to date.
> /Jarkko
I hope the above is useful for framing future discussions.
Have a good remainder of the week.
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@xxxxxxxxxxxx
------------------------------------------------------------------------------
"I suppose that could could happen but he wouldn't know a Galois Field
if it kicked him in the nuts."
-- Anonymous mathematician
Resurrection.
