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

[Enrico Weigelt, metux IT consult]

On 19.04.19 14:36, Benjamin Gaignard wrote:

Hi folks,

I've missed most of the thread, but just some comments:

>>> 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.

Haven't had a look at the code (missed that part), but think the general
idea is a good thing. In some way this seems kinda semantic superset of
pinctrl ;-) We have similar cases w/ things like audio routing in
complex codex. Maybe we could find some common ground on these specific
areas that could be generalized.

>>> 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.

Actually, I'm I read words like "secure firmware", I think of crap code
from chip/board/bios vendors (which is anything but secure and even
likely to have backdoors - if these aren't already on-chip, eg. ME)
Something I really do *NOT* wanna have on my machines - and if I can't
get the board/soc w/o it, I wanna kick that firmware out of the way,
as much as I can.

Therefore, he *does* have *good* reasons.

This whole idea of "secure firmware" is bogus anyways. I'd appreciate
MMU improvements for things like better/stricter isolation (to defeat
side channel attacks), really fast switches to kernel space, at least
for interrupts (eg. reserve cache banks for kernel, so we don't need
to flush here), hw support for nested VMs and hw assisted int->vm
routing, etc, etc. ... there's a lot that could be done here.

But: introducing something daemonish that sits in the background,
can do whatever it likes, controlling OS and HW, w/o the user/device
owner knowing, is completely inacceptable for me. It's really bad that
this x86 crap concepts are pushed over to arm world.

>> 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.

Sounds like a good usecase. For now, we have to do application specific
hacks for that - a generic solution for configuring that (eg. via dt)
is highly appreciated.


--mtx

-- 
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@xxxxxxxxx -- +49-151-27565287