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

[Andy Lutomirski <luto@kernel.org>]

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.  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.
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.

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.

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.