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

Ard Biesheuvel ardb at kernel.org
Fri Oct 9 20:35:41 CEST 2020


On Fri, 9 Oct 2020 at 19:13, Ahmad Fatoum <a.fatoum at pengutronix.de> wrote:
>
> Hello Patrick,
>
> On 10/9/20 5:52 PM, Patrick DELAUNAY wrote:
> > I checked DACR behavior and CheckDomain /  CheckPermission
> >
> > In my case the cortex A7 try to access to part of DDR / mapped cacheable and bufferable, protected by firewall.
> >
> > So to use DACR I always need to configure the MMU with several Domain
> > - unsecure part of DDR as Domain 0 (DCACHE_WRITEALLOC)
> > - secure part of DDR as  Domain 1 (DCACHE_OFF)
> >
> > For other part of MMU region, the I/O registers are mapped as register with Domain 0 (D_CACHE_OFF)
> >
> > Then I can set DACR = 0x55555555
> > => Client Accesses are checked against the access permission bits in the TLB entry
> >
> > You ar right, the access permission is check only for domain configurated as client in DACR
> >
> > But in ARM architecture
> >
> > B2.4.8 Access permission checking
> >
> > CheckPermission() pseudo code
> > Only check perms.ap is checked
> > And perms.xp is not checked
> >
> > But as the secure memory is mapped cacheable by secure OS, OP-TEE
> > I think to avoid to map the region is the ARM preconized solution
> > As explain in my answer to ard in [1]
> >
> > [1] http://u-boot.10912.n7.nabble.com/PATCH-0-7-arm-cache-cp15-don-t-map-reserved-region-with-no-map-property-tt428715.html#a428958
>
> I don't think the aliasing described in "A3.5.7 Memory access restrictions" applies if the
> same memory is mapped twice only, once in secure and another in normal world.
> Data is already segregated in the caches by means of a NS bit. Only thing you should need
> to do within normal world is mapping it XN, cacheable and not be in manager domain.
> Unmapping sounds unnecessary to me. (You don't unmap peripherals you aren't using either.
> Why handle OP-TEE DRAM specially?)
>

Ah good point. The secure DDR is in the secure physical address space,
whereas the non-secure mapping refers to non-secure physical memory.
So from a coherency point of view, they are really not aliases of one
another, and so the mismatched attribute concern does not apply.

But this actually reinforces my previous point too: the secure and
non-secure physical address spaces are disjoint, and the DT can only
describe non-secure memory, so these regions don't belong in the DT
given to the OS in the first place.



>
>
> >
> >> 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 |
>
> --
> 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