On Fri, Jun 16, 2017 at 05:34:48PM +0200, Jan Kiszka wrote:
> 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.
QEMU userspace can provide the interface on an AF_VSOCK listen socket.
Here is a rough idea:
qemu --chardev socket,id=chardev0,type=vsock,port=1234,server,nowait \
--guest-introspection chardev=chardev0,allowed-cids=10
Since it uses a chardev this means the guest introspection API is also
available via UNIX domain sockets to local applications, etc.
In this example only CID 10 has access to the guest introspection API.
Connections from other VMs will be dropped.
Stefan
Attachment:
signature.asc
Description: PGP signature
