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

["Andreas Färber" <afaerber@suse.de>]

Am 17.03.2014 15:49, schrieb Laszlo Ersek:
> 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?
> 
> Exit(1) is considered guest crash.

I disagree. QEMU has a panic state/event for guest crashes, used by
pvpanic and s390x, which does not exit() the process.

If it's a state that the guest should not be able to trigger, then
assertions are better than exit() since they allow to use gdb for
investigating the origin.

exit(1) should correspond to an unrecoverable issue on the host, such as
ioctl failure, not a fault by the guest. And yes, there's quite a few of
them around just like there's still tons of fprintf()s around. Error
handling and reporting is a constant pain point...

Regards,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg