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_andrushche...@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_andrushche...@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
signature.asc
Description: PGP signature