From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mihai =?UTF-8?Q?Don=C8=9Bu?= Subject: Re: [RFC PATCH v2 1/1] kvm: Add documentation and ABI/API header for VM introspection Date: Wed, 02 Aug 2017 16:53:13 +0300 Message-ID: <1501681993.15747.329.camel@bitdefender.com> References: <20170707143416.11195-1-alazar@bitdefender.com> <20170707143416.11195-2-alazar@bitdefender.com> <7104167e-0747-92fe-05df-1b7e1848d65f@redhat.com> <1499934995.2110.345.camel@bitdefender.com> <1d3e3fc7-5fec-037e-4be4-82a380c85972@redhat.com> <1501172635.8856.4.camel@bitdefender.com> <5f499fe6-0ac8-56e7-a4f5-ba6809cc7c6a@redhat.com> <1501175973.8856.11.camel@bitdefender.com> <1501674729.15747.282.camel@bitdefender.com> <1b3467e4-1d67-dacd-7436-6a07c08f597b@redhat.com> <1501680749.15747.319.camel@bitdefender.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Cc: Radim =?UTF-8?Q?Kr=C4=8Dm=C3=A1=C5=99?= , Jan Kiszka , Stefan Hajnoczi , Adalbert Lazar , kvm@vger.kernel.org, Tamas K Lengyel To: Paolo Bonzini Return-path: Received: from mx01.bbu.dsd.mx.bitdefender.com ([91.199.104.161]:38310 "EHLO mx01.bbu.dsd.mx.bitdefender.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752635AbdHBNxQ (ORCPT ); Wed, 2 Aug 2017 09:53:16 -0400 Received: from smtp03.buh.bitdefender.org (smtp.bitdefender.biz [10.17.80.77]) by mx-sr.buh.bitdefender.com (Postfix) with ESMTP id 839337FC29 for ; Wed, 2 Aug 2017 16:53:14 +0300 (EEST) In-Reply-To: <1501680749.15747.319.camel@bitdefender.com> Sender: kvm-owner@vger.kernel.org List-ID: 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