February 2020 - TF-A - lists.trustedfirmware.org

Re: [TF-A] Design proposal: firmware debugfs interface

by Olivier Deprez

Hi, To complement the DebugFS design proposal document, here is a corresponding TF-A patchset: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2422 https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2431 https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2432 https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2423 https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2421 An associated TFTF test case illustrates the usage: https://review.trustedfirmware.org/c/TF-A/tf-a-tests/+/2433 Regards, Olivier. ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Olivier Deprez via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 25 October 2019 15:30 To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] Design proposal: firmware debugfs interface Hi All, We are proposing a new firmware debug interface in the form of a "debug filesystem". The intent is to expose live firmware data or firmware driver HAL to the upper layers, in debug builds. For people interested, please review and comment the design proposal: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2381 The design is not closed, the intent is to collect opinions, and have a discussion on options and implications. Thanks & Regards, Olivier. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

4 years, 8 months

1
1
0 0

Re: [TF-A] [RFC] New feature in TF-A to load encrypted FIP payloads: address implementation concerns

by Sumit Garg

Hi Everyone, I have tried to address most of the implementation concerns with updated patch-set [1] as follows: *Concern*: Firmware encryption bit needs to be signed *Address*: Moved the firmware encryption bit from FIP ToC header to "io_uuid_spec_t" struct which is part of "plat_io_policy" that is embedded in the boot-loader (BL1 or BL2) and hence firmware encryption bit is signed. Also, with this implementation fip_tool is no longer aware of encryption and just encrypted binaries are piped to fip_tool. *Concern*: Capability to encrypt with different keys for different images *Address*: Passed "img_id" buffer reference as an argument of "plat_get_enc_key_info()" API. So that platforms may choose to either provide a unique key per firmware image or just derive a key from HUK per firmware using "img_id" buffer as a salt. *Concern*: Coupling of FIP and encryption layer *Address*: Firstly I think we all can agree that encryption layer provides confidentiality protection specific to IO storage. Secondly FIP is actually a packaging layer that sits over actual IO layer and having the encryption layer coupled with FIP provides an abstraction layer for any FIP payload which in turn provides the following features: 1. Allows the firmware certificates to be encrypted as well to protect against cloning satisfying R050_TBBR_PROTECTION requirement. 2. Allows the firmware configuration data to be encrypted as well. 3. Provides a capability to have a secure key store as FIP payload which is protected using HUK. *Concern*: Allow usage of alternative verify-then-decrypt method *Address*: A platform could disable this encryption layer and implement decryption as part of "bl2_plat_handle_post_image_load()". Please let me know in case I missed any implementation concerns and feel free to provide your feedback on updated patch-set [1]. [1] https://review.trustedfirmware.org/q/topic:%22tbbr%252Ffw_enc%22+(status:op… Regards, Sumit

4 years, 9 months

4
11
0 0

Tentatively Accepted: TF-A Tech Forum @ Thu Mar 12, 2020 10:30pm - 11:30pm (IST) (Bill Fletcher via TF-A)

by sandeep.tripathy＠broadcom.com

