linux-kernel - Re: [PATCH 29/29] x86/boot/e820: Treat non-type-2 'reserved' E820 region types as E820_TYPE

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-prev] [day] [month] [year] [list]

Message-ID: <4632031c-fa17-48ac-a9ce-e6bbe1668da9@zytor.com>
Date: Thu, 24 Apr 2025 20:55:07 -0700
From: "H. Peter Anvin" <hpa@...or.com>
To: Ingo Molnar <mingo@...nel.org>, linux-kernel@...r.kernel.org
Cc: Andy Shevchenko <andy@...nel.org>, Arnd Bergmann <arnd@...nel.org>,
        Borislav Petkov <bp@...en8.de>, Juergen Gross <jgross@...e.com>,
        Kees Cook <keescook@...omium.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Mike Rapoport <rppt@...nel.org>, Paul Menzel <pmenzel@...gen.mpg.de>,
        Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        David Woodhouse <dwmw@...zon.co.uk>
Subject: Re: [PATCH 29/29] x86/boot/e820: Treat non-type-2 'reserved' E820
 region types as E820_TYPE_RESERVED

On 4/21/25 11:52, Ingo Molnar wrote:
> Paul Menzel pointed out that ACPI specification 6.3 defines 'reserved'
> E820 region types as E820_TYPE_RESERVED (type 2):
> 
>   > 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.
> 
> This has relevance for device address regions, which on some firmware such
> as CoreBoot, get passed to Linux as type-13 - which the kernel
> treats as system regions and registers them as unavailable to drivers:
> 

... so we should handle 13 accordingly (and probably request that the 
ACPI committee permanently reserve it.  It would have been better to use 
negative numbers for OS-specific things.)

However, if we run into a value that we have never seen, say something 
like 84, we shouldn't assume that it is safe to do anything at all to 
it; in particular we really don't want to assume that it is safe to 
place I/O devices there.

Note that devices may be a priori set up in type 2 memory; it pretty 
much means "this device is treated specially by firmware, don't move it 
around or bad things will happen."

	-hpa