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
