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:

quoted

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.

quoted

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