On Thu, Jun 15, 2017 at 9:33 PM, Huang, Kai <kai.huang(a)linux.intel.com> wrote:
On 6/16/2017 4:11 PM, Andy Lutomirski wrote:
> On Thu, Jun 15, 2017 at 8:46 PM, Huang, Kai <kai.huang(a)linux.intel.com>
>> On 6/13/2017 11:00 AM, Andy Lutomirski wrote:
>>> On Mon, Jun 12, 2017 at 3:08 PM, Huang, Kai
>>>> I don't know whether SGX driver will have restrict on running
>>>> enclave. In my understanding provisioning enclave is always from Intel.
>>>> However I am not expert here and probably be wrong. Can you point out
>>>> *exactly* what restricts in host must/should be applied to guest so
>>>> Jarkko can know whether he will support those restricts or not?
>>>> don't think we even need to talk about this topic at current stage.
>>> The whole point is that I don't know. But here are two types of
>>> restriction I can imagine demand for:
>>> 1. Only a particular approved provisioning enclave may run (be it
>>> Intel's or otherwise -- with a non-Intel LE, I think you can launch a
>>> non-Intel provisioning enclave). This would be done to restrict what
>>> types of remote attestation can be done. (Intel supplies a remote
>>> attestation service that uses some contractual policy that I don't
>>> know. Maybe a system owner wants a different policy applied to ISVs.)
>>> Imposing this policy on guests more or less requires filtering EINIT.
>> Hi Andy,
>> Sorry for late reply.
>> What is the issue if host and guest run provisioning enclave from
>> vendor, for example, host runs intel's provisioning enclave, and guest
>> other vendor's provisioning enclave? Or different guests run provisioning
>> enclaves from different vendors?
> There's no issue unless someone has tried to impose a policy. There
> is clearly at least some interest in having policies that affect what
> enclaves can run -- otherwise there wouldn't be LEs in the first
>> One reason I am asking is that, on Xen (where we don't have concept of
>> *host*), it's likely that we won't apply any policy at Xen hypervisor at
>> all, and guests will be able to run any enclave from any signer as their
> That seems entirely reasonable. Someone may eventually ask Xen to add
> support for SGX enclave restrictions, in which case you'll either have
> to tell them that it won't happen or implement it.
>> Sorry that I don't understand (or kind of forgot) the issues here.
>>> 2. For kiosk-ish or single-purpose applications, I can imagine that
>>> you would want to allow a specific list of enclave signers or even
>>> enclave hashes. Maybe you would allow exactly one enclave hash. You
>>> could kludge this up with a restrictive LE policy, but you could also
>>> do it for real by implementing the specific restriction in the kernel.
>>> Then you'd want to impose it on the guest, and you'd do it by
>>> filtering EINIT.
>> Assuming the enclave hash means measurement of enclave, and assuming we
>> a policy that we only allow enclave from one signer to run, would you
>> elaborate the issue that, if host and guest run enclaves from different
>> signer? If host has such policy, and we are allowing creating guests on
>> host, I think that typically we will have the same policy in the guest
> Yes, I presume this too, but.
>> (vetted by guest's kernel). The owner of that host should be aware of the
>> risk (if there's any) by creating guest and run enclave inside it.
> No. The host does not trust the guest in general. If the host has a
> policy that the only enclave that shall run is X, that doesn't mean
> that the host shall reject all enclaves requested by the normal
> userspace API except X but that, if /dev/kvm is used, then the user is
> magically trusted to not load a guest that fails to respect the host
> policy. It means that the only enclave that shall run is X regardless
> of what interface is used. The host must only allow X to be loaded by
> its userspace and the host must only allow X to be loaded by a guest.
This is theoretical thing. I think your statement makes sense only if we
have specific example that can prove there's actual risk when allowing guest
to exceed X approved by host.
I would turn this around. Can you come up with any example where the
host would have a restrictive policy but that the policy should not be
enforced for guests?