Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

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

Ouverte
  • Quelque chose ne va pas ?
#581 2 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
3/5
Temps estimé
1-2 jours
Accessibilité débutants
67/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
Active
Stack technique
rust
Domaine
operating-systems

Piste de recherche

Commencez dans src/bootinfo/memory_map.rs, au niveau de l’implémentation de From, et examinez comment MemoryRegionType franchit la frontière entre bootloader et kernel. Vérifiez qu’un type E820 non reconnu ne provoque plus de panic, qu’il est représenté par Reserved et que l’ABI 0.9 reste inchangée ; le problème distinct de upstream concernant la lecture de la map est explicitement hors périmètre.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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
Langage dominant
Rust
Étoiles
1.7k
Forks
241
Aucune PR mergée en 30 j

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de rust-osdev/bootloader

Toutes les issues de rust-osdev/bootloader

Issues similaires

Plus d'issues Rust

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.