Core: Add a firewall framework + stm32 use case #6816
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
GseoC
commented
May 3, 2024
etienne-lms
reviewed
May 6, 2024
etienne-lms
reviewed
May 6, 2024
|
Updated with comments addressed. I added a [modifications] commit that changes a bit the filtering policy of the ETZPC, please have a look at it as well @etienne-lms |
etienne-lms
reviewed
May 13, 2024
Add a generic firewall controller framework. The goal of this framework is to offer access control and configuration APIs, that are implemented in the firewall controllers drivers, to the firewall consumers. This framework requires an embedded device tree. A firewall controller is an access controller [1]. It should register itself as a provider to the framework. Firewall controllers have the possibility to populate their bus according to defined firewall accesses defined in the "access-controllers" property in each of the device's node. Any device that consumes one or more firewall should refer it/them in their "access-controllers" property. Arguments can be passed along with the phandle of the firewall controller(s). Link: https://patchwork.kernel.org/project/linux-media/patch/20240105130404.301172-2-gatien.chevallier@foss.st.com/ [1] Signed-off-by: Gatien Chevallier <gatien.chevallier@foss.st.com>
Define ETZPC bindings for STM32MP15 and STM32MP13 and add these header files into the stm32mp_dt_bindings helper. Signed-off-by: Gatien Chevallier <gatien.chevallier@foss.st.com>
Add the default tables defining the firewall configuration that will be set at boot time. STGENC and IWDG1 are set to secure on stm32mp157x-scmi boards, non-secure otherwise. Signed-off-by: Gatien Chevallier <gatien.chevallier@foss.st.com>
Remove old implementation where the ETZPC configuration was a hard coded table in the shared resources file and use the device tree to get it. Signed-off-by: Gatien Chevallier <gatien.chevallier@foss.st.com>
ETZPC is a firewall controller. Add the access-controllers property to all ETZPC sub-nodes. Also add the "simple-bus" compatible for backward compatibility and "#access-controllers-cells" to the ETZPC node. Signed-off-by: Gatien Chevallier <gatien.chevallier@foss.st.com> Change-Id: Iae9e4f96e9cad26ef69038b41ba72f7155003cfc
ETZPC is a firewall controller. Add the access-controllers property to all ETZPC sub-nodes. Also add the "simple-bus" compatible for backward compatibility and "#access-controllers-cells" to the ETZPC node. Signed-off-by: Gatien Chevallier <gatien.chevallier@foss.st.com>
Default enable the CFG_DRIVERS_FIREWALL switch that is used to enable the support of the firewall framework. On this platform, only the ETZPC is a firewall controller for now. Signed-off-by: Gatien Chevallier <gatien.chevallier@foss.st.com>
|
Updated with comments addressed and squashed. @jenswi-linaro / @jforissier do you want to have a look as well on the generic part? |
Implement stm32_etzpc.c driver in the firewall driver directory. Use the new firewall API to populate the firewall bus and register the ETZPC as a firewall provider. The ETZPC driver register the following ops: -set_conf -check_access -acquire_access -acquire_memory_access Signed-off-by: Gatien Chevallier <gatien.chevallier@foss.st.com>
|
Fixed a |
|
In order to ease reviewers commenting the generic part, maybe it would be worth creating another P-R, maybe [RFC] prefixed, with only the 1 commit of your series, knowing that this current P-R illustrate how an access-controller/firewall device integrates with this new framework. |
Fine, I'll do that edit: Done: #6837 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The need for such framework arises from the fact that there are multiple hardware firewalls implemented across multiple products. When it comes to firewalls, the purpose mostly stays the same: protect and filter hardware resources.
Add a firewall framework that offers:
This firewall framework relies on the access-controllers device tree binding that was acked in the Linux kernel and is present in the Linux-next branch.
How the arguments passed along with this property and how they're used by the controllers to filter the accesses or set configurations is platform-specific AND specific to the firewall controller. Meaning that all the filtering logic should be present in the firewall controller drivers. Firewall consumers do not have the knowledge on the controller and should rely on the device API.
As example, I have reworked and cabled the STM32 ETZPC driver (STM32MP1x series) onto the framework as it implements all of the firewall controllers ops. I also have the RIFSC driver (STM32MP2x series) ready but did not put it in this P-R to avoid pollution. The STM32 ETZPC device is responsible for filtering accesses based on security level, or co-processor isolation for any resource connected to it.