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 16:32 +0300, Mihai Donțu wrote:
> On Wed, 2017-08-02 at 14:27 +0200, Paolo Bonzini wrote:
> > On 02/08/2017 13:52, Mihai Donțu wrote:
> > > I think it might help to distinguish two situations in which we require
> > > the guest _or_ a single vCPU to be paused. Our initial KVMI_PAUSE_GUEST
> > > command can be translated into a qemu pause. In our particular usecase
> > > we made special arrangements to call it as few times as possible
> > > assuming it's very costly. The other is needed only by the internal KVM
> > > code for situations similar to:
> > > 
> > >   kvm_pause_vcpu(vcpu);
> > >   vcpu_load(vcpu);
> > >   kvm_arch_vcpu_ioctl_get_regs(vcpu, regs);
> > >   vcpu_put(vcpu);
> > >   kvm_unpause_vcpu(vcpu);
> > > 
> > > or more generally put, for accesses that involve the vCPU state
> > > (registers, MSR-s, exceptions etc.), no guest memory involved.
> > > 
> > > Here kvm_pause_vcpu() will only pull the vCPU out of the guest and, if
> > > so, make it somehow available for quick re-entry with
> > > kvm_unpause_vcpu(). If said vCPU is already out, then the function will
> > > be a no-op. Obviously, kvm_{pause,unpause}_vcpu() will do nothing if
> > > we're currently handling an event or one is pending.
> > 
> > Understood.  The issue is that there is an inherent race between
> > anything userspace is doing and get_regs.  What are the cases where you
> > need to get regs or similar outside an event?
> 
> We have currently identified three cases:
> 
>  * initial hooking of a guest
>  * periodically checking the integrity of data that is not properly
>    placed into a page and thus cannot be efficiently tracked via SPT
>  * injecting processes

A few more details are required here, taken from our current
application: cases (a) and (c) involve poking the vCPU-s a couple of
times before doing KVMI_PAUSE_GUEST() after which everything should be
OK, though we should make sure qemu sync-s the states before entering
the paused state.

Case (b), as far as I can see, is implemented only via memory maps (eg.
the IDT is mapped and kept around for quick checking), but a need
_might_ arrise to poke the vCPU a few times before concluding that an
area has really been corrupted.

> > > One exception that might have a better solution is:
> > > 
> > >   kvm_pause_all_vcpus(kvm);
> > >   kvm_set_page_access(kvm, gfn); /* pause for get too? */
> > >   kvm_unpause_all_vcpus(kvm);
> > > 
> > > There might be a way to make the change and then IPI all vCPU-s without
> > > pulling them out of the guest.
> > 
> > For that I think KVMI should define a VM-wide "mask" layered over the
> > actual memory map permissions.  Such a command can be implemented
> > relatively easily by hooking into the callers of __gfn_to_pfn_memslot
> > and kvm_vcpu_gfn_to_hva_prot.

-- 
Mihai Donțu