Re: [PATCH v2 0/7] Introduce bus firewall controller framework

[Robin Murphy]

On 2020-01-28 8:06 pm, Benjamin GAIGNARD wrote:
> On 1/28/20 6:17 PM, Sudeep Holla wrote:
> > On Tue, Jan 28, 2020 at 04:46:41PM +0000, Benjamin GAIGNARD wrote:
> > > On 1/28/20 5:36 PM, Sudeep Holla wrote:
> > > > On Tue, Jan 28, 2020 at 04:37:59PM +0100, Benjamin Gaignard wrote:
> > > > > 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.

Robin.