On 09:46-20231006, Manorit Chawdhry wrote:
Hi Nishanth,
On 06:26-20231005, Nishanth Menon wrote:
On 10:29-20231005, Manorit Chawdhry wrote:
Hi Nishanth,
On 07:24-20231004, Nishanth Menon wrote:
On 10:43-20231004, Manorit Chawdhry wrote:
These are required to remove the firewall configurations that are done by ROM, those are not the ones that are being handled by OIDs. The
I am not sure I understand this clearly. OIDs are setup to open up firewalls or close firewalls as the system requires and since it is authenticated, not compromiseable.- U-boot by itself (even if authenticated), is not a secure entity for it to dictate the firewall configuration (u-boot must be assumed to be compromised after authentication is complete). So, doing firewall configuration via APIs after boot, to me looks broken approach.
I know U-boot ain't that secure given the most trusted entity is always gonna be the software that starts up the system, we can't expect those to be doing all the work and based on that we have the secure boot designed to configure firewalls (that are not owned by anymore) and U-boot R5 being one of the early bootloaders do come as a part of it.
Regarding the OIDs thing, I don't think the OID in question is looked by ROM and ROM always configures some firewalls for it's usecase that are present in those arrays.
The OID that we are using in the series that you had shared is looked by TIFS instead of ROM and TIFS is the entity that is authenticating the binary along with setting up the firewalls.
current series that is being worked on is to add additional firewalling support with OIDs that TIFS will be handling. The above patch is essentially added to have the same development experience on GP devices similar to HS after the secure boot is done so that people don't end up
huh? the code seems to blindly call the remove_fwl_configs(cbass_hc_cfg0_fwls, ARRAY_SIZE(cbass_hc_cfg0_fwls)); where is the distinction of HS vs GP here? This implementation looks completely broken to me at least.. please correct what I missed here.
Since this call is used across all SoCs there wasn't any point to make the differentiation between GP and HS here, remove_fwl_configs internally handles looking at the firewalls and disabling them if they are enabled ( Which would be only in the case of HS devices ), for GP it would automatically by a noop.
Correct me if I understand the security chain here:
ROM sets up firewalls that are needed by itself TIFS (in multicertificate will setup it's own firewalls) R5 SPL comes along and opens up other firewalls Each stage beyond this: such as tispl.bin containing TFA/OPTEE uses OIDs to set up firewalls to protect themselves (enforced by TIFS) A53 SPL and U-boot itself startups but has no ability to change the protection firewalls enforced by x509 OIDs.
Further, firewalls have lockdown bit that enforces the setting (and cannot be over-ridden) till system restart is requested
Is this correct? If so, needs to be clearly documented.
Yes, this seems correct. Will be updating it in the upstream documentation in another series.
Thanks. I suggest: a) Add documentation as part of firewall series[1] including information as to how to customize the flow as needed. b) once the firewall series is merged c) am69/j784s4 series and add reference in code to the section of documentation.
[1] https://lore.kernel.org/all/20231004-binman-firewalling-v3-0-e4a102324e1f@ti...