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. > > Note you haven't cc-ed 2 people who has comments earlier[1][2] I will cc them, thanks > -- > Regards, > Sudeep > > [1] https://lkml.org/lkml/2018/2/27/512 > [2] https://lkml.org/lkml/2018/2/27/598
