Re: [RFC PATCH 08/19] kvm: Add the introspection subsystem

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Paolo,

On Wed, 2017-06-21 at 13:54 +0200, Paolo Bonzini wrote:
> On 16/06/2017 15:43, Adalbert Lazar wrote:
> > +	while (!list_empty(&kvm->access_list)) {
> > +		struct kvmi_mem_access *m =
> > +		    list_first_entry(&kvm->access_list, struct
> > kvmi_mem_access,
> > +				     link);
> > +
> > +		list_del(&m->link);
> > +		INIT_LIST_HEAD(&m->link);
> > +
> > +		kvmi_apply_mem_access(vcpu, m->gfn, m->access);
> > +	}

Thank you taking a look over this!

The entire mechanism for altering spte-s will need a separate
discussion, because right now it interferes with other mmu features
like dirty page logging and possibly other that I might not be aware
of.

The present code merely illustrates what we're really trying to
achieve: control the page permissions in the shadow page tables. The
mechanics are quite simple: while a VCPU is paused the introspection
tool creates a list of all spte's it wants to alter and then it
unpauses the VCPU which, on its wait back into the guest, walks the
list and applies the changes. This list-based approach is used because
sometimes accessing spte-s requires access to qemu's address space
which is tricky to do when the introspection tool runs as a separate
process. We tried using something on top of switch_mm() but it proved
unreliable. It also requires exporting some very deep x86-specific data
in order to build kvm-intel.ko.

> How does this work when multiple VCPUs are running with different MMU
> roles?  One VCPU is emptying the access_list for all, but
> kvm_mmu_set_spte is using for_each_shadow_entry per-VCPU.

Indeed, here we assume all VCPU-s' spt pointers are loaded with the
same address. A correct approach would iterate over all vCPU-s and I
suspect it would need to be a bit more complex with Intel's multiple
EPT views.

> I'm really afraid of introducing subtle bugs, with possible security
> effects.  I'm not really able to provide a suggestion yet, since I
> haven't grasped the protocol entirely.

-- 
Mihai Donțu




[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux