[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160502184106.GA17329@kroah.com>
Date: Mon, 2 May 2016 11:41:06 -0700
From: Greg KH <gregkh@...uxfoundation.org>
To: Kees Cook <keescook@...omium.org>
Cc: "Luis R. Rodriguez" <mcgrof@...e.com>,
David Woodhouse <dwmw2@...radead.org>,
"Luis R. Rodriguez" <mcgrof@...nel.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>,
mcb30@...e.org, jgross@...e.com, Ming Lei <ming.lei@...onical.com>,
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 Mon, May 02, 2016 at 11:34:33AM -0700, Kees Cook wrote:
> On Mon, Feb 29, 2016 at 10:56 AM, Luis R. Rodriguez <mcgrof@...e.com> wrote:
> > On Mon, Feb 29, 2016 at 10:12:50AM +0000, David Woodhouse wrote:
> >> On Fri, 2016-02-19 at 05:45 -0800, Luis R. Rodriguez wrote:
> >> > This ports built-in firmware to use linker tables,
> >> > this replaces the custom section solution with a
> >> > generic solution.
> >> >
> >> > This also demos the use of the .rodata (SECTION_RO)
> >> > linker tables.
> >> >
> >> > Tested with 0 built-in firmware, 1 and 2 built-in
> >> > firmwares successfully.
> >>
> >> I think we'd do better to rip this support out entirely. It just isn't
> >> needed; firmware can live in an initramfs and don't even need *any*
> >> actual running userspace support to load it from there these days, do
> >> we?
> >
> > I think this is reasonable if and only if we really don't know of anyone
> > out there not able to use initramfs. I'm happy to rip it out.
>
> The changelog for this doesn't say anything about _why_ the change is
> being made? (and what about other architectures.) Also, Chrome OS
> doesn't use an initramfs (and plenty of other things don't too). Being
> able to build monolithic kernels (e.g. Android and Brillo) with
> builtin firmware is very handy. Please don't remove built-in firmware
> support.
I second this, we can't break existing systems at all. I thought we
were going to keep built-in firmware, right Luis?
thanks,
greg k-h
Powered by blists - more mailing lists