From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HSfbV-0008TT-AI for qemu-devel@nongnu.org; Sat, 17 Mar 2007 16:34:17 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HSfbT-0008TE-UQ for qemu-devel@nongnu.org; Sat, 17 Mar 2007 16:34:17 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HSfbT-0008TB-Nk for qemu-devel@nongnu.org; Sat, 17 Mar 2007 15:34:15 -0500 Received: from mail.codesourcery.com ([65.74.133.4]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1HSfaC-0006vw-UF for qemu-devel@nongnu.org; Sat, 17 Mar 2007 16:32:57 -0400 From: Paul Brook Subject: Re: [Qemu-devel] [Bug] MIPS code fails at branch instruction Date: Sat, 17 Mar 2007 20:32:51 +0000 References: <45FB245C.2010900@mail.berlios.de> <20070317143106.GF25863@networkno.de> <45FC3A07.3070302@weilnetz.de> In-Reply-To: <45FC3A07.3070302@weilnetz.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200703172032.52010.paul@codesourcery.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Stefan Weil > >> So an emulation has several options: > >> > >> 1. Show undefined behaviour (this is what it does today). > >> 2. Emulate the behaviour of existing CPUs as far as possible. > >> As different CPUs behave different, this must depend on the > >> current CPU. > >> 3. Display an error message. > > > > (3) is bad, as it amounts to a DoS. > > DoS = Denial of Service? Then (1) is some kind of DoS, because QEMU hangs > with code which works on real hardware. I don't understand why an > error message (something printed to stdout or stderr like other boot > messages of QEMU) amounts to a DoS. It's not the same thing at all. In both cases buggy code crashes. I expect this could also happen on a fair proportion of real MIPS hardware. It may even happen on AR7 hardware is a interrupt or fault happens to trigger at the wrong time. With (1) the buggy program crashes, and the rest of the machine keeps going. With (3) an unprivileged user can effectively bring the whole machine down just by executing invalid code sequences. Paul