On Mar 1, 2011 7:07 AM, "Dor Laor" <address@hidden
> On 02/28/2011 07:44 PM, Anthony Liguori wrote:
>> On Feb 28, 2011 10:44 AM, "Jes Sorensen" <address@hidden
>> <mailto:address@hidden <mailto:address@hidden>>>
>> > 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
>> > I wrote up a summary of my thoughts on this to try to cover the
>> > issues. Feedback welcome and hopefully we can continue the
>> > a future call - maybe next week?
>> > I would like to be part of the discussion, but it's a public
>> > 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
>> built in, making code optionally built in or loadable as a separate
>> executable that is automatically launched, or making code always
>> outside the main executable?
>> I'm very nervous about having a large number of daemons necessary
>> QEMU. I think a reasonable approach would be a single front-end
> 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.
Spice is the logical place to start, no? It's the largest single
dependency we have and it does some scary things with qemu_mutex. I
would use spice as a way to prove the concept.