[XEN PATCH] hvmloader: Fix reading ACPI PM1 CNT value

[XEN PATCH] hvmloader: Fix reading ACPI PM1 CNT value

[Anthony PERARD]

In order to get the CNT value from QEMU, we were supposed to read a
word, according to the implementation in QEMU. But it has been lax and
allowed to read a single byte. This has changed with commit
5d971f9e6725 ("memory: Revert "memory: accept mismatching sizes in
memory_region_access_valid"") and result in hvmloader crashing on
the BUG_ON.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

---

I'll try to have the QEMU implementation changes to allow reading a
byte, but it would probably by nice to not have to change qemu.
---
 tools/firmware/hvmloader/hvmloader.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tools/firmware/hvmloader/hvmloader.c b/tools/firmware/hvmloader/hvmloader.c
index 598a22627872..bdcbe4a26664 100644
--- a/tools/firmware/hvmloader/hvmloader.c
+++ b/tools/firmware/hvmloader/hvmloader.c
@@ -256,7 +256,7 @@ static const struct bios_config *detect_bios(void)
 
 static void acpi_enable_sci(void)
 {
-    uint8_t pm1a_cnt_val;
+    uint16_t pm1a_cnt_val;
 
 #define PIIX4_SMI_CMD_IOPORT 0xb2
 #define PIIX4_ACPI_ENABLE    0xf1
@@ -265,11 +265,11 @@ static void acpi_enable_sci(void)
      * PIIX4 emulation in QEMU has SCI_EN=0 by default. We have no legacy
      * SMM implementation, so give ACPI control to the OSPM immediately.
      */
-    pm1a_cnt_val = inb(ACPI_PM1A_CNT_BLK_ADDRESS_V1);
+    pm1a_cnt_val = inw(ACPI_PM1A_CNT_BLK_ADDRESS_V1);
     if ( !(pm1a_cnt_val & ACPI_PM1C_SCI_EN) )
         outb(PIIX4_SMI_CMD_IOPORT, PIIX4_ACPI_ENABLE);
 
-    pm1a_cnt_val = inb(ACPI_PM1A_CNT_BLK_ADDRESS_V1);
+    pm1a_cnt_val = inw(ACPI_PM1A_CNT_BLK_ADDRESS_V1);
     BUG_ON(!(pm1a_cnt_val & ACPI_PM1C_SCI_EN));
 }
 
-- 
Anthony PERARD

Re: [XEN PATCH] hvmloader: Fix reading ACPI PM1 CNT value

[Roger Pau Monné]

On Tue, Jun 30, 2020 at 06:09:13PM +0100, Anthony PERARD wrote:
> In order to get the CNT value from QEMU, we were supposed to read a
> word, according to the implementation in QEMU. But it has been lax and
> allowed to read a single byte. This has changed with commit
> 5d971f9e6725 ("memory: Revert "memory: accept mismatching sizes in
> memory_region_access_valid"") and result in hvmloader crashing on
> the BUG_ON.

This is a bug on the QEMU side, the ACPI spec states: "Accesses to PM1
control registers are accessed through byte and word accesses.".
That's on section 4.8.3.2.1 PM1 Control Registers of my copy of the
ACPI spec (6.2A).

> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

I'm fine with this if such bogus behavior has made it's way into a
release version of QEMU, but it needs to state it's a workaround for a
QEMU bug, not a bug in hvmloader.

IMO the QEMU change should be reverted.

Thanks, Roger.

Re: [XEN PATCH] hvmloader: Fix reading ACPI PM1 CNT value

[Anthony PERARD]

On Wed, Jul 01, 2020 at 09:52:57AM +0200, Roger Pau Monné wrote:
> On Tue, Jun 30, 2020 at 06:09:13PM +0100, Anthony PERARD wrote:
> > In order to get the CNT value from QEMU, we were supposed to read a
> > word, according to the implementation in QEMU. But it has been lax and
> > allowed to read a single byte. This has changed with commit
> > 5d971f9e6725 ("memory: Revert "memory: accept mismatching sizes in
> > memory_region_access_valid"") and result in hvmloader crashing on
> > the BUG_ON.
> 
> This is a bug on the QEMU side, the ACPI spec states: "Accesses to PM1
> control registers are accessed through byte and word accesses.".
> That's on section 4.8.3.2.1 PM1 Control Registers of my copy of the
> ACPI spec (6.2A).

I guess we can ignore this patch then, and I should write a patch for
QEMU instead.

> I'm fine with this if such bogus behavior has made it's way into a
> release version of QEMU, but it needs to state it's a workaround for a
> QEMU bug, not a bug in hvmloader.

It hasn't, but might.

> IMO the QEMU change should be reverted.

The change can't be reverted, it is to fix a CVE and isn't related to
ACPI. But we can fix the emulator.

> Thanks, Roger.

Thanks,

-- 
Anthony PERARD