Re: [Qemu-devel] Coding style for errors

From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Markus Armbruster <armbru@redhat.com>,
	qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Coding style for errors
Date: Fri, 23 Oct 2015 18:02:41 +0100	[thread overview]
Message-ID: <20151023170240.GG2711@work-vm> (raw)
In-Reply-To: <20151023160138.GJ5977@stefanha-x1.localdomain>

* Stefan Hajnoczi (stefanha@gmail.com) wrote:
> 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'd add that if the QEMU detects that the guest has done something really
stupid and that the device is now dead until reset, then it should
output something diagnostic into the logs; otherwise everyone just
blames qemu and says it stopped (and I mean log, not trace - I want
to see this in the type of thing a users sends so that we have some
idea where to look immediately).

Dave
> 
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK