linux-kernel - Re: [PATCH 05/29] x86/boot/e820: Print gaps in the E820 table

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

Message-ID: <aCXBvRe6PrY_zlvU@gmail.com>
Date: Thu, 15 May 2025 12:28:13 +0200
From: Ingo Molnar <mingo@...nel.org>
To: Andy Shevchenko <andy.shevchenko@...il.com>
Cc: linux-kernel@...r.kernel.org, Andy Shevchenko <andy@...nel.org>,
	Arnd Bergmann <arnd@...nel.org>, Borislav Petkov <bp@...en8.de>,
	Juergen Gross <jgross@...e.com>, "H . Peter Anvin" <hpa@...or.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 05/29] x86/boot/e820: Print gaps in the E820 table


* Andy Shevchenko <andy.shevchenko@...il.com> wrote:

> Mon, Apr 21, 2025 at 08:51:45PM +0200, Ingo Molnar kirjoitti:
> > Gaps in the E820 table are not obvious at a glance and can
> > easily be overlooked.
> > 
> > Print out gaps in the E820 table:
> > 
> > Before:
> > 
> > 	BIOS-provided physical RAM map:
> > 	BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable
> > 	BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved
> > 	BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved
> > 	BIOS-e820: [mem 0x0000000000100000-0x000000007ffdbfff] usable
> > 	BIOS-e820: [mem 0x000000007ffdc000-0x000000007fffffff] reserved
> > 	BIOS-e820: [mem 0x00000000b0000000-0x00000000bfffffff] reserved
> > 	BIOS-e820: [mem 0x00000000fed1c000-0x00000000fed1ffff] reserved
> > 	BIOS-e820: [mem 0x00000000feffc000-0x00000000feffffff] reserved
> > 	BIOS-e820: [mem 0x00000000fffc0000-0x00000000ffffffff] reserved
> > 	BIOS-e820: [mem 0x000000fd00000000-0x000000ffffffffff] reserved
> > After:
> > 
> > 	BIOS-provided physical RAM map:
> > 	BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable
> > 	BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved
> > 	BIOS-e820: [gap 0x00000000000a0000-0x00000000000effff]
> > 	BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved
> > 	BIOS-e820: [mem 0x0000000000100000-0x000000007ffdbfff] usable
> > 	BIOS-e820: [mem 0x000000007ffdc000-0x000000007fffffff] reserved
> > 	BIOS-e820: [gap 0x0000000080000000-0x00000000afffffff]
> > 	BIOS-e820: [mem 0x00000000b0000000-0x00000000bfffffff] reserved
> > 	BIOS-e820: [gap 0x00000000c0000000-0x00000000fed1bfff]
> > 	BIOS-e820: [mem 0x00000000fed1c000-0x00000000fed1ffff] reserved
> > 	BIOS-e820: [gap 0x00000000fed20000-0x00000000feffbfff]
> > 	BIOS-e820: [mem 0x00000000feffc000-0x00000000feffffff] reserved
> > 	BIOS-e820: [gap 0x00000000ff000000-0x00000000fffbffff]
> > 	BIOS-e820: [mem 0x00000000fffc0000-0x00000000ffffffff] reserved
> > 	BIOS-e820: [gap 0x0000000100000000-0x000000fcffffffff]
> > 	BIOS-e820: [mem 0x000000fd00000000-0x000000ffffffffff] reserved
> > 
> > Also warn about badly ordered E820 table entries:
> > 
> > 	BUG: out of order E820 entry!
> > 
> > ( this is printed before the entry is printed, so there's no need to
> >   print any additional data with the warning. )
> 
> ...
> 
> > +		u64 range_start, range_end;
> 
> struct range (from range.h) and...

Yeah, using those primitives makes sense, but right now the e820 code 
isn't using them, and it's better to have similar & unified range 
handling code patterns.

In principle I wouldn't be opposed to patches that convert the e820 
code to <linux/range.h> types.

> 
> > +		range_start = entry->addr;
> > +		range_end   = entry->addr + entry->size;
> >  
> > +		/* Out of order E820 maps should not happen: */
> > +		if (range_start < range_end_prev)
> > +			pr_info("BUG: out of order E820 entry!\n");
> > +
> > +		if (range_start > range_end_prev) {
> > +			pr_info("%s: [gap %#018Lx-%#018Lx]\n",
> > +				who,
> > +				range_end_prev,
> > +				range_start-1);
> 
> %pra

This would be part of any <linux/range.h> conversion patches.

> with who mentioned the "gap"?

Not sure I understand?

Thanks,

	Ingo