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]

Message-ID: <c8a23e26-79af-eb0f-80bc-5360f30b2a37@st.com>
Date:   Tue, 23 Apr 2019 14:17:23 +0000
From:   Benjamin GAIGNARD <benjamin.gaignard@...com>
To:     Sudeep Holla <sudeep.holla@....com>
CC:     Benjamin Gaignard <benjamin.gaignard@...aro.org>,
        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:55 PM, Sudeep Holla wrote:
> On Tue, Apr 23, 2019 at 01:33:19PM +0000, Benjamin GAIGNARD wrote:
>> 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.
> Sorry if I was not clear. I told Cortex M4 non-secure execution is interesting
> as I expected it to be 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.
>>
> The above statement makes me wonder if Cortex-M4 firmware is really
> non-secure, if so why does it need such an isolation from other masters
> like Cortex-A7. For me Cortex-M4 is secure and Cortex-A7 can execute
> in non-secure hence Cortex-M4 needs to be isolated from Cortex-A7 as
> mentioned in the above excerpts from the datasheet.
Cortex-M4 firmware is non-secure, it could be a free RTOS.
ETZPC doesn't isolate Cortex M4 or A7 but control which of them have 
access to hardware blocks.
For example ETZPC controls if M4 or A7 can have access to I2C hardware 
blocks. The goal is to make sure
firmware running on each side don't use the hardware blocks of the other 
side.

Benjamin

>
> --
> Regards,
> Sudeep