From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44534) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WPcqW-0003mh-Cd for qemu-devel@nongnu.org; Mon, 17 Mar 2014 15:05:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WPcqP-0001d5-3O for qemu-devel@nongnu.org; Mon, 17 Mar 2014 15:05:12 -0400 Received: from cantor2.suse.de ([195.135.220.15]:38162 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WPcqO-0001ba-U0 for qemu-devel@nongnu.org; Mon, 17 Mar 2014 15:05:05 -0400 Message-ID: <5327475F.3030704@suse.de> Date: Mon, 17 Mar 2014 20:05:03 +0100 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 References: <53270678.8090901@redhat.com> <53270B6D.6030602@redhat.com> In-Reply-To: <53270B6D.6030602@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] virtio device error reporting best practice? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Laszlo Ersek Cc: Peter Maydell , Dave Airlie , "qemu-devel@nongnu.org" , Seiji Aguchi 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 wrote: >>> On 03/17/14 07:02, Dave Airlie wrote: >>>> The main reason I'm considering this stuff is for security reasons i= f >>>> 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. >=20 > 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? >=20 > 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 --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=C3=B6rffer; HRB 16746 AG N=C3=BC= rnberg