BIOS: panic on unknown E820 region type violates ACPI §15 (Table 15-374)

Comece em src/bootinfo/memory_map.rs, na implementação de From, e leia como MemoryRegionType atravessa a fronteira entre bootloader e kernel. Verifique se um tipo E820 não reconhecido não causa mais um panic, é representado como Reserved e mantém a ABI 0.9 inalterada; o problema separado de upstream relacionado à leitura do mapa está explicitamente fora do escopo.

Hi — reporting a panic hit on real hardware during a BIOS/CSM boot, with a proposed three-line fix. Happy to open a PR against v0.9-base if you agree with the approach.

Symptom

ASUS ROG AMD board, 32 GiB RAM, AMI BIOS 2.20.1271, booting legacy/CSM from a USB stick. The bootloader runs, reaches the memory map parsing, and stops:

panicked at src/bootinfo/memory_map.rs:225:18:
invalid region type 2954887168

The kernel never starts. Nothing indicates which region is at fault, nor how many there are.

What the specification requires

INT 15h AX=E820h is specified by the ACPI Specification, §15 — System Address Map Interfaces. Table 15-374 (Address Range Types) explicitly covers types the OS does not know:

Ranges marked "Reserved for future use" must be treated by OSPM as if the type returned was AddressRangeReserved.

So the specification anticipates unknown types, and mandates reserving them rather than failing. The current behaviour is non-conformant: a bootloader refuses to start on firmware that is within spec.

This is not hypothetical — Linux dealt with the same issue ("e820: Undefined type not treated as AddressRangeReserved"), some firmware emitting type 13 where SeaBIOS emits 2.

What 0.11 already does

The next major version handles this well:

// bootloader-x86_64-bios-stage-4/src/memory_descriptor.rs
fn kind(&self) -> MemoryRegionKind {
    match self.0.region_type {
        1     => MemoryRegionKind::Usable,
        other => MemoryRegionKind::UnknownBios(other),
    }
}

Neither panic nor silence: the region is not reusable, and the raw value is preserved. The proposal below carries that spirit into the constraints of 0.9.

Proposed fix

src/bootinfo/memory_map.rs, around line 219:

 impl From<E820MemoryRegion> for MemoryRegion {
     fn from(region: E820MemoryRegion) -> MemoryRegion {
         let region_type = match region.region_type {
             1 => MemoryRegionType::Usable,
             2 => MemoryRegionType::Reserved,
             3 => MemoryRegionType::AcpiReclaimable,
             4 => MemoryRegionType::AcpiNvs,
             5 => MemoryRegionType::BadMemory,
-            t => panic!("invalid region type {}", t),
+            // ACPI Specification §15, Table 15-374 (Address Range Types): ranges marked
+            // "Reserved for future use" must be treated by OSPM as if the type returned
+            // was AddressRangeReserved. Treating them as fatal makes the bootloader
+            // refuse to start on firmware that is within spec.
+            //
+            // Not reusing the region is both the safe and the conformant behaviour;
+            // `Reserved` expresses exactly that.
+            _ => MemoryRegionType::Reserved,
         };

Why Reserved rather than a variant carrying the value, as 0.11 does with UnknownBios(u32): MemoryRegionType is #[repr(C)] and crosses the boundary between bootloader and kernel, which are compiled separately. Adding a payload-carrying variant would change its representation and break the ABI for every existing kernel. On a maintenance branch that seems out of the question.

If you would rather preserve the value anyway, two options exist — a payload-free variant plus a separate field in MemoryRegion, or a counter exposed through BootInfo — but both touch the ABI and are your call, not mine.

What this fix does not address

In our case the value received is 2954887168 = 0xB0200000. That is not a region type, however exotic: the specification defines only a handful. It is an address. So there is additionally something wrong with how the map is read upstream of this code — entry size, entry count, or buffer overrun — which I have not characterised yet.

The proposed change does not fix that. It keeps the bootloader usable on conformant hardware, and turns a fatal stop into a merely unused region, which is what the specification asks for. I will keep investigating the root cause and report back.

Reproduction

• bootloader = "0.9.34", custom x86_64 target, image produced by cargo bootimage
• written with dd to a USB stick (SanDisk 0781:5590), 3,091,968 bytes, checksum verified
• ASUS ROG AMD board, AMI BIOS 2.20.1271, legacy/CSM boot
• the same binary runs fine under QEMU: the fault only shows on this real firmware, which is consistent with an E820 map that differs from SeaBIOS's