From: "Dr. Greg" <email@example.com> To: Borislav Petkov <firstname.lastname@example.org> Cc: Sean Christopherson <email@example.com>, Jarkko Sakkinen <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, Jethro Beekman <email@example.com>, Andy Lutomirski <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org Subject: Re: [PATCH v33 12/21] x86/sgx: Allow a limited use of ATTRIBUTE.PROVISIONKEY for attestation Date: Thu, 2 Jul 2020 15:47:10 -0500 Message-ID: <20200702204709.GA21504@wind.enjellic.com> (raw) In-Reply-To: <20200630084956.GB1093@zn.tnic> Good afternoon, I hope the week is progressing productively to an end for everyone. I think it was almost two months ago now that Thomas Gleixner indicated that security and privacy issues that we were raising with respect to this driver, with what we believe is legitimate domain expertise, threatened the upstreaming of the driver. I think the case can be made that those claims were somewhat specious given a fast forward to today and the continued uncertainty regarding the architecture of this driver. So I will take that risk once again in order to provide some context for this thread. On Tue, Jun 30, 2020 at 10:49:56AM +0200, Borislav Petkov wrote: > On Mon, Jun 29, 2020 at 03:04:00PM -0700, Sean Christopherson wrote: > > > I don't see this acronym resolved anywhere in the whole patchset. > > > > Quoting Enclave. > Yah, pls add it somewhere. For the benefit of everyone not deeply involved with this and perhaps something that Jarkko can cut and paste if he desires. The Quoting Enclave (QE) is the trusted endpoint that is responsible for signing the report of an enclave's initialized status on a platform. In Enhanced Privacy ID (EPID) based attestation, the QE is the custodian of one of the private EPID group keys that is provisioned to the platform by the Intel Attestation Service (IAS). The quoting enclave generates a signature over the attesting enclave's report structure using that key. The IAS uses its public copy of the group key to verify that the signature is from a trusted endpoint running on a member of the group. The EPID provisioning process 'trusts' that the platform, to which the private group key is being delegated to, is a known Intel platform by virtue of the fact that the Platform Certification Enclave (PCE) is able to generate an identifier that could only be generated by having access to a specific symmetric encryption key. A key that is available only to enclaves that have been initialized with the PROVISION_KEY attribute bit. The QE encrypts the private group key using a signer specific (MRSIGNER) symmetric encryption key that only the QE can generate while in a trusted initialization state. That provides a mechanisum for persisting this chain of trust outside the context of execution of the QE. Things are slightly different from a mechanistic perspective when the Data Center Attestation Protocol (DCAP) is being used, but conceptually the same. In that attestation variant, the QE carries the PROVISION_KEY attribute so that it can certify that the report signature, generated with the Elliptic Curve Digital Signature Algorithm (ECDSA) rather then EPID, is from a known platform. > > /dev/sgx/provision is root-only by default, the expectation is > > that the admin will configure the system to grant only specific > > enclaves access to the PROVISION_KEY. > Uuh, I don't like "the expectation is" - the reality happens to turn > differently, more often than not. Indeed, which is why we have consistently maintained that the platform owner should be allowed to use cryptographic access controls over which enclaves can possess the PROVISION_KEY attribute. Given the security threat on a platform that is capable of supporting Enclave Dynamic Memory Management (EDMM), the ability to initialize an enclave is also a legitimate candidate for cryptographic access control. We can bikeshed the significance of these issues all day, but for the record, access to the PROVISION_KEY allows platforms to be absolutely and precisely fingerprinted for their entire lifespan. Initialized enclaves on an EDMM capable platform have the ability to execute arbitrary code, over which the kernel security infrastructure has no visibility into or control over. There is little doubt that EDMM will be a mainstay of the Confidential Computing Initiative (CCI), which is the target of this driver. A review of the archives will indicate that RedHat/IBM has already confirmed that their candidate for this infrastructure (Enarx) requires EDMM. To refresh everyone further, the last version of the SFLC patches that we proposed, allows a platform owner to run the driver in a default mode, which uses the proposed DAC controls over all of this or to opt for stronger cryptographic controls. The approach that we took has virtually no impact on the architecture and footprint of the driver. > > In this series, access is fairly binary, i.e. there's no > > additional kernel infrastructure to help userspace make > > per-enclave decisions. There have been more than a few proposals > > on how to extend the kernel to help provide better granularity, > > e.g. LSM hooks, but it was generally agreed to punt that stuff to > > post-upstreaming to keep things "simple" once we went far enough > > down various paths to ensure we weren't painting ourselves into a > > corner. > So this all sounds to me like we should not upstream > /dev/sgx/provision now but delay it until the infrastructure for > that has been made more concrete. We can always add it > then. Changing it after the fact - if we have to and for whatever > reason - would be a lot harder for a user-visible interface which > someone has started using already. > > So I'd leave that out from the initial patchset. Without access to the PROVISION_KEY attribute, the two standard mechanisms for attestation will not function, the technology is arguably useless for its intended purposes without attestation. Once again, I will leave it to community bike shedding as to whether or not Linux wants the ability to support unfettered deterministic platform fingerprinting that can be conducted for the physical lifespan of the platform. Once again, for the record, our approach affords compatibility with the now 6+ year old out-of-tree user interface, without requiring its use. I would argue that the continually voiced concerns about 'painting ourselves into a corner', with respect to access authorization, is significantly less of a problem with our approach rather then without it. > > If you want super gory details, Intel's whitepaper on attestation > > in cloud environments is a good starting point[*], but I don't > > recommended doing much more than skimming unless you really like > > attestation stuff or are masochistic, which IMO amount to the same > > thing :-) > No thanks. :) Interesting reflections and perhaps worthy of some introspection by the Linux development community. I will concede that there are a lot of musty corners that need to be explored in order to understand how all of this works and the security/privacy issues involved. I certainly wouldn't wish exploration on those corners on anyone. I think everyone will concede that my ideas and suggestions on these issues have been deemed to be unpopular, if not without merit. They do, however, come from the perspective of someone who directed a complete and independent implementation of all of this infrastructure. A process which has left me with no uncertainty whatsoever with respect to the issues involved in all of this. > Regards/Gruss, > Boris. Best wishes for a pleasant and productive weekend to everyone. Dr. Greg As always, Dr. Greg Wettstein, Ph.D, Worker Autonomously self-defensive Enjellic Systems Development, LLC IOT platforms and edge devices. 4206 N. 19th Ave. Fargo, ND 58102 PH: 701-281-1686 EMAIL: email@example.com ------------------------------------------------------------------------------ "I suppose that could happen but he wouldn't know a Galois Field if it kicked him in the nuts." -- Anonymous mathematician Resurrection.
next prev parent reply index Thread overview: 84+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-06-17 22:08 [PATCH v33 00/21] Intel SGX foundations Jarkko Sakkinen 2020-06-17 22:08 ` [PATCH v33 01/21] x86/cpufeatures: x86/msr: Add Intel SGX hardware bits Jarkko Sakkinen 2020-06-22 17:37 ` Borislav Petkov 2020-06-25 1:25 ` Jarkko Sakkinen 2020-06-17 22:08 ` [PATCH v33 02/21] x86/cpufeatures: x86/msr: Add Intel SGX Launch Control " Jarkko Sakkinen 2020-06-24 13:04 ` Borislav Petkov 2020-06-24 14:34 ` Sean Christopherson 2020-06-25 1:28 ` Jarkko Sakkinen 2020-06-17 22:08 ` [PATCH v33 03/21] x86/mm: x86/sgx: Signal SIGSEGV with PF_SGX Jarkko Sakkinen 2020-06-25 8:59 ` Borislav Petkov 2020-06-25 15:34 ` Sean Christopherson 2020-06-25 16:49 ` Borislav Petkov 2020-06-25 20:52 ` Jarkko Sakkinen 2020-06-25 21:11 ` Borislav Petkov 2020-06-26 13:34 ` Jarkko Sakkinen 2020-06-17 22:08 ` [PATCH v33 04/21] x86/sgx: Add SGX microarchitectural data structures Jarkko Sakkinen 2020-06-17 22:08 ` [PATCH v33 05/21] x86/sgx: Add wrappers for ENCLS leaf functions Jarkko Sakkinen 2020-06-17 22:08 ` [PATCH v33 06/21] x86/cpu/intel: Detect SGX support Jarkko Sakkinen 2020-06-17 22:08 ` [PATCH v33 07/21] x86/cpu/intel: Add nosgx kernel parameter Jarkko Sakkinen 2020-06-17 22:08 ` [PATCH v33 08/21] x86/sgx: Initialize metadata for Enclave Page Cache (EPC) sections Jarkko Sakkinen 2020-06-25 10:14 ` Borislav Petkov 2020-06-25 20:11 ` Jarkko Sakkinen 2020-06-17 22:08 ` [PATCH v33 09/21] x86/sgx: Add __sgx_alloc_epc_page() and sgx_free_epc_page() Jarkko Sakkinen 2020-06-25 17:06 ` Borislav Petkov 2020-06-25 20:55 ` Jarkko Sakkinen 2020-06-17 22:08 ` [PATCH v33 10/21] mm: Introduce vm_ops->may_mprotect() Jarkko Sakkinen 2020-06-25 17:14 ` Borislav Petkov 2020-06-25 17:30 ` Matthew Wilcox 2020-06-25 18:06 ` Sean Christopherson 2020-06-25 22:40 ` Jarkko Sakkinen 2020-06-25 22:26 ` Jarkko Sakkinen 2020-06-17 22:08 ` [PATCH v33 11/21] x86/sgx: Linux Enclave Driver Jarkko Sakkinen 2020-06-25 17:23 ` Borislav Petkov 2020-06-25 18:34 ` Sean Christopherson 2020-06-25 18:45 ` Borislav Petkov 2020-06-26 14:19 ` Jarkko Sakkinen 2020-06-25 20:21 ` Jarkko Sakkinen 2020-06-25 20:25 ` Borislav Petkov 2020-06-26 13:40 ` Jarkko Sakkinen 2020-06-25 18:53 ` Borislav Petkov 2020-06-26 14:17 ` Jarkko Sakkinen 2020-06-26 9:14 ` Borislav Petkov 2020-06-26 14:16 ` Sean Christopherson 2020-06-26 14:20 ` Borislav Petkov 2020-07-03 23:04 ` Jarkko Sakkinen 2020-07-03 3:09 ` Jarkko Sakkinen 2020-06-26 15:34 ` Borislav Petkov 2020-07-04 0:13 ` Jarkko Sakkinen 2020-06-27 17:43 ` Borislav Petkov 2020-06-29 15:27 ` Sean Christopherson 2020-06-29 15:37 ` Borislav Petkov 2020-07-04 1:43 ` Jarkko Sakkinen 2020-07-07 1:38 ` Sean Christopherson 2020-07-07 3:29 ` Jarkko Sakkinen 2020-07-04 1:42 ` Jarkko Sakkinen 2020-07-02 3:59 ` Sean Christopherson 2020-07-04 3:31 ` Jarkko Sakkinen 2020-06-17 22:08 ` [PATCH v33 12/21] x86/sgx: Allow a limited use of ATTRIBUTE.PROVISIONKEY for attestation Jarkko Sakkinen 2020-06-29 16:02 ` Borislav Petkov 2020-06-29 22:04 ` Sean Christopherson 2020-06-30 8:49 ` Borislav Petkov 2020-06-30 14:20 ` Sean Christopherson 2020-06-30 17:13 ` Andy Lutomirski 2020-07-02 20:47 ` Dr. Greg [this message] 2020-07-03 2:43 ` Jarkko Sakkinen 2020-07-03 2:38 ` Jarkko Sakkinen 2020-07-03 2:32 ` Jarkko Sakkinen 2020-07-03 2:55 ` Jarkko Sakkinen 2020-06-17 22:08 ` [PATCH v33 13/21] x86/sgx: Add a page reclaimer Jarkko Sakkinen 2020-06-17 22:08 ` [PATCH v33 14/21] x86/sgx: ptrace() support for the SGX driver Jarkko Sakkinen 2020-06-17 22:08 ` [PATCH v33 15/21] x86/vdso: Add support for exception fixup in vDSO functions Jarkko Sakkinen 2020-06-29 17:10 ` Borislav Petkov 2020-06-30 6:00 ` Sean Christopherson 2020-06-30 8:41 ` Borislav Petkov 2020-06-30 14:55 ` Sean Christopherson 2020-06-30 16:48 ` Andy Lutomirski 2020-06-30 17:23 ` Sean Christopherson 2020-07-02 12:52 ` Thomas Gleixner 2020-06-17 22:08 ` [PATCH v33 16/21] x86/fault: Add helper function to sanitize error code Jarkko Sakkinen 2020-06-17 22:08 ` [PATCH v33 17/21] x86/traps: Attempt to fixup exceptions in vDSO before signaling Jarkko Sakkinen 2020-06-17 22:08 ` [PATCH v33 18/21] x86/vdso: Implement a vDSO for Intel SGX enclave call Jarkko Sakkinen 2020-06-17 22:08 ` [PATCH v33 19/21] selftests/x86: Add a selftest for SGX Jarkko Sakkinen 2020-06-17 22:08 ` [PATCH v33 20/21] docs: x86/sgx: Document SGX micro architecture and kernel internals Jarkko Sakkinen 2020-06-17 22:08 ` [PATCH v33 21/21] x86/sgx: Update MAINTAINERS Jarkko Sakkinen
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20200702204709.GA21504@wind.enjellic.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Linux-Sgx Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linux-sgx/0 linux-sgx/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 linux-sgx linux-sgx/ https://lore.kernel.org/linux-sgx \ firstname.lastname@example.org public-inbox-index linux-sgx Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-sgx AGPL code for this site: git clone https://public-inbox.org/public-inbox.git