core: firewall: add firewall framework #6837
Merged
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
jforissier
reviewed
May 15, 2024
|
Updated with comments applied |
jforissier
reviewed
May 16, 2024
etienne-lms
reviewed
May 22, 2024
GseoC
force-pushed
the
firewall_framework_only
branch
from
7fe0a03
to
977993c
Compare
|
Updated with comments addressed. I also modified a bit more some comments. I can squash the commits on-demand. |
etienne-lms
reviewed
May 23, 2024
GseoC
force-pushed
the
firewall_framework_only
branch
from
977993c
to
c9b153f
Compare
|
Updated with review commits squashed and comments applied |
etienne-lms
reviewed
May 24, 2024
GseoC
force-pushed
the
firewall_framework_only
branch
from
c9b153f
to
eff90e8
Compare
|
Updated with @etienne-lms last suggetion |
etienne-lms
reviewed
May 28, 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> Reviewed-by: Etienne Carriere <etienne.carriere@foss.st.com>
GseoC
force-pushed
the
firewall_framework_only
branch
from
eff90e8
to
3c172f9
Compare
|
Updated with last comments and review tag applied, thanks! |
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:
Firewall device consumers APIs to check, acquire accesses against firewall controllers and firewall reconfiguration as there are cases when a firewall configuration could be dynamic.
Firewall controllers APIs to register/unregister to the framework and populate their bus.
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.