Re: [RFC PATCH v2 1/1] kvm: Add documentation and ABI/API header for VM introspection

["Mihai Donțu" <mdontu@bitdefender.com>]

On Wed, 2017-08-02 at 15:51 +0200, Paolo Bonzini wrote:
> On 02/08/2017 15:32, Mihai Donțu wrote:
> > We have currently identified three cases:
> > 
> >  * initial hooking of a guest
> 
> What triggers the initial hooking, and how is it done?

There are two types o hooks: dynamic (the guest is hooked as it boots)
and static (a fully booted guest is being hooked). They both start with
a notification from qemu or some other application that a guest is
available for introspection. After that we poke its vCPU-s a few times
to determine what type of hooking to continue with. I belive the
syscall entry point MSR-s are key here.

> >  * periodically checking the integrity of data that is not properly
> >    placed into a page and thus cannot be efficiently tracked via SPT
> 
> This only needs read memory (and it's okay for it to race against DMA
> because it's periodic).

I just looked through some traces (the logic changed quite a bit since
I last checked) and looks entirely based on memory reads right now.

> >  * injecting processes
> 
> This also doesn't need pause.  IIRC you put a breakpoint somewhere, or
> make a page non-executable, to ensure the guest doesn't get in the way.
> DMA can still get in the way, but that can happen anyway right after
> process injection so it's not an issue.

That might be a very possible approach. The code we have in place now
pauses the guest entirely, though.

I have added in CC a colleague of mine, Andrei Luțaș. He leads the
development of the introspection technology, irrespective of the
hypervisor. Adalbert and I only work on bridging it with KVM. :-) I'll
kindly ask him to help with more details wherever you feel my
explanations were not sufficient.

> Have you thought about monitoring hardware registers, for example in
> order to check that IOMMU page tables protect from overwriting the kernel?

Sorry, but I'm not sure I understand: are you thinking at a way to make
sure none of the IOMMU grups are configured with a "too generous" DMA
window?

Regards,

-- 
Mihai Donțu