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] [day] [month] [year] [list]

Message-ID: <f214c0a0-c9f6-bfbb-3d75-2a2f7602083f@broadcom.com>
Date:   Mon, 17 Jul 2023 12:38:41 +0200
From:   Florian Fainelli <florian.fainelli@...adcom.com>
To:     Pali Rohár <pali@...nel.org>,
        Greg KH <greg@...ah.com>
Cc:     Aurelien Jarno <aurelien@...el32.net>, stable@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: Backporting commits for generating rpi dtb symbols to stable



On 7/16/2023 9:51 PM, Pali Rohár wrote:
> 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.

Maybe "next" should have not been taken as designating linux-next, but 
whichever kernel version you are currently using wait for 6.5 final and 
use it since it does contains Aurelien's commits.

> And as I wrote in previous email,
> I do not need here dt-overlay support. I wanted to get rid off that
> warning messages.

The motivation does not seem appropriate to warrant a stable backport, 
besides as noted in the commit message including relocation information 
inflates the resulting .dtb files, which could be seen as a regression.
-- 
Florian

Download attachment "smime.p7s" of type "application/pkcs7-signature" (4221 bytes)