LP: #2165925 — root cause is mdadm's option-ROM scan, not a missing
kernel fix
Root Cause Summary
The kernel commit cited in the description (0f4a1e80989a "x86/sev: Skip ROM
range scans and validation for SEV-SNP guests") is already present in every
Ubuntu kernel: noble 6.8 (backported as f811d8056745), OEM 6.17, and Ubuntu 7.0
(arch/x86/mm/mem_encrypt_amd.c sets x86_init.resources.probe_roms =
x86_init_noop for SNP guests). There is no kernel patch left to backport here.
That commit only stops the *kernel* from touching the legacy ROM window. It
deliberately leaves the 0xc0000-0xfffff range mapped-but-never-pvalidated, and
/dev/mem still hands that range to userspace: devmem_is_allowed() in
arch/x86/mm/init.c has no confidential-guest guard in mainline v7.2, in
linux-next (20260831), or in any Ubuntu tree.
So the failing access is mdadm's, in userspace:
- find_imsm_hba_orom() in mdadm's platform-intel.c scans the legacy option-ROM
window for the IMSM signature.
- probe_roms_init() does open("/dev/mem") + mmap(0xc0000, 0x30000), then
romsignature()/probe_address16() reads 16-bit words looking for 0xaa55.
- In an SNP guest that page is unvalidated, so the read raises #VC with
exit_code 0x404 (SVM_EXIT_NPF 0x400 plus the "encrypted but not validated"
error bits). The guest #VC handler cannot emulate it, prints the
"Wrong/unhandled opcode bytes" line from arch/x86/coco/sev/vc-shared.c, and
delivers SIGBUS to the task instead of killing the VM.
The hang is a bug in mdadm's SIGBUS recovery. probe_roms.c installs a handler
that only sets a flag and returns:
static void sigbus(int sig) { _sigbus = 1; }
static int probe_address16(const __u16 *ptr, __u16 *val)
{
*val = *ptr; <-- faults here
if (_sigbus) rc = -1; <-- never reached
}
Returning from the handler restarts the same faulting instruction. The #VC is
deterministic (the page is permanently unvalidated), so SIGBUS fires again,
forever — hence the strace full of SIGBUS and the hang. The flag is only tested
after the load completes, which it never does. There is no
sigsetjmp/siglongjmp and no SA_RESETHAND.
The reported opcode confirms this: 0xb70f is 0F B7 = MOVZX r32, r/m16, exactly
the 16-bit load in probe_address16() doing the 0xaa55 ROM-signature probe.
Key Evidence
- Reported: Wrong/unhandled opcode bytes: 0xb70f, exit_code: 0x404 — emitted by
sev_printk() in arch/x86/coco/sev/vc-shared.c; 0x404 = SVM_EXIT_NPF (0x400,
arch/x86/include/uapi/asm/svm.h) with unvalidated-page error bits.
- Reported: "Should result in a lot of SIGBUS errors" in strace — the repeated
SIGBUS is the signature of the restart loop, not of successful recovery.
- SIGBUS (not a VM abort) comes from user_exc_vmm_communication() ->
force_sig_fault(SIGBUS, BUS_OBJERR) in arch/x86/coco/sev/vc-handle.c.
- Minimal repro "mdadm --examine --metadata=imsm /dev/sr0" hits
find_imsm_hba_orom() -> probe_roms_init() -> mmap /dev/mem @ 0xc0000.
- 0f4a1e80989a present in noble/master-next (f811d8056745), oem-6.17-next, and
resolute 7.0 (master-next and oem-7.0-next).
- devmem_is_allowed(): no CC_ATTR_GUEST_MEM_ENCRYPT / SNP guard in mainline
v7.2, linux-next 20260831, or any Ubuntu tree.
- Ubuntu config, both series: CONFIG_STRICT_DEVMEM=y, CONFIG_IO_STRICT_DEVMEM=n,
CONFIG_AMD_MEM_ENCRYPT=y.
Upstream state of the /dev/mem side
This regression was reported upstream in April 2025 with the identical
signature, for fwupd/libsmbios rather than mdadm:
- Naveen N Rao (AMD), RFC "x86/sev: Disallow userspace access to BIOS region for
SEV-SNP guests", Fixes: 0f4a1e80989a, quoting
"Wrong/unhandled opcode bytes: 0x8b, exit_code: 0x404". Not merged.
- Dan Williams, "Restrict devmem for confidential VMs" (v2/v3/v5), which would
drop /dev/mem entirely for confidential guests. Only the cleanup patch landed
(1b3f2bd04d90, v6.16-rc1); the functional change did not. The thread
concluded this should be handled by lockdown policy.
There is therefore no upstream kernel fix in flight to pull for this.
mdadm state (where the fix actually is)
- 1fc0f290caeb (2025-01-29) "platform-intel: Disable legacy option ROM scan on
UEFI machines" — stat("/sys/firmware/efi") and skip the scan. Shipped in
mdadm 4.5 and 4.6. Since these SNP guests boot OVMF, this fixes the repro.
- 50583ea3d741 (2026-06-19) reverts that commit.
- 327df88fe37b (2026-06-19) replaces it with an IMSM_DISABLE_OROM=1 mdadm.conf
option, defaulting to scanning ENABLED.
So mdadm main (future 4.7) re-opens this bug for EFI SNP guests unless the user
edits mdadm.conf.
Ubuntu mdadm versions:
noble 24.04 4.3-1ubuntu2.1 no EFI-skip guard -> hangs
plucky 25.04 4.4-7ubuntu1 no EFI-skip guard -> hangs
questing 25.10 4.4-11ubuntu2 no EFI-skip guard -> hangs
resolute 4.5-5ubuntu1.1 guard present -> ok
stonking 4.6-2ubuntu1 guard present -> ok
No Ubuntu debian/patches in 4.3/4.4/4.5 alter platform-intel.c or probe_roms.c
in a way that changes this.
Recommended Actions
1. Add an mdadm (Ubuntu) task. The linux (Ubuntu) task has no actionable kernel
fix — the cited commit is already everywhere.
2. Workarounds usable in the installer today, in order of preference:
- IMSM_NO_PLATFORM=1 in the installer environment (skips all IMSM platform
and OROM probing via check_no_platform()), or
- mdadm.imsm.test=1 on the guest kernel command line — same effect, settable
from the ISO boot editor with no shell needed, or
- IMSM_DISABLE_OROM=1 in mdadm.conf (mdadm main/4.7+ only; not in any
released Ubuntu mdadm).
3. SRU mdadm for noble/plucky/questing: backport 1fc0f290caeb (EFI option-ROM
skip). Small, self-contained, already shipped in 4.5/4.6.
4. Push the durable fix to md-raid-utilities, since 1fc0f290caeb was reverted
in mdadm main: probe_roms.c's flag-based SIGBUS recovery cannot work against
a deterministic restartable fault. Convert probe_address8/16() to
sigsetjmp/siglongjmp, or detect a confidential guest and skip the scan
outright. Otherwise mdadm 4.7 regresses SNP guests again.
5. Recommend against an Ubuntu-only devmem_is_allowed() restriction; that would
break legitimate BIOS-region consumers on bare metal. Better to help revive
the upstream series (or its lockdown-policy variant).
6. Requested from the reporter, to close the remaining gap: the exact Ubuntu ISO
and kernel version tested, mdadm --version from the installer shell, full
guest dmesg around the #VC message, and the strace file. Also please confirm
whether the raw-vs-qcow2 difference reproduces with the direct
"mdadm --examine --metadata=imsm /dev/sr0" command — nothing on the kernel
side explains that asymmetry, since both QEMU invocations use the same guest
kernel and virtio-scsi-pci, and the minimal repro does not involve the target
disk format at all.
Related Past Issues
- LP: #2158249 (https://bugs.launchpad.net/bugs/2158249): "SEV-SNP guest panics
in reserve_ibft_region() during legacy iBFT scan when booted via non-EFI
boot", Triaged/Medium. Same exit_code 0x404 on the same unvalidated legacy
low-memory window, same root class — 0f4a1e80989a neutralised probe_roms,
dmi_setup, find_mptable and init_irq for SNP guests but left other legacy
scanners unguarded. reserve_ibft_region() in
drivers/firmware/iscsi_ibft_find.c bails only on efi_enabled(EFI_BOOT), so a
non-EFI SNP guest still walks that range and panics. That one is a genuine
kernel bug needing an upstream cc_platform_has(CC_ATTR_GUEST_SEV_SNP) guard,
whereas this bug is userspace. A general "SNP guests must not scan legacy low
memory" audit would cover both.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2165925
Title:
guest ISOs in SNP mode installation on raw images can fail
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2165925/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
