Re: [RESEND PATCH 0/7] Introduce bus domains controller framework

[Benjamin GAIGNARD <benjamin.gaignard@st.com>]

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