[PATCH v3 5/7] image-fdt: save no-map parameter of reserve-memory

[Ard Biesheuvel]

On Thu, 29 Apr 2021 at 18:11, Simon Glass <sjg at chromium.org> wrote:
>
> Hi Patrick,
>
> On Wed, 28 Apr 2021 at 03:23, Patrick Delaunay
> <patrick.delaunay at foss.st.com> wrote:
> >
> > Save the no-map information present in 'reserved-memory' node to allow
> > correct handling when the MMU is configured in board to avoid
> > speculative access.
> >
> > Signed-off-by: Patrick Delaunay <patrick.delaunay at foss.st.com>
> > ---
> >
> > (no changes since v1)
> >
> >  common/image-fdt.c | 23 +++++++++++++++--------
> >  1 file changed, 15 insertions(+), 8 deletions(-)
>
> Where is no-map documented?
>
> Reviewed-by: Simon Glass <sjg at chromium.org>

I don't remember exactly where the discussion ended up the last time,
so please disregard this if we settled it, but I still don't think
that secure-only memory should be described in the DT at all.

The v7 and v8 documentation are not 100% aligned on this, but the S
bit is now considered a true address bit, and so secure address 0x0
and non-secure address zero could be decoded by different peripherals
at the same time, even if some TZ firewall implementations don't
implement it that way.

Since DT addresses don't carry the S bit at all, any address described
in DT must be assumed to be a non-secure address. This means that the
no-map region essentially describes a non-secure region that does not
exist, in order to prevent a secure region at the same offset (which
DT cannot describe in the first place) from being covered by the
linear mapping.

So, apologies if we are going around in circles here, but could you
please explain again why the DT is describing secure memory as
non-secure memory, and then reserving it again using no-map?