qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Rudolf Marek <rudolf.marek@sysgo.com>
To: qemu-devel@nongnu.org
Cc: Andreas Gustafsson <gson@gson.org>
Subject: [Qemu-devel] x86 amd64 singlestepping bug through syscall instruction
Date: Thu, 8 Oct 2015 15:16:48 +0200	[thread overview]
Message-ID: <56166CC0.1000600@sysgo.com> (raw)

Hi all,

I was told on IRC to use this ML to report the following bug.

It seems that there is something wrong with QEMU with respect to handle the 
singlestepping and AMD64 syscall instruction.

The AMD "syscall" instruction will clear defined flag in the FMASK MSR. Normally 
the TF flag is set there, so the first instruction when kernel is entered after 
syscall won't cause single step exception in the kernel.

The observed scenario is a unhandled singlestep fault in the kernel or host 
reboot or QEMU crash.

The possible way how to reproduce it is to single step through any function 
which does "syscall" instruction. After syscall is entered QEMU will trigger 
singlestepping exception in the kernel despite that the TF is set in FMASK MSR. 
Real HW behaves correctly and does not trigger this exception.

What is interesting is that I was not able to trigger it if I just enabled TF 
and did the syscall instruction, perhaps for this bug is somewhat important to 
have TF set for previous few instruction.

I have stumbled to this problem while working with our custom OS. However after 
some googling I found out that the NetBSD guys (CCed) are having very similar 
problem and I asked them to prepare a ISO image where the problem ends with QEMU 
SIGSEGV or host reboot.

You can check original report here:
http://gnats.netbsd.org/49603

The way how to reproduce the problem with NetBSD is pasted to the end of this email.

Unfortunately all I was able to do is to verify that QEMU has a code to clear 
RFLAGS based on FMASK MSR. Any other help is very appreciated.

Thanks,
Rudolf

> Hi Rudolf,
>
> Here's a more Linux-friendly recipe for reproducing the bug.  A couple of
> gigabytes of of free disk space are needed for the uncompressed OS image.
>
>    wget http://www.gson.org/bugs/qemu/NetBSD-amd64-2015.08.01.16.18.47-com0.img.gz
>    gunzip NetBSD-amd64-2015.08.01.16.18.47-com0.img.gz
>    qemu-system-x86_64 -nographic -snapshot NetBSD-amd64-2015.08.01.16.18.47-com0.img
>    (wait for the qemu guest to boot to a login prompt)
>    (log in as root; there is no password)
>    gdb /bin/sync
>    break sync
>    run
>    stepi
>    stepi
>    stepi
>    (The qemu guest will either instantly reboot or hang, or qemu will segfault)
>    (On real hardware, you just get another gdb prompt, and gdb is still responding)

-- 
S přátelským pozdravem / Best regards / Mit freundlichen Grüßen

Ing. Rudolf Marek
SYSGO s.r.o.
Zelený pruh 99
CZ-14800 Praha 4
Phone: +420 222138 111, +49 6136 9948 111
Fax: +420 296374890, +49 6136 9948 1 111
rudolf.marek@sysgo.com

http://www.sysgo.com | http://www.elinos.com | http://www.pikeos.com

             reply	other threads:[~2015-10-08 13:16 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-08 13:16 Rudolf Marek [this message]
  -- strict thread matches above, loose matches on Subject: below --
2015-10-08 14:49 [Qemu-devel] x86 amd64 singlestepping bug through syscall instruction Rudolf Marek
2015-10-20 12:46 ` Rudolf Marek

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=56166CC0.1000600@sysgo.com \
    --to=rudolf.marek@sysgo.com \
    --cc=gson@gson.org \
    --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).