[Qemu-devel] x86 amd64 singlestepping bug through syscall instruction

[Qemu-devel] x86 amd64 singlestepping bug through syscall instruction

[Rudolf Marek]

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

[Qemu-devel] x86 amd64 singlestepping bug through syscall instruction

[Rudolf Marek]

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

Re: [Qemu-devel] x86 amd64 singlestepping bug through syscall instruction

[Rudolf Marek]

Hi all,

It seems this problem was not picked by anyone from QEMU community. Is there 
other way to report this bug?

Thanks
Rudolf

-- 
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