Re: [Qemu-devel] Coding style for errors

[Stefan Hajnoczi]

On Fri, Oct 23, 2015 at 07:34:50PM +0200, Lluís Vilanova wrote:
> Stefan Hajnoczi writes:
> 
> > On Thu, Oct 22, 2015 at 03:30:34PM +0200, Lluís Vilanova wrote:
> >> Markus Armbruster writes:
> >> 
> >> > Lluís Vilanova <address@hidden> 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.

It needs to be close to the text you are adding since your text
mentioned immediate exits and abort(3).  People should be aware that
using those approaches can introduce security problems.

Stefan