qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Stefan Weil <weil@mail.berlios.de>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [Bug] [Patch] MIPS code fails at branch instruction
Date: Mon, 19 Mar 2007 22:04:00 +0100	[thread overview]
Message-ID: <45FEFAC0.4060901@mail.berlios.de> (raw)
In-Reply-To: <200703172032.52010.paul@codesourcery.com>

[-- Attachment #1: Type: text/plain, Size: 2635 bytes --]

Thank you, Paul, for your explanation which clarified Thiemo's statement.

I now checked how my published test code could contribute to a DoS attack.

Current QEMU HEAD:

* The code "hangs" as I wrote before. This is from a user's point of view.
  "Hanging" means, that the test process runs in an infinite loop using any
  CPU time it can get in the virtual machine. QEMU uses all available
  CPU time from the host CPU.
  With single stepping enabled or in the debugger, the test code won't
  hang but give a random result.

Patched QEMU HEAD (see appended patch file):

* The code works in a well defined way. An optional message in the log file
  will show the faulty statement. It won't amount to a DoS because it
  is disabled by default.
  Using single stepping, the test code's result remains the same.

So the patch improves the situation. Although it does not model the real
behaviour of an AR7 cpu, it solved my problem with a Zyxel firmware.
Maybe you can apply at least part of it or even improve and extend it to
other branch operations.

Thank you
Stefan


Details of the patch

* show optional message when any branch bits in hflags are already set
  before a branch instruction is generated (so we have a branch in the
  delay slot)

* mask branch bits before setting new ones (implemented only for the jr
  statement because this was the one I needed and examined)
  - this part could be improved

* make gen_intermediate_code_internal static (might improve compiler
  optimizations and is completely unrelated to the other two changes)



Paul Brook wrote:
>>>> 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

[-- Attachment #2: translate.patch --]
[-- Type: text/x-diff, Size: 1280 bytes --]

Index: target-mips/translate.c
===================================================================
RCS file: /sources/qemu/qemu/target-mips/translate.c,v
retrieving revision 1.37
diff -u -b -B -u -r1.37 translate.c
--- target-mips/translate.c	18 Mar 2007 00:30:29 -0000	1.37
+++ target-mips/translate.c	19 Mar 2007 20:26:31 -0000
@@ -1371,6 +1371,13 @@
     target_ulong btarget;
     int blink, bcond;
 
+    if (ctx->hflags & MIPS_HFLAG_BMASK) {
+        if (loglevel & CPU_LOG_TB_IN_ASM) {
+            fprintf(logfile,
+                    "undefined branch in delay slot at pc 0x%08x\n", ctx->pc);
+        }
+    }
+
     btarget = -1;
     blink = 0;
     bcond = 0;
@@ -1480,7 +1487,7 @@
             MIPS_DEBUG("jal %08x", btarget);
             break;
         case OPC_JR:
-            ctx->hflags |= MIPS_HFLAG_BR;
+            ctx->hflags = ((ctx->hflags & ~MIPS_HFLAG_BMASK) | MIPS_HFLAG_BR);
             MIPS_DEBUG("jr %s", regnames[rs]);
             break;
         case OPC_JALR:
@@ -4999,7 +5006,7 @@
     }
 }
 
-int gen_intermediate_code_internal (CPUState *env, TranslationBlock *tb,
+static int gen_intermediate_code_internal (CPUState *env, TranslationBlock *tb,
                                     int search_pc)
 {
     DisasContext ctx, *ctxp = &ctx;

  reply	other threads:[~2007-03-19 21:05 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-16 23:12 [Qemu-devel] [Bug] MIPS code fails at branch instruction Stefan Weil
2007-03-17  0:46 ` Thiemo Seufer
2007-03-17 11:37   ` Stefan Weil
2007-03-17 14:31     ` Thiemo Seufer
2007-03-17 18:57       ` Stefan Weil
2007-03-17 20:32         ` Paul Brook
2007-03-19 21:04           ` Stefan Weil [this message]
2007-03-19 21:34             ` [Qemu-devel] [Bug] [Patch] " Thiemo Seufer
2007-03-19 22:34               ` Thiemo Seufer
2007-03-20  7:54                 ` Alexander Voropay
2007-03-20  9:51                   ` Thiemo Seufer
2007-03-20 18:27                 ` Stefan Weil
2007-03-25  0:22                   ` Thiemo Seufer
2007-03-25  1:43                     ` Aurelien Jarno
2007-03-25 12:51                       ` Stuart Brady
2007-03-25 16:26                         ` Thiemo Seufer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=45FEFAC0.4060901@mail.berlios.de \
    --to=weil@mail.berlios.de \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).