Re: [intel-sgx-kernel-dev] [PATCH 08/10] kvm: vmx: add guest's IA32_SGXLEPUBKEYHASHn runtime switch support

[Andy Lutomirski <luto@kernel.org>]

On Thu, Jun 15, 2017 at 9:33 PM, Huang, Kai <kai.huang@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@linux.intel.com>
>> wrote:
>>>
>>>
>>>
>>> On 6/13/2017 11:00 AM, Andy Lutomirski wrote:
>>>>
>>>>
>>>> On Mon, Jun 12, 2017 at 3:08 PM, Huang, Kai <kai.huang@linux.intel.com>
>>>> wrote:
>>>>>
>>>>>
>>>>>
>>>>> I don't know whether SGX driver will have restrict on running
>>>>> provisioning
>>>>> 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
>>>>> that
>>>>> Jarkko can know whether he will support those restricts or not?
>>>>> Otherwise
>>>>> I
>>>>> 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
>>> different
>>> vendor, for example, host runs intel's provisioning enclave, and guest
>>> runs
>>> 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
>> place.
>>
>>>
>>> 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
>>> wish.
>>
>>
>> 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
>>> have
>>> a policy that we only allow enclave from one signer to run, would you
>>> also
>>> 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
>>> such
>>> 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
>
>
> I agree.
>
>> 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 will dig more in your previous emails to see whether you have listed such
> real cases (I some kind forgot sorry) but if you don't mind, you can list
> such cases here.

I'm operating under the assumption that some kind of policy exists in
the first place.  I can imagine everything working fairly well without
any real policy, but apparently there are vendors who want restrictive
policies.  What I can't imagine is anyone who wants a restrictive
policy but is then okay with the host only partially enforcing it.

>
> Thanks,
> -Kai