sandeep.tripathy(a)broadcom.com has replied "Maybe" to this invitation. Title: TF-A Tech Forum This meeting originally contained an attachment. Please contact your organizer for the attachment. This event has been changed. TF-A Tech Forum When Thu 12 Mar 2020 17:00 – 18:00 United Kingdom Time Calendar tf-a(a)lists.trustedfirmware.org Who (Guest list has been hidden at organiser's request) more details » Changed: We are starting an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Future invites will be via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/ Trusted Firmware is inviting you to a scheduled Zoom meeting. Join Zoom Meeting https://zoom.us/j/9159704974 Meeting ID: 915 970 4974 One tap mobile +16465588656,,9159704974# US (New York) +16699009128,,9159704974# US (San Jose) Dial by your location +1 646 558 8656 US (New York) +1 669 900 9128 US (San Jose) 877 853 5247 US Toll-free 888 788 0099 US Toll-free Meeting ID: 915 970 4974 Find your local number: https://zoom.us/u/ad27hc6t7h (updated due to content filtering issues) Going (tf-a(a)lists.trustedfirmware.org)? Yes - Maybe - No more options » Invitation from Google Calendar You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more . When: Thu Mar 12, 2020 10:30pm – 11:30pm India Standard Time - Kolkata Calendar: Bill Fletcher via TF-A Who: * Bill Fletcher via TF-A - organizer * sandeep.tripathy(a)broadcom.com - creator Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

4 years, 9 months

1
0
0 0

Updated invitation: TF-A Tech Forum @ Thu 12 Mar 2020 17:00 - 18:00 (GMT) (tf-a@lists.trustedfirmware.org)

by Bill Fletcher

This event has been changed. Title: TF-A Tech Forum We are starting an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Future invites will be via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h  (updated due to content filtering issues) (changed) When: Thu 12 Mar 2020 17:00 – 18:00 United Kingdom Time Calendar: tf-a(a)lists.trustedfirmware.org Who: (Guest list has been hidden at organiser's request) Event details: https://www.google.com/calendar/event?action=VIEW&eid=MGVhNDdsMGVqNnEzZ3BpY… Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

4 years, 9 months

1
0
0 0

Invitation: TF-A Tech Forum @ Thu 12 Mar 2020 17:00 - 18:00 (GMT) (tf-a@lists.trustedfirmware.org)

by Bill Fletcher

You have been invited to the following event. Title: TF-A Tech Forum We are starting an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Future invites will be via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h   When: Thu 12 Mar 2020 17:00 – 18:00 United Kingdom Time Calendar: tf-a(a)lists.trustedfirmware.org Who: (Guest list has been hidden at organiser's request) Event details: https://www.google.com/calendar/event?action=VIEW&eid=MGVhNDdsMGVqNnEzZ3BpY… Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

4 years, 9 months

1
0
0 0

Re: [TF-A] FIP header flags available for feature selection

by Soby Mathew

Hi Scott Please add the platform specific flags as a field in fip_dev_state_t. typedef struct { uintptr_t dev_spec; uint32_t plat_toc_flag; } fip_dev_state_t; Then this field can be updated as part of verifying the FIP header. This header needs to be cleared when the device is closed. Introduce a helper in fip driver to query the flags: int fip_dev_get_plat_toc_flag(io_dev_info_t *dev_info, uint32_t *plat_toc_flag); That should satisfy your requirement. Best Regards Soby Mathew > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Scott > Branden via TF-A > Sent: 07 February 2020 18:57 > To: tf-a(a)lists.trustedfirmware.org > Subject: [TF-A] FIP header flags available for feature selection > > Hello, > > The fip header has reserved fields available for platform specific use. > The fiptool allows these header fields to be filled in using the --plat-toc-flags. > > A call needs to be available in the ATF framework to get these flags without > accessing the FIP file again to get these flags. > We have a solution we've used for ATF for quite some time to access these > flags. > > It's finally being upstreamed here: > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2839 > > If there are any other efficient methods to access these flags or a better > proposal please suggest. > > Thanks, > Scott > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

4 years, 10 months

2
1
0 0

Re: [TF-A] [RFC] Multiple Signing Domains

by Sandrine Bailleux

Hi Raghu, Thanks a lot for the review comments and feedback! On 2/25/20 3:45 AM, Raghu Krishnamurthy via TF-A wrote: > The patch stack looks great! I do have a suggestion for the long term > evolution/future work on root's of trust and cert_create. It would be > great to generalize "dual-root" to "multi-root". It is conceivable that > firmware supporting secure partitions/SPCI etc, could move to having > multiple root's of trust. Here we have the silicon provider, and the > platform owner as two roots, but a more complex system could contain > silicon firmware, platform firmware and multiple secure partitions, each > signed by different entities. To remove the signing dependencies between > each of these entities, we could have a ROTPK for each of these entities > and the same solution used here, can be applied to solve multiple root's > of trust and is summarized very well by your statement -"As long as > there is a defined contract between BL2 and the (P)(*)ROTK-rooted images > as to how/where to securely get this key or hash, there should not be > any need for the two vendors to do any cross-signing." >> To do this, If possible, we should start moving away from tables such as > the ones in cert_create/src/dualroot/cot.c and have platforms provide > the certificate dependencies and keys used to sign them in a config > file. This achieves two things: it makes cert_create independent of the > cert chain a platform wants to use and the number of roots of trust, > and, makes cert_create more usable by reducing the number of command > line arguments to be provided, which is a long list today. You could > potentially use the config file provided to auto generate the tbbr_cot.c > file being linked into the firmware too. > > Let me know what you think. I agree with everything you said above. Indeed, there's no reason to stop at 2 roots of trust and as you pointed out there are real use cases to enable more. The dualroot chain of trust is only the first step in that direction and is a useful way to experiment with extending the TBBR implementation and chain of trust, while addressing a real use case. Also completely agree with the lack of flexibility of the hard-coded chain of trust in cert_create/src/dualroot/cot.c and drivers/auth/dualroot/cot.c for that matter. In fact, we (at Arm) are thinking along the same lines as you and have had similar ideas boiling for some time. We are making gradual changes to introduce more flexibility into TF-A, not just for the chain of trust, but for any platform-specific data. Maybe you've seen the recent FConf framework patches, which is a key piece into enabling platform layers to move platform-specific data into configuration files. There is still work to do but down the line we are already thinking about moving the chain of trust description into such a configuration file. Moving the CoT into a configuration file has many advantages: - It could constitute the single input source for the chain of trust, serving both the cert_create tool and the firmware. Today, the CoT is described and duplicated in both places and there is really no good reason to keep things like that IMO. As you said, we could auto-generate the tbbr_cot.c file and build into the firmware, or even have the firmware dynamically parse the configuration file at runtime and extract its CoT. - It could simplify the description of the CoT. Today, I think that the C data structures in tbbr_cot.c are quite complex and not straight-forward to understand at first. If we described them using some configuration language, I believe we could abstract some of these details away or at least organize them in a more intuitive way. Regards, Sandrine

4 years, 10 months

2
1
0 0

Re: [TF-A] [RFC] Multiple Signing Domains

by Raghu Krishnamurthy

Hi Sandrine, The patch stack looks great! I do have a suggestion for the long term evolution/future work on root's of trust and cert_create. It would be great to generalize "dual-root" to "multi-root". It is conceivable that firmware supporting secure partitions/SPCI etc, could move to having multiple root's of trust. Here we have the silicon provider, and the platform owner as two roots, but a more complex system could contain silicon firmware, platform firmware and multiple secure partitions, each signed by different entities. To remove the signing dependencies between each of these entities, we could have a ROTPK for each of these entities and the same solution used here, can be applied to solve multiple root's of trust and is summarized very well by your statement -"As long as there is a defined contract between BL2 and the (P)(*)ROTK-rooted images as to how/where to securely get this key or hash, there should not be any need for the two vendors to do any cross-signing." To do this, If possible, we should start moving away from tables such as the ones in cert_create/src/dualroot/cot.c and have platforms provide the certificate dependencies and keys used to sign them in a config file. This achieves two things: it makes cert_create independent of the cert chain a platform wants to use and the number of roots of trust, and, makes cert_create more usable by reducing the number of command line arguments to be provided, which is a long list today. You could potentially use the config file provided to auto generate the tbbr_cot.c file being linked into the firmware too. Let me know what you think. Thanks Raghu On 2/24/20 3:43 AM, Sandrine Bailleux via TF-A wrote: > Hi, > > Following up on my email sent in November 2019: > https://lists.trustedfirmware.org/pipermail/tf-a/2019-November/000124.html > > and the proof-of-concept code and documentation shared at that time: > [1] > https://developer.trustedfirmware.org/w/tf_a/poc-multiple-signing-domains/ > [2] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2443 > > I've made a number of improvements and cleanups in the code. I am > posting a new version that introduces this new chain of trust (called > "dualroot", as it has 2 roots of trust) as an alternative to the default > TBBR one. Right now, it is only enabled on some Arm platforms but it > should be pretty straight-forward to extend this to other platforms. > > The code is available there: > https://review.trustedfirmware.org/q/topic:%22sb%252Fdualroot%22 > > and is comprised of the following patches: > - Introduce a new "dualroot" chain of trust > - cert_create: Define the dualroot CoT > - Build system: Changes to drive cert_create for dualroot CoT > - plat/arm: Provide some PROTK files for development > - plat/arm: Add support for dualroot CoT > - plat/arm: Pass cookie argument down to arm_get_rotpk_info() > - plat/arm: Retrieve the right ROTPK when using the dualroot CoT > > This patch stack is based on preparatory work (which has already been > merged) to select a different CoT. This patch stack: > - Did some build system refactoring. > - Introduced a new 'COT' build option to select the chosen chain of trust. > - Made no functional change. > See > http://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=dcd03… > > Note that I've not updated the TF-A documentation just yet to reflect > these changes. I will do that once I've had some initial feedback from > the community and feel that we're reaching a consensus (in the interest > of saving time keeping documentation aligned with code going under rework). > > > Changes Compared to the Proof-of-Concept Patch [2] > -------------------------------------------------- > > - Introduced a proper, separate chain of trust rather than hijacking the > TBBR one. It also has its own header file for certificate extensions > OIDs now. > > - NS-ROTPK has been renamed into "Platform ROTPK", or PROTPK for short. > Going forward, this key would sign both non-trusted images (such as > BL33) and secure partitions. The NS- prefix did not fit well this use > case. The "Platform" prefix instead refers to the owner of this key, > i.e. the platform owner, as opposed to the Silicon Provider. > > - Removed Non-Trusted World Bootloader Key Certificate. > This didn't seem needed in this context and simplifies the CoT. > > - Removed the Non-Trusted Key from the Trusted Key Certificate, as it's > not used in this CoT (the PROTPK signs all non-trusted images instead). > > - As a consequence, the corresponding option for feeding the PROTPK to > the cert_create tool has been renamed into --prot-key (was --ns-rot-key). > > - The hash of the PROTPK is now provided in a file rather than being > hard-coded into the code. This is cleaner than polluting the code with a > byte array. > > - Proper integration in the build system. > Using the dualroot chain of trust is achieved through the COT build > option: > > make <usual trusted boot build options> COT=dualroot > > - plat_get_rotpk_info() is unchanged if using the TBBR CoT. > The alternative implementation managing both ROTPK or PROTPK is > selected only if the dualroot CoT has been chosen at build time. > > > Testing and Supported Platforms > ------------------------------- > > Tested on AEMv8-A Base Platform (AArch32 and AArch64 execution states), > rde1edge, rdn1edge, SGI-575 and SGM-775 FVPs (all available on > https://developer.arm.com/tools-and-software/simulation-models/fixed-virtua…). > > Arm Juno is not supported right now because it has its own > implementation of plat_get_arm_rotpk_info() instead of piggy-backing on > the Arm common one. > > Ran the standard set of tests available in the TF-A-Tests repository: > http://git.trustedfirmware.org/TF-A/tf-a-tests.git/about/ > > Also ran the firmware update tests available in the same repository. See > > https://trustedfirmware-a-tests.readthedocs.io/en/latest/user-guide.html#ns… > for more information. > > Finally, performed some end-to-end boot tests to Linux. > > And of course, ran our regression tests to make sure that existing > configurations using the TBBR chain of trust are still working as expected. > > > Caveats > ------- > > The PROTPK hash is embedded into the firmware. It's unlikely that a real > system would like to do that. The use case targeted here is to remove > the need for the primary ROTPK owner to interact with the PROTPK owner. > If BL2 embeds the hash, this defeats the purpose, as now the BL2 owner > (which is expected to be the primary ROTPK owner) has to get the PROTPK > from the other vendor. > > In a real system, we would expect the PROTPK to be provisioned in such a > way that BL2 is able to retrieve it. For example, the PROTPK owner might > burn it (or a hash of it) in some OTP memory. As long as there is a > defined contract between BL2 and the PROTK-rooted images as to how/where > to securely get this key or hash, there should not be any need for the > two vendors to do any cross-signing. > > This caveat was already present in the proof-of-concept [2] and stays > out of the scope for this work, as this ties into broader topics such as > key provisioning. Right now, the onus is on the platform layer to handle > this appropriately. > > > Future work > ----------- > > We have plans to change the "dualroot" CoT further and extend the PROTPK > signing domain with a secure partition. This would demonstrate the use > of several secure partitions, some owned by the silicon provider, others > owned by the platform owner. > > > Regards, > Sandrine >

4 years, 10 months

1
0
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 1 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 3 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 354288: Memory - corruptions (OVERRUN) ________________________________________________________________________________________________________ *** CID 354288: Memory - corruptions (OVERRUN) /plat/intel/soc/common/socfpga_psci.c: 138 in socfpga_system_reset() 132 133 extern uint64_t intel_rsu_update_address; 134 135 static void __dead2 socfpga_system_reset(void) 136 { 137 if (intel_rsu_update_address) >>> CID 354288: Memory - corruptions (OVERRUN) >>> Overrunning buffer pointed to by "&intel_rsu_update_address" of 8 bytes by passing it to a function which accesses it at byte offset 15. 138 mailbox_rsu_update(&intel_rsu_update_address); 139 else 140 mailbox_reset_cold(); 141 142 while (1) 143 wfi(); ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/ls/click?upn=nJaKvJSIH-2FPAfmty-2BK5tYpPkl…

4 years, 10 months

1
0
0 0

Re: [TF-A] [RFC] Multiple Signing Domains

by Sandrine Bailleux

Hi, Following up on my email sent in November 2019: https://lists.trustedfirmware.org/pipermail/tf-a/2019-November/000124.html and the proof-of-concept code and documentation shared at that time: [1] https://developer.trustedfirmware.org/w/tf_a/poc-multiple-signing-domains/ [2] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2443 I've made a number of improvements and cleanups in the code. I am posting a new version that introduces this new chain of trust (called "dualroot", as it has 2 roots of trust) as an alternative to the default TBBR one. Right now, it is only enabled on some Arm platforms but it should be pretty straight-forward to extend this to other platforms. The code is available there: https://review.trustedfirmware.org/q/topic:%22sb%252Fdualroot%22 and is comprised of the following patches: - Introduce a new "dualroot" chain of trust - cert_create: Define the dualroot CoT - Build system: Changes to drive cert_create for dualroot CoT - plat/arm: Provide some PROTK files for development - plat/arm: Add support for dualroot CoT - plat/arm: Pass cookie argument down to arm_get_rotpk_info() - plat/arm: Retrieve the right ROTPK when using the dualroot CoT This patch stack is based on preparatory work (which has already been merged) to select a different CoT. This patch stack: - Did some build system refactoring. - Introduced a new 'COT' build option to select the chosen chain of trust. - Made no functional change. See http://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=dcd03… Note that I've not updated the TF-A documentation just yet to reflect these changes. I will do that once I've had some initial feedback from the community and feel that we're reaching a consensus (in the interest of saving time keeping documentation aligned with code going under rework). Changes Compared to the Proof-of-Concept Patch [2] -------------------------------------------------- - Introduced a proper, separate chain of trust rather than hijacking the TBBR one. It also has its own header file for certificate extensions OIDs now. - NS-ROTPK has been renamed into "Platform ROTPK", or PROTPK for short. Going forward, this key would sign both non-trusted images (such as BL33) and secure partitions. The NS- prefix did not fit well this use case. The "Platform" prefix instead refers to the owner of this key, i.e. the platform owner, as opposed to the Silicon Provider. - Removed Non-Trusted World Bootloader Key Certificate. This didn't seem needed in this context and simplifies the CoT. - Removed the Non-Trusted Key from the Trusted Key Certificate, as it's not used in this CoT (the PROTPK signs all non-trusted images instead). - As a consequence, the corresponding option for feeding the PROTPK to the cert_create tool has been renamed into --prot-key (was --ns-rot-key). - The hash of the PROTPK is now provided in a file rather than being hard-coded into the code. This is cleaner than polluting the code with a byte array. - Proper integration in the build system. Using the dualroot chain of trust is achieved through the COT build option: make <usual trusted boot build options> COT=dualroot - plat_get_rotpk_info() is unchanged if using the TBBR CoT. The alternative implementation managing both ROTPK or PROTPK is selected only if the dualroot CoT has been chosen at build time. Testing and Supported Platforms ------------------------------- Tested on AEMv8-A Base Platform (AArch32 and AArch64 execution states), rde1edge, rdn1edge, SGI-575 and SGM-775 FVPs (all available on https://developer.arm.com/tools-and-software/simulation-models/fixed-virtua…). Arm Juno is not supported right now because it has its own implementation of plat_get_arm_rotpk_info() instead of piggy-backing on the Arm common one. Ran the standard set of tests available in the TF-A-Tests repository: http://git.trustedfirmware.org/TF-A/tf-a-tests.git/about/ Also ran the firmware update tests available in the same repository. See https://trustedfirmware-a-tests.readthedocs.io/en/latest/user-guide.html#ns… for more information. Finally, performed some end-to-end boot tests to Linux. And of course, ran our regression tests to make sure that existing configurations using the TBBR chain of trust are still working as expected. Caveats ------- The PROTPK hash is embedded into the firmware. It's unlikely that a real system would like to do that. The use case targeted here is to remove the need for the primary ROTPK owner to interact with the PROTPK owner. If BL2 embeds the hash, this defeats the purpose, as now the BL2 owner (which is expected to be the primary ROTPK owner) has to get the PROTPK from the other vendor. In a real system, we would expect the PROTPK to be provisioned in such a way that BL2 is able to retrieve it. For example, the PROTPK owner might burn it (or a hash of it) in some OTP memory. As long as there is a defined contract between BL2 and the PROTK-rooted images as to how/where to securely get this key or hash, there should not be any need for the two vendors to do any cross-signing. This caveat was already present in the proof-of-concept [2] and stays out of the scope for this work, as this ties into broader topics such as key provisioning. Right now, the onus is on the platform layer to handle this appropriately. Future work ----------- We have plans to change the "dualroot" CoT further and extend the PROTPK signing domain with a secure partition. This would demonstrate the use of several secure partitions, some owned by the silicon provider, others owned by the platform owner. Regards, Sandrine

4 years, 10 months

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

TF-A February 2020