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

    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
    \
     
     \ /
      Last update: 2019-04-23 15:34    [W:3.880 / U:0.368 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site