qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Re: [PATCH] whitelist host virtio networking features [


From: Jamie Lokier
Subject: Re: [Qemu-devel] Re: [PATCH] whitelist host virtio networking features [was Re: qemu-kvm-0.11 regression, crashes on older ...]
Date: Thu, 5 Nov 2009 05:06:25 +0000
User-agent: Mutt/1.5.13 (2006-08-11)

Anthony Liguori wrote:
> Dustin Kirkland wrote:
> >On Mon, 2009-11-02 at 12:55 -0600, Anthony Liguori wrote:
> >  
> >>They can exit qemu via an ACPI shutdown.  I don't see the difference.
> >>    
> >
> >An ACPI shutdown is triggered by an authenticated user inside of the
> >guest.
> >
> >The present exit is triggered by any other anonymous user on the
> >network, with the ability to send a lot of packets very quickly to the
> >VM guest.  The guest isn't able to handle this properly (and rightly
> >that guest's kernel should be fixed).  But I do see a difference.
> >  
> 
> Well the problem is triggered by the guest kernel writing garbage to 
> virtio-net's backend.  That's why we're suggesting it's really a guest 
> kernel issue.
> 
> If the guest kernel writes something bad to qemu, we're may kill the 
> guest.  That's not a qemu bug, it's the designed behavior.

I'm ok with killing the guest, but think the right behaviour is
whatever the user's configured to happen when the guest is killed, in
the same way that ACPI shutdown does not shutdown if -no-shutdown is
used, and you can debug a guest which does that.

A guest writing garbage to virtio-net should not be able to use it to
escape being debugged :-)

How can a manager program determine if the exit is due to intentional
shutdown or crashing guest?

I'd be inclined to make those "exit() called from the device
emulation" cases do whatever -watchdog-action says, if the watchdog is
enabled.  With a great big log message.

-- Jamie




reply via email to

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