Skip to content

Add Trusted Boot Firmware Configuration entry #77

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
harrisonmutai-arm wants to merge 2 commits into from
Closed

Add Trusted Boot Firmware Configuration entry #77

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
4479b03
Add Trusted Boot Firmware Configuration entry
harrisonmutai-arm Feb 8, 2024
e3256a9
Add fixed reference to TB_FW_CONFIG bindings
harrisonmutai-arm Sep 15, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions source/references.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -23,6 +23,8 @@ References

.. [OPTEECore] `OP-TEE Core Architecture v4.5 <https://optee.readthedocs.io/en/4.5.0/architecture/core.html>`__

.. [TB_FW_CONFIG] `Trusted Boot Firmware Configuration bindings <https://review.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a/+/c6c882a42795da82b18d2d7dff1265bf2a1a6aab/docs/components/fconf/tb_fw_bindings.rst>`__

.. [TFAFFAMB] TF-A Secure Partition Manager: `FF-A manifest binding to device tree v2.12 <https://trustedfirmware-a.readthedocs.io/en/v2.12.0/components/ffa-manifest-binding.html>`__

.. [TCG_EFI] `Trusted Computing Group EFI Protocol Specification v15 <https://trustedcomputinggroup.org/wp-content/uploads/TCG_EFI_Platform_1_22_Final_-v15.pdf>`__
Expand Down
41 changes: 41 additions & 0 deletions source/transfer_list.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -883,6 +883,9 @@ including TF-A, OP-TEE and Hafnium.
* - :ref:`0x109 <tab_gpt_info>`
- GPT Error Info

* - :ref:`0x10a <tab_tb_fw_config>`
- DT Trusted Boot Firmware Configuration (``TB_FW_CONFIG``)

**OP-TEE pageable part address entry layout (XFERLIST_OPTEE_PAGEABLE_PART_ADDR)**

This entry type holds the address of OP-TEE pageable part which is described in
Expand Down Expand Up @@ -1416,5 +1419,43 @@ Bits [7:1] are reserved for future use.
- hdr_size
- The `gpt_error_info` field contains GPT error information.

**DT Trusted Boot Firmware Configuration entry layout
(XFERLIST_TB_FW_CONFIG)**

The Trusted Boot Firmware Configuration (TB_FW_CONFIG) is a dynamic
configuration file used in TF-A to configure properties relating to trusted
firmware (i.e. IO policies, and Mbed TLS heap info) [TB_FW_CONFIG]_. This TE
contains in its data section the configuration file in DT format [DT]_.

.. _tab_tb_fw_config:
.. list-table:: Trusted Boot Firmware Configuration entry type layout
:widths: 2 2 2 8

* - Field
- Size (bytes)
- Offset (bytes)
- Description

* - tag_id
- 0x3
- 0x0
- The tag_id field must be set to **0x10a**.

* - hdr_size
- 0x1
- 0x3
- |hdr_size_desc|

* - data_size
- 0x4
- 0x4
- The size of the configuration file in bytes.

* - tb_fw_config
- data_size
- hdr_size
- Holds a Trusted Boot Firmware Configuration file in DT format.

@sjg20 sjg20 Sep 19, 2025

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the link to the binding:

https://review.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a/+/c6c882a42795da82b18d2d7dff1265bf2a1a6aab/docs/components/fconf/tb_fw_bindings.rst

I think this needs to be brought into this spec, since it doesn't follow the Linux devicetree schema.

Some comments on the schema:

  1. As mentioned previously, the properties should have hyphens instead of underscores.
  2. UUIDs should be in binary format, not string, right?
  3. 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)
  4. Should load-address be 64-bit? You should really have #address-cells etc. to indicate this
  5. 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
  6. The compatible string should be <vendor,device> so better to use than , which might be confusing
  7. 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?
  8. For 'owner', could you enumerate value values? Is this just for logging or does it affect operation.
  9. 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?

@sjg20 sjg20 Nov 25, 2025

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there any update on this? It there a plan to upstream to Linux schema, or will it stay separate?

@harrisonmutai-arm harrisonmutai-arm Dec 11, 2025

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@harrisonmutai-arm harrisonmutai-arm Dec 11, 2025

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@sjg20 sjg20 Jan 5, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?



.. |hdr_size_desc| replace:: The size of this entry header in bytes must be set to `8`.
.. |current_version| replace:: `0x1`
Loading