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

[Sughosh Ganu]

On Thu, 8 Aug 2024 at 11:05, Michal Simek <michal.simek at amd.com> wrote:
>
>
>
> On 8/7/24 23:12, Tom Rini wrote:
> > On Tue, Aug 06, 2024 at 05:37:00PM +0530, Prasad Kummari 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.
> >>
> >> Signed-off-by: Prasad Kummari <prasad.kummari at amd.com>
> >
> > This is a much more generic issue that should be looked in to with the
> > LMB rewrite that Sughosh is working on.
>
> yes. And is it going to be the part of his series?
> I expect that if he accepts this will be done on the top of it and there is
> likely no reason to wait.

This change would be needed, but in a different form. The patch, since
based on the current master branch, is assuming a local lmb memory
map. My series is doing away with that, and so we will no longer have
the lmb_init_and_reserve() API, for example. I would suggest that the
patch be put out either on top of my patches, or ideally, once the lmb
patches get merged.


> We find the issue out on system which has more dynamic behavior that spi pytest
> read the whole memory and rewrite TF-A.
>
> And currently we are in situation where some commands are checking reserved
> location and some of them not.

Like you mention in another email, there are instances where we have
commands which are loading images to memory, but are not considering
the lmb reservations. These should be fixed, similar to what this
patch is attempting. Maybe we need a common function where the load
address gets checked with the lmb module, similar to
fs_read_lmb_check(), and then have this called from the various
commands?

-sughosh

>
> Thanks,
> Michal