[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAB=NE6VC6m8N3Me4ek7jXkBi_fv6S_oYN8-sHLdPJPd2CUEZNQ@mail.gmail.com>
Date: Tue, 3 May 2016 10:07:34 -0700
From: "Luis R. Rodriguez" <mcgrof@...e.com>
To: Kees Cook <keescook@...omium.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 Mon, May 2, 2016 at 11:34 AM, Kees Cook <keescook@...omium.org> 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.)
To be clear the RFC patch here is about linker table use and porting
custom table uses for a generic linker table solution. The topic of
conversation later changed to suggest that instead of porting built-in
firmware to linker tables we should just consider removing built-in
firmware all together. As for the reason _why_ we'd port built-in
firmware to linker tables, I'll be sure to add that in the next
iteration. The reason is that Linux has scattered strategies to both
extend and use custom linker sections, often requiring modifying the
custom linker script. The effort behind the linker script provides a
unified mechanism to do this, and also enables us to avoid having to
extend the custom linker script for this type of use.
> 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.
Thanks! Can you confirm if any Android or Brillo builds are already using it?
Luis
Powered by blists - more mailing lists