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

["Huang, Kai" <kai.huang@linux.intel.com>]

On 6/13/2017 4:24 AM, Andy Lutomirski wrote:
> On Mon, Jun 12, 2017 at 2:53 AM, Huang, Kai <kai.huang@linux.intel.com> wrote:
> \
>>>
>>>>> How that would work on a system where MSRs cannot be changed?
>>>>
>>>>
>>>> This is simple, we simply won't allow guest to choose its own
>>>> IA32_SGXLEPUBKEYHASHn by specifying 'lehash' value in Qemu parameter when
>>>> creating the guest.
>>>
>>>
>>> Why not? You could have virtual MSRs and ask host LE to generate token
>>> if they match to modulus.
>>
>>
>> The guest has its own LE running inside, and guest's LE will generate token
>> for enclaves in guest. The host will not generate token for guest in any
>> circumstances, because this is totally guest's behavior.
>>
>> Virtualization is only about to emulate hardware's behavior, but not to
>> assume, or depend on, or change guest's SW behavior. We are not trying to
>> make sure EINIT will run successfully in guest, instead, we are trying to
>> make sure EINIT will be just the same behavior as it runs on physical
>> machine -- either success or failure, according to guest's sigstruct and
>> token.
> 
> I disagree.  Virtualization can do whatever it wants, but a pretty
> strong constraint is that the guest should be at least reasonably
> function.  

Virtualization only can do whatever it wants on the part that it can 
trap and emulate, and such *whatever* should not break HW behavior 
presented to guest. This is fundamental thing for virtualization. I 
don't know whether there are some *minor* case that the HW behavior 
emulation is not fully respected but I believe, if they exist, those 
cases are extremely rare, and we certainly have a good reason why such 
cases are OK.

Anyway I'll leave this part to KVM maintainers.

Paolo, Radim,

Sorry this thread is a little bit long till now. Can you comments on this?

A Windows guest, for example, shouldn't BSOD.  But the host
> most certainly can restrict what the guest can do.  If a guest is
> given pass-through access to a graphics card, the host is well within
> its rights to impose thermal policy, prevent reflashing, etc.

You need to see whether those policies are provided by PCIE configration 
space or by device's registers. If policies are implemented via PCIE 
configuration space (which is trapped and emulated by VMM/Qemu), you 
certainly can apply restrict on it by emulating PCIE configuration space 
access. But if those policies are done by device registers, which driver 
will control totally, it's totally up to driver and host cannot apply 
any policies. You can choose to or not to pass through device's specific 
BARs (ex, you cannot passthrough the BARs contains MSI), but once the 
BARs are passthroughed to guest, you cannot control guest's behavior.


> Similarly, if a guest is given access to SGX, the host can and should
> impose required policy on the guest.  If this means that an EINIT that
> would have succeeded at host CPL 0 fails in the guest, so be it.

This is completely different. And I disagree. If EINIT can run at host 
CPL 0, it can be run in guest's CPL 0 as well. Unless hardware doesn't 
support this, in which case we even cannot support SGX virtualization.

The exception is, if HW provides, for example, some specific capability 
bits that can be used to control whether EINIT can be run in CPL 0 or 
not, and hypervisor is able to trap those bits, then hypervisor can 
manipulate those bits to make guest think HW doesn't allow EINIT to run 
in CPL 0, in which case it is quite reasonable in guest EINIT cannot run 
in CPL 0 (because it is HW behavior).

> 
> Of course, there isn't much in the way of host policy right now, so
> this may not require any particular action until interesting host
> policy shows up.
> 
>> This is not constraint, but KVM has to emulate hardware correctly. For this
>> part please see my explanation above.
>>
>> And let me explain the purpose of trapping EINIT again here.
>>
>> When guest is about to run EINIT, if guest's SHA256(sigstruct->modulus)
>> matches guest's virtual IA32_SGXLEPUBKEYHASHn (and if others are correctly
>> populated in sigstruct and token as well), KVM needs to make sure that EINIT
>> will run successfully in guest, even physical IA32_SGXLEPUBKEYHASHn are not
>> equal to guest's virtual MSRs at this particular time.
> 
> True, so long as it doesn't contradict host policy to do so.
> 
>> This is because given
>> the same condition, the EINIT will run successfully on physical machine. KVM
>> needs to emulate the right HW behavior.
> 
> No.  The host needs to do this because KVM needs to work and be
> useful, not because KVM needs to precisely match CPU behavior as seen
> by VMX root.

If we need to break HW behavior to make SGX useful. The maintainer may 
choose not to support SGX virtualization, as from HW this feature simply 
cannot be virtualized.

Anyway I'll leave this to KVM maintainers to determine.

> 
> To avoid confusion, I don't believe I've ever said that guests should
> be restricted in which LEs they can use.  The types of restrictions
> I'm talking about are that, if the host prevents user code from
> running, say, a provisioning enclave that isn't whitelisted, then the
> guest should have the same restriction applied.  This type of
> restriction *can't* be usefully done by restricting acceptable MSR
> values, but it's trivial by trapping EINIT.

OK. Sorry I didn't get your point before. I thought it was about 
restrict LE.

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.

Thanks,
-Kai

>