On Tue, Aug 20, 2019 at 02:43:32PM +0300, Mihai Donțu wrote:
On Tue, 2019-08-20 at 08:44 +0000, Nicusor CITU wrote:
quoted
quoted
quoted
quoted
quoted
+static void vmx_msr_intercept(struct kvm_vcpu *vcpu, unsigned
int
msr,
+ bool enable)
+{
+ struct vcpu_vmx *vmx = to_vmx(vcpu);
+ unsigned long *msr_bitmap = vmx->vmcs01.msr_bitmap;
Is KVMI intended to play nice with nested virtualization? Unconditionally
updating vmcs01.msr_bitmap is correct regardless of whether the vCPU
is in L1 or L2, but if the vCPU is currently in L2 then the effective
bitmap, i.e. vmcs02.msr_bitmap, won't be updated until the next nested VM-
Enter.
Our initial proof of concept was running with success in nested
virtualization. But most of our tests were done on bare-metal.
We do however intend to make it fully functioning on nested systems
too.
Even thought, from KVMI point of view, the MSR interception
configuration would be just fine if it gets updated before the vcpu is
actually entering to nested VM.
I believe Sean is referring here to the case where the guest being
introspected is a hypervisor (eg. Windows 10 with device guard).
Yep.
Even though we are looking at how to approach this scenario, the
introspection tools we have built will refuse to attach to a
hypervisor.
In that case, it's probably a good idea to make KVMI mutually exclusive
with nested virtualization. Doing so should, in theory, simplify the
implementation and expedite upstreaming, e.g. reviewers don't have to
nitpick edge cases related to nested virt. My only hesitation in
disabling KVMI when nested virt is enabled is that it could make it much
more difficult to (re)enable the combination in the future.
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization