On 1/31/20 7:25 PM, Robin Murphy wrote:

On 29/01/2020 1:40 pm, 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.

Sure, but unless you can limit that number to strictly zero, then 
presumably the firmware must have the general capability to verify, 
modify, and re-sign a DTB. At that point having it also tweak the 
status of nodes that it wants for itself doesn't seem like a 
particularly big ask.

quoted

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.

And like I'm sure I said before, the interface between Linux and the 
Secure environment to ultimately achieve that will almost certainly 
make inspecting a passive status bit in a register redundant anyway.

It is not only about secure and non secure hardware blocks split but 
also about the split with the coprocessor.

The goal is to describe, in the device tree, these possible 
configurations to be able to use them dynamically rather than

having a static configuration. It could also help to detect 
misconfiguration between the firewall and the DT nodes.

In the interest of being productive, though, there is another way of 
looking at this. If we drop the pretence that it's in any way generic 
or ever going to be relevant beyond certain configurations of certain 
STMicro SoCs, then in plain terms it's just some block of MMIO 
registers that have *something* to do with various other devices. At 
that point, the answer is just to treat it as a syscon and make the 
relevant drivers for those SoCs aware of it. I'm most familiar with 
the "General Register File" on Rockchip SoCs as a prime example of 
"bunch of registers that relate to the integration of various IP 
blocks", which manages to be supported just fine without invasive 
hooks in the driver core.

I had thought to use syscon but there is some problems with that way: if 
the firewall hardware change the way it encode the information you have 
change all it customers. That would mean add in each driver a test to 
detect the firewall version and act accordingly. That doesn't sound 
reasonable to me so I decide to create an interface to abstract the 
firewall to avoid this problem.

I could reuse this interface in the ~40 impacted drivers (not all 
dedicated to STMicro SoCs) but adding it in the driver core as a generic 
service was making more sens for me. Note that I have take care of using 
a compilation flag to not impact the others architectures.

Benjamin

Robin.

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