On 5/17/2017 2:21 AM, Paolo Bonzini wrote:
On 16/05/2017 02:48, Huang, Kai wrote:
If host only allows one single LE to run, KVM can add a restrict that
only allows to create KVM guest with runtime change to
IA32_SGXLEPUBKEYHASHn disabled, so that only host allowed (single) hash
can be used by guest. From guest's view, it simply has
IA32_FEATURE_CONTROL[bit17] cleared and has IA32_SGXLEPUBKEYHASHn with
default value to be host allowed (single) hash.
If host allows several LEs (not but everything), and if we create guest
with 'lewr', then the behavior is not consistent with HW behavior, as
from guest's hardware's point of view, we can actually run any LE but we
have to tell guest that you are only allowed to change
IA32_SGXLEPUBKEYHASHn to some specific values. One compromise solution
is we don't allow to create guest with 'lewr' specified, and at the
meantime, only allow to create guest with host approved hashes specified
in 'lehash'. This will make guest's behavior consistent to HW behavior
but only allows guest to run one LE (which is specified by 'lehash' when
guest is created).
I'd like to hear comments from you guys.
Paolo, do you also have comments here from KVM's side?
I would start with read-only LE hash (same as the host), which is a
valid configuration anyway. Then later we can trap EINIT to emulate
IA32_SGXLEPUBKEYHASHn.
You mean we can start with creating guest without Qemu 'lewr' parameter
support, and always disallowing guest to change IA32_SGXLEPUBKEYHASHn?
Even in this way, KVM still needs to emulate IA32_SGXLEPUBKEYHASHn (just
allow MSR reading but not writing), and write guest's value to physical
MSRs when running guest (trapping EINIT and write MSRs during EINIT is
really just performance optimization). Because host can run multiple LEs
and change MSRs. Your suggestion only works when runtime change to
IA32_SGXLEPUBKEYHASHn is disabled on host (meaning physical machine).
Thanks,
-Kai
Paolo
