| Summary: | qemuarmv5 fails to boot with qemu lsi hw error | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] OE-Core | Reporter: | Jon Mason <jon.mason> |
| Component: | virtual machines | Assignee: | Steve Sakoman <steve> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | Medium+ | CC: | peter.maydell, randy.macleod, richard.purdie, ross.burton, steve |
| Version: | 3.1.34 | ||
| Target Milestone: | 3.1.30 | ||
| Hardware: | Other | ||
| OS: | arm | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | Don't know | |
|
Description
Jon Mason
2023-11-06 23:11:51 UTC
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. 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. 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. 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? 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. Peter's #1 suggestion seems like the best approach. Fixed in: https://git.yoctoproject.org/poky/commit/?h=dunfell&id=72c7bacfd367378e979d7800e655f6b445733e60 |