Messages in this thread | | | From | Benjamin GAIGNARD <> | Subject | Re: [RESEND PATCH 0/7] Introduce bus domains controller framework | Date | Tue, 23 Apr 2019 13:33:19 +0000 |
| |
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 <sudeep.holla@arm.com> 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:
https://www.st.com/resource/en/datasheet/stm32mp157a.pdf
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.
Benjamin
> > -- > Regards, > Sudeep
| |