Re: [RFC PATCH 00/19] Guest introspection

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jun 20, 2017 at 05:58:41PM +0300, alazar@xxxxxxxxxxxxxxx wrote:
> On Mon, 19 Jun 2017 10:39:28 +0100, Stefan Hajnoczi <stefanha@xxxxxxxxx> 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: signature.asc
Description: PGP signature


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux