Bug#1017944: grub-xen-host: 2.06-3 crashes PV guests in early boot

2022-09-11 Thread Diederik de Haas 
Package: grub-xen-host
Version: 2.06-3
Followup-For: Bug #1017944
X-Debbugs-Cc: pkg-xen-de...@lists.alioth.debian.org

I can confirm this issue happening on an up-to-date Bookworm system with
a 5.19.6 kernel and also with a 5.18.16 one.

I'll leave adjusting the severity up to the GRUB maintainers, but I
think a good case can be made for 'grave' or 'critical' as it breaks an
important group of Xen VM types (unrelated software).

Xen output:
===
root@cknowsvr01:~# uname -a
Linux cknowsvr01 5.19.0-1-amd64 #1 SMP PREEMPT_DYNAMIC Debian 5.19.6-1 
(2022-09-01) x86_64 GNU/Linux
root@cknowsvr01:~# xl dmesg
(XEN) Xen version 4.16.2 (Debian 4.16.2-1) 
(pkg-xen-de...@lists.alioth.debian.org) (x86_64-linux-gnu-gcc (Debian 12.2.0-1) 
12.2.0) debug=n Tue Aug 23 11:25:38 UTC 2022
(XEN) Bootloader: GRUB 2.06-3
(XEN) Command line: placeholder
(XEN) Xen image load base address: 0x7920
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: none; EDID transfer time: 1 seconds
(XEN)  EDID info not retrieved because no DDC retrieval method detected
(XEN) Disc information:
(XEN)  Found 5 MBR signatures
(XEN)  Found 5 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)  [, 0009e7ff] (usable)
(XEN)  [0009e800, 0009] (reserved)
(XEN)  [000e, 000f] (reserved)
(XEN)  [0010, 79a87fff] (usable)
(XEN)  [79a88000, 7b8cafff] (reserved)
(XEN)  [7b8cb000, 7b924fff] (ACPI data)
(XEN)  [7b925000, 7bec] (ACPI NVS)
(XEN)  [7bed, 8fff] (reserved)
(XEN)  [fed1c000, fed44fff] (reserved)
(XEN)  [ff00, ] (reserved)
(XEN)  [0001, 00407fff] (usable)
(XEN) ACPI: RSDP 000F0580, 0024 (r2 ALASKA)
(XEN) ACPI: XSDT 7B8DD0A8, 00CC (r1 ALASKA   A M I   1072009 AMI 10013)
(XEN) ACPI: FACP 7B909AB0, 010C (r5 ALASKA   A M I   1072009 AMI 10013)
(XEN) ACPI: DSDT 7B8DD210, 2C89F (r2 ALASKA   A M I   1072009 INTL 20091013)
(XEN) ACPI: FACS 7BECEF80, 0040
(XEN) ACPI: APIC 7B909BC0, 0224 (r3 ALASKA   A M I   1072009 AMI 10013)
(XEN) ACPI: FPDT 7B909DE8, 0044 (r1 ALASKA   A M I   1072009 AMI 10013)
(XEN) ACPI: FIDT 7B909E30, 009C (r1 ALASKA   A M I   1072009 AMI 10013)
(XEN) ACPI: MCFG 7B909ED0, 003C (r1 ALASKAA M I  1072009 MSFT   97)
(XEN) ACPI: EINJ 7B924DF8, 0130 (r1 ALASKA   A M I 1 INTL1)
(XEN) ACPI: UEFI 7B909F68, 0042 (r1 ALASKA   A M I   1072009 0)
(XEN) ACPI: HPET 7B909FB0, 0038 (r1 ALASKA   A M I 1 INTL 20091013)
(XEN) ACPI: MSCT 7B909FE8, 0090 (r1 ALASKA   A M I 1 INTL 20091013)
(XEN) ACPI: SLIT 7B90A078, 0030 (r1 ALASKA   A M I 1 INTL 20091013)
(XEN) ACPI: SRAT 7B90A0A8, 1158 (r3 ALASKA   A M I 1 INTL 20091013)
(XEN) ACPI: WDDT 7B90B200, 0040 (r1 ALASKA   A M I 0 INTL 20091013)
(XEN) ACPI: SSDT 7B90B240, 16FB3 (r2 ALASKAPmMgt1 INTL 20120913)
(XEN) ACPI: SPMI 7B9221F8, 0041 (r5 ALASKA   A M I 0 AMI.0)
(XEN) ACPI: SSDT 7B922240, 2652 (r2 ALASKA SpsNm   2 INTL 20120913)
(XEN) ACPI: SSDT 7B924898, 0064 (r2 ALASKA SpsNvs  2 INTL 20120913)
(XEN) ACPI: PRAD 7B924900, 0102 (r2 ALASKA   A M I 2 INTL 20120913)
(XEN) ACPI: DMAR 7B924A08, 00E8 (r1 ALASKA   A M I 1 INTL 20091013)
(XEN) ACPI: HEST 7B924AF0, 00A8 (r1 ALASKA   A M I 1 INTL1)
(XEN) ACPI: BERT 7B924B98, 0030 (r1 ALASKA   A M I 1 INTL1)
(XEN) ACPI: ERST 7B924BC8, 0230 (r1 ALASKA   A M I 1 INTL1)
(XEN) System RAM: 262042MB (268331160kB)
(XEN) Domain heap initialised DMA width 32 bits
(XEN) x2APIC mode is already enabled by BIOS.
(XEN) ACPI: 32/64X FACS address mismatch in FADT - 7becef80/, 
using 32
(XEN) IOAPIC[0]: apic_id 1, version 32, address 0xfec0, GSI 0-23
(XEN) IOAPIC[1]: apic_id 2, version 32, address 0xfec01000, GSI 24-47
(XEN) IOAPIC[2]: apic_id 3, version 32, address 0xfec4, GSI 48-71
(XEN) CPU0: 1200 ... 2100 MHz
(XEN) xstate: size: 0x340 and states: 0x7
(XEN) CMCI: threshold 0x2 too large for CPU0 bank 17, using 0x1
(XEN) CMCI: threshold 0x2 too large for CPU0 bank 18, using 0x1
(XEN) CMCI: threshold 0x2 too large for CPU0 bank 19, using 0x1
(XEN) Speculative mitigation facilities:
(XEN)   Hardware hints:
(XEN)   Hardware features: IBPB IBRS STIBP SSBD L1D_FLUSH MD_CLEAR
(XEN)   Compiled-in support: INDIRECT_THUNK SHADOW_PAGING
(XEN)   Xen settings: BTI-Thunk RETPOLINE, SPEC_CTRL: IBRS- STIBP- SSBD-, 
Other: IBPB-ctxt L1D_FLUSH VERW BRANCH_HARDEN
(XEN)   L1TF: believed vulnerable, maxphysaddr L1D 46, CPUID 46, Safe address 
3000
(XEN)   Support for HVM VMs: MSR_SPEC_CTRL RSB EAGER_FPU
(XEN)   Support for PV VMs: MSR_SPEC_CTRL EAGER_FPU MD_CLEAR
(XEN)   XPTI (64-bit PV only): Dom0 enabled, DomU enabled (with PCID)
(XEN)   PV L1TF

