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.ma...@sysgo.com

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

Reply via email to