15274 2023-11-06 23:11:51 +0000 qemuarmv5 fails to boot with qemu lsi hw error 2023-11-20 23:06:34 +0000 1 1 7 Build System, Metadata & Runtime OE-Core virtual machines 3.1.34 Other arm RESOLVED FIXED Medium+ normal 3.1.30 1 jon.mason steve peter.maydell randy.macleod richard.purdie ross.burton steve --- --- Don't know oldest_to_newest 97207 0 jon.mason 2023-11-06 23:11:51 +0000 I see the following error (100% reproducible) when booting qemuarmv5 on dunfell: WARNING: core-image-base-1.0-r0 do_testimage: Last 25 lines of text: [ 2.346176] pci 0000:00:10.0: reg 0x20: [mem 0x00000000-0x00003fff 64bit pref] [ 2.347319] PCI: bus0: Fast back to back transfers disabled [ 2.348129] pci 0000:00:0e.0: BAR 6: assigned [mem 0x60000000-0x6003ffff pref] [ 2.348404] pci 0000:00:0e.0: BAR 4: assigned [mem 0x60040000-0x60043fff 64bit pref] [ 2.348658] pci 0000:00:0f.0: BAR 4: assigned [mem 0x60044000-0x60047fff 64bit pref] [ 2.348840] pci 0000:00:10.0: BAR 4: assigned [mem 0x60048000-0x6004bfff 64bit pref] [ 2.349017] pci 0000:00:0d.0: BAR 2: assigned [mem 0x50000000-0x50001fff] [ 2.349168] pci 0000:00:0d.0: BAR 1: assigned [mem 0x50002000-0x500023ff] [ 2.349310] pci 0000:00:0c.0: BAR 0: assigned [mem 0x50002400-0x500024ff] [ 2.349467] pci 0000:00:0d.0: BAR 0: assigned [io 0x1000-0x10ff] [ 2.349762] pci 0000:00:10.0: BAR 0: assigned [io 0x1400-0x147f] [ 2.349926] pci 0000:00:0e.0: BAR 0: assigned [io 0x1480-0x149f] [ 2.350065] pci 0000:00:0f.0: BAR 0: assigned [io 0x14a0-0x14bf] [ 2.350645] pci 0000:00:0c.0: enabling device (0100 -> 0102) [ 2.351795] clcd-pl11x 10120000.display: PL110 designer 41 rev0 at 0x10120000 [ 2.352619] clcd-pl11x: probe of 10120000.display failed with error -2 [ 2.353713] virtio-pci 0000:00:0e.0: enabling device (0100 -> 0103) [ 2.355176] virtio-pci 0000:00:0f.0: enabling device (0100 -> 0103) [ 2.355893] virtio-pci 0000:00:10.0: enabling device (0100 -> 0103) [ 2.370420] random: crng init done [ 2.385144] brd: module loaded [ 2.388394] virtio_blk virtio2: [vda] 131072 512-byte logical blocks (67.1 MB/64.0 MiB) [ 2.396945] sym53c8xx 0000:00:0d.0: enabling device (0100 -> 0103) [ 2.398519] sym0: <895a> rev 0x0 at pci 0000:00:0d.0 irq 67 [ 2.402440] sym0: No NVRAM, ID 7, Fast-40, LVD, parity checking WARNING: core-image-base-1.0-r0 do_testimage: Check full boot log: /builder/meta-arm/build/tmp/work/qemuarmv5-poky-linux-gnueabi/core-image-base/1.0-r0/testimage/qemu_boot_log.20231106203634 WARNING: core-image-base-1.0-r0 do_testimage: Qemu ended unexpectedly, dump data from host is in /builder/meta-arm/build/tmp/log/runtime-hostdump/202311062040_qemu WARNING: core-image-base-1.0-r0 do_testimage: qemu-system ended unexpectedly Output from runqemu: vpb_sic_write: Bad register offset 0x2c runqemu - ERROR - Failed to run qemu: qemu-system-arm: warning: Blocked re-entrant IO on MemoryRegion: lsi-ram at addr: 0x1000 qemu-system-arm: /builder/meta-arm/build/tmp/work/x86_64-linux/qemu-system-native/4.2.1-r0/qemu-4.2.1/hw/scsi/lsi53c895a.c:624: lsi_do_dma: Assertion `s->current' failed. runqemu - INFO - Cleaning up 97212 1 peter.maydell 2023-11-07 10:37:34 +0000 Hi; this error message: runqemu - ERROR - Failed to run qemu: qemu-system-arm: warning: Blocked re-entrant IO on MemoryRegion: lsi-ram at addr: 0x1000 means you have hit a bug which is fixed in newer versions of QEMU. The simplest solution is to use a newer QEMU version than whatever this is. 97213 2 peter.maydell 2023-11-07 10:42:46 +0000 PS: the assertion message filename implies that this is qemu-4.2.1, which is odd because the assertion you hit was not present in that upstream QEMU. That suggests that perhaps this is a custom QEMU with some backported patches, and the set of patches backported was not correct or complete or is missing some later fixes for backported pieces. Backporting the patch which added this assert was probably a mistake -- it is a useful security fix if you're using an up to date QEMU, but on something as elderly as 4.2 there are bound to be a ton of other security problems unfixed. So either (a) don't bother backporting security fixes or (b) use newer QEMU. If you only care about emulation then (a) is probably better, because from upstream QEMU's point of view the emulation-only use case is not on our security boundary and bugs allowing an emulated guest to escape the VM are not considered "security" bugs that get CVEs/announcements/etc. 97214 3 richard.purdie 2023-11-07 11:19:52 +0000 It does look like the backport of a2e1753b8054344f32cf94f31c6399a58794a380 adds this message so the fix for CVE-2023-0330 looks to have broken qemuarmv5. Dunfell is our oldest LTS release and upgrading QEMU there likely isn't an option sadly. 97215 4 richard.purdie 2023-11-07 11:24:25 +0000 It looks like the crash is in hw/scsi/lsi53c895a.c and the short log for hw/scsi/lsi53c895a.c is: b987718bbb hw/scsi/lsi53c895a: Fix reentrancy issues in the LSI controller (CVE-2023-0330) d139fe9ad8 lsi53c895a: disable reentrancy detection for MMIO region, too bfd6e7ae6a lsi53c895a: disable reentrancy detection for script RAM i.e. the first one is definitely needed, perhaps with the other two? 97216 5 peter.maydell 2023-11-07 11:44:10 +0000 My suggestions in order of preference: (1) drop the backport of a2e1753b8054344f32 -- if you're running QEMU 4.2 you clearly don't care about security against guests escaping from the VM, so applying this change only introduces the possibility of regressions for existing guest setups you're using (2) backport at least commit bfd6e7ae6a72 and commit d139fe9ad8a27bc Some background to a2e1753b8054344f32: there is a longstanding class of bugs in QEMU where a malicious guest can program a DMA-capable device so that it does DMA to its own registers (or more complicated scenarios where device A DMAs to device B which DMAs back to device A), and then the QEMU device model code is re-entered in a way it doesn't expect, causing misbehaviour, crashes, etc. Commit a2e1753b8054344f32 is a big hammer which forbids this for all devices; it then caused a certain amount of fallout where we found cases where in fact DMA back to a particular device was a legitimate scenario, and we had to permit those special cases. It's not a good idea to backport a2e1753b8054344f32 without also tracking down and backporting the subsequent fixes (and unfortunately we didn't always tag those commits with "Fixes: a2e1753b805" when we made them, so there's no easy way to locate them all). So a2e1753b8054344f32 is a very risky commit to backport from a "possible regressions" perspective and you should only do it if you critically need the security improvement it gets you; which you don't if you're happy to stay on 4.2. 97292 6 steve 2023-11-20 23:06:34 +0000 Peter's #1 suggestion seems like the best approach. Fixed in: https://git.yoctoproject.org/poky/commit/?h=dunfell&id=72c7bacfd367378e979d7800e655f6b445733e60