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

Ahmad Fatoum a.fatoum at pengutronix.de
Wed Oct 7 13:23:31 CEST 2020


Hello Ard, Patrick,

On 10/7/20 12:26 PM, Ard Biesheuvel wrote:
>> 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.
>>
> 
> Spurious peculative accesses to device regions would be a severe
> silicon bug, so I wonder what is going on here.
> 
> (Apologies if we are rehashing stuff here that has already been
> discussed - I don't remember the details)
> 
> Are you sure that the speculative accesses were not caused by
> misconfigured CPU or page tables, missing TLB maintenance, etc etc?
> Because it really does smell like a software issue not a hardware
> issue.

I debugged a similar issue a year ago on an i.MX6 UltraLite (also a Cortex-A7)
that turned to ultimately be caused by barebox not mapping I/O memory as
non-executable. This led to very interesting effects.

My findings[1] back then were that U-Boot did set the eXecute Never bit only on
OMAP, but not for other platforms.  So I could imagine this being the root cause
of Patrick's issues as well:
The CPU is speculatively executing from the region that the firewalled DRAM
is mapped at.

barebox now configures XN for non-RAM before it turns on the MMU. You should
do that as well (in ARM arch code, not only for stm32mp1). Additionally,
you will want to XN map the region where your OP-TEE sits at.

[1]: https://community.nxp.com/thread/511925

Cheers
Ahmad

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


More information about the U-Boot mailing list