From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Date: Mon, 16 Feb 2015 14:55:38 +0100 Subject: [U-Boot] [PATCH v2 11/12] tegra124: Reserve secure RAM using MC_SECURITY_CFG{0, 1}_0 In-Reply-To: <20150216134920.GD8994@leverpostej> References: <1a2463987464ef637b09316a4dbb440b7831b07e.1424091289.git.jan.kiszka@siemens.com> <20150216134920.GD8994@leverpostej> Message-ID: <54E1F6DA.3010603@siemens.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 2015-02-16 14:49, Mark Rutland wrote: > On Mon, Feb 16, 2015 at 12:54:48PM +0000, Jan Kiszka wrote: >> From: Ian Campbell >> >> These registers can be used to prevent non-secure world from accessing a >> megabyte aligned region of RAM, use them to protect the u-boot secure monitor >> code. > > What happens if the CPU tried to read this memory from the non-secure > world? If the OS has it mapped then the CPU could perform speculative > reads at any point in time. > > If that can raise an abort then the OS needs to not map the region. > > I take it U-Boot uses a secure mapping for the region (which I believe > should avoid the mismatched attributes issue I mentioned in my other > reply). What I can contribute to this are kernel messages due to a misconfiguration of our hypervisor Jailhouse (while Linux was still trying to boot it): [ 61.896860] tegra-mc 70019000.memory-controller: mpcorew: write @0x00000000fff00040: Security violation (TrustZone violation) [ 61.896888] tegra-mc 70019000.memory-controller: mpcorew: write @0x00000000fff2d340: Security violation (TrustZone violation) So it seems that Linux is receiving a violation report here when trying to access the memory. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SES-DE Corporate Competence Center Embedded Linux