devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v2] of: reserved_mem: Add fixup function to amend corrupted reserved memory regions
@ 2025-11-05 16:08 Andrea della Porta
  2025-11-14 18:19 ` Rob Herring
  0 siblings, 1 reply; 3+ messages in thread
From: Andrea della Porta @ 2025-11-05 16:08 UTC (permalink / raw)
  To: Rob Herring, Saravana Kannan, devicetree, linux-kernel, iivanov,
	svarbanov, mbrugger, Phil Elwell
  Cc: Andrea della Porta

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.

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.

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.

Add a fixup function that corrects the FDT in early stage by adding the
missing cell in the size portion of the reg property, so that the resulting
DT is well-formed and can be correctly parsed.
Since it's searching for 'raspberrypi,bootloader-config' compatible
node, this fix is specific for Raspberry PI.

Signed-off-by: Andrea della Porta <andrea.porta@suse.com>
---
This patch can be considered a followup version of [1] even though the
commit subject has changed entirely and the approch has evolved from a
general heuristic to a fixup handler specific for RPi5.

A couple of notes:

* The FDT region is precisely sized so I needed to copy it on a new
  buffer big enough to contain it. Using memblock to dinamically allocate
  the precise amount of memory is not feasible since memblock cannot
  be used before paging is up. Also, AFAIK any memory allocated through
  memblock will be reclaimed by the buddy allocator and we need that
  memory to be preserved since it will be referenced by the live DT.
  This could *may* be avoided via a clever usage of memblock_reserve()
  and mapping the memory later, but we still have the former problem of
  not being able to map the memory for immediate usage.
  So I've just used a static buffer that should be big enough to
  accomodate for the DTB + overlays.
  For reference, those are the current sizes for the DTBs for RPi5:

  - upstream DTB: ~23Kb
  - downstream DTB: ~85Kb
  - size of the static buffer: 150Kb

  If this space is of concern to anyone we can maybe guard this fixup
  handelr behind a CONFIG_ option.

* This fixup is specific for RPi5 and I don't have in mind any other
  use cases for other handlers, but in case we need to extend this for
  other platforms it may be worth to setup a list of handlers to be
  registered so that they can be called in sequence (and on specific
  nodes).

Links:
[1] - https://lore.kernel.org/all/aO-Q6xMDd8Bfeww2@apocalypse/
---
 drivers/of/of_reserved_mem.c | 77 +++++++++++++++++++++++++++++++++++-
 1 file changed, 76 insertions(+), 1 deletion(-)

diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
index 2e9ea751ed2d..2c278ab91b9d 100644
--- a/drivers/of/of_reserved_mem.c
+++ b/drivers/of/of_reserved_mem.c
@@ -148,6 +148,73 @@ static int __init early_init_dt_reserve_memory(phys_addr_t base,
 	return memblock_reserve(base, size);
 }
 
+static void * __init of_apply_rmem_fixups(const void *fdt, int node)
+{
+	int t_len = (dt_root_addr_cells + dt_root_size_cells) * sizeof(__be32);
+	int parent_node, new_node, child;
+	static char new_fdt[150000];
+	int len, err, alloc_size;
+	phys_addr_t base, size;
+	__be32 new_reg_prop[4];
+	const __be32 *prop;
+	const char *uname;
+
+	fdt_for_each_subnode(child, fdt, node) {
+		if (!of_fdt_device_is_available(fdt, child))
+			continue;
+
+		prop = of_get_flat_dt_prop(child, "reg", &len);
+		if (!prop ||
+		    !of_flat_dt_is_compatible(child, "raspberrypi,bootloader-config") ||
+		    (t_len - len) != sizeof(__be32) ||
+		    t_len != 4 * sizeof(__be32))
+			continue;
+
+		alloc_size = fdt_totalsize(fdt) + sizeof(__be32);
+		err = fdt_open_into(fdt, new_fdt, alloc_size);
+		if (err) {
+			pr_err("Failed to open FDT\n");
+			return ERR_PTR(err);
+		}
+
+		base = dt_mem_next_cell(dt_root_addr_cells, &prop);
+		size = dt_mem_next_cell(1, &prop);
+		new_reg_prop[0] = cpu_to_be32(upper_32_bits(base));
+		new_reg_prop[1] = cpu_to_be32(lower_32_bits(base));
+		new_reg_prop[2] = 0;
+		new_reg_prop[3] = cpu_to_be32(size);
+
+		parent_node = fdt_path_offset(new_fdt, "/reserved-memory");
+		if (parent_node < 0) {
+			pr_err("No reserved-memory node in the copied FDT\n");
+			return ERR_PTR(parent_node);
+		}
+
+		uname = fdt_get_name(fdt, child, NULL);
+		if (!uname) {
+			pr_err("Cannot retrieve the node name\n");
+			return ERR_PTR(-EINVAL);
+		}
+
+		new_node = fdt_subnode_offset(new_fdt, parent_node, uname);
+		if (new_node < 0) {
+			pr_err("No %s node in the copied FDT\n", uname);
+			return ERR_PTR(new_node);
+		}
+
+		err = fdt_setprop(new_fdt, new_node, "reg", new_reg_prop, sizeof(new_reg_prop));
+		if (err < 0) {
+			pr_warn("Cannot fix 'reg' property for node %s: %s\n",
+				uname, fdt_strerror(err));
+			return ERR_PTR(err);
+		}
+
+		return new_fdt;
+	}
+
+	return NULL;
+}
+
 /*
  * __reserved_mem_reserve_reg() - reserve all memory described in 'reg' property
  */
@@ -295,7 +362,8 @@ int __init fdt_scan_reserved_mem(void)
 	int node, child;
 	int dynamic_nodes_cnt = 0, count = 0;
 	int dynamic_nodes[MAX_RESERVED_REGIONS];
-	const void *fdt = initial_boot_params;
+	void *fdt = initial_boot_params;
+	void *fixed_fdt;
 
 	node = fdt_path_offset(fdt, "/reserved-memory");
 	if (node < 0)
@@ -306,6 +374,13 @@ int __init fdt_scan_reserved_mem(void)
 		return -EINVAL;
 	}
 
+	fixed_fdt = of_apply_rmem_fixups(fdt, node);
+	if (!IS_ERR_OR_NULL(fixed_fdt)) {
+		initial_boot_params = fixed_fdt;
+		fdt = fixed_fdt;
+		node = fdt_path_offset(fdt, "/reserved-memory");
+	}
+
 	fdt_for_each_subnode(child, fdt, node) {
 		const char *uname;
 		int err;
-- 
2.35.3


^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: [PATCH v2] of: reserved_mem: Add fixup function to amend corrupted reserved memory regions
  2025-11-05 16:08 [PATCH v2] of: reserved_mem: Add fixup function to amend corrupted reserved memory regions Andrea della Porta
@ 2025-11-14 18:19 ` Rob Herring
  2025-12-19 18:03   ` Andrea della Porta
  0 siblings, 1 reply; 3+ messages in thread
From: Rob Herring @ 2025-11-14 18:19 UTC (permalink / raw)
  To: Andrea della Porta
  Cc: Saravana Kannan, devicetree, linux-kernel, iivanov, svarbanov,
	mbrugger, Phil Elwell

On Wed, Nov 05, 2025 at 05:08:18PM +0100, Andrea della Porta 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.
> 
> 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.
> 
> 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.
> 
> Add a fixup function that corrects the FDT in early stage by adding the
> missing cell in the size portion of the reg property, so that the resulting
> DT is well-formed and can be correctly parsed.
> Since it's searching for 'raspberrypi,bootloader-config' compatible
> node, this fix is specific for Raspberry PI.
> 
> Signed-off-by: Andrea della Porta <andrea.porta@suse.com>
> ---
> This patch can be considered a followup version of [1] even though the
> commit subject has changed entirely and the approch has evolved from a
> general heuristic to a fixup handler specific for RPi5.
> 
> A couple of notes:
> 
> * The FDT region is precisely sized so I needed to copy it on a new
>   buffer big enough to contain it. Using memblock to dinamically allocate
>   the precise amount of memory is not feasible since memblock cannot
>   be used before paging is up. Also, AFAIK any memory allocated through
>   memblock will be reclaimed by the buddy allocator and we need that
>   memory to be preserved since it will be referenced by the live DT.
>   This could *may* be avoided via a clever usage of memblock_reserve()
>   and mapping the memory later, but we still have the former problem of
>   not being able to map the memory for immediate usage.
>   So I've just used a static buffer that should be big enough to
>   accomodate for the DTB + overlays.
>   For reference, those are the current sizes for the DTBs for RPi5:
> 
>   - upstream DTB: ~23Kb
>   - downstream DTB: ~85Kb
>   - size of the static buffer: 150Kb
> 
>   If this space is of concern to anyone we can maybe guard this fixup
>   handelr behind a CONFIG_ option.

Can't we just ensure the FDT mapping has extra space. Just rounding up 
to the next page size should be plenty. 

Otherwise, the FDT is no longer where the arch thinks it is. Arm64 makes 
the FDT read-only after calling early_init_dt_scan(), but that would 
have no effect (perhaps read-only is pointless though). 

> 
> * This fixup is specific for RPi5 and I don't have in mind any other
>   use cases for other handlers, but in case we need to extend this for
>   other platforms it may be worth to setup a list of handlers to be
>   registered so that they can be called in sequence (and on specific
>   nodes).
> 
> Links:
> [1] - https://lore.kernel.org/all/aO-Q6xMDd8Bfeww2@apocalypse/
> ---
>  drivers/of/of_reserved_mem.c | 77 +++++++++++++++++++++++++++++++++++-
>  1 file changed, 76 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
> index 2e9ea751ed2d..2c278ab91b9d 100644
> --- a/drivers/of/of_reserved_mem.c
> +++ b/drivers/of/of_reserved_mem.c
> @@ -148,6 +148,73 @@ static int __init early_init_dt_reserve_memory(phys_addr_t base,
>  	return memblock_reserve(base, size);
>  }
>  
> +static void * __init of_apply_rmem_fixups(const void *fdt, int node)
> +{
> +	int t_len = (dt_root_addr_cells + dt_root_size_cells) * sizeof(__be32);
> +	int parent_node, new_node, child;
> +	static char new_fdt[150000];
> +	int len, err, alloc_size;
> +	phys_addr_t base, size;
> +	__be32 new_reg_prop[4];
> +	const __be32 *prop;
> +	const char *uname;
> +
> +	fdt_for_each_subnode(child, fdt, node) {
> +		if (!of_fdt_device_is_available(fdt, child))
> +			continue;
> +
> +		prop = of_get_flat_dt_prop(child, "reg", &len);
> +		if (!prop ||
> +		    !of_flat_dt_is_compatible(child, "raspberrypi,bootloader-config") ||
> +		    (t_len - len) != sizeof(__be32) ||
> +		    t_len != 4 * sizeof(__be32))
> +			continue;
> +
> +		alloc_size = fdt_totalsize(fdt) + sizeof(__be32);
> +		err = fdt_open_into(fdt, new_fdt, alloc_size);
> +		if (err) {
> +			pr_err("Failed to open FDT\n");
> +			return ERR_PTR(err);
> +		}
> +
> +		base = dt_mem_next_cell(dt_root_addr_cells, &prop);
> +		size = dt_mem_next_cell(1, &prop);
> +		new_reg_prop[0] = cpu_to_be32(upper_32_bits(base));
> +		new_reg_prop[1] = cpu_to_be32(lower_32_bits(base));
> +		new_reg_prop[2] = 0;
> +		new_reg_prop[3] = cpu_to_be32(size);
> +
> +		parent_node = fdt_path_offset(new_fdt, "/reserved-memory");
> +		if (parent_node < 0) {
> +			pr_err("No reserved-memory node in the copied FDT\n");
> +			return ERR_PTR(parent_node);
> +		}
> +
> +		uname = fdt_get_name(fdt, child, NULL);
> +		if (!uname) {
> +			pr_err("Cannot retrieve the node name\n");
> +			return ERR_PTR(-EINVAL);
> +		}
> +
> +		new_node = fdt_subnode_offset(new_fdt, parent_node, uname);
> +		if (new_node < 0) {
> +			pr_err("No %s node in the copied FDT\n", uname);
> +			return ERR_PTR(new_node);
> +		}
> +
> +		err = fdt_setprop(new_fdt, new_node, "reg", new_reg_prop, sizeof(new_reg_prop));
> +		if (err < 0) {
> +			pr_warn("Cannot fix 'reg' property for node %s: %s\n",
> +				uname, fdt_strerror(err));
> +			return ERR_PTR(err);
> +		}
> +
> +		return new_fdt;
> +	}
> +
> +	return NULL;

I think we should print some message along the lines of 'fix your 
buggy firmware'.

Rob

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH v2] of: reserved_mem: Add fixup function to amend corrupted reserved memory regions
  2025-11-14 18:19 ` Rob Herring
