linux-kernel - Re: [RFC 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: <CAL_JsqKwj46CSB8vRbYyU6kRMTXqa2Q6O=vQkJwTwC_gHjOf-g@mail.gmail.com>
Date:   Thu, 17 Jan 2019 11:57:21 -0600
From:   Rob Herring <robh@...nel.org>
To:     Benjamin Gaignard <benjamin.gaignard@...com>
Cc:     Mark Brown <broonie@...nel.org>, Arnd Bergmann <arnd@...db.de>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        loic pallardy <loic.pallardy@...com>,
        Benjamin Gaignard <benjamin.gaignard@...aro.org>
Subject: Re: [RFC 0/7] Introduce bus domains controller framework

On Mon, Jan 14, 2019 at 8:42 AM Benjamin Gaignard
<benjamin.gaignard@...com> wrote:
>
> The goal of this framework is to offer an interface for the
> hardware blocks controlling bus accesses rights.
>
> Bus domains controllers are typically used to control if a
> hardware block can perform read or write operations on bus.

Lots of things are domains. Power domains, clock domains, etc. But
naming is hard.

We now have the inter-connect binding which ATM only deals with
bandwidth. Any reason we can't add access controls to that?

> Smarter domains controllers could be able to define accesses
> rights per hardware blocks to control where they can read
> or write.
>
> Domains controller configurations are provided in device node,
> parsed by the framework and send to the driver to apply them.
> Each controller may need different number and type of inputs
> to configure a domain so device-tree properties size have to
> be define by using "#domainctrl-cells".
> Domains configurations properties have to be named "domainsctrl-X"
> on device node.
> "domainsctrl-names" keyword can also be used to give a name to
> a specific configuration.
>
> 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.

We already have a way to assign secure vs. non-secure with 'status'.
Ignoring co-processors for a minute, why does that not work for you?

Co-processors are so varied in terms of capabilities and view of the
system, I'm not sure we can define something generic.

> Up to 94 hardware blocks of the soc could be managed by ETZPC and
> assigned to one of the three domains.
>
> It is an RFC, comments are welcome to help to create this framework, thanks.

Finally, for a new, common binding, I'd like to see more than one
platform using it (or at least an intent to use it).

Rob