Stefan Weil wrote: > 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.
This is a bug in qemu, since it doesn't match CPU behaviour. While the architecture spec claims UNPREDICTABLE, such a code sequence shouldn't impede other processes on the same CPU. Throwing an RI exception should suffice for the general case (i.e. not AR7). > 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. Sorry, but I missed the "well defined". What does the jump in the branch delay slot exactly _do_ now? Where does the PC point to when it was a conditional branch which wasn't taken? [snip] > * 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) Agreed on that, since it is debug output which is only written when asked for. Thiemo _______________________________________________ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
