[PATCH] Added FDT PAD memory size while reserving memory for FDT to avoid some memory corruption issue

[Selvakumar Velandi]

Hi,

The issue is happening in the following scenario.
1) Launch the QEMU for RISCV virt platform with uboot and ubuntu OS (Host
system). Now the OS is booted without any issue.
2) Enable the KVM in the ubuntu OS.
3) Create a VM by launching the same RISC V QEMU from the Ubuntu OS (Host
system)  after enabling KVM.
4) So now the qemu is running from the HOST OS and launching the uboot and
then OS. The system crash is happening in the VM OS booting.
If the FDT is reserved with stub bytes then the VM is launched properly.

The issue is not happening while launching Host OS even if it use the same
uboot code.
As per the image_fdt code in uboot, the  FDT size is blindly increased even
if the relocation is disabled and updated in the FDT header.
So i reserve the Padding bytes while reserving FDT in uboot board_f phase
itself for adding bootargs in uboot after image_fdt.

Regards,
Selva


On Sat, Feb 10, 2024 at 1:55 AM Tom Rini <trini at konsulko.com> wrote:

> On Fri, Feb 09, 2024 at 07:45:10PM +0530, Selvakumar Velandi wrote:
>
> > The FDT relocation is not disabled. I am adding the FDT PADDING bytes
> while
> > doing FDT reservation in the board_f file.
> > Also update the FDT length based on the new allocation, instead of
> blindly
> > increasing the size.
> > Currently the size is getting increased even for the relocation disabled
> > scenario also.
> > So without increasing the physical memory for the disable relocation use
> > case, the fdt total size is updated. thus causing memory corruption
>
> Please explain on what system you're seeing this with, and how things
> are configured and what else is required to trigger this problem. Your
> changes to boot/image-fdt.c change things so that we don't pad the
> non-relocated device tree (but we need to, we still change the bootargs
> and so forth). And the changes to common/board_f.c look like we're
> trying to do that instead, earlier? But we should not have a kernel
> corruption problem unless:
> - We aren't relocating the device tree
> - We aren't relocating the device tree far enough away from the kernel,
>   but this shouldn't be a problem on arm64 and riscv where the Image
>   header structure tells us how big the BSS is to be and we obey that.
>
> --
> Tom
>

-- 
***
This communication is confidential, may be privileged and is meant only 
for the intended recipient and purpose. No part of this email or any files 
transmitted with it can be shared, copied, forwarded or published online or 
offline, without prior written consent of the sender. If you are not the 
intended recipient, please preserve the confidentiality, delete the e-mail 
and attachments, if any from your system and inform the sender immediately. 
 

***