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:   Mon, 18 Mar 2019 12:05:54 +0100
From:   Benjamin Gaignard <benjamin.gaignard@...aro.org>
To:     Sudeep Holla <sudeep.holla@....com>
Cc:     Benjamin Gaignard <benjamin.gaignard@...com>,
        Mark Brown <broonie@...nel.org>, Rob Herring <robh@...nel.org>,
        Arnd Bergmann <arnd@...db.de>, Shawn Guo <shawnguo@...nel.org>,
        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, kernel@...gutronix.de,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [RESEND PATCH 0/7] Introduce bus domains controller framework

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.
For example you can do "complex" tasks like display pipe configuration
on Cortex A7
where linux is running and handover the control of this hardware block
to Cortex M4 to
offload drawing on framebuffer.

Benjamin

>
> --
> Regards,
> Sudeep