Re: [RFC PATCH 00/19] Guest introspection

From: Stefan Hajnoczi <stefanha@gmail.com>
To: alazar@bitdefender.com
Cc: "Jan Kiszka" <jan.kiszka@siemens.com>,
	"Mihai Dontu" <mdontu@bitdefender.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Radim Krčmář" <rkrcmar@redhat.com>,
	kvm@vger.kernel.org
Subject: Re: [RFC PATCH 00/19] Guest introspection
Date: Wed, 21 Jun 2017 12:04:07 +0100	[thread overview]
Message-ID: <20170621110407.GE16183@stefanha-x1.localdomain> (raw)
In-Reply-To: <1497970721.139b8aD.12149@host>

[-- Attachment #1: Type: text/plain, Size: 2888 bytes --]

On Tue, Jun 20, 2017 at 05:58:41PM +0300, alazar@bitdefender.com wrote:
> On Mon, 19 Jun 2017 10:39:28 +0100, Stefan Hajnoczi <stefanha@gmail.com> wrote:
> > On Fri, Jun 16, 2017 at 05:34:48PM +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:
> Moving the vsock to userland will change this:
> 
>                                      -----------------------------
>                  /----- /dev/kvm -->| new_tool (guest on/off/list)|<-- vsock -->\
>                  |                   -----------------------------              |
>                  |                                                              |
>  ----------------v-                  -----------------------------              |
> |                  |<-- /dev/kvm -->| qemu        VM1             |<-- vsock -->|
> |                  |                |-------                      |             |
> |                  |                | Linux |                     |             |
> | KVM              |                 -----------------------------              |
> |                  |<-- /dev/kvm -->| qemu        VM2             |<-- vsock -->|
> |                  |                |---------                    |             |
> |                  |                | Windows |                   |             |
> |                  |                 -----------------------------              |
> |                  |<-- /dev/kvm -->| qemu        VM3      /----->|<-- vsock -->/
> |           -------|                |---------------------v----   |
> |          | kvmi  |                | guest introspection tool |  |
>  ------------------                  -----------------------------
> 
> There will be a need for a new tool (and/or libvirt modified) to get
> the guest events (on/off/list) and change the VM1, VM2 invocations (to
> make them connect with the introspection tool). This might also be a
> problem with products having the host locked down (eg. RHEV).

I think that is desirable in fact.  kvmi should be an explicit feature
that is controlled by the management tools.  This way the policy can be
decided by the administrator.  Libvirt changes will be necessary.

Some KVM users do not want kvmi.  Think of the new memory encryption
hardware support that is coming out - the point is to prevent the
hypervisor from looking inside the VMs!  What you are doing is the
opposite of that.

Also, anyone who doesn't actually use kvmi would be better of disabling
the feature to minimize the attack surface.

I'm not sure if kvmi should be inside the QEMU process though.  If a
guest is compromised and escapes into QEMU, then kvmi is defeated.  It
may be a better design for kvmi to be an isolated component.

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]