From: Patrick Delaunay <patrick.delaunay@st.com>
To: u-boot@lists.denx.de
Subject: [PATCH 0/7] arm: cache: cp15: don't map reserved region with no-map property
Date: Tue, 6 Oct 2020 18:35:55 +0200 [thread overview]
Message-ID: <20201006163602.21687-1-patrick.delaunay@st.com> (raw)
Hi,
On STM32MP15x platform we can use OP-TEE, loaded in DDR in a region
protected by a firewall. This region is reserved in device with "no-map"
property.
But sometime the platform boot failed in U-boot on a Cortex A7 access to
this region (depending of the binary and the issue can change with compiler
version or with code alignment), then the firewall raise a error,
for example:
E/TC:0 tzc_it_handler:19 TZC permission failure
E/TC:0 dump_fail_filter:420 Permission violation on filter 0
E/TC:0 dump_fail_filter:425 Violation @0xde5c6bf0, non-secure privileged read,
AXI ID 5c0
E/TC:0 Panic
After investigation, the forbidden access is a speculative request performed
by the Cortex A7 because all the DDR is mapped as MEMORY with CACHEABLE
property.
The issue is solved only when the region reserved by OP-TEE is no more
mapped in U-Boot (mapped as DEVICE/NON-CACHEABLE wasn't enough) as it is
already done in Linux kernel.
I think that can be a general issue for ARM architecture: the no-map tag
in device should be respected by U-boot, so I propose a generic solution
in arm/lib/cache-cp15.c:dram_bank_mmu_setup().
This serie is composed by 7 patches
- 1..4/7: preliminary steps to support flags in library in lmb
(as it is done in memblock.c in Linux)
- 5/7: unitary test on the added feature in lmb lib
- 6/7: save the no-map flags in lmb when the device tree is parsed
- 7/7: update the generic behavior for "no-map" region in
arm/lib/cache-cp15.c::dram_bank_mmu_setup()
It is a rebase on master branch of previous RFC [2].
I can change this last patch if this feature is note required by other
ARM architecture; it is a weak function so I can avoid to map the region
with "no-map" property in device tree only for STM32MP architecture
(in arch/arm/mach-stm32mp/cpu.c).
See also [1] which handle same speculative access on armv8 for area
with Executable attribute.
[1] http://patchwork.ozlabs.org/project/uboot/patch/20200903000106.5016-1-marek.bykowski at gmail.com/
[2] http://patchwork.ozlabs.org/project/uboot/list/?series=199486&archive=both&state=*
Regards
Patrick
Patrick Delaunay (7):
lmb: Add support of flags for no-map properties
lmb: add lmb_is_reserved_flags
lmb: remove lmb_region.size
lmb: add lmb_dump_region() function
test: lmb: add test for lmb_reserve_flags
image-fdt: save no-map parameter of reserve-memory
arm: cache: cp15: don't map the reserved region with no-map property
arch/arm/include/asm/system.h | 3 +
arch/arm/lib/cache-cp15.c | 19 ++++++-
common/image-fdt.c | 23 +++++---
include/lmb.h | 22 +++++++-
lib/lmb.c | 100 +++++++++++++++++++++++-----------
test/lib/lmb.c | 89 ++++++++++++++++++++++++++++++
6 files changed, 212 insertions(+), 44 deletions(-)
--
2.17.1
next reply other threads:[~2020-10-06 16:35 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-06 16:35 Patrick Delaunay [this message]
2020-10-06 16:35 ` [PATCH 1/7] lmb: Add support of flags for no-map properties Patrick Delaunay
2020-10-06 16:35 ` [PATCH 2/7] lmb: add lmb_is_reserved_flags Patrick Delaunay
2020-10-06 16:35 ` [PATCH 3/7] lmb: remove lmb_region.size Patrick Delaunay
2020-10-06 16:35 ` [PATCH 4/7] lmb: add lmb_dump_region() function Patrick Delaunay
2020-10-06 16:36 ` [PATCH 5/7] test: lmb: add test for lmb_reserve_flags Patrick Delaunay
2020-10-06 16:36 ` [PATCH 6/7] image-fdt: save no-map parameter of reserve-memory Patrick Delaunay
2020-10-06 16:36 ` [PATCH 7/7] arm: cache: cp15: don't map the reserved region with no-map property Patrick Delaunay
2020-10-07 10:26 ` [PATCH 0/7] arm: cache: cp15: don't map " Ard Biesheuvel
2020-10-07 11:23 ` [Uboot-stm32] " Ahmad Fatoum
2020-10-07 11:52 ` Ahmad Fatoum
2020-10-07 13:15 ` Ard Biesheuvel
2020-10-07 14:55 ` Etienne Carriere
2020-10-07 15:07 ` Ard Biesheuvel
2020-10-07 15:13 ` Etienne Carriere
2020-10-09 17:00 ` Patrick DELAUNAY
2020-10-27 17:25 ` Tom Rini
2020-10-27 21:04 ` Ard Biesheuvel
2020-10-28 10:33 ` Patrick DELAUNAY
2020-10-29 10:40 ` Etienne Carriere
2020-10-29 11:26 ` Ard Biesheuvel
2020-10-29 16:06 ` Etienne Carriere
2020-10-29 16:31 ` Ard Biesheuvel
2020-10-29 16:35 ` Jerome Forissier
2020-10-29 17:11 ` Etienne Carriere
2020-10-09 15:52 ` Patrick DELAUNAY
2020-10-09 17:12 ` Ahmad Fatoum
2020-10-09 17:15 ` Ahmad Fatoum
2020-10-09 18:35 ` Ard Biesheuvel
2020-10-12 9:09 ` Etienne Carriere
2020-10-12 9:20 ` Ard Biesheuvel
2020-10-12 9:51 ` Etienne Carriere
2020-10-12 10:27 ` Ard Biesheuvel
2020-10-09 11:18 ` Patrick DELAUNAY
2020-10-09 12:26 ` Ard Biesheuvel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201006163602.21687-1-patrick.delaunay@st.com \
--to=patrick.delaunay@st.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox