qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] [Bug 1645355] [NEW] x86: singlestepping through SYSCALL ins


From: Rudolf Marek
Subject: [Qemu-devel] [Bug 1645355] [NEW] x86: singlestepping through SYSCALL instruction causes exception in kernelspace
Date: Mon, 28 Nov 2016 15:05:52 -0000

Public bug reported:

Hi,

The bug was originally reported [1] and [2] here. There is a problem
inside QEMU with singlestepping from userspace until SYSCALL instruction
is reached. The OS has in FMASK TF bit set, therefore there should be no
singlestepping exception when transitioning to kernelmode. But, inside
QEMU there is (TF is clear seems FMASK is applied). See below for
further details.

The reproducer is available at [2].

Here is the original text with some minor clarifications:

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 (in userspace) 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. 

Thanks
Rudolf

[1] https://lists.gnu.org/archive/html/qemu-devel/2015-10/msg02289.html
[2] http://gnats.netbsd.org/49603

** Affects: qemu
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1645355

Title:
  x86: singlestepping through SYSCALL instruction causes exception in
  kernelspace

Status in QEMU:
  New

Bug description:
  Hi,

  The bug was originally reported [1] and [2] here. There is a problem
  inside QEMU with singlestepping from userspace until SYSCALL
  instruction is reached. The OS has in FMASK TF bit set, therefore
  there should be no singlestepping exception when transitioning to
  kernelmode. But, inside QEMU there is (TF is clear seems FMASK is
  applied). See below for further details.

  The reproducer is available at [2].

  Here is the original text with some minor clarifications:

  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 (in userspace) 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. 

  Thanks
  Rudolf

  [1] https://lists.gnu.org/archive/html/qemu-devel/2015-10/msg02289.html
  [2] http://gnats.netbsd.org/49603

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1645355/+subscriptions



reply via email to

[Prev in Thread] Current Thread [Next in Thread]