[PATCH] cmd: sf: prevent overwriting the reserved memory

Simon Glass sjg at chromium.org
Wed Aug 7 16:36:25 CEST 2024


Hi Prasad,

On Tue, 6 Aug 2024 at 23:05, Kummari, Prasad <Prasad.Kummari at amd.com> wrote:
>
> Hi Glass,
>
> > -----Original Message-----
> > From: Simon Glass <sjg at chromium.org>
> > Sent: Wednesday, August 7, 2024 3:21 AM
> > To: Kummari, Prasad <Prasad.Kummari at amd.com>
> > Cc: u-boot at lists.denx.de; git (AMD-Xilinx) <git at amd.com>; Simek, Michal
> > <michal.simek at amd.com>; Abbarapu, Venkatesh
> > <venkatesh.abbarapu at amd.com>; git at xilinx.com;
> > jagan at amarulasolutions.com; n-francis at ti.com; d-gole at ti.com
> > Subject: Re: [PATCH] cmd: sf: prevent overwriting the reserved memory
> >
> > Caution: This message originated from an External Source. Use proper
> > caution when opening attachments, clicking links, or responding.
> >
> >
> > Hi Prasad,
> >
> > On Tue, 6 Aug 2024 at 06:08, Prasad Kummari <prasad.kummari at amd.com> wrote:
> > >
> > > Added LMB API to prevent SF command from overwriting reserved memory
> > > areas. The current SPI code does not use LMB APIs for loading data
> > > into memory addresses. To resolve this, LMB APIs were added to check
> > > the load address of an SF command and ensure it does not overwrite
> > > reserved memory addresses. Similar checks are used in TFTP, serial
> > > load, and boot code to prevent overwriting reserved memory.
> >
> > The SPI flash may be used to load other things, not just an OS. What is your
> > use case or problem here?
>
> [Prasad]:  We have observed that SF command can overwrite the reserved area without throwing any errors or warnings.
>  This issue was noticed when the TF-A area is reserved in the Device Tree at address 0xf000000. The sf command is
>  corrupting the reserved area,  and U-Boot relocation address too.
>
> EX: TF-A reserved at ddr address 0xf000000
>
>       Versal NET> sf read 0x0f000000 0x0 0x100     ----> Overwriting reserved area.
>       device 0 offset 0x0, size 0x100
>       SF: 256 bytes @ 0x0 Read: OK
>
>      U-boot relocation address relocaddr   = 0x000000007fec2000
>
>       Versal NET> sf write 0x0000000077ec2000 0x0 0x100   --> Overwriting reserved area.
>       device 0 offset 0x0, size 0x100
>       SF: 256 bytes @ 0x0 Written: OK

Yes. There are many things which can overwrite memory, e.g. the mw
command. It is a boot loader so this is normal.

What image are you loading here?

Regards,
Simon


More information about the U-Boot mailing list