From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mihai =?UTF-8?Q?Don=C8=9Bu?= Subject: Re: [RFC PATCH 00/19] Guest introspection Date: Fri, 16 Jun 2017 18:59:04 +0300 Message-ID: <1497628744.10504.12.camel@bitdefender.com> References: <20170616134348.17725-1-alazar@bitdefender.com> <1befe4ae-9c9c-eb3e-589d-775b23ba3152@siemens.com> <1497626293.10504.9.camel@bitdefender.com> <4c48494d-ee5e-ddd5-ce92-c29c25316ca3@siemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Cc: Paolo Bonzini , Radim =?UTF-8?Q?Kr=C4=8Dm=C3=A1=C5=99?= , Adalbert Lazar , kvm@vger.kernel.org To: Jan Kiszka Return-path: Received: from mx01.bbu.dsd.mx.bitdefender.com ([91.199.104.161]:43988 "EHLO mx01.bbu.dsd.mx.bitdefender.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750750AbdFPP7H (ORCPT ); Fri, 16 Jun 2017 11:59:07 -0400 Received: from smtp03.buh.bitdefender.org (smtp.bitdefender.biz [10.17.80.77]) by mx-sr.buh.bitdefender.com (Postfix) with ESMTP id 8AA2B7FC03 for ; Fri, 16 Jun 2017 18:59:05 +0300 (EEST) In-Reply-To: <4c48494d-ee5e-ddd5-ce92-c29c25316ca3@siemens.com> Sender: kvm-owner@vger.kernel.org List-ID: On Fri, 2017-06-16 at 17:34 +0200, Jan Kiszka wrote: > On 2017-06-16 17:18, Mihai Donțu wrote: > > On Fri, 2017-06-16 at 16:45 +0200, Jan Kiszka wrote: > > > On 2017-06-16 15:43, Adalbert Lazar wrote: > > > > This patch series proposes an interface that will allow a guest > > > > introspection tool to monitor and control other guests, in order to > > > > protect them against different forms of exploits. This type of interface > > > > is already present in the XEN hypervisor. > > > > > > > > With the current implementation, the introspection tool connects to > > > > the KVMi (the introspection subsystem from KVM) using a vsock socket, > > > > establishes a main communication channel, used for a few messages > > > > (KVMI_EVENT_GUEST_ON, KVMI_EVENT_GUEST_OFF, KVMI_GET_GUESTS and > > > > KVMI_GET_VERSION). > > > > > > > > Every KVMI_EVENT_GUEST_ON notification, makes the introspection tool > > > > establish a new connection, used to monitor and control that guest. > > > > Thank you very much for taking a look over this series! > > > > > What prevented building this on top of the already existing guest debug > > > interfaces of KVM, maybe extending it where needed? Could be win-win. > > > > I might be mistaking, but this would require the application using the > > introspection capabilities to run on the host. If so, what we are > > trying to do is to isolate the application into its own VM. This is why > > we use vSock to communicate with the host. > > Communication alone does not require isolation. Interpretation of what > can be sees may benefit from that, though. > > > If instead you are suggesting we integrate the kernel-side API into the > > debug framework, I see no problem with that right now. We'll need a bit > > more time to look into what that entails. > > The hypervisor process could terminate your link, providing that other > VM the introspection access. Or you even have a gdb-speaking process > running on the host, just reusing the existing gdbstub of QEMU. Just > wild ideas, I didn't look into details, and you may further elaborate on > your requirements. > > > > Also, this looks like as if it can easily work against the userspace > > > part of the hypervisor - bad idea. > > > > The way it is implemented right now, it works behind its back (qemu > > specifically), in that it intercepts and handles certain events before > > it. It should be possible to put some code in qemu and move part of the > > logic in it, but we're trying hard to avoid context switches as guest > > exits themselves are currently quite expensive. The experience comes > > from working with Xen. We have no benchmark numbers for KVM. > > Even if you don't run the hot-paths through QEMU, you should inform it > about what is going on. Starting/stopping behind its back it bad, so is > fiddling with guest stats. Keep in mind that your introspection VM is, > well, just another VM that could be scheduled, suspended or even > migrated away, and then you leave the original VM rather clueless behind. > > Migration is actually an interesting topic of its own... On this topic specifically, a complete security solution using guest introspection interfaces will need to tap into the management application and be notified when a migration is taking place. The reason being, and I'm talking from our perspective only, that the introspected guest is patched and those patches „talk” with the security solution. A guest that reaches the destination in this state will remain in limbo and (so far) can only be recovered through a reboot. > > > API/ABI documentation is missing. > > > > Understood. We will try to put something together in the coming weeks. > > > > > Did you check if the concept is portable to other architectures? Another > > > reason to try hard to reuse existing interfaces. > > > > The API that we propose is the result of work done for x86 and ARM, > > though for the latter we're still working on a PoC. It's fairly > > generic. > > > > > Last but not least: LGPL slipped into your kernel parts - the kernel is GPL. > > > > Good catch! We'll make the adjustment. > > > > Thank-you! > > > > BTW, I remember that there was/is some larger research community > interested in such kind of interfaces as well, or they even have their > own out-of-tree tooling. Hope they will speak up and review your > proposals as well so that the result is of general use. -- Mihai Donțu