linux-kernel - Re: [RFC v2 3/7] firmware: port built-in section to linker table

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: <CAGXu5jL9i38=yahifwC1GWeo4E3y66-eojBe6AmXWj6UvmK2sg@mail.gmail.com>
Date:	Tue, 3 May 2016 10:21:37 -0700
From:	Kees Cook <keescook@...omium.org>
To:	"Luis R. Rodriguez" <mcgrof@...nel.org>
Cc:	David Woodhouse <dwmw2@...radead.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
	"x86@...nel.org" <x86@...nel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Andy Lutomirski <luto@...capital.net>,
	Boris Ostrovsky <boris.ostrovsky@...cle.com>,
	Rusty Russell <rusty@...tcorp.com.au>,
	David Vrabel <david.vrabel@...rix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	Michael Brown <mcb30@...e.org>,
	Juergen Gross <jgross@...e.com>,
	Ming Lei <ming.lei@...onical.com>,
	Greg KH <gregkh@...uxfoundation.org>,
	Arnd Bergmann <arnd@...db.de>,
	linux-arch <linux-arch@...r.kernel.org>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	"benh@...nel.crashing.org" <benh@...nel.crashing.org>,
	jbaron@...mai.com, "ananth@...ibm.com" <ananth@...ibm.com>,
	anil.s.keshavamurthy@...el.com,
	"David S. Miller" <davem@...emloft.net>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
	"xen-devel@...ts.xensource.com" <xen-devel@...ts.xensource.com>
Subject: Re: [RFC v2 3/7] firmware: port built-in section to linker table

On Tue, May 3, 2016 at 10:10 AM, Luis R. Rodriguez <mcgrof@...nel.org> wrote:
> On Tue, May 3, 2016 at 10:07 AM, Luis R. Rodriguez <mcgrof@...e.com> wrote:
>> Thanks! Can you confirm if any Android or Brillo builds are already using it?
>
> Also more importantly, any chance you can provide any technical
> reasons why initramfs cannot be used, or it was decided to not use it
> on these systems? It should help others in the future as well.

In Chrome OS, the kernels are built specifically for the hardware
they're going to be on, so an initramfs was seen as a needless
additional boot step. Since Chrome OS was heavily optimized for boot
speed, it was designed to not need the initramfs at all. This is
actually enforced by the read-only boot firmware, so there's no
trivial way to _start_ using an initramfs on (existing) Chrome OS
devices either.

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security