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. Benjamin > >> At least two other hardware blocks can take benefits of this: >> - ARM TZC-400: http://infocenter.arm.com/help/topic/com.arm.doc.100325_0001_02_en/arm_corelink_tzc400_trustzone_address_space_controller_trm_100325_0001_02_en.pdf >> which is able to manage up to 8 regions in address space. > I strongly have to disagree with the above and NACK any patch trying > to do so. AFAIK, no system designed has TZC with non-secure access. > So we simply can't access this in the kernel and hence need no driver > for the same. Please avoid adding above misleading information in future. > > -- > Regards, > Sudeep >
