lkml.org 
[lkml]   [2018]   [Nov]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v17 18/23] platform/x86: Intel SGX driver
    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@enjellic.com
    ------------------------------------------------------------------------------
    "I suppose that could could happen but he wouldn't know a Galois Field
    if it kicked him in the nuts."
    -- Anonymous mathematician
    Resurrection.

    \
     
     \ /
      Last update: 2018-11-22 12:14    [W:3.209 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site