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:	Mon, 25 Aug 2014 13:53:06 +0100
From:	Matt Fleming <matt@...sole-pimps.org>
To:	Mantas Mikulėnas <grawity@...il.com>
Cc:	Harald Hoyer <harald@...hat.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-efi@...r.kernel.org, Yinghai Lu <yinghai@...nel.org>,
	Matt Fleming <matt.fleming@...el.com>,
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: Loading initrd above 4G causes freeze on boot

On Mon, 25 Aug, at 02:08:59PM, Mantas Mikulėnas wrote:
> 
> Well, all I could find is:
> 
> > Freeing initrd memory: 5552K (ffff8800be22e000 - ffff8800be79a000)
> 
> Attaching the entire log.

Here we go,

> [    0.000000] RAMDISK: [mem 0xbe22e000-0xbe799fff]

OK, we're out of options here. Yinghai, we're going to have to revert
your patch, 4bf7111f5016 ("x86/efi: Support initrd loaded above 4G")

We could conceivably add a boot parameter option to attempt loading
inirds above 4G, but we can't turn the feature on by default because of
all these buggy EFI implementations - things must work out of the box.

But the boot parameter would be useful for those people that a) know
their firmware isn't buggy and b) need to leave < 4G memory available
for use by other things. Yinghai, can you provide some justification for
your original commit? Do you have concrete use cases where loading
initrds above 4G is critical? How important is it that we enable this
functionality as opposed to reverting it?

It might also make sense to bump the default max initrd address
(hdr->initrd_addr_max) from 0x7fffffff to 0xffffffff at this point.
Peter, do you forsee any problem with this change?

-- 
Matt Fleming, Intel Open Source Technology Center
--
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/

Powered by blists - more mailing lists