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: <59938F3B.30704@gmail.com>
Date:   Tue, 15 Aug 2017 17:18:03 -0700
From:   Frank Rowand <frowand.list@...il.com>
To:     Tom Rini <trini@...sulko.com>, devicetree@...r.kernel.org
Cc:     Tero Kristo <t-kristo@...com>, Nishanth Menon <nm@...com>,
        Tomi Valkeinen <tomi.valkeinen@...com>,
        Sekhar Nori <nsekhar@...com>, Rob Herring <robh+dt@...nel.org>,
        Masahiro Yamada <yamada.masahiro@...ionext.com>,
        Michal Marek <mmarek@...e.com>,
        Pantelis Antoniou <pantelis.antoniou@...sulko.com>,
        linux-kernel@...r.kernel.org, linux-kbuild@...r.kernel.org
Subject: Re: [PATCH] devicetree: Enable generation of __symbols__ in all dtb
 files

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.

< snip >

And for some background, for those who were not on the irc channel,
here is the conversation that Tom and I had:

<Tartarus> frowand: So, dtc knows -@, but the kernel doesn't globally use -@ yet due to increased memory usage, in the dtb?
<frowand> yes
<frowand> It is available via the pattern that you can see in drivers/of/unittest-data/Makefile
<Tartarus> Is there an opt-in way to get the extra symbols?
<frowand> # enable creation of __symbols__ node
<frowand> DTC_FLAGS_overlay := -@
<Tartarus> ah, hm
<frowand> The problem is that it is always on, once the flags are added
<frowand> there are a few ways I have thought of making it optional
<frowand> 1) DTC_FLAGS_overlay := CONFIG_OVERLAY_ENABLED_IN_BASE
<Tartarus> OK.  There's at least a few vendors that are eagerly awaiting overlays Just Working, is why I'm asking
<Tartarus> How much extra memory usage are we talking about, on a 'big' platform for example?
<frowand> where  CONFIG_OVERLAY_ENABLED_IN_BASE is a string of either empty or "-@".  I don't know if the kconfig allows that, but I'm guessing there is some way to do it
<frowand> Not sure of size penalty.
<Tartarus> CONFIG_USE_xxx as a bool, CONFIG_xxx as the string
<Tartarus> I would kind of assume wanting overlays to just work would be the common case, at least in terms of in-kernel users
<frowand> 2) When instantiating the device tree from the FDT, do not keep the __SYMBOLS__ node if overlays are not enabled in the kernel
<Tartarus> ie if it's a CONFIG opt-in, multi_v7_defconfig, etc, would want it on
<frowand> the issue with 2, is that the boot image still has the size penalty
<frowand> 3) the bootloader could choose whether to pass the __SYMBOLS__ node to the kernel or not
<Tartarus> I'm not sure about 3 honestly
<frowand> Yep, 3 is my least favorite.
<Tartarus> If one has a case where there's a desire for no overlay support, for whatever reason, that's a feature of the kernel
<frowand> There is probably also option 4, 5, etc.  But I haven't thought it through too deeply yet.
<Tartarus> I can see some sort of CONFIG option, default y, being a reasonable option here
<frowand> I'm not sure about the common case.  There are some boards where overlays would almost always be used, but there may also be boards where there are rarely used.
<frowand> But the common case is a bikeshed issue to me.
<Tartarus> heh
<Tartarus> Well, here's why I was thinking that
<frowand> As long as the users and distros have a way to control it.
<Tartarus> Lots of proprietary boards I've dealt with could just be an EVM + overlay
<Tartarus> wrt dtb
<frowand> what is EVM?
<Tartarus> Today it's take the evm dts, start hacking
<Tartarus> evaluation platform
<Tartarus> The second, similar, example would be custom platforms based on SoMs
<frowand> Are you saying to use an overlay to add onto the base EVM dts kinda sorta the way that some driver writers use kernel modules to add drivers?
<Tartarus> A reasonable analogy, yes
<frowand> ok, just wanted to verify I understood the model
<frowand> I see that as a reasonable development technique
<frowand> I have some time critical errands to run, so I'll be gone for a few hours.  It would be good to share what we just said with the mail list, and see if anyone else has some brilliant ideas.  Start with what the objectives/issues are, some possible solutions...