Re: [XEN PATCH] hvmloader: Fix reading ACPI PM1 CNT value
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
Re: [XEN PATCH] hvmloader: Fix reading ACPI PM1 CNT value
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 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.
[XEN PATCH] hvmloader: Fix reading ACPI PM1 CNT value
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 --- 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_ENABLE0xf1 @@ -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