Re: [Qemu-devel] virtio device error reporting best practice?

[Kevin Wolf <kwolf@redhat.com>]

Am 17.03.2014 um 15:49 hat Laszlo Ersek geschrieben:
> On 03/17/14 15:40, Peter Maydell wrote:
> > On 17 March 2014 14:28, Laszlo Ersek <lersek@redhat.com> wrote:
> >> On 03/17/14 07:02, Dave Airlie wrote:
> >>> The main reason I'm considering this stuff is for security reasons if
> >>> the guest asks for something really illegal or crazy what should the
> >>> expected behaviour of the host be? (at least secure I know that).
> >>
> >> exit(1).
> > 
> > No thanks -- the guest should never be able to cause QEMU
> > to exit (in an ideal world). Use
> >    qemu_log_mask(LOG_GUEST_ERROR, ...)
> > and continue.
> 
> How do you continue with a garbled virtio ring? Say you detect an error
> that would cause integer overflow or buffer overflow in the host, a
> clear virtio protocol violation etc. Error reporting is just one thing
> -- what are the semantics of continuing?

Stop processing the ring until the guest resets it.

You don't want a buggy guest driver to crash the whole system
needlessly, it's good enough if the one device doesn't work any more.

Also, consider that a qemu process can be doing entirely different
things, like executing block jobs or hosting the builtin NBD server (and
being a QMP server, too), and you don't want to allow the guest to
interrupt this.

As far as I can tell, exit() also doesn't do bdrv_close_all(), so it's
an unclean shutdown that may leave images in an inconsistent state.

And this is only the block layer perspective on it. Not sure about how
well other subsystems cope with unclean shutdowns.

Not to forget that a user will be surprised if his qemu process is
suddenly gone without him intentionally shutting down the VM. An error
message indicating the failing device inside the guest is much nicer.


tl;dr: exit() calls in hw/ do exist, but these are longstanding bugs,
not examples to follow.

Kevin