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 17:17:29 +0300 Message-ID: <1501683449.15747.334.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 , Andrei LUTAS To: Paolo Bonzini Return-path: Received: from mx01.bbu.dsd.mx.bitdefender.com ([91.199.104.161]:38870 "EHLO mx01.bbu.dsd.mx.bitdefender.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752286AbdHBORb (ORCPT ); Wed, 2 Aug 2017 10:17:31 -0400 Received: from smtp01.buh.bitdefender.com (unknown [10.17.80.75]) by mx-sr.buh.bitdefender.com (Postfix) with ESMTP id A86977FC2A for ; Wed, 2 Aug 2017 17:17:29 +0300 (EEST) In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: 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