Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#581 2 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
67/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
rust
Área
operating-systems

Línea de trabajo

Empieza en src/bootinfo/memory_map.rs, en la implementación de From, y revisa cómo MemoryRegionType atraviesa la frontera entre bootloader y kernel. Verifica que un tipo E820 no reconocido ya no provoque un panic, se represente como Reserved y deje la ABI 0.9 sin cambios; el problema independiente de upstream relacionado con la lectura del mapa queda explícitamente fuera del alcance.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

help wanted

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
Lenguaje dominante
Rust
Estrellas
1.7k
Forks
240
Sin PR fusionados en 30 d

Preparar el entorno

Aún no hemos revisado los archivos de configuración de este proyecto. Empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de rust-osdev/bootloader

Todos los issues de rust-osdev/bootloader

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.