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
