linux-kernel - Re: Bug#584846: Detects only 64MB and fails to boot on Intel Green City board if e820 hooked by GRUB2

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: <20100622160741.GC11407@feather>
Date:	Tue, 22 Jun 2010 09:07:42 -0700
From:	Josh Triplett <josh@...htriplett.org>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Ben Hutchings <ben@...adent.org.uk>, x86@...nel.org,
	584846@...s.debian.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: Bug#584846: Detects only 64MB and fails to boot on Intel Green
 City board if e820 hooked by GRUB2

On Mon, Jun 21, 2010 at 11:07:31PM -0700, H. Peter Anvin wrote:
> On 06/21/2010 10:22 PM, Josh Triplett wrote:
> > 
> > How might I diagnose this further?  What might cause Linux to refuse to
> > use the e820 and e801 results provided by GRUB, but accept the ones
> > provided by the BIOS?
> > 
> 
> This is interesting... you apparently have a ACPI 3-style e820 BIOS as
> evidenced by the [1] markers, but Grub presents it as legacy style.

Interesting!  I didn't know until now that that system supported the
ACPI 3-style e820.  (Looks like it doesn't actually use that mechanism
to disable any regions, though, fortunately.)

And yes, GRUB always provides 20-byte e820 entries, never larger,
regardless of what the caller asks for.

> Now, the kernel shouldn't care, but this at least gives a clue.
> 
> Something that might be worthwhile is to add printf's to the kernel's
> e820-parsing routine (in arch/x86/boot/e820.c) and figure out why it
> doesn't like the output.  It's a bit strange that meminfo would produce
> sensible-looking output (well, legal, at least; presenting a two-byte
> range is rather beyond crazy, and so forth) and the kernel wouldn't
> accept it, as the code is intentionally very similar.

Do you mean arch/x86/kernel/e820.c ?  OK, will do.

In the failure case Linux prints the memory map as "BIOS-88".  It looks
like that can only happen if the call to append_e820_map fails.  That in
turn looks like it can only happen if the number of map entries becomes
less than 2 (and since it shouldn't start that way that would have to
happen in sanitize_e820_map), or if 64-bit overflow occurred in the
memory map when adding the start and size fields.

I'll investigate further and try to figure out exactly what caused Linux
to refuse to use the e820 map.

- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/