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: <4E9C8AAC.7080803@gmail.com>
Date:	Mon, 17 Oct 2011 22:06:04 +0200
From:	Maarten Lankhorst <m.b.lankhorst@...il.com>
To:	Matt Fleming <matt@...sole-pimps.org>
CC:	"H. Peter Anvin" <hpa@...ux.intel.com>,
	Matthew Garrett <mjg@...hat.com>, linux-kernel@...r.kernel.org,
	Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>, x86@...nel.org,
	Matt Fleming <matt.fleming@...el.com>,
	Mike Waychison <mikew@...gle.com>,
	Andi Kleen <andi@...stfloor.org>
Subject: Re: [PATCH v5 10/10] x86, efi: EFI boot stub support

Hey Matt,

On 10/17/2011 12:40 PM, Matt Fleming wrote:
> From: Matt Fleming <matt.fleming@...el.com>
>
> There is currently a large divide between kernel development and the
> development of EFI boot loaders. The idea behind this patch is to give
> the kernel developers full control over the EFI boot process. As
> H. Peter Anvin put it,
>
> "The 'kernel carries its own stub' approach been very successful in
> dealing with BIOS, and would make a lot of sense to me for EFI as
> well."
>
> This patch introduces an EFI boot stub that allows an x86 bzImage to
> be loaded and executed by EFI firmware. The bzImage appears to the
> firmware as an EFI application. Luckily there are enough free bits
> within the bzImage header so that it can masquerade as an EFI
> application, thereby coercing the EFI firmware into loading it and
> jumping to its entry point. The beauty of this masquerading approach
> is that both BIOS and EFI boot loaders can still load and run the same
> bzImage, thereby allowing a single kernel image to work in any boot
> environment.
>
> The EFI boot stub supports multiple initrds, but they must exist on
> the same partition as the bzImage. Command-line arguments for the
> kernel can be appended after the bzImage name when run from the EFI
> shell, e.g.
>
> Shell> bzImage console=ttyS0 root=/dev/sdb initrd=initrd.img
Seems initrd is failing for me. Is there any limitation on the size of the initrd? The default one fedora generates for my kernel is 46mb. It loads the kernel, but it reboots before it gets to userspace. Loading the kernel and initrd with grub2-efi works. EFI booting without initrd works too.

Cheers,
Maarten
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