[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug 1909823] [NEW] RDPMC check on PCE is backwards
From: |
Bruce Merry |
Subject: |
[Bug 1909823] [NEW] RDPMC check on PCE is backwards |
Date: |
Fri, 01 Jan 2021 17:50:11 -0000 |
Public bug reported:
At [this
line](https://github.com/qemu/qemu/blob/75ee62ac606bfc9eb59310b9446df3434bf6e8c2/target/i386/tcg/misc_helper.c#L225)
the check on CR4_PCE_MASK is backwards: it's raising an exception if the
flag is set (and CPL != 0) rather than if the flag is clear.
It's low priority at the moment because the instruction isn't
implemented, so you get an illegal opcode exception when expecting a
GPF, or vice versa, but it's a time bomb for if it is ever implemented.
The Intel docs also indicate that CR0.PE influences the protection; I
don't know if that's already reflected in env->hflags & HF_CPL_MASK.
** 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/1909823
Title:
RDPMC check on PCE is backwards
Status in QEMU:
New
Bug description:
At [this
line](https://github.com/qemu/qemu/blob/75ee62ac606bfc9eb59310b9446df3434bf6e8c2/target/i386/tcg/misc_helper.c#L225)
the check on CR4_PCE_MASK is backwards: it's raising an exception if
the flag is set (and CPL != 0) rather than if the flag is clear.
It's low priority at the moment because the instruction isn't
implemented, so you get an illegal opcode exception when expecting a
GPF, or vice versa, but it's a time bomb for if it is ever
implemented.
The Intel docs also indicate that CR0.PE influences the protection; I
don't know if that's already reflected in env->hflags & HF_CPL_MASK.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1909823/+subscriptions
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Bug 1909823] [NEW] RDPMC check on PCE is backwards,
Bruce Merry <=