Re: [Qemu-devel] Coding style for errors

["Lluís Vilanova" <vilanova@ac.upc.edu>]

Stefan Hajnoczi writes:

> On Thu, Oct 22, 2015 at 03:30:34PM +0200, Lluís Vilanova wrote:
>> Markus Armbruster writes:
>> 
>> > Lluís Vilanova <vilanova@ac.upc.edu> writes:
>> [...]
>> >> So, is there any agreement on what should be used? If so, could that please be
>> >> added to CODING_STYLE?
>> 
>> > I think HACKING would be a better fit.
>> 
>> What about this? (at the end of HACKING) Feel free to add references to other
>> functions you think are important. I'll send a patch once we agree on the text.
>> 
>> Cheers,
>> Lluis
>> 
>> 
>> 7. Error reporting

> Guest-triggerable errors should not terminate QEMU.  There are plently
> of examples where this is violated today but there are good reasons to
> stop doing it.

> Denial of service cases:

> 1. If a guest userspace application is somehow able to trigger a QEMU
>    abort, then an unprivileged guest application is able to bring down
>    the whole VM.

> 2. If nested virtualization is used, it's possible that a nested guest
>    can kill its parent, and thereby also kill its sibling VMs.

> 3. abort(3) is heavyweight if crash reporting/coredumps are enabled.  A
>    broken/malicious guest that keeps triggering abort(3) can be a big
>    nuisance that consumes memory, disk, and CPU resources.

> Emulated hardware should behave the same way that physical hardware
> behaves.  This may mean that the device becomes non-operational (ignores
> or fails new requests) until the next hard or soft reset.

I'm not sure how this should be translated into the form of error-reporting
guidelines.


Thanks,
  Lluis

-- 
"And it's much the same thing with knowledge, for whenever you learn
something new, the whole world becomes that much richer."
-- The Princess of Pure Reason, as told by Norton Juster in The Phantom
Tollbooth