Add Trusted Boot Firmware Configuration entry#77
Add Trusted Boot Firmware Configuration entry#77harrisonmutai-arm wants to merge 2 commits intoFirmwareHandoff:mainfrom
Conversation
| * - tb_fw_config | ||
| - data_size | ||
| - hdr_size | ||
| - Holds a Trusted Boot Firmware Configuration file in DT format. |
There was a problem hiding this comment.
Thanks for the link to the binding:
I think this needs to be brought into this spec, since it doesn't follow the Linux devicetree schema.
Some comments on the schema:
- As mentioned previously, the properties should have hyphens instead of underscores.
- UUIDs should be in binary format, not string, right?
- This is presumably ARM-specific so I think this should be clearly mentioned in the entry type (i.e. it would not be valid to use this on other archs)
- Should load-address be 64-bit? You should really have #address-cells etc. to indicate this
- It isn't obvious which node this properties are in. I suppose it doesn't matter, since there is a compatible string, so long as it isn't the root node
- The compatible string should be <vendor,device> so better to use than , which might be confusing
- The binding should indicate what these things are for. For example 'Platform Secure Partition Content Certificate UUID' does not impart much information. What is the certificate for and how do you create it or use it?
- For 'owner', could you enumerate value values? Is this just for logging or does it affect operation.
- The beinding refers to a 'Chain of Trust Bindings' document. It isn't clear how we decide if this needed, but if it is needed, it should be described in this spec too.
As a general comment, rather than UUIDs, perhaps strings would be more helpful for humans?
There was a problem hiding this comment.
Is there any update on this? It there a plan to upstream to Linux schema, or will it stay separate?
There was a problem hiding this comment.
Hi Simon, thanks for your comment. I’ve been considering how to incorporate some of your suggestions, but I haven’t had much time to work through them. One challenge is that there are external platforms that have been using this DT format for quite a while. When the DT was originally defined, it came with very few constraints - properties were added ad hoc, and it was intended solely as an IMPDEF mechanism for passing information between BL1 and BL2. Unfortunately, going back now to standardize it isn’t straightforward, what I've provided so far is really just a best-effort attempt to outline a schema.
There was a problem hiding this comment.
For now the plan is to keep this separate from the Linux schema, we don't envision a scenario where this DT leaves the bounds of TF-A.
There was a problem hiding this comment.
To deal with compatibility, you could change the compatible string. It would allow you to write new and old if you really need to (with new being the default).
Is there no interest in getting this through schema review?
Defines a new Transfer Entry type (0x109) for passing the Trusted Boot Firmware Configuration (TB_FW_CONFIG) DT blob within the Transfer List. Includes layout table, usage description, and references the official bindings documentation. Signed-off-by: Harrison Mutai <harrison.mutai@arm.com>
Signed-off-by: Harrison Mutai <harrison.mutai@arm.com>
harrisonmutai-arm
force-pushed
the
hm/tf-configs
branch
from
9494e70 to
e3256a9
Compare
|
Hi @harrisonmutai-arm , should we move this PR to https://github.com/FirmwareHandoff/ProjectTEs ? |
3 participants
Defines a TE type for passing the Trusted Boot Firmware Configuration (TB_FW_CONFIG) DT blob. Includes layout table, usage description, and references the TF-A bindings. Note, this DT format is platform specific, unstable and only used by TF-A BL1/BL2. It's content is not expected to make it's way to subsequent firmware stages. A binding document is provided as reference for what contents might be included by a platform.