| Message ID | 20200617220844.57423-13-jarkko.sakkinen@linux.intel.com (mailing list archive) |
|---|---|
| State | Rejected |
| Headers | show |
| Series | Intel SGX foundations | expand |
On Thu, Jun 18, 2020 at 01:08:34AM +0300, Jarkko Sakkinen wrote: > Provisioning Certification Enclave (PCE), the root of trust for other > enclaves, generates a signing key from a fused key called Provisioning > Certification Key. PCE can then use this key to certify an attestation key > of a QE, e.g. we get the chain of trust down to the hardware if the Intel What's a QE? I don't see this acronym resolved anywhere in the whole patchset. > signed PCE is used. > > To use the needed keys, ATTRIBUTE.PROVISIONKEY is required but should be > only allowed for those who actually need it so that only the trusted > parties can certify QE's. > > Obviously the attestation service should know the public key of the used > PCE and that way detect illegit attestation, but whitelisting the legit > users still adds an additional layer of defence. > > Add new device file called /dev/sgx/provision. The sole purpose of this > file is to provide file descriptors that act as privilege tokens to allow > to build enclaves with ATTRIBUTE.PROVISIONKEY set. A new ioctl called > SGX_IOC_ENCLAVE_SET_ATTRIBUTE is used to assign this token to an enclave. So I'm sure I'm missing something here: what controls which enclave can open /dev/sgx/provision and thus pass the FD to SGX_IOC_ENCLAVE_SET_ATTRIBUTE? And in general, how does that whole flow look like: what calls SGX_IOC_ENCLAVE_SET_ATTRIBUTE when? Thx.
On Mon, Jun 29, 2020 at 06:02:42PM +0200, Borislav Petkov wrote: > On Thu, Jun 18, 2020 at 01:08:34AM +0300, Jarkko Sakkinen wrote: > > Provisioning Certification Enclave (PCE), the root of trust for other > > enclaves, generates a signing key from a fused key called Provisioning > > Certification Key. PCE can then use this key to certify an attestation key > > of a QE, e.g. we get the chain of trust down to the hardware if the Intel > > What's a QE? > > I don't see this acronym resolved anywhere in the whole patchset. Quoting Enclave. > > signed PCE is used. > > > > To use the needed keys, ATTRIBUTE.PROVISIONKEY is required but should be > > only allowed for those who actually need it so that only the trusted > > parties can certify QE's. > > > > Obviously the attestation service should know the public key of the used > > PCE and that way detect illegit attestation, but whitelisting the legit > > users still adds an additional layer of defence. > > > > Add new device file called /dev/sgx/provision. The sole purpose of this > > file is to provide file descriptors that act as privilege tokens to allow > > to build enclaves with ATTRIBUTE.PROVISIONKEY set. A new ioctl called > > SGX_IOC_ENCLAVE_SET_ATTRIBUTE is used to assign this token to an enclave. > > So I'm sure I'm missing something here: what controls which > enclave can open /dev/sgx/provision and thus pass the FD to > SGX_IOC_ENCLAVE_SET_ATTRIBUTE? /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. > And in general, how does that whole flow look like: what calls > SGX_IOC_ENCLAVE_SET_ATTRIBUTE when? The basic gist is that the host process of an enclave that needs/wants access to the PROVISION_KEY will invoke SGX_IOC_ENCLAVE_SET_ATTRIBUTE when building the enclave. Any enclave can request access to PROVISION_KEY, but practically speaking only the PCE and QE (or their non-Intel equivalents) actually need access to the key. KVM (future series) will also respect /dev/sgx/provision, i.e. require a similar ioctl() to expose the PROVISION_KEY to a guest. E.g. for my own personal testing, I never do anything attestation related, so none of the enclaves I run request PROVISION_KEY, but I do expose it to VMs to test the KVM paths. 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. 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 :-) [*] https://download.01.org/intel-sgx/dcap-1.0/docs/SGX_ECDSA_QuoteGenReference_DCAP_API_Linux_1.0.pdf
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. > /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. > 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. > 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. :)
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: > > /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. Would it help if I worded it as "only root should ever be able to run an enclave with access to PROVISION_KEY"? We obviously can't control what admins actually do, hence my wording of it as the expected behavior. > > 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. The userspace and attestation infrastructure is very concrete, i.e. the need for userspace to be able to access PROVISION_KEY is there, as is the desire to be able to restrict access to PROVISION_KEY, e.g. I believe Andy Lutomirski originally requested the ability to restrict access. The additional infrastructure for per-enclave decisions is somewhat orthogonal to the PROVISION_KEY, e.g. they won't necessarily be employed by everyone running enclaves, and environments that do have per-enclave policies would still likely want the extra layer of restriction for PROVISION_KEY. I only brought the additional policy crud to call out that we've done enough path-finding on additional restrictions to have strong confidence that adding /dev/sgx/provision won't prevent us from adding more fine grained control in the future. > So I'd leave that out from the initial patchset.
On Tue, Jun 30, 2020 at 7:20 AM Sean Christopherson <sean.j.christopherson@intel.com> wrote: > > 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: > > > /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. > > Would it help if I worded it as "only root should ever be able to run an > enclave with access to PROVISION_KEY"? We obviously can't control what > admins actually do, hence my wording of it as the expected behavior. > > > > 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. > > The userspace and attestation infrastructure is very concrete, i.e. the > need for userspace to be able to access PROVISION_KEY is there, as is the > desire to be able to restrict access to PROVISION_KEY, e.g. I believe Andy > Lutomirski originally requested the ability to restrict access. > > The additional infrastructure for per-enclave decisions is somewhat > orthogonal to the PROVISION_KEY, e.g. they won't necessarily be employed > by everyone running enclaves, and environments that do have per-enclave > policies would still likely want the extra layer of restriction for > PROVISION_KEY. I only brought the additional policy crud to call out that > we've done enough path-finding on additional restrictions to have strong > confidence that adding /dev/sgx/provision won't prevent us from adding more > fine grained control in the future. I agree. I anticipate that most of the nasty fine-grained stuff will end up in userspace down the road. Systems can be configured such that provisioning is done as root, or systems can end up with fancy SELinux rules or daemons that pass around fds or whatever, but all of this can be done with the kernel code in this patchset.
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: greg@enjellic.com ------------------------------------------------------------------------------ "I suppose that could happen but he wouldn't know a Galois Field if it kicked him in the nuts." -- Anonymous mathematician Resurrection.
On Mon, Jun 29, 2020 at 06:02:42PM +0200, Borislav Petkov wrote: > On Thu, Jun 18, 2020 at 01:08:34AM +0300, Jarkko Sakkinen wrote: > > Provisioning Certification Enclave (PCE), the root of trust for other > > enclaves, generates a signing key from a fused key called Provisioning > > Certification Key. PCE can then use this key to certify an attestation key > > of a QE, e.g. we get the chain of trust down to the hardware if the Intel > > What's a QE? > > I don't see this acronym resolved anywhere in the whole patchset. Quoting Enclave. > > > signed PCE is used. > > > > To use the needed keys, ATTRIBUTE.PROVISIONKEY is required but should be > > only allowed for those who actually need it so that only the trusted > > parties can certify QE's. > > > > Obviously the attestation service should know the public key of the used > > PCE and that way detect illegit attestation, but whitelisting the legit > > users still adds an additional layer of defence. > > > > Add new device file called /dev/sgx/provision. The sole purpose of this > > file is to provide file descriptors that act as privilege tokens to allow > > to build enclaves with ATTRIBUTE.PROVISIONKEY set. A new ioctl called > > SGX_IOC_ENCLAVE_SET_ATTRIBUTE is used to assign this token to an enclave. > > So I'm sure I'm missing something here: what controls which > enclave can open /dev/sgx/provision and thus pass the FD to > SGX_IOC_ENCLAVE_SET_ATTRIBUTE? > > And in general, how does that whole flow look like: what calls > SGX_IOC_ENCLAVE_SET_ATTRIBUTE when? I've documented it in the Remote Attestation section: https://github.com/jsakkine-intel/linux-sgx/blob/master/Documentation/x86/sgx.rst /Jarkko
On Mon, Jun 29, 2020 at 03:04:00PM -0700, Sean Christopherson wrote: > On Mon, Jun 29, 2020 at 06:02:42PM +0200, Borislav Petkov wrote: > > On Thu, Jun 18, 2020 at 01:08:34AM +0300, Jarkko Sakkinen wrote: > > > Provisioning Certification Enclave (PCE), the root of trust for other > > > enclaves, generates a signing key from a fused key called Provisioning > > > Certification Key. PCE can then use this key to certify an attestation key > > > of a QE, e.g. we get the chain of trust down to the hardware if the Intel > > > > What's a QE? > > > > I don't see this acronym resolved anywhere in the whole patchset. > > Quoting Enclave. > > > > signed PCE is used. > > > > > > To use the needed keys, ATTRIBUTE.PROVISIONKEY is required but should be > > > only allowed for those who actually need it so that only the trusted > > > parties can certify QE's. > > > > > > Obviously the attestation service should know the public key of the used > > > PCE and that way detect illegit attestation, but whitelisting the legit > > > users still adds an additional layer of defence. > > > > > > Add new device file called /dev/sgx/provision. The sole purpose of this > > > file is to provide file descriptors that act as privilege tokens to allow > > > to build enclaves with ATTRIBUTE.PROVISIONKEY set. A new ioctl called > > > SGX_IOC_ENCLAVE_SET_ATTRIBUTE is used to assign this token to an enclave. > > > > So I'm sure I'm missing something here: what controls which > > enclave can open /dev/sgx/provision and thus pass the FD to > > SGX_IOC_ENCLAVE_SET_ATTRIBUTE? > > /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. > > > And in general, how does that whole flow look like: what calls > > SGX_IOC_ENCLAVE_SET_ATTRIBUTE when? > > The basic gist is that the host process of an enclave that needs/wants access > to the PROVISION_KEY will invoke SGX_IOC_ENCLAVE_SET_ATTRIBUTE when building > the enclave. Any enclave can request access to PROVISION_KEY, but practically > speaking only the PCE and QE (or their non-Intel equivalents) actually need > access to the key. KVM (future series) will also respect /dev/sgx/provision, > i.e. require a similar ioctl() to expose the PROVISION_KEY to a guest. > > E.g. for my own personal testing, I never do anything attestation related, so > none of the enclaves I run request PROVISION_KEY, but I do expose it to VMs to > test the KVM paths. > > 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. > > 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 :-) > > [*] https://download.01.org/intel-sgx/dcap-1.0/docs/SGX_ECDSA_QuoteGenReference_DCAP_API_Linux_1.0.pdf Section 3 in [*] is what describes the infrastructure. DCAP is only a component in the whole attestation infrastructure. [*] https://software.intel.com/sites/default/files/managed/f1/b8/intel-sgx-support-for-third-party-attestation.pdf /Jarkko
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. > > > /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. > > > 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. I'm trying to understand what is meant by "more concrete". Attestation is needed for most enclave applications. If this patch is dropped, should we also allow PROVISION_KEY attribute to all enclaves? Dropping this patch and keeping that check in the driver patch is not very coherent behaviour. /Jarkko
On Fri, Jul 03, 2020 at 05:32:28AM +0300, Jarkko Sakkinen wrote: > On Mon, Jun 29, 2020 at 06:02:42PM +0200, Borislav Petkov wrote: > > On Thu, Jun 18, 2020 at 01:08:34AM +0300, Jarkko Sakkinen wrote: > > > Provisioning Certification Enclave (PCE), the root of trust for other > > > enclaves, generates a signing key from a fused key called Provisioning > > > Certification Key. PCE can then use this key to certify an attestation key > > > of a QE, e.g. we get the chain of trust down to the hardware if the Intel > > > > What's a QE? > > > > I don't see this acronym resolved anywhere in the whole patchset. > > Quoting Enclave. Thanks for spotting this. I updated my GIT-tree accordingly. /Jarkko
diff --git a/arch/x86/include/uapi/asm/sgx.h b/arch/x86/include/uapi/asm/sgx.h index 5edb08ab8fd0..57d0d30c79b3 100644 --- a/arch/x86/include/uapi/asm/sgx.h +++ b/arch/x86/include/uapi/asm/sgx.h @@ -25,6 +25,8 @@ enum sgx_page_flags { _IOWR(SGX_MAGIC, 0x01, struct sgx_enclave_add_pages) #define SGX_IOC_ENCLAVE_INIT \ _IOW(SGX_MAGIC, 0x02, struct sgx_enclave_init) +#define SGX_IOC_ENCLAVE_SET_ATTRIBUTE \ + _IOW(SGX_MAGIC, 0x03, struct sgx_enclave_set_attribute) /** * struct sgx_enclave_create - parameter structure for the @@ -63,4 +65,13 @@ struct sgx_enclave_init { __u64 sigstruct; }; +/** + * struct sgx_enclave_set_attribute - parameter structure for the + * %SGX_IOC_ENCLAVE_SET_ATTRIBUTE ioctl + * @attribute_fd: file handle of the attribute file in the securityfs + */ +struct sgx_enclave_set_attribute { + __u64 attribute_fd; +}; + #endif /* _UAPI_ASM_X86_SGX_H */ diff --git a/arch/x86/kernel/cpu/sgx/driver.c b/arch/x86/kernel/cpu/sgx/driver.c index b4aa7b9f8376..d90114cec1c3 100644 --- a/arch/x86/kernel/cpu/sgx/driver.c +++ b/arch/x86/kernel/cpu/sgx/driver.c @@ -150,6 +150,13 @@ static struct miscdevice sgx_dev_enclave = { .fops = &sgx_encl_fops, }; +static struct miscdevice sgx_dev_provision = { + .minor = MISC_DYNAMIC_MINOR, + .name = "provision", + .nodename = "sgx/provision", + .fops = &sgx_provision_fops, +}; + int __init sgx_drv_init(void) { unsigned int eax, ebx, ecx, edx; @@ -190,5 +197,12 @@ int __init sgx_drv_init(void) return ret; } + ret = misc_register(&sgx_dev_provision); + if (ret) { + pr_err("Creating /dev/sgx/provision failed with %d.\n", ret); + misc_deregister(&sgx_dev_enclave); + return ret; + } + return 0; } diff --git a/arch/x86/kernel/cpu/sgx/driver.h b/arch/x86/kernel/cpu/sgx/driver.h index e4063923115b..72747d01c046 100644 --- a/arch/x86/kernel/cpu/sgx/driver.h +++ b/arch/x86/kernel/cpu/sgx/driver.h @@ -23,6 +23,8 @@ extern u64 sgx_attributes_reserved_mask; extern u64 sgx_xfrm_reserved_mask; extern u32 sgx_xsave_size_tbl[64]; +extern const struct file_operations sgx_provision_fops; + long sgx_ioctl(struct file *filep, unsigned int cmd, unsigned long arg); int sgx_drv_init(void); diff --git a/arch/x86/kernel/cpu/sgx/ioctl.c b/arch/x86/kernel/cpu/sgx/ioctl.c index 420d13fc03da..721096f1d5ba 100644 --- a/arch/x86/kernel/cpu/sgx/ioctl.c +++ b/arch/x86/kernel/cpu/sgx/ioctl.c @@ -669,6 +669,50 @@ static long sgx_ioc_enclave_init(struct sgx_encl *encl, void __user *arg) return ret; } +/** + * sgx_ioc_enclave_set_attribute - handler for %SGX_IOC_ENCLAVE_SET_ATTRIBUTE + * @filep: open file to /dev/sgx + * @arg: userspace pointer to a struct sgx_enclave_set_attribute instance + * + * Mark the enclave as being allowed to access a restricted attribute bit. + * The requested attribute is specified via the attribute_fd field in the + * provided struct sgx_enclave_set_attribute. The attribute_fd must be a + * handle to an SGX attribute file, e.g. "/dev/sgx/provision". + * + * Failure to explicitly request access to a restricted attribute will cause + * sgx_ioc_enclave_init() to fail. Currently, the only restricted attribute + * is access to the PROVISION_KEY. + * + * Note, access to the EINITTOKEN_KEY is disallowed entirely. + * + * Return: 0 on success, -errno otherwise + */ +static long sgx_ioc_enclave_set_attribute(struct sgx_encl *encl, + void __user *arg) +{ + struct sgx_enclave_set_attribute params; + struct file *attribute_file; + int ret; + + if (copy_from_user(¶ms, arg, sizeof(params))) + return -EFAULT; + + attribute_file = fget(params.attribute_fd); + if (!attribute_file) + return -EINVAL; + + if (attribute_file->f_op != &sgx_provision_fops) { + ret = -EINVAL; + goto out; + } + + encl->allowed_attributes |= SGX_ATTR_PROVISIONKEY; + ret = 0; + +out: + fput(attribute_file); + return ret; +} long sgx_ioctl(struct file *filep, unsigned int cmd, unsigned long arg) { @@ -694,6 +738,9 @@ long sgx_ioctl(struct file *filep, unsigned int cmd, unsigned long arg) case SGX_IOC_ENCLAVE_INIT: ret = sgx_ioc_enclave_init(encl, (void __user *)arg); break; + case SGX_IOC_ENCLAVE_SET_ATTRIBUTE: + ret = sgx_ioc_enclave_set_attribute(encl, (void __user *)arg); + break; default: ret = -ENOIOCTLCMD; break;