linux-kernel - Re: 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 for Android: free password hash cracker in your pocket

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

Message-ID: <084FA661-17FD-4FC7-B863-92A4FE112201@zytor.com>
Date: Thu, 17 Apr 2025 11:44:06 -0700
From: "H. Peter Anvin" <hpa@...or.com>
To: Paul Menzel <pmenzel@...gen.mpg.de>, 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: Re: e820: Undefined type not treated as AddressRangeReserved

On April 16, 2025 11:49:04 PM PDT, Paul Menzel <pmenzel@...gen.mpg.de> wrote:
>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

Don't create macros; *all* unknown memory types *must* be treated as equivalent to 2.