@ 2025-12-19 18:03   ` Andrea della Porta
  0 siblings, 0 replies; 3+ messages in thread
From: Andrea della Porta @ 2025-12-19 18:03 UTC (permalink / raw)
  To: Rob Herring
  Cc: Andrea della Porta, Saravana Kannan, devicetree, linux-kernel,
	iivanov, svarbanov, mbrugger, Phil Elwell

Hi Rob,

On 12:19 Fri 14 Nov     , Rob Herring wrote:
> On Wed, Nov 05, 2025 at 05:08:18PM +0100, Andrea della Porta 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.
> > 
> > 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.
> > 
> > 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.
> > 
> > Add a fixup function that corrects the FDT in early stage by adding the
> > missing cell in the size portion of the reg property, so that the resulting
> > DT is well-formed and can be correctly parsed.
> > Since it's searching for 'raspberrypi,bootloader-config' compatible
> > node, this fix is specific for Raspberry PI.
> > 
> > Signed-off-by: Andrea della Porta <andrea.porta@suse.com>
> > ---
> > This patch can be considered a followup version of [1] even though the
> > commit subject has changed entirely and the approch has evolved from a
> > general heuristic to a fixup handler specific for RPi5.
> > 
> > A couple of notes:
> > 
> > * The FDT region is precisely sized so I needed to copy it on a new
> >   buffer big enough to contain it. Using memblock to dinamically allocate
> >   the precise amount of memory is not feasible since memblock cannot
> >   be used before paging is up. Also, AFAIK any memory allocated through
> >   memblock will be reclaimed by the buddy allocator and we need that
> >   memory to be preserved since it will be referenced by the live DT.
> >   This could *may* be avoided via a clever usage of memblock_reserve()
> >   and mapping the memory later, but we still have the former problem of
> >   not being able to map the memory for immediate usage.
> >   So I've just used a static buffer that should be big enough to
> >   accomodate for the DTB + overlays.
> >   For reference, those are the current sizes for the DTBs for RPi5:
> > 
> >   - upstream DTB: ~23Kb
> >   - downstream DTB: ~85Kb
> >   - size of the static buffer: 150Kb
> > 
> >   If this space is of concern to anyone we can maybe guard this fixup
> >   handelr behind a CONFIG_ option.
> 
> Can't we just ensure the FDT mapping has extra space. Just rounding up 
> to the next page size should be plenty. 

Not sure, I guess there's no guarantee that memory addresses right after
the FDT end do not contain important data. In that case, enlarging the fdt
would mean overwriting that data.

> 
> Otherwise, the FDT is no longer where the arch thinks it is. Arm64 makes 
> the FDT read-only after calling early_init_dt_scan(), but that would 
> have no effect (perhaps read-only is pointless though).

Good point. Padding the DTB to get some extra space (very hacky, just
saying) would not work because the fw is correcting the amount of available 
space to what's effectively occupied after touching the FDT.

Anyway, the fixed fw should be out in the wild by now so I guess this patch
is not so relevant anymore.

Many thanks,
Andrea


> 
> > 
> > * This fixup is specific for RPi5 and I don't have in mind any other
> >   use cases for other handlers, but in case we need to extend this for
> >   other platforms it may be worth to setup a list of handlers to be
> >   registered so that they can be called in sequence (and on specific
> >   nodes).
> > 
> > Links:
> > [1] - https://lore.kernel.org/all/aO-Q6xMDd8Bfeww2@apocalypse/
> > ---
> >  drivers/of/of_reserved_mem.c | 77 +++++++++++++++++++++++++++++++++++-
> >  1 file changed, 76 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
> > index 2e9ea751ed2d..2c278ab91b9d 100644
> > --- a/drivers/of/of_reserved_mem.c
> > +++ b/drivers/of/of_reserved_mem.c
> > @@ -148,6 +148,73 @@ static int __init early_init_dt_reserve_memory(phys_addr_t base,
> >  	return memblock_reserve(base, size);
> >  }
> >  
> > +static void * __init of_apply_rmem_fixups(const void *fdt, int node)
> > +{
> > +	int t_len = (dt_root_addr_cells + dt_root_size_cells) * sizeof(__be32);
> > +	int parent_node, new_node, child;
> > +	static char new_fdt[150000];
> > +	int len, err, alloc_size;
> > +	phys_addr_t base, size;
> > +	__be32 new_reg_prop[4];
> > +	const __be32 *prop;
> > +	const char *uname;
> > +
> > +	fdt_for_each_subnode(child, fdt, node) {
> > +		if (!of_fdt_device_is_available(fdt, child))
> > +			continue;
> > +
> > +		prop = of_get_flat_dt_prop(child, "reg", &len);
> > +		if (!prop ||
> > +		    !of_flat_dt_is_compatible(child, "raspberrypi,bootloader-config") ||
> > +		    (t_len - len) != sizeof(__be32) ||
> > +		    t_len != 4 * sizeof(__be32))
> > +			continue;
> > +
> > +		alloc_size = fdt_totalsize(fdt) + sizeof(__be32);
> > +		err = fdt_open_into(fdt, new_fdt, alloc_size);
> > +		if (err) {
> > +			pr_err("Failed to open FDT\n");
> > +			return ERR_PTR(err);
> > +		}
> > +
> > +		base = dt_mem_next_cell(dt_root_addr_cells, &prop);
> > +		size = dt_mem_next_cell(1, &prop);
> > +		new_reg_prop[0] = cpu_to_be32(upper_32_bits(base));
> > +		new_reg_prop[1] = cpu_to_be32(lower_32_bits(base));
> > +		new_reg_prop[2] = 0;
> > +		new_reg_prop[3] = cpu_to_be32(size);
> > +
> > +		parent_node = fdt_path_offset(new_fdt, "/reserved-memory");
> > +		if (parent_node < 0) {
> > +			pr_err("No reserved-memory node in the copied FDT\n");
> > +			return ERR_PTR(parent_node);
> > +		}
> > +
> > +		uname = fdt_get_name(fdt, child, NULL);
> > +		if (!uname) {
> > +			pr_err("Cannot retrieve the node name\n");
> > +			return ERR_PTR(-EINVAL);
> > +		}
> > +
> > +		new_node = fdt_subnode_offset(new_fdt, parent_node, uname);
> > +		if (new_node < 0) {
> > +			pr_err("No %s node in the copied FDT\n", uname);
> > +			return ERR_PTR(new_node);
> > +		}
> > +
> > +		err = fdt_setprop(new_fdt, new_node, "reg", new_reg_prop, sizeof(new_reg_prop));
> > +		if (err < 0) {
> > +			pr_warn("Cannot fix 'reg' property for node %s: %s\n",
> > +				uname, fdt_strerror(err));
> > +			return ERR_PTR(err);
> > +		}
> > +
> > +		return new_fdt;
> > +	}
> > +
> > +	return NULL;
> 
> I think we should print some message along the lines of 'fix your 
> buggy firmware'.
> 
> Rob

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2025-12-19 18:00 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-11-05 16:08 [PATCH v2] of: reserved_mem: Add fixup function to amend corrupted reserved memory regions Andrea della Porta
2025-11-14 18:19 ` Rob Herring
2025-12-19 18:03   ` Andrea della Porta

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).