Add Trusted Boot Firmware Configuration entry #37
Conversation
harrisonmutai-arm
force-pushed
the
hm/tf-configs
branch
from
1784dcd
to
562d7f3
Compare
| @@ -902,5 +902,42 @@ This manifest contains the SPMC attribute node consumed by the SPMD | |||
| - hdr_size | |||
| - Holds a SPMC manifest image in DT format. | |||
|
|
|||
| **DT Trusted Boot Firmware Configuration entry layout | |||
There was a problem hiding this comment.
Would it be possible to put this information into the control dtb?
There was a problem hiding this comment.
No I don't think it would, the information in this dtb ( i.e. chain-of-trust, and mbedtls settings) is only intended for consumption by the trusted bootloader. Putting this information in the hardware dtb would require a client to strip this information prior to handover to later stages.
There was a problem hiding this comment.
Why is that? Where are the bindings for these nodes/properties?
There was a problem hiding this comment.
The nodes/properties are used specifically for the configuration of firmware. They aren't intended for use by any other components, and are unrelated to hardware descriptions. In some cases, the nodes are meant to be secret. Here is an example of the chain-of-trust bindings: https://review.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a/+/refs/heads/master/docs/components/cot-binding.rst.
There was a problem hiding this comment.
The nodes/properties are used specifically for the configuration of firmware. They aren't intended for use by any other components, and are unrelated to hardware descriptions. In some cases, the nodes are meant to be secret. Here is an example of the chain-of-trust bindings: https://review.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a/+/refs/heads/master/docs/components/cot-binding.rst.
Thank you for the info. The binding looks like a good start but shouldn't it be in yaml format? How is this validated? I don't see mention of secret nodes. We don't have a way (at present) of specifying when nodes should be deleted before the next boot phase is invoked.
I see that the widevine binding is in the 'other' DT. This will get very confusing.
In general this seems to be a can of worms. We should have one DT schema and work to get it upstream
There was a problem hiding this comment.
Each FW image may have its own FW_CONFIG contain data that only of relevance to its receiver and not subsequent components. This data is orthogonal to the HW device tree and device tree format is simply used as a convenient format for this data. This is all internal TF-A design stuff and doesn't need to be specified more widely.
This seems to open a distinction between the devicetree used by the system as a whole and the one used by TF-A. I have been pushing back against attempts to have U-Boot have its own DT. If TF-A has this, then we will need U-Boot to access two different DTs, won't we?
Why have a separate one? I mean, what is the benefit?
There was a problem hiding this comment.
This seems to open a distinction between the devicetree used by the system as a whole and the one used by TF-A.
TF-A consumes both system device tree and this special device tree.
This TE is for Trusted Boot Configuration data which is consumed by BL2 (image loader) phase of TF-A. To load images with chain of trust we need image UUIDs and for some images (like Secure partitions) we also need load addresses. Considering we have a lot of images (32 standard images + Any number of SP's) we use device tree as a configuration file.
If TF-A has this, then we will need U-Boot to access two different DTs, won't we?
No, U-boot don't need this devicetree
We are currently working on documenting binding within this device tree in TF-A documentation.
There was a problem hiding this comment.
Thanks for the responses.
I would like to see the lifetime of this information defined...e.g. you suggest that some pieces must not be passed onto the OS. Which ones and why not? It should be written out explicitly.
Also if we want to use a single DT, is that possible / allowed?
I also wish to note that you do not intend (I believe) to get these bindings accepted in dt-schema.
I suspect you plan to merge this anyway, but at least you have my objection noted. This will be the second PR merged over my objections.
There was a problem hiding this comment.
Hi Simon,
I've created a binding document within the TF-A documentation that outlines the usage of the TB_FW_CONFIG format. This document is referenced in the specification and contains all the essential information. Let us know if you're satisfied with this and we can look to get the change merged.
There was a problem hiding this comment.
Hi again,
Thank you for the binding. It helps a lot!
The properties should have hyphens, not underscores. It isn't clear to me why UUIDs are in there. The binding documentation is mostly not enough (for me) to figure out what it all means. For one thing, I don't see any mention of nodes.
Anyway the purpose of this PR is not to agree the binding. It just seems clear to me that the binding as is would need changes for dt-schema. Other projects have gone to enormous efforts to get bindings agreed (e.g. U-Boot). Could TF-A put in some effort to?
Could you clarify the lifetime of this information, as I requested?
Overall I believe it would be better to get an official binding agreed.
| @@ -902,5 +902,42 @@ This manifest contains the SPMC attribute node consumed by the SPMD | |||
| - hdr_size | |||
| - Holds a SPMC manifest image in DT format. | |||
|
|
|||
| **DT Trusted Boot Firmware Configuration entry layout | |||
There was a problem hiding this comment.
Each FW image may have its own FW_CONFIG contain data that only of relevance to its receiver and not subsequent components. This data is orthogonal to the HW device tree and device tree format is simply used as a convenient format for this data. This is all internal TF-A design stuff and doesn't need to be specified more widely.
harrisonmutai-arm
force-pushed
the
hm/tf-configs
branch
2 times, most recently
from
8d1ce64
to
3d07a8a
Compare
harrisonmutai-arm
force-pushed
the
hm/tf-configs
branch
from
3d07a8a
to
24d296f
Compare
`TL_TAG_RW_MEM_LAYOUT64` encapsulates a structure used to represent the layout of a region of memory on 64-bit platforms [2]. In TF-A this is used to represent the `meminfo_t` structure passed between BL1 and BL2, which provides BL2 with information about the space it has available in BL2. The `TL_TAG_TB_FW_CONFIG` entry type encapsulates the trusted bootloader firmware configuration [1]. [1] FirmwareHandoff/firmware_handoff#37 [2] FirmwareHandoff/firmware_handoff#36 Change-Id: I1e0eeec2ec204e469896490d42a9dce9b1b2f209 Signed-off-by: Harrison Mutai <harrison.mutai@arm.com>
This entry type holds the flattened device tree used to configure trusted firmware, it is specific the to the Trusted Firmware-A project. Signed-off-by: Harrison Mutai <harrison.mutai@arm.com>
harrisonmutai-arm
force-pushed
the
hm/tf-configs
branch
from
24d296f
to
f2c7740
Compare
This entry type holds the flattened device tree used to configure trusted firmware, it is specific the to the Trusted Firmware-A project.