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

[Oleksandr Andrushchenko]

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

>   Thanks!
>