From mboxrd@z Thu Jan 1 00:00:00 1970 From: Etienne Carriere Date: Thu, 29 Oct 2020 18:11:36 +0100 Subject: [Uboot-stm32] [PATCH 0/7] arm: cache: cp15: don't map reserved region with no-map property In-Reply-To: <54533fa8-0e11-56de-90c2-d05817de738d@forissier.org> References: <20201006163602.21687-1-patrick.delaunay@st.com> <190d019a-7e18-b4bc-9276-e14bbe4c2855@pengutronix.de> <258ba4fa-8d1e-56be-e0de-2d6c09812c13@pengutronix.de> <20201027172533.GD14816@bill-the-cat> <976b2b1443424f659fa85a2d11b4b507@SFHDAG2NODE3.st.com> <54533fa8-0e11-56de-90c2-d05817de738d@forissier.org> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Thu, 29 Oct 2020 at 17:35, Jerome Forissier wrote: > > > > On 10/29/20 5:06 PM, Etienne Carriere wrote: > > On Thu, 29 Oct 2020 at 12:26, Ard Biesheuvel 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