[lkml]   [2019]   [Apr]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RESEND PATCH 0/7] Introduce bus domains controller framework

On 4/23/19 3:21 PM, Sudeep Holla wrote:
> On Mon, Mar 18, 2019 at 12:05:54PM +0100, Benjamin Gaignard wrote:
>> Le lun. 18 mars 2019 à 11:43, Sudeep Holla <> a écrit :
>>> On Mon, Mar 18, 2019 at 11:05:58AM +0100, Benjamin Gaignard wrote:
>>>> Bus domains controllers allow to divided system on chip into multiple domains
>>>> that can be used to select by who hardware blocks could be accessed.
>>>> A domain could be a cluster of CPUs (or coprocessors), a range of addresses or
>>>> a group of hardware blocks.
>>>> Framework architecture is inspirated by pinctrl framework:
>>>> - a default configuration could be applied before bind the driver
>>>> - configurations could be apllied dynamically by drivers
>>>> - device node provides the bus domains configurations
>>>> An example of bus domains controller is STM32 ETZPC hardware block
>>>> which got 3 domains:
>>>> - secure: hardware blocks are only accessible by software running on trust
>>>> zone.
>>>> - non-secure: hardware blocks are accessible by non-secure software (i.e.
>>>> linux kernel).
>>>> - coprocessor: hardware blocks are only accessible by the corpocessor.
>>>> Up to 94 hardware blocks of the soc could be managed by ETZPC and
>>>> assigned to one of the three domains.
>>> You fail to explain why do we need this in non-secure Linux ?
>>> You need to have solid reasons as why this can't be done in secure
>>> firmware. And yes I mean even on arm32. On platforms with such hardware
>>> capabilities you will need some secure firmware to be running and these
>>> things can be done there. I don't want this enabled for ARM64 at all,
>>> firmware *has to deal* with this.
>> We use ETZPC to define if hardware blocks can be used by Cortex A7 or Cortex
>> M4 (both non-secure) on STM32MP1 SoC, this new framework allow to change
>> hardware block split at runtime. This could be done even on non-secure world
>> because their is nothing critical to change hardware blocks users.
> OK, that's interesting, assuming Cortex M4 execution as non-secure. I would
> expect otherwise. Even if it's configurable, I would see that happen in
> secure entity via OPTEE or something similar from non-secure side.
Your assumption is correct Cortex M4 execution is non-secure.
> Do you have any documents that I can refer to get the overall security
> design for such platforms ?

SoC datasheet is here:

with just few words about ETZPC:

3.14 TrustZone protection controller (ETZPC)
ETZPC is used to configure TrustZone security of bus masters and slaves with
programmable-security attributes (securable resources) such as:
• On-chip SYSRAM with programmable secure region size
• AHB and APB peripherals to be made secure
Notice that by default, SYSRAM and peripheral are set to secure access
only, so, not
accessible by non-secure masters such as Cortex-M4 or DMA1/DMA2.
ETZPC can also allocate peripherals and SRAM to be accessible only by
the Cortex-M4
and/or DMA1/DMA2. This ensures the safe execution of the Cortex-M4
firmware, protected
from other masters (e.g. Cortex-A7) unwanted accesses.


> --
> Regards,
> Sudeep
 \ /
  Last update: 2019-04-23 15:34    [W:0.049 / U:1.356 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site