On 6/13/2017 4:24 AM, Andy Lutomirski wrote:
On Mon, Jun 12, 2017 at 2:53 AM, Huang, Kai <kai.huang@xxxxxxxxxxxxxxx> 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
