linux-kernel - Re: 2.6.39.1 immediately reboots/resets on EFI system

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: <20110608212813.GB32056@srcf.ucam.org>
Date:	Wed, 8 Jun 2011 22:28:13 +0100
From:	Matthew Garrett <mjg59@...f.ucam.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Yinghai Lu <yinghai@...nel.org>, Jim Bos <jim876@...all.nl>,
	"H. Peter Anvin" <hpa@...ux.intel.com>,
	Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	Maarten Lankhorst <m.b.lankhorst@...il.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Greg KH <gregkh@...e.de>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: 2.6.39.1 immediately reboots/resets on EFI system

On Wed, Jun 08, 2011 at 02:06:21PM -0700, Linus Torvalds wrote:
> On Wed, Jun 8, 2011 at 1:42 PM, Matthew Garrett <mjg59@...f.ucam.org> wrote:
> > On Wed, Jun 08, 2011 at 01:36:57PM -0700, Yinghai Lu wrote:
> >
> >> or just let bootloader to mark those boot services just like run-time services in e820 table or setupdata?
> >
> > That was my original approach, but if there's boot services code at the
> > top of RAM it means that max_pfn is wrong and it's difficult to recover
> > the memory.
> 
> WHO CARES if the memory is difficult to recover? Just let it be. EFI
> is an abomination in the eyes of God, and we sure as hell shouldn't
> bend over backwards over the stupidities in it. If it means that you
> lose a meg of RAM when you use EFI, that's the least of our problems.

Boot services data includes everything that was allocated by the EFI 
memory allocator. Depending on what the system decided to do before 
deigning to run our code, that might be a meg - or it might be several 
hundred. And in the process it's probably fragmented RAM into god knows 
how many small chunks.

E820 limits us to 128 ranges, and systems I'm looking at right now are 
already using over 140 boot services regions. Some of them are 
contiguous and we could just merge them for e820, but that leaves us at 
the whim of whoever wrote the allocator for the firmware. And do you 
want to bet on them having done this sanely?

-- 
Matthew Garrett | mjg59@...f.ucam.org
--
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/