On Fri, 2017-08-04 at 10:35 +0200, Paolo Bonzini wrote: > On 02/08/2017 16:17, Mihai Donțu wrote: > > 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. > > Reads need not be transactional here, and the syscall entry point MSRs > are generally immutable so I think it is fine not to pause. I might be misunderstanding. Entry point MSR-s (and maybe others) are generally immutable in well behaving guests. We are, however, looking for signs that something is breaking this pattern. > I'm curious how the introspector decides that the guest is ready to be > hooked in, that is, that it's far enough in the boot process. I will let Andrei add some details here. > I think a command to "pause" KVM_RUN is okay to add. That is, if in > KVM_RUN it would e.g. return 1, trigger a 'paused' event immediately and > halt the vCPU. If not in KVM_RUN, the command would return 0 and > trigger the 'paused' event as soon as the hypervisor invokes KVM_RUN. > > The introspector then can decide whether to wait if the commands return > 0. There is no need for an "unpause" command, as that is achieved > simply by completing the 'paused' event. This mechanism will allow exposing a KVMI_PAUSE_VCPU to introspectors, something that maybe some future users can leverage. I, however, was trying to justify a "slow" KVMI_PAUSE_VM and "fast" kvm_pause_vcpu(), the latter existing only in KVM (kernel). The event-based mecanism for pausing a vCPU feels like it has too much overhead for what one usually needs it (read some registers). > > > 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? > > Yes, exactly. Optional, of course. We could add a command that returns the list of DMA ranges which can then be used by an introspector to check if the OS has made a mistake and placed sensible data in that rage. Also, I belive we have refined a number of ideas on this thread and more remain to clarify. I would like to update the design document with what we have agreed on so far, add some more details to what felt 'under explained' and continue again from there. Is it OK for you? Regards, -- Mihai Donțu
