[Uboot-stm32] [PATCH 0/7] arm: cache: cp15: don't map reserved region with no-map property

[Etienne Carriere]

On Thu, 29 Oct 2020 at 17:35, Jerome Forissier <jerome at forissier.org> wrote:
>
>
>
> On 10/29/20 5:06 PM, Etienne Carriere wrote:
> > On Thu, 29 Oct 2020 at 12:26, Ard Biesheuvel <ardb at kernel.org> wrote:
> >> The point I made before was that secure and non-secure are two
> >> disjoint address spaces. The fact that TZ firewalls exist where you
> >> can move things from one side to the other does not imply that things
> >> works like this in the general case.
> >>
> >> E.g., you could have
> >>
> >> secure DRAM at S 0x0
> >> non-secure DRAM at NS 0x0
> >>
> >> where the ranges are backed by *different* memory. Since the DT
> >> description does not include the S/NS distinction, only the address
> >> range, the only thing we can assume when looking at memory@ and
> >> /reserved-memory is that everything it describes is NS.
> >
> > From Arm Trustzone stand point, both secure and non-secure worlds
> > share the very same physical address space. I your example, physical
> > address 0x0 would refer to the same DRAM cell. Whether this cell is secure
> > or non-secure is a configuration set in the DRAM firmwall.
>
> No, like Ard said it is a possibility but it doesn't have to be the
> case. See the Armv8-A ARM (DDI 0487F.c) section D5.1.3 VMSA address
> types and address spaces, "Physical address (PA)".

Ok. I didn't know that. Thanks both to highlight this and thanks for the refs.

However, I think this does not change the question on whether or not a memory
node in non-secure world FDT can cover address ranges that are carved out
with reserved-memory/no-map because non-secure world generic mapping
cannot presume valid default mapping attributes.


> If we need to differentiate between non-secure and secure PA I suppose
> we could use the status and secure-status properties in the memory
> nodes, consistent with the usual usage described in [1].
>
> As Etienne says, it seems that a majority of systems actually have a
> single PA space with access control added on top, and by default the
> secure state can access non-secure memory. That goes well with memory
> nodes without a status nor a secure-status property, yet other
> configurations can easily be supported.
>
> [1]
> https://www.kernel.org/doc/Documentation/devicetree/bindings/arm/secure.txt
>
> --
> Jerome

Cheers,
Etienne