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 12:04:44 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Mike Travis <travis@....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.

On 05/26/2010 11:47 AM, Mike Travis wrote:
> 
> 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?] 
> 

The 128-entry limit (caused by the fixed array in struct setup_info) was
brought to our attention in 2007.  At that time, a number of
alternatives were discussed; Linus in particular was adamant that this
should be handled in the bootloader, and not by the kernel.

The result was that we added a facility to the kernel to supply
arbitrary information via a linked list.  That has been in there since
at least early 2008.  However, noone who cares about this issue has
bothered stepping up and put the support into the bootloaders --
instead, we got suckered into accepting a "temporary hack" which only
has had the effect of giving you guys yet another excuse not to do what
you signed off to do in the first place.

Accordingly, the right answer for me to do is to veto this and any
further patches which enable you to skirt your responsibility, and I'm
getting damned close to doing so.

	-hpa
--
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/