Messages in this thread | | | Subject | Re: [RESEND PATCH 0/7] Introduce bus domains controller framework | From | "Enrico Weigelt, metux IT consult" <> | Date | Tue, 23 Apr 2019 09:41:37 +0200 |
| |
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@metux.net -- +49-151-27565287
| |