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. 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. > 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. > 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! -- Mihai Donțu
