[PATCH] common/board_f: Respect original FDT size while relocating

Tom Rini trini at konsulko.com
Fri Jun 19 19:51:33 CEST 2020


On Fri, Jun 19, 2020 at 03:19:21PM +0000, Oleksandr Andrushchenko wrote:
> On 6/19/20 4:53 PM, Tom Rini wrote:
> > On Fri, Jun 19, 2020 at 11:22:18AM +0300, Oleksandr Andrushchenko wrote:
> >
> >> From: Oleksandr Andrushchenko <oleksandr_andrushchenko at epam.com>
> >>
> >> While relocating FDT we reserve some memory for the new FDT and
> >> set the size of the FDT with that respect. But FDT may be placed
> >> at the end of the RAM leading to memory access beyond it.
> >> Fix this by copying exact FDT size bytes, not the reserved size.
> >>
> >> Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko at epam.com>
> >> ---
> >>   common/board_f.c | 2 +-
> >>   1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/common/board_f.c b/common/board_f.c
> >> index 01194eaa0e4d..aa1285e94999 100644
> >> --- a/common/board_f.c
> >> +++ b/common/board_f.c
> >> @@ -670,7 +670,7 @@ static int reloc_fdt(void)
> >>   	if (gd->flags & GD_FLG_SKIP_RELOC)
> >>   		return 0;
> >>   	if (gd->new_fdt) {
> >> -		memcpy(gd->new_fdt, gd->fdt_blob, gd->fdt_size);
> >> +		memcpy(gd->new_fdt, gd->fdt_blob, fdt_totalsize(gd->fdt_blob));
> >>   		gd->fdt_blob = gd->new_fdt;
> >>   	}
> >>   #endif
> > So, I think the problem is placing the fdt so close to the end of memory
> > and we need to fix that.
> Exactly
> >    With the above change, we won't copy past the
> > end of memory
> yes
> >   but gd->fdt_blob + gd->fdt_size will still point past it,
> > yes?
> 
> Not really as the next op after the memcpy will set fdt_blob to the new location
> 
> and it is safe to access the memory in [gd->fdt_blob; gd->fdt_blob + gd->fdt_size) range.
> 
> We only ensure we are copying the fdt itself, not also the reserved memory which
> 
> doesn't exist past the original fdt addresses

Ah, so I had something backwards then.  We're fine because gd->new_fdt +
gd->fdt_size is fine.  Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200619/badca31b/attachment.sig>


More information about the U-Boot mailing list