linux-kernel - Re: [PATCH] devicetree: Enable generation of __symbols_

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: <20170816154129.GP20467@bill-the-cat>
Date:   Wed, 16 Aug 2017 11:41:29 -0400
From:   Tom Rini <trini@...sulko.com>
To:     Rob Herring <robh+dt@...nel.org>
Cc:     Frank Rowand <frowand.list@...il.com>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        Tero Kristo <t-kristo@...com>, Nishanth Menon <nm@...com>,
        Tomi Valkeinen <tomi.valkeinen@...com>,
        Sekhar Nori <nsekhar@...com>,
        Masahiro Yamada <yamada.masahiro@...ionext.com>,
        Michal Marek <mmarek@...e.com>,
        Pantelis Antoniou <pantelis.antoniou@...sulko.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>
Subject: Re: [PATCH] devicetree: Enable generation of __symbols__ in all dtb
 files

On Wed, Aug 16, 2017 at 10:22:03AM -0500, Rob Herring wrote:
> On Tue, Aug 15, 2017 at 7:42 PM, Tom Rini <trini@...sulko.com> wrote:
> > On Tue, Aug 15, 2017 at 04:50:40PM -0700, Frank Rowand wrote:
> >> On 08/15/17 14:15, Tom Rini wrote:
> >> > With support for stacked overlays being part of libfdt it is now
> >> > possible and likely that overlays which require __symbols__ will be
> >> > applied to the dtb files generated by the kernel.  This is done by
> >> > passing -@ to dtc.  This does increase the filesize (and resident memory
> >> > usage) based on the number of __symbol__ entries added to match the
> >> > contents of the dts.
> >> >
> >> > Cc: Rob Herring <robh+dt@...nel.org>
> >> > Cc: Frank Rowand <frowand.list@...il.com>
> >> > Cc: Masahiro Yamada <yamada.masahiro@...ionext.com>
> >> > Cc: Michal Marek <mmarek@...e.com>
> >> > Cc: Pantelis Antoniou <pantelis.antoniou@...sulko.com>
> >> > Cc: devicetree@...r.kernel.org
> >> > Cc: linux-kernel@...r.kernel.org
> >> > CC: linux-kbuild@...r.kernel.org
> >> > Signed-off-by: Tom Rini <trini@...sulko.com>
> >> > ---
> >> > In order for a dtb file to be useful with all types of overlays, it
> >> > needs to be generated with the -@ flag passed to dtc so that __symbols__
> >> > are generated.  This however is not free, and increases the resulting
> >> > dtb file by up to approximately 50% today.  In the current worst case
> >> > this is moving from 88KiB to 133KiB.  In talking with Frank about this,
> >> > he outlined 3 possible ways (with the 4th option of something else
> >> > entirely).
> >> >
> >> > 1. Make passing -@ to dtc be dependent upon some CONFIG symbol.
> >> > 2. In the kernel, if the kernel does not have overlay support, discard
> >> > the __symbols__ information that we've been passed.
> >> > 3. Have the bootloader pass in, or not, __symbols__ information.
> >>
> >> I also was hoping that other people might have ideas for additional
> >> approaches.
> >
> > Yes, please.
> 
> A couple of other options come to mind:
> 
> "make DTC_FLAGS='-@' dtbs" should already work. So there's already a
> way to build what you want and the kernel is not setting the policy.

Not ideal since that drops out the -Wno... flags we pass in.  I don't
see off-hand why it's not appending to DTC_FLAGS, but that's a fixable
problem.

> Do like we do for the unittests and make it a per board decision:
> 
> DTC_FLAGS_my-som-board.dtb := -@
> 
> Then boards that actually need it like SoMs can turn it on.

A concern about that of mine is that we'll start to see a 'flood' of
patches growing that list at the end of arch/arm/boot/dts/Makefile.

-- 
Tom

Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)