On 1/28/20 12:06 PM, Benjamin GAIGNARD wrote:

On 1/28/20 6:17 PM, Sudeep Holla wrote:

quoted

On Tue, Jan 28, 2020 at 04:46:41PM +0000, Benjamin GAIGNARD wrote:

quoted

On 1/28/20 5:36 PM, Sudeep Holla wrote:

quoted

On Tue, Jan 28, 2020 at 04:37:59PM +0100, Benjamin Gaignard wrote:

quoted

Bus firewall framework aims to provide a kernel API to set the configuration
of the harware blocks in charge of busses access control.

Framework architecture is inspirated by pinctrl framework:
- a default configuration could be applied before bind the driver.
    If a configuration could not be applied the driver is not bind
    to avoid doing accesses on prohibited regions.
- configurations could be apllied dynamically by drivers.
- device node provides the bus firewall configurations.

An example of bus firewall controller is STM32 ETZPC hardware block
which got 3 possible configurations:
- trust: hardware blocks are only accessible by software running on trust
    zone (i.e op-tee firmware).
- non-secure: hardware blocks are accessible by non-secure software (i.e.
    linux kernel).
- coprocessor: hardware blocks are only accessible by the coprocessor.
Up to 94 hardware blocks of the soc could be managed by ETZPC.

/me confused. Is ETZPC accessible from the non-secure kernel space to
begin with ? If so, is it allowed to configure hardware blocks as secure
or trusted ? I am failing to understand the overall design of a system
with ETZPC controller.

Non-secure kernel could read the values set in ETZPC, if it doesn't match
with what is required by the device node the driver won't be probed.

OK, but I was under the impression that it was made clear that Linux is
not firmware validation suite. The firmware need to ensure all the devices
that are not accessible in the Linux kernel are marked as disabled and
this needs to happen before entering the kernel. So if this is what this
patch series achieves, then there is no need for it. Please stop pursuing
this any further or provide any other reasons(if any) to have it. Until
you have other reasons, NACK for this series.

No it doesn't disable the nodes.

When the firmware disable a node before the kernel that means it change

the DTB and that is a problem when you want to sign it. With my proposal

the DTB remains the same.

Could you use an overlay then which is the result of the firewalling
results by your firewall block, which is smaller than the main SoC/board
DTB and can be easily audited not to accidentally enable blocks, but
only disable them by adding/changing the respective "status" property.
Worst case, your driver probes, has been firewalled and this is not
reflected in the DTB, you get a bus error, or a hang, or however it gets
implemented.

Like Robin and Sudeep here, I do not understand why the kernel should
have any business in this, let alone allowing blocks to change owners,
that sounds contrary to the purpose of a firewall being controlled under
an untrusted entity (Linux).
-- 
Florian

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel