linux-kernel - Re: Backporting commits for generating rpi dtb symbols to stable

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: <20230716195150.ppa6vdjogjevlzgq@pali>
Date:   Sun, 16 Jul 2023 21:51:50 +0200
From:   Pali Rohár <pali@...nel.org>
To:     Greg KH <greg@...ah.com>
Cc:     Aurelien Jarno <aurelien@...el32.net>,
        Florian Fainelli <florian.fainelli@...adcom.com>,
        stable@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: Backporting commits for generating rpi dtb symbols to stable

On Sunday 16 July 2023 21:08:38 Greg KH wrote:
> On Sun, Jul 16, 2023 at 06:38:52PM +0200, Pali Rohár wrote:
> > On Sunday 16 July 2023 18:32:42 Greg KH wrote:
> > > On Sun, Jul 16, 2023 at 06:24:44PM +0200, Pali Rohár wrote:
> > > > Hello,
> > > > 
> > > > I see that raspberry pi bootloader throws ton of warnings when supplied
> > > > DTB file does not contain /__symbols__/ node.
> > > > 
> > > > On RPI 1B rev1 it looks like this:
> > > > 
> > > > dterror: no symbols found
> > > > dterror: no symbols found
> > > > dterror: no symbols found
> > > > dterror: no symbols found
> > > > dterror: no symbols found
> > > > dterror: no symbols found
> > > > dterror: no symbols found
> > > > dterror: no symbols found
> > > > dterror: no symbols found
> > > > dterror: no symbols found
> > > > 
> > > > Bootloader also propagates these warnings to kernel via dtb property
> > > > chosen/user-warnings and they can be read by simple command:
> > > > 
> > > > $ cat /sys/firmware/devicetree/base/chosen/user-warnings
> > > > ...
> > > > 
> > > > Upstream Linux kernel build process by default does not generate
> > > > /__symbols__/ node for DTB files, but DTB files provided by raspberrypi
> > > > foundation have them for a longer time.
> > > > 
> > > > I wanted to look at this issue, but I figured out that it is already
> > > > solved by just recent Aurelien's patches:
> > > > 
> > > > e925743edc0d ("arm: dts: bcm: Enable device-tree overlay support for RPi devices")
> > > > 3cdba279c5e9 ("arm64: dts: broadcom: Enable device-tree overlay support for RPi devices")
> > > > 
> > > > My testing showed that /__symbols__/ node is required by rpi bootloader
> > > > for overlay support even when overlayed DTB file does not use any DTB
> > > > symbol (and reference everything via full node path). So seems that
> > > > /__symbols__/ node is crucial for rpi bootloader even when symbols from
> > > > them are not used at all.
> > > > 
> > > > So I would like to ask, would you consider backporting these two
> > > > raspberry pi specific patches to stable kernel trees? Upstream kernel
> > > > would get rid of those bootloader warnings and also allow users to use
> > > > overlayed dtbs...
> > > 
> > > What kernel tree(s) should these be applied to?  What trees did you test
> > > them for?
> > > 
> > > Also, adding dt-overlay support does not seem like a stable kernel fix,
> > > as this isn't a bugfix from what I can tell, right?
> > > 
> > > thanks,
> > > 
> > > greg k-h
> > 
> > I wanted to discuss what do you think about it. As I wrote my motivation
> > was to understood and get rid of those warnings "dterror: no symbols
> > found" from bootloader when using DTB files from mainline kernel (as
> > opposite of the DTB files from rpi foundation). And fix for it was just
> > to generate DTB files from kernel via dtc's -@ parameter, same what are
> > doing those mentioned patches (but they describe different problem for
> > which is same fix). I thought that fixing those bootloader warnings is a
> > bugfix.
> 
> Why not just use the next kernel version instead?  What's forcing you to
> use an older stable kernel that didn't have dt-overlay support?
> 
> thanks,
> 
> greg k-h

Why not use the next kernel? It is pretty simple, next is the
development tree, not for production. And as I wrote in previous email,
I do not need here dt-overlay support. I wanted to get rid off that
warning messages.