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/11/2017 12:23 AM, Jarkko Sakkinen wrote:
> On Fri, Jun 09, 2017 at 11:47:13AM +1200, Huang, Kai wrote:
>> In my understanding, although you only allows one LE in kernel, but you
>> won't limit who's LE can be run (basically kernel can run LE signed by
>> anyone, but just one LE when kernel is running), so I don't see there is any
>> limitation to KVM guests here.
>>
>> But it may still be better if SGX driver can provide function like:
>>
>>      int sgx_validate_sigstruct(struct sigstruct *sig);
>>
>> for KVM to call, in case driver is changed (ex, to only allows LEs from some
>> particular ones to run), but this is not necessary now. KVM changes can be
>> done later when driver make the changes.
>>
>> Andy,
>>
>> Am I understanding correctly? Does this make sense to you?
>>
>> Thanks,
>> -Kai
> 
> Nope. I don't even understand the *beginnings* what that function would
> do. I don't understand what the validation means here and what VMM would
> do if that functions reports "success".

The validation means either the sigstruct->modulus or 
SHA256(sigstruct->modulus) should be in a 'approved white-list' 
maintained by kernel (which I know doesn't exist now, but Andy some kind 
suggested we may or should have, in the future I guess), otherwise the 
function returns error to indicate the LE from guest is "unapproved by 
host kernel/driver".

Andy, would you explain here?

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

To elaborate, currently in my design Qemu has below new parameters to 
support SGX:

	# qemu-system-x86_64 -sgx, epc=<size>,lehash=<sha-256 hash>,lewr

The 'epc=<size>' specifies guest's EPC size obviously, lehash specifies 
guest's initial IA32_SGXLEPUBKEYHASHn (similar to the value configured 
in BIOS for real machine), and 'lewr' specifies whether guest's 
IA32_SGXLEPUBKEYHASHn can be changed by OS at runtime. The 'lehash' and 
'lewr' are optional.

If MSRs cannot be changed on physical machine, then we will fail to 
create guest if either 'lehash' or 'lewr' is specified when creating the 
guest.

> 
> In that kind of system the host OS must generate EINITTOKEN for the LE
> running on inside the guest and maintain completely virtualized MSR
> values for the guest.

The host OS will not generate EINITTOKEN for guest in any circumstances, 
as EINITTOKEN will always be from guest's EINIT instruction. KVM traps 
EINIT from guest and gets both SIGSTRUCT and EINITTOKEN from the EINIT 
leaf, update MSRs, and run EINIT on behalf of guest.

Btw the purpose for KVM to trap EINIT is to update guest's virtual 
IA32_SGXLEPUBKEYHASHn to physical MSRs, before running EINIT. In fact 
KVM even doesn't need to trap EINIT but simply updating guest's MSRs to 
real MSRs when vcpu is scheduled in, if SGX driver can update host LE's 
hash to MSRs before EINIT in host. KVM are not trying to guarantee 
running EINIT successfully here, but simply to emulate guest's 
IA32_SGXLEPUBKEYHASHn and EINIT in the guest.

Thanks,
-Kai

> 
> /Jarkko
>