Bug#1017944: grub-xen-host: 2.06-3 crashes PV guests in early boot

2022-09-12 Thread Tom Lew 

On Tue, 6 Sep 2022 15:55:39 +0200 Valentin Kleibel wrote:

found 1017944 grub2/2.06-3~deb11u1
severity 1017944 serious
tags 1017944 patch

Dear Maintainers,

We can confirm that this bug affects all pv and pvh domUs that use 
pvgrub.
The commit responsible is 20239c28 "Bump debhelper from old 10 to 13." 
[1]

...


Cheers,
Valentin

[1]
https://salsa.debian.org/grub-team/grub/-/commit/20239c28e1e9ca3eba993e7702f5cb4da81dcf95


As yet another victim of this bug on bullseye/stable, I built grub2
package with this proposed patch, and I confirm the patched
grub2 2.06-3~deb11u1 packages fix the bug on a Xen server we
upgraded from 11.4 to 11.5 yesterday, where all PV/PVH domains
didn't start after reboot. Both hypervisor reboot (with autostart
domUs) and starting individual domU are all fine with the patched
grub2 packages.

I also vote for raising severity of this bug to "critical". Current
Debian 11.5 grub-xen-host package breaks all Xen PV/PVH domain boot
attemps.

Bug#1017944: grub-xen-host: 2.06-3 crashes PV guests in early boot

2022-09-12 Thread Steve McIntyre 
Control: seveerity -1 grave

On Tue, Sep 06, 2022 at 03:55:39PM +0200, Valentin Kleibel wrote:
>found 1017944 grub2/2.06-3~deb11u1
>severity 1017944 serious
>tags 1017944 patch
>
>Dear Maintainers,
>
>We can confirm that this bug affects all pv and pvh domUs that use pvgrub.
>The commit responsible is 20239c28 "Bump debhelper from old 10 to 13." [1]
>The relevant change in debhelper came with version v11: "The dh_strip and
>dh_shlibdeps tools no longer uses filename patterns to determine which files
>to process. Instead, they open the file and look for an ELF header to
>determine if a given file is an shared object or an ELF executable."
>By choosing debhelper 13, this led to pv grub getting stripped.
>A simple override to dh_strip mitigates the issue.
>
>We assume that testing and unstable are affected as well but we do not have
>systems to test this.

Thanks Valentin, I'm looking at this now.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"When C++ is your hammer, everything looks like a thumb." -- Steven M. Haflich