On 2017-06-16 17:18, Mihai Donțu wrote: > Hi Jan, > > 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... > >> 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. Jan -- Siemens AG, Corporate Technology, CT RDA ITP SES-DE Corporate Competence Center Embedded Linux
