Bug 503955

+++ This bug was initially created as a clone of Bug #489654 +++

So the idea is the following:
* Motivation
    - Some (many) of qemu's features are not officially supported.
        - We cannot fix them in time
        - It is also problematic to block them in the code and some users might want to use tech preview of them.
    - Also qemu is a complex beast. If controlled directly without vdsm/libvirt it can lead
      to serious problems like corruption is disk caching is used (write back), ungraceful shutdown of the vm,
      running with the wrong -drive/rtc-time-drift, etc parameters.
* Proposed solution
    - Qemu will only run if supplied with the flag -experimental or -authorized_mgmt_interface
        - -experimental would be for non production use.
       - -authorized_mgmt_interface would be used for libvirt, vdsm and any authorized solution
         by 3rd party that we reviewed.
    - Libvirt/vdsm/vdc will forbid the usage of non official features like:
       - scsi
       - usb pass through
       - Userspace irqchip
       - qcow1/vmdk (will be allowed to convert through qemu-img)
       - etc

Closing bugs 484343, 485219 and replace with this one.

--- Additional comment from dlaor on 2009-03-11 04:08:36 EDT ---

*** Bug 485219 has been marked as a duplicate of this bug. ***

--- Additional comment from dlaor on 2009-03-11 04:08:47 EDT ---

*** Bug 484343 has been marked as a duplicate of this bug. ***

--- Additional comment from dlaor on 2009-03-16 19:05:53 EDT ---

Following the thread to disable qemu/kvm features, here is a list of
unsupported/should-be-blocked features. It is relevant only to libvirt/vdsm
invocations (probably libvirt does not use most of the cmds below).
Qemu from cmdline is not supported at all.

    - scsi
    - qcow1/vmdk/vhd (not qemu-img for convert)
    - usb pass through
    - hpet
    --enable-nesting
    - huge-pages (mem path)
    --virtioconsole
-----------
Actually we probably need to block there:
    - es1370 sound device ( ac97 is much better)
       - It stops playing if 2 streams where using it.
    - All the none default -cpu options
    - -M machine flag
    - no-graphics
    - stg-vga mode
    - smb
    - -kernel

--- Additional comment from rjones on 2009-03-17 04:25:02 EDT ---

I would like to keep -nographic and -kernel options.

--- Additional comment from berrange on 2009-03-17 05:49:38 EDT ---

libvirt *always* sets -M machine flag, and will also use "-cpu qemu32" to force a 64-bit emulator into 32-bit mode.

-nographics is perfectly acceptable if you have a serial console and libvirt will use it.

-kernel, -initrd & -append are the *strongly recommended* way to provision Linux guests because you can boot straight into the installer with install URL pre-populated.

-std-vga mode is not currently used, but will be in next libvirt release.

-smb is crazy & shouldn't be used - SELinux ought to block its use too.

libvirt happily exposes USB passthrough and I know of people succesfully and happily using it.

hpet, enable-nesting, huge-pages & virtioconsole are not used in libvirt so no prboelm with those at this time.  NB, the next release of libvirt will likely include virtioconsole support because it is very useful to have a virtio based text console we can enable by default in all guest OS - its one of the things people often ask us for after experiancing Xen PV.

--- Additional comment from rjones on 2009-03-17 13:05:06 EDT ---

Created an attachment (id=335562)
qemu-no-qcow2-snapshots patch

For discussion only, how about something like that patch above,
that allows qemu to be configured to disable a dangerous feature
(in this case qcow2 snapshots)?

Apart from qcow2 snapshots, are there other genuinely dangerous
features?

--- Additional comment from berrange on 2009-04-28 08:14:31 EDT ---

This patch looks good to me. The only thing would be to block the corresponding 'savevm' and 'loadvm' monitor commands, since they're unusable without qcow2 snapshots (or equiv).

Probably compiling without the -smb / SAMBA support would be desirable from a security POV.

--- Additional comment from dlaor on 2009-04-30 07:13:41 EDT ---

We're fixing the savevm bug

Eduardo, what about compiling out the -smb option?

--- Additional comment from dlaor on 2009-04-30 08:38:40 EDT ---

Patch sent to virtualist

--- Additional comment from markmc on 2009-05-27 05:28:33 EDT ---

*** Bug 502586 has been marked as a duplicate of this bug. ***

--- Additional comment from markmc on 2009-05-27 05:33:15 EDT ---

As per bug #502586, currently discussed solution is:

 1) Move /usr/bin/qemu-kvm to /usr/libexec/qemu-kvm

 2) Make /usr/bin/qemu-kvm a script which checks whether the requested features
    are supported and, if not, warns the user

Note, it's not mentioned anywhere else in this bug, but TCG should be included in this - and in order to do that, the script needs to warn if KVM is not available on the host

--- Additional comment from rjones on 2009-05-27 05:46:06 EDT ---

Can we make sure this script does 'exec /usr/libexec/qemu-kvm ...'
as the last line?  The reason is that if it just runs qemu-kvm
(forked from the script's shell) then you can't easily send
signals to the qemu-kvm process.  You end up sending them to
the shell script's shell, which doesn't pass them down.  This
is particularly important for libguestfs, but I guess libvirt
too if it runs the script instead of the direct executable.

--- Additional comment from markmc on 2009-05-27 06:03:56 EDT ---

(In reply to comment #12)
> Can we make sure this script does 'exec /usr/libexec/qemu-kvm ...'
> as the last line?

Definitely, yes.

> but I guess libvirt too if it runs the script instead of the direct 
> executable.

I think libvirt should use /usr/libexec/qemu-kvm directly - that's kind of the point, we're almost trying to deprecate /usr/bin/qemu-kvm and make it clear that /usr/libexec/qemu-kvm should only be run by e.g. libvirt or libguestfs, not directly by users