On Thu, 29 Oct 2020 at 17:35, Jerome Forissier <jer...@forissier.org> wrote: > > > > On 10/29/20 5:06 PM, Etienne Carriere wrote: > > On Thu, 29 Oct 2020 at 12:26, Ard Biesheuvel <a...@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