linux-kernel - e820: Undefined type not treated as AddressRangeReserved

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <074c2637-1b65-428e-b3e2-24384780e936@molgen.mpg.de>
Date: Thu, 17 Apr 2025 08:49:04 +0200
From: Paul Menzel <pmenzel@...gen.mpg.de>
To: Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
 Borislav Petkov <bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>,
 x86@...nel.org
Cc: LKML <linux-kernel@...r.kernel.org>
Subject: e820: Undefined type not treated as AddressRangeReserved

Dear Linux folks,


Some firmware, like coreboot with older FILO payload [1] or GRUB as 
payload [2], mark memory regions(?) with type E820 type 13 (Undefined), 
that is reserved for future use. Other payloads like SeaBIOS mark it as 
2 (AddressRangeReserved). As a result, userspace is not able to access 
this region, which can be worked around by booting with `iomem=relaxed`, 
or probably with the `memmap` parameter.

     $ grep -A1 3ff7b000 /proc/iomem # FILO
     3ff7b000-3fffffff : Unknown E820 type
       3ffa1000-3ffa8fff : BOOT0000:00

     $ grep -A1 3ff7b000 /proc/iomem # SeaBIOS, that marks it as reserved
     3ff7b000-3fffffff : Reserved
       3ffa1000-3ffa8fff : BOOT0000:00

Table 15-374 *Address Range Types* in the ACPI specification 6.3 says:

 > Reserved for future use. OSPM must treat any range of this type as if
 > the type returned was AddressRangeReserved.

Could and should Linux be adapted to follow the specification, and fix 
some real-world use cases? I looked at 
`arch/x86/include/asm/e820/types.h` and `arch/x86/kernel/e820.c`, but 
failed to find the place where to implement this, and how to name the 
macros for the undefined regions.


Kind regards,

Paul


[1]: https://review.coreboot.org/c/filo/+/51120
[2]: https://ticket.coreboot.org/issues/590
[3]: https://uefi.org/sites/default/files/resources/ACPI_6_3_final_Jan30.pdf


diff --git a/arch/x86/include/asm/e820/types.h 
b/arch/x86/include/asm/e820/types.h
index 80c4a7266629..1b341914d438 100644
--- a/arch/x86/include/asm/e820/types.h
+++ b/arch/x86/include/asm/e820/types.h
@@ -14,6 +14,10 @@ enum e820_type {
         E820_TYPE_NVS           = 4,
         E820_TYPE_UNUSABLE      = 5,
         E820_TYPE_PMEM          = 7,
+       E820_TYPE_UNDEFINED_8   = 8, /* reserved for future use */
+       E820_TYPE_UNDEFINED_9   = 9, /* reserved for future use */
+       E820_TYPE_UNDEFINED_10  = 10, /* reserved for future use */
+       E820_TYPE_UNDEFINED_11  = 11, /* reserved for future use */

         /*
          * This is a non-standardized way to represent ADR or
@@ -28,6 +32,8 @@ enum e820_type {
          */
         E820_TYPE_PRAM          = 12,

+       E820_TYPE_UNDEFINED_13  = 13, /* reserved for future use */
+
         /*
          * Special-purpose memory is indicated to the system via the
          * EFI_MEMORY_SP attribute. Define an e820 translation of this