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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 23 Apr 2019 13:33:19 +0000
From:   Benjamin GAIGNARD <benjamin.gaignard@...com>
To:     Sudeep Holla <sudeep.holla@....com>,
        Benjamin Gaignard <benjamin.gaignard@...aro.org>
CC:     Mark Brown <broonie@...nel.org>, Rob Herring <robh@...nel.org>,
        "Arnd Bergmann" <arnd@...db.de>, Shawn Guo <shawnguo@...nel.org>,
        "s.hauer@...gutronix.de" <s.hauer@...gutronix.de>,
        Fabio Estevam <fabio.estevam@....com>,
        Loic PALLARDY <loic.pallardy@...com>,
        "Greg Kroah-Hartman" <gregkh@...uxfoundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "linux-imx@....com" <linux-imx@....com>,
        "kernel@...gutronix.de" <kernel@...gutronix.de>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [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 <sudeep.holla@....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