Re: [RFC PATCH 00/19] Guest introspection

["Mihai Donțu" <mdontu@bitdefender.com>]

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