[Top][All Lists]

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

Re: [Qemu-devel] QEMU: Discussion of separating core functionality vs su

From: Dor Laor
Subject: Re: [Qemu-devel] QEMU: Discussion of separating core functionality vs supportive features
Date: Tue, 01 Mar 2011 14:07:12 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Lightning/1.0b3pre Thunderbird/3.1.7 ThunderBrowse/3.3.4

On 02/28/2011 07:44 PM, Anthony Liguori wrote:

On Feb 28, 2011 10:44 AM, "Jes Sorensen" <address@hidden
<mailto:address@hidden>> wrote:
 > Hi,
 > On last week's call we discussed the issue of splitting non core
 > features of QEMU into it's own process to reduce the security risks etc.
 > I wrote up a summary of my thoughts on this to try to cover the various
 > issues. Feedback welcome and hopefully we can continue the discussion on
 > a future call - maybe next week?
 > I would like to be part of the discussion, but it's a public holiday
 > here March 1st, so I won't be on that call.
 > Cheers,
 > Jes
 > Separating host-side virtagent and other tasks from core QEMU
 > =============================================================
 > To improve auditing of the core QEMU code, it would be ideal to be
 > able to separate the core QEMU functionality from utility
 > functionality by  moving the utility functionality into its own
 > process. This process will be referred to as the QEMU client below.

Separating as in moving code outside of qemu.git, making code optionally
built in, making code optionally built in or loadable as a separate
executable that is automatically launched, or making code always built
outside the main executable?

I'm very nervous about having a large number of daemons necessary to run
QEMU.  I think a reasonable approach would be a single front-end daemond.

s/daemon/son processes/
Qemu is the one that should spawn them and they should be transparent from the management. This way running qemu stays the same and qemu just need to add the logic to get a SIGCHILD and potentially re-execute an dead son process.

Once QAPI is merged, there is a very incremental approach we can take
for this sort of work.  Take your favorite subsystem (like gdbstub or
SDL) and make it only use QMP apis.  Once we're only using QMP
internally in a subsystem, then building it out of the main QEMU and
using libqmp should be fairly easy.


Anthony Liguori

 > Components which are candidates for moving out of QEMU include:
 >  - virtagent
 >  - vnc server (and other graphical displays such as SDL, spice and
 >   curses)
 >  - human monitor

These are all much harder than they may seem.  There's a ton of QMP
functions that would be needed before we could even try to do this.

 > The idea is to have QEMU launch as a daemon, and then allow for one of
 > more client processes to connect to it. These will then offer the
 > various services. The main issue to discuss is how to handle various
 > state information, reconnects, and migration.
 > Security
 > ========
 > The primary reason for this discussion is security, however there are
 > other benefits from this split, as will be mentioned below. During a
 > demo of virtagent I hit a case where a bug in the agent command
 > handling code caused a crash of the host QEMU process. While it is
 > probably a simple bug, it shows how adding more complexity to the QEMU
 > process increases the risk of adding security problems that could
 > potentially be exploited by a hostile guest.
 > By splitting non core functionality into a QEMU client process, the
 > host process will be isolated from a large number of potential
 > security problems, ie. in case a client process is killed or crashes,
 > it should not affect the main QEMU process. In addition it makes it
 > easier to audit the core QEMU functionality.
 > virtagent
 > =========
 > In short virtagent provides a set of simple commands, most of which
 > do not have state associated with them. These include shutdown, ping,
 > fsfreeze/fsthaw, etc. Other commands might be multi-stage commands
 > which could fail if the client is disconnected from the daemon while
 > the command is in progress. These include copy-paste and file copy.
 > vnc server
 > ==========
 > The vnc server simply needs a connection to the video memory of the
 > QEMU process, video mode state, as well as channels for sending
 > keyboard and mouse events. It is stateless by nature and supports
 > reconnects. This applies to the other graphical display engines (SDL,
 > spice, and curses) as well.
 > Human monitor
 > =============
 > The human monitor is effectively stateless. It issues commands and
 > prints the result. There is no state in the monitor and it can be
 > built directly on top of QMP.
 > An additional benefit here is that it would allow for multiple
 > monitors.
 > Disconnects
 > ===========
 > It must be possible for a client process getting killed or
 > disconnected from the QEMU process, in which case is should be
 > possible to launch a new client that connects to the QEMU
 > process. In this case, commands needs to be provided allowing the
 > client process to query the QEMU process and virtagent for current
 > state information. In-progress commands may fail, and will need to be
 > re-run, such as copy-paste and and file copy. However neither of
 > these are vital commands and a re-run of such commands is acceptable
 > behavior.
 > Migration
 > =========
 > Given that migration moves the guest to a new QEMU process, normally
 > on a different host, any connection from management tools to the
 > monitor, QMP sockets, virtio-serial, etc. require a new connection
 > through the new QEMU process. Stateless connections, such as the
 > monitor, QMP and the vnc-server handles reconnects without problems,
 > and should not have any issues during migration that are different
 > from the issues in the current implementation.
 > The main issues causing problems are stateful events such as
 > copy-paste, which is handled via a guest agent. The copy-paste problem
 > can be handled by blocking copy-paste operations during migration,
 > until the guest agent is reachable through the QEMU process on the new
 > host. This does mean that copy-paste can block or fail temporarily
 > (depending on whether is it implemented as -EBUSY or just blocks),
 > however it is not a mission critical feature, and it can also block or
 > fail temporarily during normal operation on a non virtual system.
 > Per the nature of the operation, a file copy via a guest agent is
 > going to fail and will have to be restarted after migration has
 > completed, in case it does not complete. This is again a non critical
 > feature and requiring a restart is acceptable.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]