linux-kernel - Re: [PATCH] of: reserved_mem: Add heuristic to validate reserved memory regions

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: <CAL_Jsq+CugQrswhOWntK5RiRBSKkWRNUoB0pB8HoKPmym2e65w@mail.gmail.com>
Date: Tue, 14 Oct 2025 08:12:19 -0500
From: Rob Herring <robh@...nel.org>
To: Andrea della Porta <andrea.porta@...e.com>
Cc: Saravana Kannan <saravanak@...gle.com>, devicetree@...r.kernel.org, 
	linux-kernel@...r.kernel.org, iivanov@...e.de, svarbanov@...e.de, 
	mbrugger@...e.com, Phil Elwell <phil@...pberrypi.com>
Subject: Re: [PATCH] of: reserved_mem: Add heuristic to validate reserved
 memory regions

On Tue, Oct 14, 2025 at 2:32 AM Andrea della Porta
<andrea.porta@...e.com> wrote:
>
> When parsing static reserved-memory DT nodes, any node with a reg property
> length that is not perfectly conformant is discarded.
> Specifically, any reg property whose length is not a multiple of the parent's
> (#address-cells + #size-cells) is dropped.
>
> Relax this condition (while still treating perfect multiples as having higher
> precedence) by allowing regions that are subsets of the parent's addressable
> space to be considered for inclusion.
> For example, in the following scenario:
>
> / {
>         #address-cells = <0x02>;
>         #size-cells = <0x02>;
>         ...
>
>         reserved-memory {
>                 #address-cells = <0x02>;
>                 #size-cells = <0x02>;
>                 ...
>
>                 nvram {
>                         reg = <0x00 0x3fd16d00 0x37>;
>                         ...
>                 };
>         };
> };
>
> Even though the reg property of the nvram node is not well-formed from a DT
> syntax perspective, it still references a perfectly valid memory region of
> 0x37 bytes that should be reserved.

No it isn't. I could just as easily argue that the reserved size
should be 0x37_00000000 because it's BE data. I have little interest
in supporting incorrect DTs especially generically where we have no
clue what platform needs it and whether we still have to carry the
code. There's enough of that crap with ancient PPC and Sparc systems.

Furthermore, this looks like an abuse of /reserved-memory which should
*only* be holes in what /memory node(s) define. I don't think we
enforce that and I imagine there is lots of abuse.

> This has at least one real-world equivalent on the Raspberry Pi 5, for example,
> on which the firmware incorrectly overwrites the nvram node's reg property
> without taking into account the actual value of the parent's #size-cells.

If we have to support this broken firmware, the kernel should fixup
the entry to be correct.

Rob