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_corel... 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