On 1/31/20 9:51 PM, Florian Fainelli wrote:

On 1/29/20 5:40 AM, Benjamin GAIGNARD wrote:

quoted

On 1/28/20 11:06 PM, Robin Murphy wrote:

quoted

On 2020-01-28 8:06 pm, Benjamin GAIGNARD wrote:

quoted

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.

???

:/

The DTB is used to pass the kernel command line, memory reservations,
random seeds, and all manner of other things dynamically generated by
firmware at boot-time. Apologies for being blunt but if "changing the
DTB" is considered a problem then I can't help but think you're doing
it wrong.

Yes but I would like to limit the number of cases where a firmware has
to change the DTB.

With this proposal nodes remain the same and embedded the firewall
configuration(s).

Until now firewall configuration is "static", the firmware disable (or
remove) the nodes not accessible from Linux.

If Linux can rely on node's firewall information it could allow switch
dynamically an hardware block from Linux to a coprocessor.

For example Linux could manage the display pipe configuration and when
going to suspend handover the display hardware block to a coprocessor in
charge a refreshing only some pixels.

OK, let's continue that example, would not it make sense then to just
steal the peripheral away from Linux by ensuring that Linux is no longer
running and the only thing that you need to make sure of is that either
you restore the HW in the exact same that you stole it from, or that
Linux is capable of refreshing its state against what the HW state was
left in?

If you have a set of display pipeline drivers, on your way to suspend,
you can define a protocol with the co-processor so as to signal an
ownership change, and the co-processor can take control from there.

To handover a hardware block to the co-processor we need to inform it 
and change the firewall configuration.
My proposal only aim to cover this last point by describing in the 
device tree the possible configuration.
The example I had mind is how the pinctrl framework is working with it 
states so doing something like changing firewall configuration and then 
inform the co-processor in suspend function.

In your example, it sounds like the firewall could be meant to detect
uncoordinated concurrent accesses to the same HW block between different
SW/FW entities. If that is the case, this is most likely a bug and you
can probably just get away with doing reporting instead of an entirely
new subsystem?

Prohibited accesses, most of the time, generate an abort on the bus so 
your platform just crash and yes it is a bug.
This new subsystem won't change that, it only allow to describe and 
dynamically set a configuration for DT information rather doing that for 
type of firewall.

Benjamin