linux-kernel - Re: [Patch 1/1] x86 efi: Fill all reserved memmap entries if add_efi

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]

Date:	Wed, 26 May 2010 11:47:51 -0700
From:	Mike Travis <travis@....com>
To:	"H. Peter Anvin" <hpa@...or.com>
CC:	Yinghai Lu <yinghai@...nel.org>, Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>, x86@...nel.org,
	Suresh Siddha <suresh.b.siddha@...el.com>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Jens Axboe <jens.axboe@...cle.com>,
	Jack Steiner <steiner@....com>,
	LKML <linux-kernel@...r.kernel.org>, jkosina@...ell.com
Subject: Re: [Patch 1/1] x86 efi: Fill all reserved memmap entries if 	add_efi_memmap
 specified.

H. Peter Anvin wrote:
> On 05/26/2010 10:42 AM, Mike Travis wrote:
>> I'm open for suggestions on how to improve this, but we are shipping
>> systems very soon and I don't think we'll get any other change into
>> the system until the next update.
>>
> 
> You know you've been using that excuse for two years when it comes to
> not fixing the bootloader, and I'm starting to be a bit frustrated with
> that.
> 
> 	-hpa

I didn't know bootloader had a problem two years ago  And as I mentioned,
I'm open to suggestions but what I've heard is "fix the bootloader". What
I don't know is how to do that.

I see that BIOS sets up an e820 compatible memory map and extra memmap
entries "somewhere".  EFI seems to pick this up via ELILO and somehow
the kernel finds these extra memmap entries.

So my question is what is broken?  Should the bootloader not use the
standard e820 memmap at all, and invent another way of passing the
memmap entries?  And what about EFI grub, shouldn't that also change?
And how does this affect compatibility?

I'm in the dark here as to how the bootloader manages to pass these
entries from BIOS to the kernel, and how far I can go modifying these
things when I don't completely understand them.  The last problem I
worked on in ELILO I couldn't even print messages as that invalidated
the "magic key" and it would loop endlessly between ELILO and BIOS.

The other thing is priorities.  If something is working and not
causing undue problems, it does not get higher priority than issues
that cause complete system failure.  I've suggested a workable
(maybe short term solution), that gets us past the boot, and on to
the other potentially far more important problems.

And p.s. it's been way longer than two years... ;-)  [the other thing
to consider is we haven't had real hardware that long, and many, many,
many problems have surfaced since then.  The memmap problem only
showed up when we ran over 128 entries.  When has that happened before?
And how was it handled then?] 

Thanks,
Mike
--
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/