Am 26.10.2009 um 09:33 schrieb Avi Kivity <avi@xxxxxxxxxx>:
On 10/25/2009 06:45 PM, Alexander Graf wrote:
It's not. We can't use the guest memory for hsave because then
the guest could break the l1 state, so a malicious hypervisor
could break us.
Guest hsave should be used for storing guest state when switching
into the nested guest, not host state. Host state is not part of
the save/restore state in any case.
No it's not.
When going in an l2 guest, we need to save the l1 state in the
hsave. Now if we'd use the l1 given hsave, the l2 guest could
modify the hsave.
That means the l2 guest could rewrite the intercept bitmap to 0 and
compromize the host.
L1 hsave stores the architected state saved by vmrun, e.g. cs.sel,
next_rip, cr0, cr3, etc. The host intercept bitmap is not state
since it is calculated from the L1 intercept bitmap and host code.
Indeed it can be different from host to host even with the same
guest state.
Ah, so you'd only save off the cpu state parts of the vmcb.
Currently we save off control parts too, so we can easily swap them in
on #vmexit.
So if we'd migrate off when inside the nested guest, we'd have to save
off the resume control state, OR them again with the guest vmcb
control states and be inside the nested guest.
Wouldn't it be much easier to not migrate / save state when inside a
nested guest? I'm afraid the code will become overly complex if we do
allow migration while in a nested context.
Alex
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
