Re: [intel-sgx-kernel-dev] SGX notes from KS/LPC

[Andy Lutomirski]

On Wed, Mar 8, 2017 at 10:03 PM, Kai Huang <kaih.linux@xxxxxxxxx> wrote:
> === Virtualization considerations === At some point, someone will need to
> decide what restrictions if any KVM should impose on its guests' use of SGX.
> For example, should KVM limit the set of SGXLEPUBKEYHASH values that its
> guests can use? Should KVM intercept EINIT and filter enclaves directly?

You must be using one of those newfangled gmail apps that totally
screws up quoting.  Sigh.  I need to switch away from gmail myself --
they keep regressing basic text editing functionality :(

>
>
> Hi Andy,
>
> Thank you very much for the informative notes. It is very helpful!
>
> For virtualization considerations, would you elaborate why we should impose
> restrictions on the guests use of SGX? I think in general virtualization
> only *virtualize* the hardware behavior but doesn't impose restrictions from
> software's perspective. For example, we cannot restrict a physical machine
> to only run launch enclave provided by RedHat (am I right?), so if we
> virtualize a machine with SGX supported, we should not restrict that the
> virtual machine to be only able to run launch enclave from RedHat.

Good question.  In general, I agree with you, but there are a couple
of SGX-specific considerations here.

1. Assuming that Launch Control serves a purpose at all, the best
legitimate purpose is to enforce some kind of policy on what enclaves
may run.  On Linux, this policy will primarily be configured by the
kernel.  If the kernel were to be configured so as to only allow some
subset of enclaves but KVM didn't restrict what guests could do, then
KVM could be used to do an end run around the kernel policy.  We don't
know what kinds of kernel policies will be useful, so I doubt it's
clear to anyone as to whether this matters.

2. Since Intel didn't provide a way for a hypervisor to make keys
derived by EGETKEY in guests different from keys derived in the host,
enclaves in a guest are effectively running at full host privilege and
with the host's identity.  This means, for example, that a
provisioning enclave running in the guest will be able to convince a
third part that it represents the *host*.  This may be a bad thing and
I can see some cause for preventing provisioning enclaves from running
in guests unless explicitly opted-in by the host admin.  Similarly,
normal enclaves in the guest get the same sealing key that they would
get in other guests on the same host, which could break certain
security assumptions.  I'm not sure how to address this without
Intel's help, but constraining what guests can do would be a start.