- TF-A - lists.trustedfirmware.org

Re: [TF-A] [EXT] Patch-set review request: New NXP Platform LX2120ARDB support on TFA

by Varun Wadekar

Hello Pankaj, Hope you are doing well. The initial email point to one change, but I see that as the tip of a patch series. I reviewed https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3370 and left some comments, but did not review the complete patch series. Are you requesting a review of the entire patch series? -Varun From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Joanna Farley via TF-A Sent: Tuesday, March 31, 2020 9:37 AM To: Pankaj Gupta <pankaj.gupta(a)nxp.com>; tf-a(a)lists.trustedfirmware.org Subject: Re: [TF-A] [EXT] Patch-set review request: New NXP Platform LX2120ARDB support on TFA External email: Use caution opening links or attachments Hi Pankaj, We will try, one of the arm team has done some +1 reviews and I have just kicked of a CI+2 run on the top of the patch stack. As you can imagine the Arm team is pressed for time the closer to the freeze date. Other TF-A contributors you all have +1 rights so if folks have time assistance with further +1 reviews would be appreciated as that would help in accelerating confidence is getting +2 and merging. Traditionally the project has relied on Arm folks but for some time now all contributors have had +1 rights on each other patches and the new project maintenance proposal is set up to take us in the direction of enabling all contributors helping each other. Thanks Joanna From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org<mailto:tf-a-bounces@lists.trustedfirmware.org>> on behalf of Pankaj Gupta via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Reply to: Pankaj Gupta <pankaj.gupta(a)nxp.com<mailto:pankaj.gupta@nxp.com>> Date: Monday, 30 March 2020 at 20:48 To: "tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>" <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Subject: Re: [TF-A] [EXT] Patch-set review request: New NXP Platform LX2120ARDB support on TFA Please find the link to the review request. https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3370 Regards Pankaj From: Pankaj Gupta via TF-A Sent: Monday, 30 March, 22:57 Subject: [EXT] [TF-A] Patch-set review request: New NXP Platform LX2120ARDB support on TFA To: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> Caution: EXT Email Hi All, Please pick this review request so that code changes can be merged before code freeze. Thanks. Regards Pankaj 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. ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. -----------------------------------------------------------------------------------

5 years, 1 month

2
2
0 0

Re: [TF-A] RFR: Tegra fixes for v2.3

by Varun Wadekar

Hello team, Please help review and merge the following bug fixes before v2.3 is released. * https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3819: include: context_mgmt: include ep_info.h * https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3820: Tegra: enable EHF for watchdog timer interrupts * https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3818: Tegra: remove ENABLE_SVE_FOR_NS = 0 Thanks. From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Varun Wadekar via TF-A Sent: Monday, March 30, 2020 10:02 AM To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] RFR: Tegra fixes for v2.3 External email: Use caution opening links or attachments Hello team, Please help review and merge the following bug fixes before v2.3 is released. * https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3731: Tegra: fixup GIC init from the 'on_finish' handler * https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3770: Tegra186: increase memory mapped regions Thanks. ________________________________ This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ________________________________

5 years, 1 month

1
0
0 0

Re: [TF-A] Event Log for Measured Boot

by Varun Wadekar

Hello Alexei, Just curious, the patch is huge and will take some time to review. Do you expect this change to be merged before the v2.3 release? -Varun From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Alexei Fedorov via TF-A Sent: Tuesday, March 31, 2020 7:19 AM To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] Event Log for Measured Boot External email: Use caution opening links or attachments Hi, Please review and provide your comments for the patch which adds Event Log generation for the Measured Boot. https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3806 Thanks. Alexei 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. ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. -----------------------------------------------------------------------------------

5 years, 1 month

2
1
0 0

Re: [TF-A] [EXT] Patch-set review request: New NXP Platform LX2120ARDB support on TFA

by Joanna Farley

Hi Pankaj, We will try, one of the arm team has done some +1 reviews and I have just kicked of a CI+2 run on the top of the patch stack. As you can imagine the Arm team is pressed for time the closer to the freeze date. Other TF-A contributors you all have +1 rights so if folks have time assistance with further +1 reviews would be appreciated as that would help in accelerating confidence is getting +2 and merging. Traditionally the project has relied on Arm folks but for some time now all contributors have had +1 rights on each other patches and the new project maintenance proposal is set up to take us in the direction of enabling all contributors helping each other. Thanks Joanna From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Pankaj Gupta via TF-A <tf-a(a)lists.trustedfirmware.org> Reply to: Pankaj Gupta <pankaj.gupta(a)nxp.com> Date: Monday, 30 March 2020 at 20:48 To: "tf-a(a)lists.trustedfirmware.org" <tf-a(a)lists.trustedfirmware.org> Subject: Re: [TF-A] [EXT] Patch-set review request: New NXP Platform LX2120ARDB support on TFA Please find the link to the review request. https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3370 Regards Pankaj From: Pankaj Gupta via TF-A Sent: Monday, 30 March, 22:57 Subject: [EXT] [TF-A] Patch-set review request: New NXP Platform LX2120ARDB support on TFA To: tf-a(a)lists.trustedfirmware.org Caution: EXT Email Hi All, Please pick this review request so that code changes can be merged before code freeze. Thanks. Regards Pankaj 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.

5 years, 1 month

1
0
0 0

Event Log for Measured Boot

by Alexei Fedorov

Hi, Please review and provide your comments for the patch which adds Event Log generation for the Measured Boot. https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3806 Thanks. Alexei 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.

5 years, 1 month

1
0
0 0

Re: [TF-A] [EXT] Patch-set review request: New NXP Platform LX2120ARDB support on TFA

by Pankaj Gupta

Please find the link to the review request. https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3370 Regards Pankaj From: Pankaj Gupta via TF-A Sent: Monday, 30 March, 22:57 Subject: [EXT] [TF-A] Patch-set review request: New NXP Platform LX2120ARDB support on TFA To: tf-a(a)lists.trustedfirmware.org Caution: EXT Email Hi All, Please pick this review request so that code changes can be merged before code freeze. Thanks. Regards Pankaj

5 years, 1 month

1
0
0 0

Patch-set review request: New NXP Platform LX2120ARDB support on TFA

by Pankaj Gupta

Hi All, Please pick this review request so that code changes can be merged before code freeze. Thanks. Regards Pankaj

5 years, 1 month

1
0
0 0

RFR: Tegra fixes for v2.3

by Varun Wadekar

Hello team, Please help review and merge the following bug fixes before v2.3 is released. * https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3731: Tegra: fixup GIC init from the 'on_finish' handler * https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3770: Tegra186: increase memory mapped regions Thanks. ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. -----------------------------------------------------------------------------------

5 years, 1 month

1
0
0 0

GICv3 driver makefile

by Alexei Fedorov

Hello, As the prepartion for the series of patches for adding GICv3.1 and GICv4 support, please review and provide your comments for the patch which introduces GICv3 makefile and adds configuration options for the driver. https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3754 Regards. Alexei 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.

5 years, 1 month

1
0
0 0

Re: [TF-A] Proposal for Measured Boot Implementation

by Alexei Fedorov

Hi Raghu, Thanks for reviewing the proposal. Please find my answers below. 1) The idea was to use the same hash algorithm throughout all TF-A code for consistency and not introduce any new build flags. One of the initial implementations even didn't calculate the hash itself but was reading verified data provided by the Chain of Trust (CoT) for the purpose of optimisation. Existing definition of TF_MBEDTLS_HASH_ALG_ID in 'drivers\auth\mbedtls\mbedtls_common.mk' at line #76: ifeq (${HASH_ALG}, sha384) TF_MBEDTLS_HASH_ALG_ID := TF_MBEDTLS_SHA384 else ifeq (${HASH_ALG}, sha512) TF_MBEDTLS_HASH_ALG_ID := TF_MBEDTLS_SHA512 else TF_MBEDTLS_HASH_ALG_ID := TF_MBEDTLS_SHA256 endif passed to 'include\drivers\auth\mbedtls\mbedtls_config.h', line #72 #define MBEDTLS_SHA256_C #if (TF_MBEDTLS_HASH_ALG_ID != TF_MBEDTLS_SHA256) #define MBEDTLS_SHA512_C #endif and used in Mbed TLS to define MBEDTLS_MD_MAX_SIZE in 'include\mbedtls\md.h': #if defined(MBEDTLS_SHA512_C) #define MBEDTLS_MD_MAX_SIZE 64 /* longest known is SHA512 */ #else #define MBEDTLS_MD_MAX_SIZE 32 /* longest known is SHA256 or less */ #endif makes impossible usage HASH_ALG=sha256 for TF-A and sha512 for Measured Boot calculations, because the following chain of function calls arm_bl1_set_bl2_hash() -> crypto_mod_calc_hash() -> crypto_lib_desc.calc_hash() -> calc_hash() -> mbedtls_md_info_from_type() returns CRYPTO_ERR_HASH error caused by insufficient space in internal Mbed TLS buffers and fixing this issue needs extra modifications in make and header files. Upgrading/changing the hash algorithm will require re-building of TF-A and re-flashing BL1 in ROM, so please explain what you mean by "potentially break measured boot on old devices in case a hash algorithm is broken" The functionality for getting the hash algorithm from the platform (e.g. eFuses) can be added later as a platform build option and requires fixing the issue described above. 2) Yes, Measured Boot requires TF-A built with TRUSTED_BOARD_BOOT option enabled, and as BL2 image is a part of CoT it is verified by BL1. 3) Yes. Event Log implementation is based on TCG Specifications. BL2 loads images, calculates their hashes and writes data into Event Log stored in Secure memory. 4) It is planned to add fTPM service implementation to TF-A, see Javier's message: https://lists.trustedfirmware.org/pipermail/tf-a/2020-March/000339.html Stuart could also comment on the naming convention. 5) N/A 6) Event Log is a complex structure with entries of different lengths, and TFTF test checks the length of each field against the remaining size of the Event Log's data to be processed before accessing and printing the actual data. Thanks. Alexei. ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Raghu Krishnamurthy via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 21 March 2020 05:53 To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: Re: [TF-A] Proposal for Measured Boot Implementation Hi Alexei, Thanks. This looks good at first glance. However, i do have some questions that aren't obvious to me by reading the description below and looking at code. Questions are numbered based on your original email. Perhaps these can be discussed in the TF-A forum if it is inconvenient over email. 1) Would be good if the hash alg comes from the config file. This will make the implementation "crypto agile" from the very beginning. It is common to want to upgrade/change the hash algorithm and since BL1 is in ROM, you potentially break measured boot on old devices in case a hash algorithm is broken. The other option is to get the hash algorithm from the platform, perhaps a platform gets it from eFuses as opposed to config files. 2) It looks like you are using memory allocated in the loaded DTB as the equivalent of a TPM "PCR". How is this protected from direct modification by BL2? Or is it not protected because BL2 forms a part of the Root-of-Trust for Measurement(RTM)?(since it's signature is verified by BL1?) 3) What does "Event Log" refer to? Is it the same event log proposed by TCG in the platform firmware profile ? As a general question, how close is the measured boot in TF-A/PSA going to be to TCG ? Will BL2 extend measurements for other images ? 4) Would be great not to refer to "TPM" in the measured boot implementation. Here we are implementing measured boot without a TPM, but it could be implemented with a TPM. Maybe it should be tcg event log? 5) OK. 6) What does validate event log mean here? More details ? Thanks -Raghu On 3/20/20 7:15 AM, Alexei Fedorov via TF-A wrote: > Hello, > > I'm preparing the next set of patches for Measured Boot support in TF-A, > please find some details on design and implementation below. > > 1. SHA256/384/512 hash algorithm for Measured Boot related hash calculations > is passed as an existing build 'HASH_ALG' build parameter. > > 2. BL1 calculates BL2 image hash and passes these data to BL2 via > FW_CONFIG/TB_FW_CONFIG device tree in new 'bl2_hash_data' byte array > added > in 'fvp_fw_config.dts'. > > These changes are part of the patch under review, please see > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3555 > > 3. Event Log is calculated by BL2 in Secure Memory and copied to > Non-secure memory. Address in Non-secure memory is calculated as: > > "nt_fw_config_addr + nt_fw_config_max_size" > > with values obtained from 'tb_fw_config': > > nt_fw_config_addr = <0x0 0x80000000>; > nt_fw_config_max_size = <0x200>; > > 4. Event Log address and size is passed by TOS_FW_CONFIG and NT_FW_CONFIG > device tree in 2 new added properties: > > Property name: 'tpm_event_log_addr' > Value type is an unsigned 64-bit integer specifying the physical address > of the Event Log. > > Property name: 'tpm_event_log_size' > Value type is an unsigned 32-bit integer specifying the size of the > Event Log. > > /* TPM Event Log Config */ > tpm_event_log { > compatible = "arm,nt_fw"; > tpm_event_log_addr = <0x0 0x0>; > tpm_event_log_size = <0x0>; > }; > > 5. TF-A provides Event Log to the BL33 (TFTF/UEFI/U-boot) in 'nt_fw_config' > device tree, which address is passed by BL31 as 'arg0' parameter, > see TFTF patch: > > https://review.trustedfirmware.org/c/TF-A/tf-a-tests/+/3327 > > 6. A new test which validates and prints Event Log data passed > in 'nt_fw_config' to BL33 will be added to TFTF. > > Please review and provide your comments on the proposed design. > > Regards. > Alexei. > > 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 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.

5 years, 1 month

3
7
0 0

Re: [TF-A] [TF-M] Project Maintenance Proposal for tf.org Projects

by Andrej Butok

Hello, >But I am worried that a self-review is rarely as good as a peer review On practice, unfortunately, some TF-M tasks are waiting weeks and even months for review and following approvals. If I were a maintainer & owner of my own TFM area, I do not want to wait & push & remind somebody else. Better to have a post-merge review for these cases, which does not limit and slow down the development. Thanks, Andrej Butok -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Sandrine Bailleux via TF-M Sent: Thursday, March 26, 2020 10:28 AM To: Christian Daudt <Christian.Daudt(a)cypress.com>; tf-a <tf-a(a)lists.trustedfirmware.org>; tf-m(a)lists.trustedfirmware.org; tsc(a)lists.trustedfirmware.org; op-tee(a)linaro.org Cc: nd(a)arm.com Subject: Re: [TF-M] Project Maintenance Proposal for tf.org Projects Hi Christian, Thanks a lot for the read and the comments! On 3/25/20 7:05 PM, Christian Daudt wrote: > ï¿½The maintenance proposal looks great ! I have some feedback on > specific portions: > ï¿½1. maintainer/owner/author patches. " Note that roles can be > cumulative, in particular the same individual can be both a code owner > and a maintainer. In such a scenario, the individual would be able to > self-merge a patch solely affecting his module, having the authority > to approve it from both a code owner and maintainer's point of view.": > I'm always leery of people self-approving their patches. At a minimum, > all self-patches should be published and a minimum wait time provided > for feedback. Or preferably that another maintainer does the merge (it > does not need to be mandated but should be suggested). Yes, actually this is something that generated some disagreement inside Arm as well and I am glad you're bringing this up here, as I'd like to hear more opinions on this. I too have concerns about allowing self-reviewing. I am not so much concerned about people potentially abusing of this situation to silently merge patches, as I think we should trust our maintainers. But I am worried that a self-review is rarely as good as a peer review, simply because it is so easy to miss things when it's your own work. I believe several pair of eyes is always better, as different people think differently, have different perspectives and backgrounds, and are able to catch different issues. But to pull this off, we need enough people to do all these reviews. The proposal currently allows self-review because some of us feared that mandating 2 reviewers for every patch (especially pure platform patches) would be impractical and too heavyweight, especially for the TF-M project in its current contributors organization, as I understand. It would be great to get more feedback from the TF-M community as to whether they think it could work in the end. It's a difficult balance between having the best possible code review practices, and realistically getting all the review work done in a timely manner, avoiding bottlenecks on specific people and keeping the flow of patches smooth. I like your idea of a minimum wait time provided for feedback. I think it could be a good middle ground solution. Your other suggestion of having a different maintainer doing the merge would work as well IMO but requires more workforce. Again this comes down to whether this can realistically be achieved for each project. This solution was actually suggested within Arm as well (and even called out at the end of the proposal ;) ). Bottom line is, in an ideal world I would like to condemn self-review because I consider this as bad practice, but I do not know whether this will be practical and will work for TF-M as well. > ï¿½2. 'timely manner': This expectation should be more explicit - > when the author can start requesting other maintainers to merge on > assumption that silence == approval (or not). Such timeliness > expectations are probably best set per project however. Yes, "timely manner" is definitely too vague and was actually left that way on purpose at this stage to avoid touching upon what I think is a sensitive subject! I am aware that some patches sometimes spend a long time in review, definitely longer than they should and it understandably generates some frustration. This is something we absolutely need to improve on IMO and hopefully a bigger pool of maintainers will help solve this issue. But I agree that the expected review timeline should be clearly established and it is probably best to let each project decides theirs. > ï¿½3. The proposal does not address branching strategies. i.e. will > there be separate maintainers for dev/master/stable branches? I don't > think it needs to address it yet - keep it simpler for a start. But a > todo saying something like "in the future this project maintenance > proposal might be expanded to address multi-branch maintainership" would be good. Good point. A todo sounds good, I will add one in the last section of the document. > ï¿½4. The platform lifecycle state machine has too many transitions. > "Fully maintained" <-> "orphan" -> "out" seems sufficient to me. Hmm OK. There might be too many transitions but I feel we need something between fully maintained and out, i.e. the limited support one. Julius Werner also pointed out on Thursday that orphan might be misplaced, as all these other stages deal with some degrees of feature support (what's known to work), whereas orphan is an orthogonal topic that is not directly related to the level of supported features. For example, a platform could have recently become orphan but all features and tests still work for some time. Regards, Sandrine -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…

5 years, 1 month

1
0
0 0

fTPM service implementation to test Measured Boot

by Javier Almansa Sobrino

Hello, Following up with the Proposal for Measured Boot Implementation described in https://lists.trustedfirmware.org/pipermail/tf-a/2020-March/000332.html , I am working on the implementation of a test fTPM service to exercise Measured Boot on TF-A. Some details about the implementation can be found below: 1.- The service will be based on Microsoft's reference implementation of the TPM 2.0 Specification by TCG. It will be implemented as an OP- TEE TA. 2.- During service initialisation, the fTPM service will read the TPM Event Log stored by Measured Boot in Secure Memory and it will extend it into the PCR specified by the log header. 3.- Alongside with the fTPM service, a test framework based on OP-TEE Toolkit is being implemented as well. This test framework will generate and run a Linux/Buildroot environment over a Foundation Model so the fTPM's PCRs can be accessed to verify its content. It is important here to highlight that this fTPM service and the related test framework are meant to be used only for demonstration purposes, it is not meant to be used as a production implementation. Please, let me know any comment or query you might have with regards this. Best regards, Javier

5 years, 1 month

1
0
0 0

Forthcoming Trusted Firmware-A 2.3 release

by Bipin Ravi

Hi, This is to notify that we are planning to target the Trusted Firmware-A 2.3 release during the third week of April as part of the regular 6 month cadence. The aim is to consolidate all TF-A work since the 2.2 release. As part of this, a release candidate tag will be created and release activities will commence from Monday April 6th. Essentially we will not merge any major enhancements from this date until the release is made. Please ensure any Pull Requests (PR's) desired to make the 2.2 release are submitted in good time to be complete by Friday April 3rd. Any major enhancement PR's still open after that date will not be merged until after the release. Thanks & best regards, [cid:image001.jpg@01D5F78C.8108B010] Bipin Ravi | Principal Design Enginee Bipin.ravi(a)arm.com<mailto:Bipin.ravi@arm.com> | Skype: Bipin.Ravi.ARM Direct: +1-512-225 -1071 | Mobile: +1-214-212-0794 5707 Southwest Parkway, Suite 100, Austin, TX 78735

5 years, 1 month

1
1
0 0

Project Maintenance Proposal for tf.org Projects

by Sandrine Bailleux

Hello all, As the developers community at trustedfirmware.org is growing, there is an increasing need to have work processes that are clearly documented, feel smooth and scale well. We think that there is an opportunity to improve the way the trustedfirmware.org projects are managed today. That's why we are sharing a project maintenance proposal, focusing on the TF-A and TF-M projects initially. The aim of this document is to propose a set of rules, guidelines and processes to try and improve the way we work together as a community today. Note that this is an early draft at this stage. This is put up for further discussion within the trustedfirmware.org community. Nothing is set in stone yet and it is expected to go under change as feedback from the community is incorporated. Please find the initial proposal here: https://developer.trustedfirmware.org/w/collaboration/project-maintenance-p… Please provide any feedback you may have by replying to this email thread, keeping all 4 mailing lists in the recipients list. I will collate comments from the community and try to incorporate them in the document, keeping you updated on changes made between revisions. Regards, Sandrine

5 years, 1 month

1
0
0 0

Trusted Firmware Keynote @Linaro TechDays (Wed 25 Mar, 16:00-16:30 GMT)

by Matteo Carlini

Hi all, Trusted Firmware will be opening the Linaro Tech Days event on Wed 25th March at 4pm (16:00) GMT with a keynote presenting all the latest exciting news from the project. https://connect.linaro.org/resources/ltd20/ltd20-200k/ and, once registered, on sched: https://linarotechdays.sched.com/event/ZZFK/ltd20-200k-keynote-trusted-firm… The session will be live streamed and recorded (links in the above resources) and slides will be attached there too. Don't miss it! Thanks Matteo

5 years, 1 month

1
0
0 0

Re: [TF-A] Trusted Debug Control

by Matteo Carlini

Hi Victor, There's currently no plan to support Trusted Debug Control, primarily for the lack of an available platform IP component requiring it. Are you aware of a specific need for a real platform, that could also be available for testing the implementation? Thanks Matteo From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Victor Duan via TF-A Sent: 18 March 2020 01:35 To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] Trusted Debug Control Trusted Debug Control specified by TBBR CLIENT is as not supported in the current TF-A v2.2. Is there any plan to support it in the future? Thank you!

5 years, 1 month

1
0
0 0

Re: [TF-A] Proposal for Measured Boot Implementation

by Raghu Krishnamurthy

Hi Alexei, Thanks. This looks good at first glance. However, i do have some questions that aren't obvious to me by reading the description below and looking at code. Questions are numbered based on your original email. Perhaps these can be discussed in the TF-A forum if it is inconvenient over email. 1) Would be good if the hash alg comes from the config file. This will make the implementation "crypto agile" from the very beginning. It is common to want to upgrade/change the hash algorithm and since BL1 is in ROM, you potentially break measured boot on old devices in case a hash algorithm is broken. The other option is to get the hash algorithm from the platform, perhaps a platform gets it from eFuses as opposed to config files. 2) It looks like you are using memory allocated in the loaded DTB as the equivalent of a TPM "PCR". How is this protected from direct modification by BL2? Or is it not protected because BL2 forms a part of the Root-of-Trust for Measurement(RTM)?(since it's signature is verified by BL1?) 3) What does "Event Log" refer to? Is it the same event log proposed by TCG in the platform firmware profile ? As a general question, how close is the measured boot in TF-A/PSA going to be to TCG ? Will BL2 extend measurements for other images ? 4) Would be great not to refer to "TPM" in the measured boot implementation. Here we are implementing measured boot without a TPM, but it could be implemented with a TPM. Maybe it should be tcg event log? 5) OK. 6) What does validate event log mean here? More details ? Thanks -Raghu On 3/20/20 7:15 AM, Alexei Fedorov via TF-A wrote: > Hello, > > I'm preparing the next set of patches for Measured Boot support in TF-A, > please find some details on design and implementation below. > > 1. SHA256/384/512 hash algorithm for Measured Boot related hash calculations > is passed as an existing build 'HASH_ALG' build parameter. > > 2. BL1 calculates BL2 image hash and passes these data to BL2 via > FW_CONFIG/TB_FW_CONFIG device tree in new 'bl2_hash_data' byte array > added > in 'fvp_fw_config.dts'. > > These changes are part of the patch under review, please see > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3555 > > 3. Event Log is calculated by BL2 in Secure Memory and copied to > Non-secure memory. Address in Non-secure memory is calculated as: > > "nt_fw_config_addr + nt_fw_config_max_size" > > with values obtained from 'tb_fw_config': > > nt_fw_config_addr = <0x0 0x80000000>; > nt_fw_config_max_size = <0x200>; > > 4. Event Log address and size is passed by TOS_FW_CONFIG and NT_FW_CONFIG > device tree in 2 new added properties: > > Property name: 'tpm_event_log_addr' > Value type is an unsigned 64-bit integer specifying the physical address > of the Event Log. > > Property name: 'tpm_event_log_size' > Value type is an unsigned 32-bit integer specifying the size of the > Event Log. > > /* TPM Event Log Config */ > tpm_event_log { > compatible = "arm,nt_fw"; > tpm_event_log_addr = <0x0 0x0>; > tpm_event_log_size = <0x0>; > }; > > 5. TF-A provides Event Log to the BL33 (TFTF/UEFI/U-boot) in 'nt_fw_config' > device tree, which address is passed by BL31 as 'arg0' parameter, > see TFTF patch: > > https://review.trustedfirmware.org/c/TF-A/tf-a-tests/+/3327 > > 6. A new test which validates and prints Event Log data passed > in 'nt_fw_config' to BL33 will be added to TFTF. > > Please review and provide your comments on the proposed design. > > Regards. > Alexei. > > 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. >

5 years, 1 month

1
0
0 0

Re: [TF-A] Platforms to maintain their own Change Log files following 2.3 Release

by Varun Wadekar

>> As a general reminder, it is up to the developer to document changes in common TF-A code that is relevant in the "Upcoming Change Log" file. Thanks for highlighting this. For Tegra platforms, we will provide up to date information to the platform change log after 2.3. We will have to live with the current state of the log for 2.3. >> Reviewers please continue to help determine if documentation is required for a given patch. Curious, have there been discussions around automating this somehow? E.g. add a tag to the commit message for a script to pick later. From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Lauren Wehrmeister via TF-A Sent: Tuesday, March 17, 2020 10:51 AM To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] Platforms to maintain their own Change Log files following 2.3 Release External email: Use caution opening links or attachments Hi All, Following the TF-A release planned for April, platforms will be expected to maintain their own Change Log files to document relevant changes in platform specific code. The common TF-A Change Log will no longer document Platform specific updates after the 2.3 release. As a general reminder, it is up to the developer to document changes in common TF-A code that is relevant in the "Upcoming Change Log" file. Reviewers please continue to help determine if documentation is required for a given patch. During each code freeze for a release the documentation in the upcoming change log will be moved to the change log corresponding to the release. Thanks, Lauren Wehrmeister ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. -----------------------------------------------------------------------------------

5 years, 1 month

2
2
0 0

Proposal for Measured Boot Implementation

by Alexei Fedorov

Hello, I'm preparing the next set of patches for Measured Boot support in TF-A, please find some details on design and implementation below. 1. SHA256/384/512 hash algorithm for Measured Boot related hash calculations is passed as an existing build 'HASH_ALG' build parameter. 2. BL1 calculates BL2 image hash and passes these data to BL2 via FW_CONFIG/TB_FW_CONFIG device tree in new 'bl2_hash_data' byte array added in 'fvp_fw_config.dts'. These changes are part of the patch under review, please see https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3555 3. Event Log is calculated by BL2 in Secure Memory and copied to Non-secure memory. Address in Non-secure memory is calculated as: "nt_fw_config_addr + nt_fw_config_max_size" with values obtained from 'tb_fw_config': nt_fw_config_addr = <0x0 0x80000000>; nt_fw_config_max_size = <0x200>; 4. Event Log address and size is passed by TOS_FW_CONFIG and NT_FW_CONFIG device tree in 2 new added properties: Property name: 'tpm_event_log_addr' Value type is an unsigned 64-bit integer specifying the physical address of the Event Log. Property name: 'tpm_event_log_size' Value type is an unsigned 32-bit integer specifying the size of the Event Log. /* TPM Event Log Config */ tpm_event_log { compatible = "arm,nt_fw"; tpm_event_log_addr = <0x0 0x0>; tpm_event_log_size = <0x0>; }; 5. TF-A provides Event Log to the BL33 (TFTF/UEFI/U-boot) in 'nt_fw_config' device tree, which address is passed by BL31 as 'arg0' parameter, see TFTF patch: https://review.trustedfirmware.org/c/TF-A/tf-a-tests/+/3327 6. A new test which validates and prints Event Log data passed in 'nt_fw_config' to BL33 will be added to TFTF. Please review and provide your comments on the proposed design. Regards. Alexei. 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.

5 years, 1 month

1
0
0 0

TF-A Tech Forum @ Thu 26 Mar 2020 17:00 - 18:00 (GMT)

by Joanna Farley

Hi All, The second TF-A Tech Forum is scheduled for next week for Thu 26 Mar 2020 17:00 - 18:00 (GMT). A reoccurring meeting invite has been sent out to the subscribers of this TF-A mailing list. If you don’t have this please let me know. I have an agenda for next week however for future meetings if other project contributors would also like to present on topics please reach out to me and I will look to schedule. Agenda: * Technical Overview of the Fconf (Firmware Configuration) Feature by Louis Mayencourt * Optional TF-A Mailing List Topic Discussions Thanks Joanna 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.

5 years, 1 month

1
0
0 0

Invitation: TF-A Tech Forum @ Every 2 weeks from 17:00 to 18:00 on Thursday (GMT) (tf-a@lists.trustedfirmware.org)

by Bill Fletcher

You have been invited to the following event. Title: TF-A Tech Forum We run 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. Invites are 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: Every 2 weeks from 17:00 to 18:00 on Thursday United Kingdom Time Where: Zoom 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=N3ZoNDBuZzZnM2k4cGszY… 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

5 years, 2 months

1
0
0 0

Trusted Debug Control

by Victor Duan

Trusted Debug Control specified by TBBR CLIENT is as not supported in the current TF-A v2.2. Is there any plan to support it in the future? Thank you!

5 years, 2 months

1
0
0 0

Platforms to maintain their own Change Log files following 2.3 Release

by Lauren Wehrmeister

Hi All, Following the TF-A release planned for April, platforms will be expected to maintain their own Change Log files to document relevant changes in platform specific code. The common TF-A Change Log will no longer document Platform specific updates after the 2.3 release. As a general reminder, it is up to the developer to document changes in common TF-A code that is relevant in the "Upcoming Change Log" file. Reviewers please continue to help determine if documentation is required for a given patch. During each code freeze for a release the documentation in the upcoming change log will be moved to the change log corresponding to the release. Thanks, Lauren Wehrmeister

5 years, 2 months

1
0
0 0

RFR: Tegra changes for review pushed on 03/12/2020

by Varun Wadekar

Hello team, This is an email requesting reviews for the latest Tegra platform changes [1] from our downstream branch. Please review these changes at the earliest and help us get them merged before the release candidate tag is generated. We hope to push one more batch for v2.3, after [1] gets merged. Thanks in advance. Varun [1] https://review.trustedfirmware.org/q/topic:%22tegra-downstream-03122020%22+… ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. -----------------------------------------------------------------------------------

5 years, 2 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. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 354931: Parse warnings (PARSE_ERROR) /lib/xlat_tables_v2/xlat_tables_context.c: 34 in () ________________________________________________________________________________________________________ *** CID 354931: Parse warnings (PARSE_ERROR) /lib/xlat_tables_v2/xlat_tables_context.c: 34 in () 28 #if PLAT_RO_XLAT_TABLES 29 #define BASE_XLAT_TABLE_SECTION ".rodata" 30 #else 31 #define BASE_XLAT_TABLE_SECTION ".bss" 32 #endif 33 >>> CID 354931: Parse warnings (PARSE_ERROR) >>> expected a string literal 34 REGISTER_XLAT_CONTEXT(tf, MAX_MMAP_REGIONS, MAX_XLAT_TABLES, 35 PLAT_VIRT_ADDR_SPACE_SIZE, PLAT_PHY_ADDR_SPACE_SIZE, 36 BASE_XLAT_TABLE_SECTION); 37 38 void mmap_add_region(unsigned long long base_pa, uintptr_t base_va, size_t size, 39 unsigned int attr) ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/ls/click?upn=nJaKvJSIH-2FPAfmty-2BK5tYpPkl…

5 years, 2 months

1
0
0 0

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

by Sandrine Bailleux

Hi Sumit, On 3/4/20 4:55 PM, Sumit Garg via TF-A wrote: >> The last remaining item would be to address the MISRA violations >> that Coverity found, which I've copied & pasted for you on Gerrit in the >> top patch. > > I have tried to address most of MISRA violations and updated the > patch-set. But since I don't have access to Coverity tool you are > using, so can you please check if there is any relevant MISRA > violation that I missed? Sure, I will re-run the tool in our internal CI and let you know the results. >> Also, this feature is only used on QEMU right now and I am not aware of >> anyone trying to enable it for their platforms just yet. Thus there is a >> risk we might have overlooked some issues that we'll discover at that time. > > Socionext being a silicon vendor is actively looking for this feature > and I think they will build upon this feature to enable firmware > encryption on their platforms to meet DRM robustness rules. Interesting, thanks for sharing this information. >> Furthermore, I know that you've done some testing of this feature on >> QEMU but this is not integrated into the CI loop right now. Thus, there >> is a risk that we might break it in the future and this will go >> unnoticed, unless you plan to test it regularly on your end. > > Yeah we should plan to enable testing for this feature in CI loop. For now, I've added in our internal CI a simple build test based on the build instructions you've provided in the patch set. This will at least make sure we do not break the build inadvertently in the future. But as you say, going forward, we should plan for proper testing on QEMU. I am hoping we will soon be able to extend the OpenCI [1] and add this support there. [1] https://lists.trustedfirmware.org/pipermail/tf-a/2020-February/000264.html >> * Saying so in the (upcoming) change log. > > I hope you can take care of this. Actually this is something you have access to, it's a matter of adding a line in docs/change-log-upcoming.rst in the TF-A source tree. Regards, Sandrine

5 years, 2 months

2
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

5 years, 2 months

4
11
0 0

Re: [TF-A] Incorrect section attributes with ALLOW_RO_XLAT_TABLES=1

by Petre-Ionut Tudor

Hi Masahiro, That warning is expected. GCC complains about this, since tf_base_xlat_table is not constant and we are asking it to be put in a read-only section (see the REGISTER_XLAT_CONTEXT_RO_BASE_TABLE macro). This is fine since: * We only want the base table to be read-only after the tables have been initialized. The only time we change tf_base_xlat_table is when we initialize it, and at that point in the platform setup sequence the MMU is off, so permissions have no effect. * We never write to this with the MMU on (it's the level 1 translation table), so there is no danger of generating MMU faults. I hope this answers your question. Thanks Petre ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Masahiro Yamada via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 06 March 2020 12:30 To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] Incorrect section attributes with ALLOW_RO_XLAT_TABLES=1 Hi. If I build TF-A with ALLOW_RO_XLAT_TABLES=1, the base xlat table goes into .rodata section instead of .bss section. Then, I see a warning like: /tmp/ccswitLr.s: Assembler messages: /tmp/ccswitLr.s:297: Warning: setting incorrect section attributes for .rodata Is this a know issue? [Reproduce Command] make PLAT=fvp CROSS_COMPILE=aarch64-linux-gnu- ALLOW_RO_XLAT_TABLES=1 The full build log is below: masahiro@pug:~/ref/trusted-firmware-a$ make PLAT=fvp CROSS_COMPILE=aarch64-linux-gnu- ALLOW_RO_XLAT_TABLES=1 CC lib/libfdt/fdt.c CC lib/libfdt/fdt_addresses.c CC lib/libfdt/fdt_empty_tree.c CC lib/libfdt/fdt_ro.c CC lib/libfdt/fdt_rw.c CC lib/libfdt/fdt_strerror.c CC lib/libfdt/fdt_sw.c CC lib/libfdt/fdt_wip.c AR build/fvp/release/lib/libfdt.a Building fvp CC lib/libc/abort.c CC lib/libc/assert.c CC lib/libc/exit.c CC lib/libc/memchr.c CC lib/libc/memcmp.c CC lib/libc/memcpy.c CC lib/libc/memmove.c CC lib/libc/memrchr.c CC lib/libc/memset.c CC lib/libc/printf.c CC lib/libc/putchar.c CC lib/libc/puts.c CC lib/libc/snprintf.c CC lib/libc/strchr.c CC lib/libc/strcmp.c CC lib/libc/strlcpy.c CC lib/libc/strlen.c CC lib/libc/strncmp.c CC lib/libc/strnlen.c CC lib/libc/strrchr.c AS lib/libc/aarch64/setjmp.S AR build/fvp/release/lib/libc.a CC drivers/arm/smmu/smmu_v3.c CC drivers/arm/sp805/sp805.c CC drivers/delay_timer/delay_timer.c CC drivers/io/io_semihosting.c CC lib/semihosting/semihosting.c CC plat/arm/board/fvp/fvp_bl1_setup.c CC plat/arm/board/fvp/fvp_err.c CC plat/arm/board/fvp/fvp_io_storage.c CC drivers/arm/cci/cci.c CC drivers/delay_timer/generic_delay_timer.c CC drivers/cfi/v2m/v2m_flash.c CC drivers/io/io_fip.c CC drivers/io/io_memmap.c CC drivers/io/io_storage.c CC plat/arm/common/arm_bl1_setup.c CC plat/arm/common/arm_err.c CC plat/arm/common/arm_fconf_io_storage.c CC plat/arm/common/fconf/arm_fconf_io.c CC lib/fconf/fconf.c CC lib/fconf/fconf_dyn_cfg_getter.c CC plat/arm/common/arm_dyn_cfg.c CC plat/arm/common/arm_dyn_cfg_helpers.c CC common/fdt_wrappers.c CC bl1/bl1_main.c CC bl1/aarch64/bl1_arch_setup.c CC bl1/aarch64/bl1_context_mgmt.c CC lib/cpus/errata_report.c CC lib/el3_runtime/aarch64/context_mgmt.c CC plat/common/plat_bl1_common.c CC common/bl_common.c CC common/tf_log.c CC drivers/console/multi_console.c CC plat/common/plat_bl_common.c CC plat/common/plat_log_common.c CC plat/common/aarch64/plat_common.c CC lib/compiler-rt/builtins/popcountdi2.c CC lib/compiler-rt/builtins/popcountsi2.c CC plat/arm/board/fvp/fvp_common.c CC plat/arm/common/arm_common.c CC plat/arm/common/arm_console.c CC lib/xlat_tables_v2/aarch64/xlat_tables_arch.c CC lib/xlat_tables_v2/xlat_tables_context.c CC lib/xlat_tables_v2/xlat_tables_core.c CC lib/xlat_tables_v2/xlat_tables_utils.c AS lib/semihosting/aarch64/semihosting_call.S AS plat/arm/board/fvp/aarch64/fvp_helpers.S AS lib/cpus/aarch64/aem_generic.S AS lib/cpus/aarch64/cortex_a35.S AS lib/cpus/aarch64/cortex_a53.S AS lib/cpus/aarch64/cortex_a57.S AS lib/cpus/aarch64/cortex_a72.S AS lib/cpus/aarch64/cortex_a73.S AS bl1/aarch64/bl1_entrypoint.S AS bl1/aarch64/bl1_exceptions.S AS lib/cpus/aarch64/cpu_helpers.S AS plat/common/aarch64/platform_up_stack.S AS lib/cpus/aarch64/dsu_helpers.S AS lib/el3_runtime/aarch64/context.S AS common/aarch64/debug.S AS lib/aarch64/cache_helpers.S AS lib/aarch64/misc_helpers.S AS plat/common/aarch64/platform_helpers.S AS drivers/arm/pl011/aarch64/pl011_console.S AS plat/arm/board/common/aarch64/board_arm_helpers.S AS plat/arm/common/aarch64/arm_helpers.S AS lib/xlat_tables_v2/aarch64/enable_mmu.S PP bl1/bl1.ld.S LD build/fvp/release/bl1/bl1.elf BIN build/fvp/release/bl1.bin Built build/fvp/release/bl1.bin successfully OD build/fvp/release/bl1/bl1.dump CC drivers/arm/sp805/sp805.c CC drivers/io/io_semihosting.c CC lib/utils/mem_region.c CC lib/semihosting/semihosting.c CC plat/arm/board/fvp/fvp_bl2_setup.c CC plat/arm/board/fvp/fvp_err.c CC plat/arm/board/fvp/fvp_io_storage.c CC plat/arm/common/arm_nor_psci_mem_protect.c CC drivers/arm/tzc/tzc400.c CC plat/arm/board/fvp/fvp_security.c CC plat/arm/common/arm_tzc400.c CC drivers/cfi/v2m/v2m_flash.c CC drivers/delay_timer/delay_timer.c CC drivers/delay_timer/generic_delay_timer.c CC drivers/io/io_fip.c CC drivers/io/io_memmap.c CC drivers/io/io_storage.c CC plat/arm/common/arm_bl2_setup.c CC plat/arm/common/arm_err.c CC plat/arm/common/arm_fconf_io_storage.c CC plat/arm/common/fconf/arm_fconf_io.c CC lib/fconf/fconf.c CC lib/fconf/fconf_dyn_cfg_getter.c CC plat/arm/common/arm_dyn_cfg.c CC plat/arm/common/arm_dyn_cfg_helpers.c CC common/fdt_wrappers.c CC plat/arm/common/aarch64/arm_bl2_mem_params_desc.c CC plat/arm/common/arm_image_load.c CC common/desc_image_load.c CC bl2/bl2_image_load_v2.c CC bl2/bl2_main.c CC bl2/aarch64/bl2_arch_setup.c CC common/bl_common.c CC common/tf_log.c CC drivers/console/multi_console.c CC plat/common/plat_bl_common.c CC plat/common/plat_log_common.c CC plat/common/aarch64/plat_common.c CC lib/compiler-rt/builtins/popcountdi2.c CC lib/compiler-rt/builtins/popcountsi2.c CC plat/arm/board/fvp/fvp_common.c CC plat/arm/common/arm_common.c CC plat/arm/common/arm_console.c CC lib/xlat_tables_v2/aarch64/xlat_tables_arch.c CC lib/xlat_tables_v2/xlat_tables_context.c CC lib/xlat_tables_v2/xlat_tables_core.c CC lib/xlat_tables_v2/xlat_tables_utils.c AS lib/semihosting/aarch64/semihosting_call.S AS lib/locks/exclusive/aarch64/spinlock.S AS plat/common/aarch64/platform_up_stack.S AS common/aarch64/early_exceptions.S AS bl2/aarch64/bl2_entrypoint.S AS common/aarch64/debug.S AS lib/aarch64/cache_helpers.S AS lib/aarch64/misc_helpers.S AS plat/common/aarch64/platform_helpers.S AS drivers/arm/pl011/aarch64/pl011_console.S AS plat/arm/board/common/aarch64/board_arm_helpers.S AS plat/arm/common/aarch64/arm_helpers.S AS lib/xlat_tables_v2/aarch64/enable_mmu.S PP bl2/bl2.ld.S LD build/fvp/release/bl2/bl2.elf BIN build/fvp/release/bl2.bin Built build/fvp/release/bl2.bin successfully OD build/fvp/release/bl2/bl2.dump CC drivers/arm/fvp/fvp_pwrc.c CC drivers/arm/smmu/smmu_v3.c CC drivers/delay_timer/delay_timer.c CC drivers/cfi/v2m/v2m_flash.c CC lib/utils/mem_region.c CC plat/arm/board/fvp/fvp_bl31_setup.c CC plat/arm/board/fvp/fvp_pm.c CC plat/arm/board/fvp/fvp_topology.c CC plat/arm/common/arm_nor_psci_mem_protect.c CC drivers/arm/gic/common/gic_common.c CC drivers/arm/gic/v3/gicv3_main.c CC drivers/arm/gic/v3/gicv3_helpers.c CC plat/common/plat_gicv3.c CC plat/arm/common/arm_gicv3.c CC drivers/arm/gic/v3/gic500.c CC drivers/arm/cci/cci.c CC drivers/arm/tzc/tzc400.c CC plat/arm/board/fvp/fvp_security.c CC plat/arm/common/arm_tzc400.c CC drivers/delay_timer/generic_delay_timer.c CC lib/cpus/aarch64/cpuamu.c CC plat/arm/common/arm_bl31_setup.c CC plat/arm/common/arm_pm.c CC plat/arm/common/arm_topology.c CC plat/common/plat_psci_common.c CC plat/arm/common/aarch64/execution_state_switch.c CC plat/arm/common/arm_sip_svc.c CC lib/pmf/pmf_smc.c CC bl31/bl31_main.c CC bl31/interrupt_mgmt.c CC bl31/bl31_context_mgmt.c CC common/runtime_svc.c CC services/arm_arch_svc/arm_arch_svc_setup.c CC services/std_svc/std_svc_setup.c CC lib/el3_runtime/cpu_data_array.c CC lib/el3_runtime/aarch64/context_mgmt.c CC lib/cpus/errata_report.c CC lib/psci/psci_off.c CC lib/psci/psci_on.c CC lib/psci/psci_suspend.c CC lib/psci/psci_common.c CC lib/psci/psci_main.c CC lib/psci/psci_setup.c CC lib/psci/psci_system_off.c CC lib/psci/psci_mem_protect.c CC lib/locks/bakery/bakery_lock_coherent.c CC lib/psci/psci_stat.c CC lib/pmf/pmf_main.c CC lib/extensions/spe/spe.c CC lib/extensions/amu/aarch64/amu.c CC lib/extensions/sve/sve.c CC common/bl_common.c CC common/tf_log.c CC drivers/console/multi_console.c CC plat/common/plat_bl_common.c CC plat/common/plat_log_common.c CC plat/common/aarch64/plat_common.c CC lib/compiler-rt/builtins/popcountdi2.c CC lib/compiler-rt/builtins/popcountsi2.c CC plat/arm/board/fvp/fvp_common.c CC plat/arm/common/arm_common.c CC plat/arm/common/arm_console.c CC lib/xlat_tables_v2/aarch64/xlat_tables_arch.c CC lib/xlat_tables_v2/xlat_tables_context.c /tmp/ccswitLr.s: Assembler messages: /tmp/ccswitLr.s:297: Warning: setting incorrect section attributes for .rodata CC lib/xlat_tables_v2/xlat_tables_core.c CC lib/xlat_tables_v2/xlat_tables_utils.c AS plat/arm/board/fvp/aarch64/fvp_helpers.S AS lib/cpus/aarch64/aem_generic.S AS lib/cpus/aarch64/cortex_a35.S AS lib/cpus/aarch64/cortex_a53.S AS lib/cpus/aarch64/cortex_a57.S AS lib/cpus/aarch64/cortex_a72.S AS lib/cpus/aarch64/cortex_a73.S AS lib/cpus/aarch64/cpuamu_helpers.S AS bl31/aarch64/bl31_entrypoint.S AS bl31/aarch64/crash_reporting.S AS bl31/aarch64/ea_delegate.S AS bl31/aarch64/runtime_exceptions.S AS lib/cpus/aarch64/dsu_helpers.S AS plat/common/aarch64/platform_mp_stack.S AS lib/el3_runtime/aarch64/cpu_data.S AS lib/cpus/aarch64/cpu_helpers.S AS lib/locks/exclusive/aarch64/spinlock.S AS lib/psci/aarch64/psci_helpers.S AS lib/el3_runtime/aarch64/context.S AS lib/extensions/amu/aarch64/amu_helpers.S AS lib/cpus/aarch64/wa_cve_2017_5715_bpiall.S AS lib/cpus/aarch64/wa_cve_2017_5715_mmu.S AS common/aarch64/debug.S AS lib/aarch64/cache_helpers.S AS lib/aarch64/misc_helpers.S AS plat/common/aarch64/platform_helpers.S AS drivers/arm/pl011/aarch64/pl011_console.S AS plat/arm/board/common/aarch64/board_arm_helpers.S AS plat/arm/common/aarch64/arm_helpers.S AS lib/xlat_tables_v2/aarch64/enable_mmu.S PP bl31/bl31.ld.S LD build/fvp/release/bl31/bl31.elf BIN build/fvp/release/bl31.bin Built build/fvp/release/bl31.bin successfully OD build/fvp/release/bl31/bl31.dump CC plat/arm/board/fvp/fvp_bl2u_setup.c CC drivers/arm/tzc/tzc400.c CC plat/arm/board/fvp/fvp_security.c CC plat/arm/common/arm_tzc400.c CC drivers/delay_timer/delay_timer.c CC drivers/delay_timer/generic_delay_timer.c CC plat/arm/common/arm_bl2u_setup.c CC bl2u/bl2u_main.c CC common/bl_common.c CC common/tf_log.c CC drivers/console/multi_console.c CC plat/common/plat_bl_common.c CC plat/common/plat_log_common.c CC plat/common/aarch64/plat_common.c CC lib/compiler-rt/builtins/popcountdi2.c CC lib/compiler-rt/builtins/popcountsi2.c CC plat/arm/board/fvp/fvp_common.c CC plat/arm/common/arm_common.c CC plat/arm/common/arm_console.c CC lib/xlat_tables_v2/aarch64/xlat_tables_arch.c CC lib/xlat_tables_v2/xlat_tables_context.c CC lib/xlat_tables_v2/xlat_tables_core.c CC lib/xlat_tables_v2/xlat_tables_utils.c AS bl2u/aarch64/bl2u_entrypoint.S AS plat/common/aarch64/platform_up_stack.S AS common/aarch64/early_exceptions.S AS common/aarch64/debug.S AS lib/aarch64/cache_helpers.S AS lib/aarch64/misc_helpers.S AS plat/common/aarch64/platform_helpers.S AS drivers/arm/pl011/aarch64/pl011_console.S AS plat/arm/board/common/aarch64/board_arm_helpers.S AS plat/arm/common/aarch64/arm_helpers.S AS lib/xlat_tables_v2/aarch64/enable_mmu.S PP bl2u/bl2u.ld.S LD build/fvp/release/bl2u/bl2u.elf BIN build/fvp/release/bl2u.bin Built build/fvp/release/bl2u.bin successfully OD build/fvp/release/bl2u/bl2u.dump CPP plat/arm/board/fvp/fdts/fvp_fw_config.dts DTC plat/arm/board/fvp/fdts/fvp_fw_config.dts CPP plat/arm/board/fvp/fdts/fvp_soc_fw_config.dts DTC plat/arm/board/fvp/fdts/fvp_soc_fw_config.dts CPP plat/arm/board/fvp/fdts/fvp_nt_fw_config.dts DTC plat/arm/board/fvp/fdts/fvp_nt_fw_config.dts CPP fdts/fvp-base-gicv3-psci.dts DTC fdts/fvp-base-gicv3-psci.dts ./build/fvp/release/fdts/fvp-base-gicv3-psci.pre.dts:215.20-220.5: Warning (simple_bus_reg): /smb@0,0/motherboard/flash@0,00000000: simple-bus unit address format error, expected "0" ./build/fvp/release/fdts/fvp-base-gicv3-psci.pre.dts:221.19-224.5: Warning (simple_bus_reg): /smb@0,0/motherboard/vram@2,00000000: simple-bus unit address format error, expected "200000000" ./build/fvp/release/fdts/fvp-base-gicv3-psci.pre.dts:225.23-229.5: Warning (simple_bus_reg): /smb@0,0/motherboard/ethernet@2,02000000: simple-bus unit address format error, expected "202000000" ./build/fvp/release/fdts/fvp-base-gicv3-psci.pre.dts:230.26-235.5: Warning (simple_bus_reg): /smb@0,0/motherboard/clk24mhz: missing or empty reg/ranges property ./build/fvp/release/fdts/fvp-base-gicv3-psci.pre.dts:236.30-241.5: Warning (simple_bus_reg): /smb@0,0/motherboard/refclk1mhz: missing or empty reg/ranges property ./build/fvp/release/fdts/fvp-base-gicv3-psci.pre.dts:242.32-247.5: Warning (simple_bus_reg): /smb@0,0/motherboard/refclk32khz: missing or empty reg/ranges property ./build/fvp/release/fdts/fvp-base-gicv3-psci.pre.dts:248.21-370.5: Warning (simple_bus_reg): /smb@0,0/motherboard/iofpga@3,00000000: simple-bus unit address format error, expected "300000000" ./build/fvp/release/fdts/fvp-base-gicv3-psci.pre.dts:371.33-377.5: Warning (simple_bus_reg): /smb@0,0/motherboard/fixedregulator: missing or empty reg/ranges property ./build/fvp/release/fdts/fvp-base-gicv3-psci.pre.dts:381.21-387.6: Warning (simple_bus_reg): /smb@0,0/motherboard/mcc/osc: missing or empty reg/ranges property ./build/fvp/release/fdts/fvp-base-gicv3-psci.pre.dts:388.12-391.6: Warning (simple_bus_reg): /smb@0,0/motherboard/mcc/muxfpga: missing or empty reg/ranges property ./build/fvp/release/fdts/fvp-base-gicv3-psci.pre.dts:392.12-395.6: Warning (simple_bus_reg): /smb@0,0/motherboard/mcc/dvimode: missing or empty reg/ranges property -- Best Regards Masahiro Yamada -- 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.

5 years, 2 months

1
0
0 0

Incorrect section attributes with ALLOW_RO_XLAT_TABLES=1

by Masahiro Yamada

Hi. If I build TF-A with ALLOW_RO_XLAT_TABLES=1, the base xlat table goes into .rodata section instead of .bss section. Then, I see a warning like: /tmp/ccswitLr.s: Assembler messages: /tmp/ccswitLr.s:297: Warning: setting incorrect section attributes for .rodata Is this a know issue? [Reproduce Command] make PLAT=fvp CROSS_COMPILE=aarch64-linux-gnu- ALLOW_RO_XLAT_TABLES=1 The full build log is below: masahiro@pug:~/ref/trusted-firmware-a$ make PLAT=fvp CROSS_COMPILE=aarch64-linux-gnu- ALLOW_RO_XLAT_TABLES=1 CC lib/libfdt/fdt.c CC lib/libfdt/fdt_addresses.c CC lib/libfdt/fdt_empty_tree.c CC lib/libfdt/fdt_ro.c CC lib/libfdt/fdt_rw.c CC lib/libfdt/fdt_strerror.c CC lib/libfdt/fdt_sw.c CC lib/libfdt/fdt_wip.c AR build/fvp/release/lib/libfdt.a Building fvp CC lib/libc/abort.c CC lib/libc/assert.c CC lib/libc/exit.c CC lib/libc/memchr.c CC lib/libc/memcmp.c CC lib/libc/memcpy.c CC lib/libc/memmove.c CC lib/libc/memrchr.c CC lib/libc/memset.c CC lib/libc/printf.c CC lib/libc/putchar.c CC lib/libc/puts.c CC lib/libc/snprintf.c CC lib/libc/strchr.c CC lib/libc/strcmp.c CC lib/libc/strlcpy.c CC lib/libc/strlen.c CC lib/libc/strncmp.c CC lib/libc/strnlen.c CC lib/libc/strrchr.c AS lib/libc/aarch64/setjmp.S AR build/fvp/release/lib/libc.a CC drivers/arm/smmu/smmu_v3.c CC drivers/arm/sp805/sp805.c CC drivers/delay_timer/delay_timer.c CC drivers/io/io_semihosting.c CC lib/semihosting/semihosting.c CC plat/arm/board/fvp/fvp_bl1_setup.c CC plat/arm/board/fvp/fvp_err.c CC plat/arm/board/fvp/fvp_io_storage.c CC drivers/arm/cci/cci.c CC drivers/delay_timer/generic_delay_timer.c CC drivers/cfi/v2m/v2m_flash.c CC drivers/io/io_fip.c CC drivers/io/io_memmap.c CC drivers/io/io_storage.c CC plat/arm/common/arm_bl1_setup.c CC plat/arm/common/arm_err.c CC plat/arm/common/arm_fconf_io_storage.c CC plat/arm/common/fconf/arm_fconf_io.c CC lib/fconf/fconf.c CC lib/fconf/fconf_dyn_cfg_getter.c CC plat/arm/common/arm_dyn_cfg.c CC plat/arm/common/arm_dyn_cfg_helpers.c CC common/fdt_wrappers.c CC bl1/bl1_main.c CC bl1/aarch64/bl1_arch_setup.c CC bl1/aarch64/bl1_context_mgmt.c CC lib/cpus/errata_report.c CC lib/el3_runtime/aarch64/context_mgmt.c CC plat/common/plat_bl1_common.c CC common/bl_common.c CC common/tf_log.c CC drivers/console/multi_console.c CC plat/common/plat_bl_common.c CC plat/common/plat_log_common.c CC plat/common/aarch64/plat_common.c CC lib/compiler-rt/builtins/popcountdi2.c CC lib/compiler-rt/builtins/popcountsi2.c CC plat/arm/board/fvp/fvp_common.c CC plat/arm/common/arm_common.c CC plat/arm/common/arm_console.c CC lib/xlat_tables_v2/aarch64/xlat_tables_arch.c CC lib/xlat_tables_v2/xlat_tables_context.c CC lib/xlat_tables_v2/xlat_tables_core.c CC lib/xlat_tables_v2/xlat_tables_utils.c AS lib/semihosting/aarch64/semihosting_call.S AS plat/arm/board/fvp/aarch64/fvp_helpers.S AS lib/cpus/aarch64/aem_generic.S AS lib/cpus/aarch64/cortex_a35.S AS lib/cpus/aarch64/cortex_a53.S AS lib/cpus/aarch64/cortex_a57.S AS lib/cpus/aarch64/cortex_a72.S AS lib/cpus/aarch64/cortex_a73.S AS bl1/aarch64/bl1_entrypoint.S AS bl1/aarch64/bl1_exceptions.S AS lib/cpus/aarch64/cpu_helpers.S AS plat/common/aarch64/platform_up_stack.S AS lib/cpus/aarch64/dsu_helpers.S AS lib/el3_runtime/aarch64/context.S AS common/aarch64/debug.S AS lib/aarch64/cache_helpers.S AS lib/aarch64/misc_helpers.S AS plat/common/aarch64/platform_helpers.S AS drivers/arm/pl011/aarch64/pl011_console.S AS plat/arm/board/common/aarch64/board_arm_helpers.S AS plat/arm/common/aarch64/arm_helpers.S AS lib/xlat_tables_v2/aarch64/enable_mmu.S PP bl1/bl1.ld.S LD build/fvp/release/bl1/bl1.elf BIN build/fvp/release/bl1.bin Built build/fvp/release/bl1.bin successfully OD build/fvp/release/bl1/bl1.dump CC drivers/arm/sp805/sp805.c CC drivers/io/io_semihosting.c CC lib/utils/mem_region.c CC lib/semihosting/semihosting.c CC plat/arm/board/fvp/fvp_bl2_setup.c CC plat/arm/board/fvp/fvp_err.c CC plat/arm/board/fvp/fvp_io_storage.c CC plat/arm/common/arm_nor_psci_mem_protect.c CC drivers/arm/tzc/tzc400.c CC plat/arm/board/fvp/fvp_security.c CC plat/arm/common/arm_tzc400.c CC drivers/cfi/v2m/v2m_flash.c CC drivers/delay_timer/delay_timer.c CC drivers/delay_timer/generic_delay_timer.c CC drivers/io/io_fip.c CC drivers/io/io_memmap.c CC drivers/io/io_storage.c CC plat/arm/common/arm_bl2_setup.c CC plat/arm/common/arm_err.c CC plat/arm/common/arm_fconf_io_storage.c CC plat/arm/common/fconf/arm_fconf_io.c CC lib/fconf/fconf.c CC lib/fconf/fconf_dyn_cfg_getter.c CC plat/arm/common/arm_dyn_cfg.c CC plat/arm/common/arm_dyn_cfg_helpers.c CC common/fdt_wrappers.c CC plat/arm/common/aarch64/arm_bl2_mem_params_desc.c CC plat/arm/common/arm_image_load.c CC common/desc_image_load.c CC bl2/bl2_image_load_v2.c CC bl2/bl2_main.c CC bl2/aarch64/bl2_arch_setup.c CC common/bl_common.c CC common/tf_log.c CC drivers/console/multi_console.c CC plat/common/plat_bl_common.c CC plat/common/plat_log_common.c CC plat/common/aarch64/plat_common.c CC lib/compiler-rt/builtins/popcountdi2.c CC lib/compiler-rt/builtins/popcountsi2.c CC plat/arm/board/fvp/fvp_common.c CC plat/arm/common/arm_common.c CC plat/arm/common/arm_console.c CC lib/xlat_tables_v2/aarch64/xlat_tables_arch.c CC lib/xlat_tables_v2/xlat_tables_context.c CC lib/xlat_tables_v2/xlat_tables_core.c CC lib/xlat_tables_v2/xlat_tables_utils.c AS lib/semihosting/aarch64/semihosting_call.S AS lib/locks/exclusive/aarch64/spinlock.S AS plat/common/aarch64/platform_up_stack.S AS common/aarch64/early_exceptions.S AS bl2/aarch64/bl2_entrypoint.S AS common/aarch64/debug.S AS lib/aarch64/cache_helpers.S AS lib/aarch64/misc_helpers.S AS plat/common/aarch64/platform_helpers.S AS drivers/arm/pl011/aarch64/pl011_console.S AS plat/arm/board/common/aarch64/board_arm_helpers.S AS plat/arm/common/aarch64/arm_helpers.S AS lib/xlat_tables_v2/aarch64/enable_mmu.S PP bl2/bl2.ld.S LD build/fvp/release/bl2/bl2.elf BIN build/fvp/release/bl2.bin Built build/fvp/release/bl2.bin successfully OD build/fvp/release/bl2/bl2.dump CC drivers/arm/fvp/fvp_pwrc.c CC drivers/arm/smmu/smmu_v3.c CC drivers/delay_timer/delay_timer.c CC drivers/cfi/v2m/v2m_flash.c CC lib/utils/mem_region.c CC plat/arm/board/fvp/fvp_bl31_setup.c CC plat/arm/board/fvp/fvp_pm.c CC plat/arm/board/fvp/fvp_topology.c CC plat/arm/common/arm_nor_psci_mem_protect.c CC drivers/arm/gic/common/gic_common.c CC drivers/arm/gic/v3/gicv3_main.c CC drivers/arm/gic/v3/gicv3_helpers.c CC plat/common/plat_gicv3.c CC plat/arm/common/arm_gicv3.c CC drivers/arm/gic/v3/gic500.c CC drivers/arm/cci/cci.c CC drivers/arm/tzc/tzc400.c CC plat/arm/board/fvp/fvp_security.c CC plat/arm/common/arm_tzc400.c CC drivers/delay_timer/generic_delay_timer.c CC lib/cpus/aarch64/cpuamu.c CC plat/arm/common/arm_bl31_setup.c CC plat/arm/common/arm_pm.c CC plat/arm/common/arm_topology.c CC plat/common/plat_psci_common.c CC plat/arm/common/aarch64/execution_state_switch.c CC plat/arm/common/arm_sip_svc.c CC lib/pmf/pmf_smc.c CC bl31/bl31_main.c CC bl31/interrupt_mgmt.c CC bl31/bl31_context_mgmt.c CC common/runtime_svc.c CC services/arm_arch_svc/arm_arch_svc_setup.c CC services/std_svc/std_svc_setup.c CC lib/el3_runtime/cpu_data_array.c CC lib/el3_runtime/aarch64/context_mgmt.c CC lib/cpus/errata_report.c CC lib/psci/psci_off.c CC lib/psci/psci_on.c CC lib/psci/psci_suspend.c CC lib/psci/psci_common.c CC lib/psci/psci_main.c CC lib/psci/psci_setup.c CC lib/psci/psci_system_off.c CC lib/psci/psci_mem_protect.c CC lib/locks/bakery/bakery_lock_coherent.c CC lib/psci/psci_stat.c CC lib/pmf/pmf_main.c CC lib/extensions/spe/spe.c CC lib/extensions/amu/aarch64/amu.c CC lib/extensions/sve/sve.c CC common/bl_common.c CC common/tf_log.c CC drivers/console/multi_console.c CC plat/common/plat_bl_common.c CC plat/common/plat_log_common.c CC plat/common/aarch64/plat_common.c CC lib/compiler-rt/builtins/popcountdi2.c CC lib/compiler-rt/builtins/popcountsi2.c CC plat/arm/board/fvp/fvp_common.c CC plat/arm/common/arm_common.c CC plat/arm/common/arm_console.c CC lib/xlat_tables_v2/aarch64/xlat_tables_arch.c CC lib/xlat_tables_v2/xlat_tables_context.c /tmp/ccswitLr.s: Assembler messages: /tmp/ccswitLr.s:297: Warning: setting incorrect section attributes for .rodata CC lib/xlat_tables_v2/xlat_tables_core.c CC lib/xlat_tables_v2/xlat_tables_utils.c AS plat/arm/board/fvp/aarch64/fvp_helpers.S AS lib/cpus/aarch64/aem_generic.S AS lib/cpus/aarch64/cortex_a35.S AS lib/cpus/aarch64/cortex_a53.S AS lib/cpus/aarch64/cortex_a57.S AS lib/cpus/aarch64/cortex_a72.S AS lib/cpus/aarch64/cortex_a73.S AS lib/cpus/aarch64/cpuamu_helpers.S AS bl31/aarch64/bl31_entrypoint.S AS bl31/aarch64/crash_reporting.S AS bl31/aarch64/ea_delegate.S AS bl31/aarch64/runtime_exceptions.S AS lib/cpus/aarch64/dsu_helpers.S AS plat/common/aarch64/platform_mp_stack.S AS lib/el3_runtime/aarch64/cpu_data.S AS lib/cpus/aarch64/cpu_helpers.S AS lib/locks/exclusive/aarch64/spinlock.S AS lib/psci/aarch64/psci_helpers.S AS lib/el3_runtime/aarch64/context.S AS lib/extensions/amu/aarch64/amu_helpers.S AS lib/cpus/aarch64/wa_cve_2017_5715_bpiall.S AS lib/cpus/aarch64/wa_cve_2017_5715_mmu.S AS common/aarch64/debug.S AS lib/aarch64/cache_helpers.S AS lib/aarch64/misc_helpers.S AS plat/common/aarch64/platform_helpers.S AS drivers/arm/pl011/aarch64/pl011_console.S AS plat/arm/board/common/aarch64/board_arm_helpers.S AS plat/arm/common/aarch64/arm_helpers.S AS lib/xlat_tables_v2/aarch64/enable_mmu.S PP bl31/bl31.ld.S LD build/fvp/release/bl31/bl31.elf BIN build/fvp/release/bl31.bin Built build/fvp/release/bl31.bin successfully OD build/fvp/release/bl31/bl31.dump CC plat/arm/board/fvp/fvp_bl2u_setup.c CC drivers/arm/tzc/tzc400.c CC plat/arm/board/fvp/fvp_security.c CC plat/arm/common/arm_tzc400.c CC drivers/delay_timer/delay_timer.c CC drivers/delay_timer/generic_delay_timer.c CC plat/arm/common/arm_bl2u_setup.c CC bl2u/bl2u_main.c CC common/bl_common.c CC common/tf_log.c CC drivers/console/multi_console.c CC plat/common/plat_bl_common.c CC plat/common/plat_log_common.c CC plat/common/aarch64/plat_common.c CC lib/compiler-rt/builtins/popcountdi2.c CC lib/compiler-rt/builtins/popcountsi2.c CC plat/arm/board/fvp/fvp_common.c CC plat/arm/common/arm_common.c CC plat/arm/common/arm_console.c CC lib/xlat_tables_v2/aarch64/xlat_tables_arch.c CC lib/xlat_tables_v2/xlat_tables_context.c CC lib/xlat_tables_v2/xlat_tables_core.c CC lib/xlat_tables_v2/xlat_tables_utils.c AS bl2u/aarch64/bl2u_entrypoint.S AS plat/common/aarch64/platform_up_stack.S AS common/aarch64/early_exceptions.S AS common/aarch64/debug.S AS lib/aarch64/cache_helpers.S AS lib/aarch64/misc_helpers.S AS plat/common/aarch64/platform_helpers.S AS drivers/arm/pl011/aarch64/pl011_console.S AS plat/arm/board/common/aarch64/board_arm_helpers.S AS plat/arm/common/aarch64/arm_helpers.S AS lib/xlat_tables_v2/aarch64/enable_mmu.S PP bl2u/bl2u.ld.S LD build/fvp/release/bl2u/bl2u.elf BIN build/fvp/release/bl2u.bin Built build/fvp/release/bl2u.bin successfully OD build/fvp/release/bl2u/bl2u.dump CPP plat/arm/board/fvp/fdts/fvp_fw_config.dts DTC plat/arm/board/fvp/fdts/fvp_fw_config.dts CPP plat/arm/board/fvp/fdts/fvp_soc_fw_config.dts DTC plat/arm/board/fvp/fdts/fvp_soc_fw_config.dts CPP plat/arm/board/fvp/fdts/fvp_nt_fw_config.dts DTC plat/arm/board/fvp/fdts/fvp_nt_fw_config.dts CPP fdts/fvp-base-gicv3-psci.dts DTC fdts/fvp-base-gicv3-psci.dts ./build/fvp/release/fdts/fvp-base-gicv3-psci.pre.dts:215.20-220.5: Warning (simple_bus_reg): /smb@0,0/motherboard/flash@0,00000000: simple-bus unit address format error, expected "0" ./build/fvp/release/fdts/fvp-base-gicv3-psci.pre.dts:221.19-224.5: Warning (simple_bus_reg): /smb@0,0/motherboard/vram@2,00000000: simple-bus unit address format error, expected "200000000" ./build/fvp/release/fdts/fvp-base-gicv3-psci.pre.dts:225.23-229.5: Warning (simple_bus_reg): /smb@0,0/motherboard/ethernet@2,02000000: simple-bus unit address format error, expected "202000000" ./build/fvp/release/fdts/fvp-base-gicv3-psci.pre.dts:230.26-235.5: Warning (simple_bus_reg): /smb@0,0/motherboard/clk24mhz: missing or empty reg/ranges property ./build/fvp/release/fdts/fvp-base-gicv3-psci.pre.dts:236.30-241.5: Warning (simple_bus_reg): /smb@0,0/motherboard/refclk1mhz: missing or empty reg/ranges property ./build/fvp/release/fdts/fvp-base-gicv3-psci.pre.dts:242.32-247.5: Warning (simple_bus_reg): /smb@0,0/motherboard/refclk32khz: missing or empty reg/ranges property ./build/fvp/release/fdts/fvp-base-gicv3-psci.pre.dts:248.21-370.5: Warning (simple_bus_reg): /smb@0,0/motherboard/iofpga@3,00000000: simple-bus unit address format error, expected "300000000" ./build/fvp/release/fdts/fvp-base-gicv3-psci.pre.dts:371.33-377.5: Warning (simple_bus_reg): /smb@0,0/motherboard/fixedregulator: missing or empty reg/ranges property ./build/fvp/release/fdts/fvp-base-gicv3-psci.pre.dts:381.21-387.6: Warning (simple_bus_reg): /smb@0,0/motherboard/mcc/osc: missing or empty reg/ranges property ./build/fvp/release/fdts/fvp-base-gicv3-psci.pre.dts:388.12-391.6: Warning (simple_bus_reg): /smb@0,0/motherboard/mcc/muxfpga: missing or empty reg/ranges property ./build/fvp/release/fdts/fvp-base-gicv3-psci.pre.dts:392.12-395.6: Warning (simple_bus_reg): /smb@0,0/motherboard/mcc/dvimode: missing or empty reg/ranges property -- Best Regards Masahiro Yamada

5 years, 2 months

1
0
0 0

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

by Joanna Farley

Hi All, I’ll be running the TF-A Tech Forum next week and I wanted to give an idea of what to expect in this inaugural meeting. While in future meetings I will want to seek input of what the agenda will be before the meeting with the option for other project contributors to present on topics in this first one I have a set agenda which is influenced by the format used in the counterpart TF-M Tech Forum. Agenda: * Introduction to the TF-A Technical Forum Meeting * Technical Overview of the Debug-FS Feature * Optional TF-A Mailing List Topic Discussions Thanks Joanna From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Bill Fletcher via TF-A <tf-a(a)lists.trustedfirmware.org> Reply to: Bill Fletcher <bill.fletcher(a)linaro.org> Date: Friday, 28 February 2020 at 15:25 To: <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] Updated invitation: TF-A Tech Forum @ Thu 12 Mar 2020 17:00 - 18:00 (GMT) (tf-a(a)lists.trustedfirmware.org) 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 »<https://www.google.com/calendar/event?action=VIEW&eid=MGVhNDdsMGVqNnEzZ3BpY…> 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/<https://www.google.com/url?q=https%3A%2F%2Fwww.trustedfirmware.org%2Fmeetin…> Trusted Firmware is inviting you to a scheduled Zoom meeting. Join Zoom Meeting https://zoom.us/j/9159704974<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fj%2F9159704974&sa=D&us…> 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<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fu%2Fad27hc6t7h&sa=D&us…> (updated due to content filtering issues) Going (tf-a(a)lists.trustedfirmware.org)? Yes<https://www.google.com/calendar/event?action=RESPOND&eid=MGVhNDdsMGVqNnEzZ3…> - Maybe<https://www.google.com/calendar/event?action=RESPOND&eid=MGVhNDdsMGVqNnEzZ3…> - No<https://www.google.com/calendar/event?action=RESPOND&eid=MGVhNDdsMGVqNnEzZ3…> more options »<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<https://support.google.com/calendar/answer/37135#forwarding>. -- 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.

5 years, 2 months

1
0
0 0

GICv3 driver changes

by Alexei Fedorov

Hello, I'm preparing a set of patches for GICv3 driver for GICv3.1 and GICv4 support. Please review and provide your comments for the 1st patch which separates GICD and GICR accessor functions and adds new macros for GICv3 registers access. https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3550 Regards. Alexei 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.

5 years, 2 months

1
0
0 0

debug

by Iñigo Vicente Waliño

Hi, Is there any way to see through the console or to debug the TFA on the imx8m board? Best

5 years, 2 months

1
0
0 0

Imx8m mini boot

by Iñigo Vicente Waliño

Hi, Is there any way to see the traceability or registers by the command line of the secure boot on my imx8m mini board with u-boot? Thanks Iñigo

5 years, 2 months

1
0
0 0

Review request

by Pramod Kumar

Hi All, Please help me reviewing below patches- https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3493 https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3580 Regards, Pramod

5 years, 2 months

1
0
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

5 years, 2 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

5 years, 2 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

5 years, 2 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.

5 years, 2 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

5 years, 2 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 >

5 years, 2 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…

5 years, 2 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

5 years, 2 months

1
0
0 0

Need to synchronize pending EA

by Madhukar Pappireddy

Hi, I have pushed a patch [1] to use a barrier to synchronize pending EA at the entry and exit of exception handlers in BL31(EL3S). There is an interesting discussion as seen in the gerrit review comments of the patch. It looks like this patch is just enabling early panic/crash of the system in the event of SErrors but it does come with performance penalty (due to DSBs) for common exceptions like SMC calls. We believe this needs broader discussion to understand the practical approach to handle SErrors, especially in SoCs without RAS support. Please let us know your thoughts on this patch. [1] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3440 Thanks, Madhukar

5 years, 2 months

1
0
0 0

Re: [TF-A] Protecting Secure World Translation Tables

by Petre-Ionut Tudor

Hi Raghu, Thank you for your comments. My own comments are inline. ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Raghu Krishnamurthy via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 18 February 2020 00:16 To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: Re: [TF-A] Protecting Secure World Translation Tables I think it is worth implementing this to raise the bar for successful attacks. To Varun's point, in today's systems without S-EL2(<v8.4), it would be less effective as pointed out, since EL3 memory can be completely accessed by SEL1 and SEL1 code tends to have a larger code base on mobile devices(OPTEE, tlk etc). However, on systems with very thin SEL1 shims(typically servers), this would definitely raise the bar for attacks, since you effectively only have SEL0 and EL3. SEL1 cannot be exploited practically. For new SoCs with SEL2, this mitigation can still be very effective if we can ensure future SEL2 implementations have much smaller code bases and implements this mitigation itself. Effectively, i view SEL2 and EL3 as being equally privileged(it is no different than SEL1 because SEL2 can barf all over EL3 memory and TZ resources if exploited). SEL2 extensions, however, gives EL3 protection from SEL1 and can prevent SEL1 from accessing ALL TZ resources. If you view SEL2 and EL3 as equally privileged and view both together as a single entity, v8.4 systems effectively have EL3, SEL1, SEL0 AND the ability for EL3 to protect itself and other TZ resources from SEL1. In such a system, EL3(and SEL2) having this mitigation will definitely raise the bar for successful attacks. Also, the cost to implement this mitigation is relatively low for a fairly significant raise in the bar for successful attacks. PS - I say significantly raise the bar since an attacker will potentially require gadgets to modify TTBRx, invalidate TLB's, and enough gadgets in the code base to have a successful attack. If code in TF-A EL3 is fairly small, and code that writes to TTBR_EL3 can be in some section of the image that can be reclaimed/erased after initial setup, the attacker would have no gadget to modify TTBR_EL3, so there would be virtually no way to change TTBR_EL3. On a default build of FVP, there is a grand total of 1 instruction that writes to TTBR0_EL3 in enable_mmu_direct_el3. This might be a nice follow up change to this mitigation, if others think it is worth it. The same could be extended to other system registers that don't ever need to be changed(VBAR_EL3? SCTLR_EL3?). Petre: enable_mmu_direct_el3 is also used in the read-only xlat tables API, because the change is made while the MMU is on (so it must be disabled first). I decided to implement it this way in order to allow a platform to make any changes it needs to the translation tables (e.g. for reclaiming initialization code) before calling this API. So, it is kind of "dynamic"...but after it is called nothing can be done to the tables from that EL. This means that we have to reclaim before using this API (otherwise we would have to choose between reclaiming and this feature since RO tables won't allow changing the memory map). I was afraid the change might impose too much rigidity on the initialization of platform BL images, so I went with this approach instead of making the tables read-only at creation by the init_xlat_tables* functions. Thanks Raghu On 2/17/20 12:35 PM, Varun Wadekar via TF-A wrote: > Hello Petre, > > Thanks for the patch. Before I review the actual code, would like to understand how effective this patch will be and if you have seen a real world attack that this patch mitigates. > > AFAIU, the ARM architecture provides the TZ bit as the only protection to create "partitions" on a CPU core. So, potentially S-EL1 can access almost all TZ resources that EL3 can access. Thus, creating a silo inside EL3 exception mode is not an effective mitigation against any other TZ component writing to the physical memory where the page tables are stored. For the scope of this attack vector, are we assuming that the system cannot be compromised by attacking other TZ software components in the system? > > I feel until we have a way to distinguish between CPU realms (EL3 v S-EL2 v S-EL1) at the hardware bus level (ARM v9?), these mitigations are not that effective. > > Thoughts? > > -Varun > > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Petre-Ionut Tudor via TF-A > Sent: Monday, February 17, 2020 9:40 AM > To: tf-a(a)lists.trustedfirmware.org > Subject: [TF-A] Protecting Secure World Translation Tables > > External email: Use caution opening links or attachments > > > Hello Everyone, > > For quite some time I have been working on a security hardening feature that offers extra protection against tampering with the Secure world translation tables. An example would be using a gadget that can perform writes to arbitrary Secure memory locations to change memory attributes and/or the memory map. > > A real world exploit that uses read/write gadgets to tamper with translation tables can be found here: https://vimeo.com/335948808. If you only want the slide deck, it's available here: https://speakerdeck.com/hhj4ck/el3-tour-get-the-ultimate-privilege-of-andro…. > > A patch implementing this feature has been recently pushed upstream here: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3349. It extends v2 of the translation tables library with an API that can be called by a BL image any time after the initialization of the xlat tables to make them read-only. > > It would be great to hear your opinions about this, particularly whether or not it is a desirable feature to have in TF-A and what extra work needs to be done for it to meet the use cases that you consider most relevant. > > Best wishes > Petre > 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 > > ----------------------------------------------------------------------------------- > This email message is for the sole use of the intended recipient(s) and may contain > confidential information. Any unauthorized review, use, disclosure or distribution > is prohibited. If you are not the intended recipient, please contact the sender by > reply email and destroy all copies of the original message. > ----------------------------------------------------------------------------------- > -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 2 months

2
5
0 0

Re: [TF-A] Protecting Secure World Translation Tables

by Petre-Ionut Tudor

Hi Varun, Thank you for the suggestions. My comments are inline. Petre ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Varun Wadekar via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 18 February 2020 05:44 To: Raghu Krishnamurthy <raghu.ncstate(a)icloud.com> Cc: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: Re: [TF-A] Protecting Secure World Translation Tables Thanks Raghu. I agree that this patch reduces the attack surface and would be a good addition, if we consider use cases where EL3 code runs in a silo. Since S-EL1 can contain any third party code, there is an opportunity to change memory contents without EL3 ever noticing the change. A hash for the RO page tables would improve this change immensely IMO. > Petre: Thank you for the suggestion. Sounds like an interesting improvement to make (maybe in a follow-up to this change?, since my rotation in the TF-A team is nearing its end). This change is not effective for platforms that use dynamic page tables e.g. Tegra platforms, so we won't be enabling it. But if other maintainers think this is a good addition to their platforms, I don’t have any objection. > Petre: Do you think it would be worth making this feature play more nicely with the dynamic translation library? I'm thinking providing a counter-API to make tables writable again. So that, every time a dynamic API is needed, since the translation context will be aware of the tables being RO, it first calls a make_tables_writable API before doing whatever it needs to and after it completes (whether successfully or not) calls make_tables_readonly. Essentially, it would act like a wrapper around the dynamic library functions. What do you think of this? Is the disable MMU + cache flush penalty too severe (incurred twice for each dynamic xlat API call)? -----Original Message----- From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Raghu Krishnamurthy via TF-A Sent: Monday, February 17, 2020 4:16 PM To: tf-a(a)lists.trustedfirmware.org Subject: Re: [TF-A] Protecting Secure World Translation Tables External email: Use caution opening links or attachments I think it is worth implementing this to raise the bar for successful attacks. To Varun's point, in today's systems without S-EL2(<v8.4), it would be less effective as pointed out, since EL3 memory can be completely accessed by SEL1 and SEL1 code tends to have a larger code base on mobile devices(OPTEE, tlk etc). However, on systems with very thin SEL1 shims(typically servers), this would definitely raise the bar for attacks, since you effectively only have SEL0 and EL3. SEL1 cannot be exploited practically. For new SoCs with SEL2, this mitigation can still be very effective if we can ensure future SEL2 implementations have much smaller code bases and implements this mitigation itself. Effectively, i view SEL2 and EL3 as being equally privileged(it is no different than SEL1 because SEL2 can barf all over EL3 memory and TZ resources if exploited). SEL2 extensions, however, gives EL3 protection from SEL1 and can prevent SEL1 from accessing ALL TZ resources. If you view SEL2 and EL3 as equally privileged and view both together as a single entity, v8.4 systems effectively have EL3, SEL1, SEL0 AND the ability for EL3 to protect itself and other TZ resources from SEL1. In such a system, EL3(and SEL2) having this mitigation will definitely raise the bar for successful attacks. Also, the cost to implement this mitigation is relatively low for a fairly significant raise in the bar for successful attacks. PS - I say significantly raise the bar since an attacker will potentially require gadgets to modify TTBRx, invalidate TLB's, and enough gadgets in the code base to have a successful attack. If code in TF-A EL3 is fairly small, and code that writes to TTBR_EL3 can be in some section of the image that can be reclaimed/erased after initial setup, the attacker would have no gadget to modify TTBR_EL3, so there would be virtually no way to change TTBR_EL3. On a default build of FVP, there is a grand total of 1 instruction that writes to TTBR0_EL3 in enable_mmu_direct_el3. This might be a nice follow up change to this mitigation, if others think it is worth it. The same could be extended to other system registers that don't ever need to be changed(VBAR_EL3? SCTLR_EL3?). Thanks Raghu On 2/17/20 12:35 PM, Varun Wadekar via TF-A wrote: > Hello Petre, > > Thanks for the patch. Before I review the actual code, would like to understand how effective this patch will be and if you have seen a real world attack that this patch mitigates. > > AFAIU, the ARM architecture provides the TZ bit as the only protection to create "partitions" on a CPU core. So, potentially S-EL1 can access almost all TZ resources that EL3 can access. Thus, creating a silo inside EL3 exception mode is not an effective mitigation against any other TZ component writing to the physical memory where the page tables are stored. For the scope of this attack vector, are we assuming that the system cannot be compromised by attacking other TZ software components in the system? > > I feel until we have a way to distinguish between CPU realms (EL3 v S-EL2 v S-EL1) at the hardware bus level (ARM v9?), these mitigations are not that effective. > > Thoughts? > > -Varun > > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of > Petre-Ionut Tudor via TF-A > Sent: Monday, February 17, 2020 9:40 AM > To: tf-a(a)lists.trustedfirmware.org > Subject: [TF-A] Protecting Secure World Translation Tables > > External email: Use caution opening links or attachments > > > Hello Everyone, > > For quite some time I have been working on a security hardening feature that offers extra protection against tampering with the Secure world translation tables. An example would be using a gadget that can perform writes to arbitrary Secure memory locations to change memory attributes and/or the memory map. > > A real world exploit that uses read/write gadgets to tamper with translation tables can be found here: https://vimeo.com/335948808. If you only want the slide deck, it's available here: https://speakerdeck.com/hhj4ck/el3-tour-get-the-ultimate-privilege-of-andro…. > > A patch implementing this feature has been recently pushed upstream here: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3349. It extends v2 of the translation tables library with an API that can be called by a BL image any time after the initialization of the xlat tables to make them read-only. > > It would be great to hear your opinions about this, particularly whether or not it is a desirable feature to have in TF-A and what extra work needs to be done for it to meet the use cases that you consider most relevant. > > Best wishes > Petre > 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 > > ---------------------------------------------------------------------- > ------------- This email message is for the sole use of the intended > recipient(s) and may contain confidential information. Any > unauthorized review, use, disclosure or distribution is prohibited. > If you are not the intended recipient, please contact the sender by > reply email and destroy all copies of the original message. > ---------------------------------------------------------------------- > ------------- > -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 2 months

2
2
0 0

Re: [TF-A] Protecting Secure World Translation Tables

by Varun Wadekar

Hello Petre, Thanks for the patch. Before I review the actual code, would like to understand how effective this patch will be and if you have seen a real world attack that this patch mitigates. AFAIU, the ARM architecture provides the TZ bit as the only protection to create "partitions" on a CPU core. So, potentially S-EL1 can access almost all TZ resources that EL3 can access. Thus, creating a silo inside EL3 exception mode is not an effective mitigation against any other TZ component writing to the physical memory where the page tables are stored. For the scope of this attack vector, are we assuming that the system cannot be compromised by attacking other TZ software components in the system? I feel until we have a way to distinguish between CPU realms (EL3 v S-EL2 v S-EL1) at the hardware bus level (ARM v9?), these mitigations are not that effective. Thoughts? -Varun -----Original Message----- From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Petre-Ionut Tudor via TF-A Sent: Monday, February 17, 2020 9:40 AM To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] Protecting Secure World Translation Tables External email: Use caution opening links or attachments Hello Everyone, For quite some time I have been working on a security hardening feature that offers extra protection against tampering with the Secure world translation tables. An example would be using a gadget that can perform writes to arbitrary Secure memory locations to change memory attributes and/or the memory map. A real world exploit that uses read/write gadgets to tamper with translation tables can be found here: https://vimeo.com/335948808. If you only want the slide deck, it's available here: https://speakerdeck.com/hhj4ck/el3-tour-get-the-ultimate-privilege-of-andro…. A patch implementing this feature has been recently pushed upstream here: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3349. It extends v2 of the translation tables library with an API that can be called by a BL image any time after the initialization of the xlat tables to make them read-only. It would be great to hear your opinions about this, particularly whether or not it is a desirable feature to have in TF-A and what extra work needs to be done for it to meet the use cases that you consider most relevant. Best wishes Petre 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 ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. -----------------------------------------------------------------------------------

5 years, 2 months

2
1
0 0

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

by Soby Mathew

On 18/02/2020 05:52, Sumit Garg wrote: > On Tue, 18 Feb 2020 at 00:44, Soby Mathew <Soby.Mathew(a)arm.com> wrote: >> >> Hi Everyone, >> I have confirmation from the TBFU architect that both decrypt-then-verify and verify-then-decrypt is acceptable and neither case affects boot integrity. > > Thanks for this confirmation. > >> So I think the flexibility should be given to the platform to choose this. >> >> @Sumit Garg, could you please rework the patches as I mentioned in my previous feedback and submit again? > > Sure I will try to address implementation specific concerns. Actually > earlier I was waiting for above design specific confirmation. > > -Sumit [Adding back the tf-a list] OK, Thanks Sumit. >> >> Best Regards >> Soby Mathew >> >>> -----Original Message----- >>> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Raghupathy >>> Krishnamurthy via TF-A >>> Sent: 28 January 2020 14:58 >>> To: Sumit Garg <sumit.garg(a)linaro.org> >>> Cc: Daniel Thompson <daniel.thompson(a)linaro.org>; Miklos Balint >>> <Miklos.Balint(a)arm.com>; Kiyoshi Owada <owada.kiyoshi(a)socionext.com>; tf- >>> a(a)lists.trustedfirmware.org; Joakim Bech <joakim.bech(a)linaro.org>; nd >>> <nd(a)arm.com>; Sandrine Bailleux <Sandrine.Bailleux(a)arm.com> >>> Subject: Re: [TF-A] [RFC] New feature in TF-A to load encrypted FIP payloads >>> >>> Hi Sumit, >>> >>> >>> I completely agree with you! All i'm asking for is that what you are proposing is >>> ratified in the spec clearly, without any ambiguities and that we don't >>> implement what we *think* is correct, but implement the spec. If the spec >>> specifies encryption, we should implement encryption, not authenticated >>> encryption. One is not a direct substitute for the other and requires careful >>> thinking. Similarly, the order of signing, encryption, decryption and >>> authentication must be specified and explained clearly, specifically to avoid >>> these kinds of discussions. >>> >>> >>> Thanks >>> -Raghu >>> >>> On January 27, 2020 at 10:49 PM, Sumit Garg <sumit.garg(a)linaro.org> wrote: >>> >>> >>> On Mon, 27 Jan 2020 at 22:54, Raghupathy Krishnamurthy >>> <raghu.ncstate(a)icloud.com> wrote: >>> >>> >>> >>> Sumit, >>> >>> >>> Great point. This perhaps needs to be added to the list of things that need >>> clarification(Sandrine can you help with this too?) in the PSA-TBFU . I believe >>> the answer to your concern lies in the PSA-TBFU in section 3.5, where it talks >>> about optimizing the trusted boot process. To overcome the problem you're >>> talking about, you would: >>> 1) Verify asymmetric signature. >>> 2) Decrypt firmware using SSK on successful signature verification. >>> 3) Rekey the firmware using BSSK(or as the PSA specifies, a key derived from >>> the HUK using a KDF). >>> You will only verify the asymmetric signature on every firmware update, and >>> use the rekeyed firmware(encrypted and mac;d with device specific key) on >>> normal boot. >>> >>> >>> >>> Following is the quote from PSA-TBFU spec: >>> >>> "An implementation **can** optimize the trusted boot process at the expense >>> of **simplicity**" >>> >>> It doesn't seems to be a recommended practice from spec. And especially for >>> DRM use-cases, this approach is NOT recommended due to following concerns >>> raised by DRM vendors (original concerns were with respect to TAs but will >>> equally apply for firmware as well): >>> - allows the device to self sign code authorized to run on the device. >>> - increase the attack surface by having two different ways to load firmware. >>> - allow a break once break forever situation, if you defeat the RSA 'install' once, >>> no matter how hard it is, now your firmware is nicely transformed in a secure >>> firmware and can be reused. >>> >>> Whereas on the other hand, considering >>> "sign-then-encrypt-then-authenticate", it provides two mutually exclusive >>> crypto layers (signature layer and authenticated encryption >>> layer) which in turns provides implementation flexibility as follows: >>> >>> Firmware update: >>> - Require both layers. >>> >>> Normal boot: >>> - DRM use-case, require both layers. >>> - Boot time optimization required, can use only authenticated encryption. >>> - Platform provides secure on-chip NVM and boot time optimization required, >>> can use only signature verification (or simply hash stored in secure on-chip >>> NVM memory). >>> >>> -Sumit >>> >>> >>> Thanks >>> Raghu >>> >>> >>> On January 26, 2020 at 10:34 PM, Sumit Garg <sumit.garg(a)linaro.org> wrote: >>> >>> >>> On Fri, 24 Jan 2020 at 16:36, Sumit Garg <sumit.garg(a)linaro.org> wrote: >>> >>> >>> >>> >>> On Fri, 24 Jan 2020 at 04:02, Raghupathy Krishnamurthy >>> >>> >>> <raghu.ncstate(a)icloud.com> wrote: >>> >>> >>>> >>> >>> >>>> I also just realized that both the TBBR and ARM PSA only talk about >>> encryption of the image, and not authenticated encryption. The guarantees >>> provided by both are completely different. Your >>> review(https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2495/) >>> talks about the requirement R060_TBBR_FUNCTION being implemented, which >>> is technically not true(and potentially misleading). We must make a note of this >>> difference and use the appropriate terminology, without mixing the two, in the >>> documentation, commit messages, source code comments and error prints. >>> The tool is also called 'encrypt_fw ' but should maybe be named appropriately >>> to indicate it is doing authenticated encryption. >>> >>> >>> >>> >>> I wouldn't call it misleading. Since firmware encryption feature >>> >>> >>> essentially provides confidentiality protection and authenticated >>> >>> >>> encryption is the type of crypto algorithm which we have used to >>> >>> >>> implement it. >>> >>> >>> >>> >>>> >>> >>> >>>> BTW, ARM PSA(file:///home/raghu/repos/fvp/DEN0072-PSA_TBFU_1-0- >>> REL.pdf) expects that the image manifest(X509 certificate) contain the hash of >>> the ENCRYPTED image(Table 2 and as described in my answer to your question >>> "How would this ensure integrity of ciphertext"). The TBBR spec completely >>> misses this fact, and is a crucial detail if we only implement encryption(as >>> opposed to authenticated encryption).Build_macros.mk, in your change, passes >>> the un-encrypted image to cert-tool. You can get away with it in your >>> implementation, since you are using authenticated encryption, not if you were >>> only implementing firmware encryption. >>> >>> >>> >>> >>> I have already highlighted the issue with signing the ciphertext in my >>> >>> >>> previous reply which deviates from security properties provided by >>> >>> >>> signature verification of plain firmware. So I think we need to >>> >>> >>> revisit ARM PSA TBFU spec. >>> >>> >>> >>> >>> >>> >>> In addition to this, there are implementation specific issues with "signing the >>> ciphertext" too. It simply makes the ciphertext immutable for device and >>> disallows meeting following firmware re-encryption requirement as per TBBR >>> spec: >>> >>> >>> R070_TBBR_PROTECTION. The Trusted boot firmware may do the binding of >>> software image updates at run- time by decrypting the updated SoC certificates >>> and software images using the OTP/Fuse Secret Symmetric Key (SSK), followed >>> by the re-encrypting these SoC certificates and software images using a >>> reproducible secret unique per device symmetric key (BSSK), and then updating >>> the ToC correspondingly. >>> >>> >>> Also, externally signing every firmware image encrypted with BSSK doesn't >>> seem scalable as well. It also hampers the case where encryption key is never >>> exposed out from device eg. encryption key is only accessible to hardware >>> crypto engine etc. >>> >>> >>> -Sumit >>> >>> >>> >>> >>>> >>> >>> >>>> Is it possible for somebody from ARM to have the TBBR spec updated to >>> reflect this? Also perhaps talk to the spec writers about incorporating >>> authenticated encryption into TBBR and PSA? This patch set is somewhat >>> trailblazing in this regard. >>> >>> >>>> >>> >>> >>>> -Raghu >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> On January 23, 2020 at 12:08 PM, Raghupathy Krishnamurthy via TF-A <tf- >>> a(a)lists.trustedfirmware.org> wrote: >>> >>> >>>> >>> >>> >>>> Hi Sumit, >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> Thanks for your response. >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> So firstly I would suggest you to revisit TBBR spec [1], >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> [RK] I'm very familiar with the TBBR spec and the requirements. Note >>>> that not all SoC's adhere perfectly to the TBBR spec, since it does >>>> not apply to devices in all market segments. However, these devices do >>>> use arm trusted firmware and TBBR CoT in a slightly modified form, >>>> which is still perfectly valid. Also, the TBBR spec can be changed if >>>> required :) >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> Why would one use authenticated decryption only to establish TBBR >>> >>> >>>> >>> >>> >>>> Chain of Trust providing device the capability to self sign its firmware? >>> >>> >>>> >>> >>> >>>> [RK] Fair point. However, you may have devices that don't have the >>> processing power or hardware budget or cost factors(paying for HSM's to store >>> private asymmetric keys), to implement asymmetric verification, in which case >>> using authenticated decryption to verify firmware authenticity and integrity is >>> perfectly valid. The attacks on devices that use symmetric keys to verify >>> firmware authenticity and integrity are usually related to exploiting firmware >>> flaws that leak the key or insiders leaking keys, but that is a different problem >>> and requires different solutions. Fundamentally, there is nothing wrong with >>> using symmetric keys for this purpose, so long as the key is well protected. Also >>> note, security requirements and guarantees are different for different systems. >>> The risk is taken by the system designer and should not be imposed by >>> framework code. I don't advocate doing this but it is an option that your >>> implementation does not provide(and perhaps rightly so). >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> How would this ensure integrity of ciphertext? >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> [RK] You sign the ciphertext. In your design, you pass bl31_enc.bin to >>> cert_tool to sign. You don't decrypt the encrypted cipher text until you have >>> verified the asymmetric signature(which provides integrity). As far as signature >>> verification is concerned, whether you sign the plain text or ciphertext is >>> immaterial, since you are simply verifying that the absolute bits you loaded >>> have not been modified(assuming you use a secure signature scheme). >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> Have a look at some defective sign and encrypt techniques here [2] >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> [RK] Again, very familiar with [2]. In the S/MIME case, you have multiple >>> parties. With secure boot, you have one party, effectively verifying its own >>> messages across time. There is only one key used to verify signatures. 1.1 and >>> 1.2 does not apply. Also you are encrypting and signing with completely >>> different keys and algorithms. Section 1.2 applies when you use RSA/El-gamal >>> encryption. Here you use symmetric encryption and asymmetric signing. >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> Why would one not use TBBR CoT here? >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> [RK] see above. Not all systems are designed equal. >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> and why would one like to hardcode in a device during >>> >>> >>>> >>> >>> >>>> provisioning to boot only either an encrypted or a plain firmware >>> >>> >>>> image? >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> [RK] Why would you not? You typically want to have the same security policy >>> for a class of devices and not be modifiable by an attacker. It isn't common for >>> the same class of devices to use encrypted firmware some times, and un- >>> encrypted firmware other times. If it is common, there is no problem with >>> setting the bit in the FIP header, as long as verified boot is mandatory. The only >>> concern(as my original email said) is the coupling of the FIP layer and the >>> crypto module, in the implementation. I still don't like that fact that the bit >>> saying the file is encrypted is not signed and this may require talking to the >>> TBBR spec writers. Page 22 of the TBBR spec calls out ToC as "Trusted Table of >>> Contents". The FIP header cannot be "trusted", if it is not in ROM or its integrity >>> is verified by some means! R010_TBBR_TOC should perhaps be mandatory >>> then. Also see R080_TBBR_TOC that says the TOC MUST be ROM'ed or tied by >>> hardware in readable registers. This requirement seems contradictory to >>> R010_TBBR_TOC, given that the FIP header(TOC) is copied from mutable NVM >>> by ROM or some boot stage and then ROM'd or loaded into registers. I may be >>> misunderstanding R080_TBBR_TOC, but i'd interpret it as the TOC(FIP header >>> in ATF implementation of TBBR) as being in ROM or integrity verified. >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> How would one handle a case where BL31 is in plain format and BL32 is in >>> encrypted format? >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> [RK]TBBR CoT is equipped to do this. The table is defined on a per image >>> basis. >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> If you are really paranoid about authentication of FIP header... >>> >>> >>>> >>> >>> >>>> [RK] I don't mean to pontificate but there are real world customers buying >>> real hardware, running ATF code, who care about such details and ask about >>> such things routinely. It is not just me being paranoid and is definitely not a >>> minor matter to think of such details. We should discuss more and consider the >>> implications of R080_TBBR_TOC and R010_TBBR_TOC, perhaps on a different >>> thread, without blocking your code review. Can somebody from ARM clarify >>> these requirements with the spec writers? >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> Thanks >>> >>> >>>> -Raghu >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> On January 23, 2020 at 12:38 AM, Sumit Garg <sumit.garg(a)linaro.org> >>> wrote: >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> Hi Raghu, >>> >>> >>>> >>> >>> >>>> I guess you have completely misunderstood this feature. This is an >>> >>> >>>> optional feature which allows to load encrypted FIP payloads using >>> >>> >>>> authenticated decryption which MUST be used along with signature >>> >>> >>>> verification (or TBBR CoT). >>> >>> >>>> >>> >>> >>>> So firstly I would suggest you to revisit TBBR spec [1], especially >>> >>> >>>> requirements: R040_TBBR_TOC, R060_TBBR_FUNCTION etc. >>> >>> >>>> >>> >>> >>>> On Thu, 23 Jan 2020 at 00:14, Raghupathy Krishnamurthy >>> >>> >>>> <raghu.ncstate(a)icloud.com> wrote: >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> Hello, >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> The patch stack looks good. The only comment i have is that the FIP layer has >>> now become security aware and supports authenticated decryption(only). This >>> is a deviation from the secure/signed/verified boot design, where we use the >>> TBBR COT to dictate the security operations on the file. This is nice, because >>> file IO is decoupled from the security policy. This may be a big deviation(i >>> apologize if this was considered and shot down for some other reason), but it >>> may be worthwhile to consider making authenticated decryption a part of the >>> authentication framework as opposed to coupling it with the FIP layer. >>> >>> >>>> >>> >>> >>>> It looks like you have mixed both TBBR CoT and this authenticated >>> >>> >>>> decryption feature. They both are completely different and rather >>> >>> >>>> complement each other where TBBR CoT establishes >>> >>> >>>> secure/signed/verified boot and this authenticated decryption feature >>> >>> >>>> provides confidentiality protection for FIP payloads. >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> At a high level, this would mean adding a new authentication >>> method(perhaps AUTH_METHOD_AUTHENTICATED_DECRYPTION), and having >>> the platform specify that the image is using authenticated encryption in the >>> TBBR COT. >>> >>> >>>> >>> >>> >>>> Why would one use authenticated decryption only to establish TBBR >>> >>> >>>> Chain of Trust providing device the capability to self sign its >>> >>> >>>> firmwares? We must use signature verification for TBBR CoT (see >>> >>> >>>> section: 2.1 Authentication of Code Images by Certificate in TBBR spec >>> >>> >>>> [1]). >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> The authentication framework is already well designed and well equipped to >>> handle these types of extensions. >>> >>> >>>> 1) This would make the change simpler, since you would not require changes >>> to the FIP tool and the FIP layer. >>> >>> >>>> 2) This would also allow for future cases where a platform may want to only >>> encrypt the file and use public key authentication on the encrypted file(for ex. >>> the soc does not have a crypto accelerator for aes-gcm but only for AES and >>> public key verification, for whatever reason). >>> >>> >>>> >>> >>> >>>> How would this ensure integrity of ciphertext? This approach may be >>> >>> >>>> vulnerable to Chosen Ciphertext Attacks (CCAs). Authentication tag as >>> >>> >>>> part of AES-GCM provides integrity protection for ciphertext. >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> 3) This would let you choose the order in which you want to do the >>> authenticated decryption(or just decryption) and signature verification, if you >>> use both, one or the other. >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> Have a look at some defective sign and encrypt techniques here [2]. >>> >>> >>>> The order can't be any arbitrary one, we need to be careful about >>> >>> >>>> this. >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> One other thing i'm not entirely comfortable with is that the flag indicating if >>> there are encrypted files or not in the FIP, is in the *unsigned* portion of the >>> FIP header. An attacker could simply flip bits that dictate security policy in the >>> header and avoid detection(in this case, the indication that the file needs >>> authenticated decryption). If a platform only uses authenticated encryption, but >>> not verified boot, an attacker could flip the bit in the FIP header and have any >>> image loaded on the platform. >>> >>> >>>> >>> >>> >>>> Why would one not use TBBR CoT here? >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> If authenticated encryption cannot be used without verified boot(which >>> requires build time flags), having a flag to indicate that there are encrypted >>> files in the FIP header is moot, since this can come at build time through the >>> TBBR COT. In any case, it seems like the security policy that firmware images >>> need to be decrypted or authenticated with authenticated decryption, seems >>> like a firmware build time or manufacturing time decision(perhaps a bit set in >>> the e-fuses). >>> >>> >>>> >>> >>> >>>> Again you are confusing TBBR CoT with authenticated decryption >>> >>> >>>> feature. And why would one like to hardcode in a device during >>> >>> >>>> provisioning to boot only either an encrypted or a plain firmware >>> >>> >>>> image? >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> There seems to be no benefit to having a flag in the FIP header. >>> >>> >>>> >>> >>> >>>> How would one handle a case where BL31 is in plain format and BL32 is >>> >>> >>>> in encrypted format? >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> Otherwise, I cant think of any attacks due to this and it may be completely >>> okay, but generally, consuming data that dictates security policy/operations >>> before verifying its integrity seems like a recipe for disaster. >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> If you are really paranoid about authentication of FIP header then you >>> >>> >>>> should look at implementing optional requirement: R010_TBBR_TOC as per >>> >>> >>>> TBBR spec [1]. >>> >>> >>>> >>> >>> >>>> [1] >>>> https://developer.arm.com/docs/den0006/latest/trusted-board-boot-requi >>>> rements-client-tbbr-client-armv8-a >>> >>> >>>> [2] http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html >>> >>> >>>> >>> >>> >>>> -Sumit >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> -Raghu >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> On January 22, 2020 at 3:51 AM, Sumit Garg via TF-A <tf- >>> a(a)lists.trustedfirmware.org> wrote: >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> Hi Sandrine, >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> On Wed, 22 Jan 2020 at 15:43, Sandrine Bailleux >>> >>> >>>> <Sandrine.Bailleux(a)arm.com> wrote: >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> Hello Sumit, >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> Thank you for reworking the patches and addressing all of my review >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> comments. I am happy with the latest version of these and consider >>>> them >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> ready to go. I plan to leave them in Gerrit for another week to give >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> extra time for other potential reviewers to have a look and comment. >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> Thanks for your review. >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> To everyone on the list: Please raise any concerns you may have about >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> these patches in the coming week. If I don't hear anything by 29th >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> January 2020, I will merge these patches. >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> @Sumit: One of the next actions for this patch stack would be to have >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> some level of testing in the CI system to detect any potential >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> regressions. We (at Arm) can quite easily add a few build tests but >>>> then >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> testing the software stack on QEMU is a bit more involved for various >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> reasons (first instance of QEMU testing, dependencies on OPTEE, UEFI, >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> ...) so this might have to wait for some time. >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> Okay, will wait for CI testing. >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> -Sumit >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> Regards, >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> Sandrine >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> -- >>> >>> >>>> TF-A mailing list >>> >>> >>>> TF-A(a)lists.trustedfirmware.org >>> >>> >>>> https://lists.trustedfirmware.org/mailman/listinfo/tf-a >>> >>> >>>> -- >>> >>> >>>> TF-A mailing list >>> >>> >>>> TF-A(a)lists.trustedfirmware.org >>> >>> >>>> https://lists.trustedfirmware.org/mailman/listinfo/tf-a >>> -- >>> TF-A mailing list >>> TF-A(a)lists.trustedfirmware.org >>> https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 3 months

1
0
0 0

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

by Soby Mathew

On 17/02/2020 23:25, Raghu Krishnamurthy wrote: > Thanks Soby. Couple of questions: > 1) Is this going to be clarified in the PSA-TBFU ? Hi Raghu, Yes, this clarification will added to the spec. > 2) Is authenticated encryption/decryption going to be addressed ? One of > the issues i had was the fact that AES-GCM was being used here instead > of just encryption such as aes-cbc/ctr etc. I think it is worth adding a > note in the spec stating that it can be used safely instead of > encryption, and probably preferred. Yes, clarification regarding using AEAD algorithms/AES-GCM will be provided as I understand. Best Regards Soby Mathew > > Thanks > Raghu > > On 2/17/20 11:14 AM, Soby Mathew wrote: >> Hi Everyone, >> I have confirmation from the TBFU architect that both decrypt-then-verify and verify-then-decrypt is acceptable and neither case affects boot integrity. So I think the flexibility should be given to the platform to choose this. >> >> @Sumit Garg, could you please rework the patches as I mentioned in my previous feedback and submit again? >> >> Best Regards >> Soby Mathew >> >>> -----Original Message----- >>> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Raghupathy >>> Krishnamurthy via TF-A >>> Sent: 28 January 2020 14:58 >>> To: Sumit Garg <sumit.garg(a)linaro.org> >>> Cc: Daniel Thompson <daniel.thompson(a)linaro.org>; Miklos Balint >>> <Miklos.Balint(a)arm.com>; Kiyoshi Owada <owada.kiyoshi(a)socionext.com>; tf- >>> a(a)lists.trustedfirmware.org; Joakim Bech <joakim.bech(a)linaro.org>; nd >>> <nd(a)arm.com>; Sandrine Bailleux <Sandrine.Bailleux(a)arm.com> >>> Subject: Re: [TF-A] [RFC] New feature in TF-A to load encrypted FIP payloads >>> >>> Hi Sumit, >>> >>> >>> I completely agree with you! All i'm asking for is that what you are proposing is >>> ratified in the spec clearly, without any ambiguities and that we don't >>> implement what we *think* is correct, but implement the spec. If the spec >>> specifies encryption, we should implement encryption, not authenticated >>> encryption. One is not a direct substitute for the other and requires careful >>> thinking. Similarly, the order of signing, encryption, decryption and >>> authentication must be specified and explained clearly, specifically to avoid >>> these kinds of discussions. >>> >>> >>> Thanks >>> -Raghu >>> >>> On January 27, 2020 at 10:49 PM, Sumit Garg <sumit.garg(a)linaro.org> wrote: >>> >>> >>> On Mon, 27 Jan 2020 at 22:54, Raghupathy Krishnamurthy >>> <raghu.ncstate(a)icloud.com> wrote: >>> >>> >>> >>> Sumit, >>> >>> >>> Great point. This perhaps needs to be added to the list of things that need >>> clarification(Sandrine can you help with this too?) in the PSA-TBFU . I believe >>> the answer to your concern lies in the PSA-TBFU in section 3.5, where it talks >>> about optimizing the trusted boot process. To overcome the problem you're >>> talking about, you would: >>> 1) Verify asymmetric signature. >>> 2) Decrypt firmware using SSK on successful signature verification. >>> 3) Rekey the firmware using BSSK(or as the PSA specifies, a key derived from >>> the HUK using a KDF). >>> You will only verify the asymmetric signature on every firmware update, and >>> use the rekeyed firmware(encrypted and mac;d with device specific key) on >>> normal boot. >>> >>> >>> >>> Following is the quote from PSA-TBFU spec: >>> >>> "An implementation **can** optimize the trusted boot process at the expense >>> of **simplicity**" >>> >>> It doesn't seems to be a recommended practice from spec. And especially for >>> DRM use-cases, this approach is NOT recommended due to following concerns >>> raised by DRM vendors (original concerns were with respect to TAs but will >>> equally apply for firmware as well): >>> - allows the device to self sign code authorized to run on the device. >>> - increase the attack surface by having two different ways to load firmware. >>> - allow a break once break forever situation, if you defeat the RSA 'install' once, >>> no matter how hard it is, now your firmware is nicely transformed in a secure >>> firmware and can be reused. >>> >>> Whereas on the other hand, considering >>> "sign-then-encrypt-then-authenticate", it provides two mutually exclusive >>> crypto layers (signature layer and authenticated encryption >>> layer) which in turns provides implementation flexibility as follows: >>> >>> Firmware update: >>> - Require both layers. >>> >>> Normal boot: >>> - DRM use-case, require both layers. >>> - Boot time optimization required, can use only authenticated encryption. >>> - Platform provides secure on-chip NVM and boot time optimization required, >>> can use only signature verification (or simply hash stored in secure on-chip >>> NVM memory). >>> >>> -Sumit >>> >>> >>> Thanks >>> Raghu >>> >>> >>> On January 26, 2020 at 10:34 PM, Sumit Garg <sumit.garg(a)linaro.org> wrote: >>> >>> >>> On Fri, 24 Jan 2020 at 16:36, Sumit Garg <sumit.garg(a)linaro.org> wrote: >>> >>> >>> >>> >>> On Fri, 24 Jan 2020 at 04:02, Raghupathy Krishnamurthy >>> >>> >>> <raghu.ncstate(a)icloud.com> wrote: >>> >>> >>>> >>> >>> >>>> I also just realized that both the TBBR and ARM PSA only talk about >>> encryption of the image, and not authenticated encryption. The guarantees >>> provided by both are completely different. Your >>> review(https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2495/) >>> talks about the requirement R060_TBBR_FUNCTION being implemented, which >>> is technically not true(and potentially misleading). We must make a note of this >>> difference and use the appropriate terminology, without mixing the two, in the >>> documentation, commit messages, source code comments and error prints. >>> The tool is also called 'encrypt_fw ' but should maybe be named appropriately >>> to indicate it is doing authenticated encryption. >>> >>> >>> >>> >>> I wouldn't call it misleading. Since firmware encryption feature >>> >>> >>> essentially provides confidentiality protection and authenticated >>> >>> >>> encryption is the type of crypto algorithm which we have used to >>> >>> >>> implement it. >>> >>> >>> >>> >>>> >>> >>> >>>> BTW, ARM PSA(file:///home/raghu/repos/fvp/DEN0072-PSA_TBFU_1-0- >>> REL.pdf) expects that the image manifest(X509 certificate) contain the hash of >>> the ENCRYPTED image(Table 2 and as described in my answer to your question >>> "How would this ensure integrity of ciphertext"). The TBBR spec completely >>> misses this fact, and is a crucial detail if we only implement encryption(as >>> opposed to authenticated encryption).Build_macros.mk, in your change, passes >>> the un-encrypted image to cert-tool. You can get away with it in your >>> implementation, since you are using authenticated encryption, not if you were >>> only implementing firmware encryption. >>> >>> >>> >>> >>> I have already highlighted the issue with signing the ciphertext in my >>> >>> >>> previous reply which deviates from security properties provided by >>> >>> >>> signature verification of plain firmware. So I think we need to >>> >>> >>> revisit ARM PSA TBFU spec. >>> >>> >>> >>> >>> >>> >>> In addition to this, there are implementation specific issues with "signing the >>> ciphertext" too. It simply makes the ciphertext immutable for device and >>> disallows meeting following firmware re-encryption requirement as per TBBR >>> spec: >>> >>> >>> R070_TBBR_PROTECTION. The Trusted boot firmware may do the binding of >>> software image updates at run- time by decrypting the updated SoC certificates >>> and software images using the OTP/Fuse Secret Symmetric Key (SSK), followed >>> by the re-encrypting these SoC certificates and software images using a >>> reproducible secret unique per device symmetric key (BSSK), and then updating >>> the ToC correspondingly. >>> >>> >>> Also, externally signing every firmware image encrypted with BSSK doesn't >>> seem scalable as well. It also hampers the case where encryption key is never >>> exposed out from device eg. encryption key is only accessible to hardware >>> crypto engine etc. >>> >>> >>> -Sumit >>> >>> >>> >>> >>>> >>> >>> >>>> Is it possible for somebody from ARM to have the TBBR spec updated to >>> reflect this? Also perhaps talk to the spec writers about incorporating >>> authenticated encryption into TBBR and PSA? This patch set is somewhat >>> trailblazing in this regard. >>> >>> >>>> >>> >>> >>>> -Raghu >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> On January 23, 2020 at 12:08 PM, Raghupathy Krishnamurthy via TF-A <tf- >>> a(a)lists.trustedfirmware.org> wrote: >>> >>> >>>> >>> >>> >>>> Hi Sumit, >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> Thanks for your response. >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> So firstly I would suggest you to revisit TBBR spec [1], >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> [RK] I'm very familiar with the TBBR spec and the requirements. Note >>>> that not all SoC's adhere perfectly to the TBBR spec, since it does >>>> not apply to devices in all market segments. However, these devices do >>>> use arm trusted firmware and TBBR CoT in a slightly modified form, >>>> which is still perfectly valid. Also, the TBBR spec can be changed if >>>> required :) >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> Why would one use authenticated decryption only to establish TBBR >>> >>> >>>> >>> >>> >>>> Chain of Trust providing device the capability to self sign its firmware? >>> >>> >>>> >>> >>> >>>> [RK] Fair point. However, you may have devices that don't have the >>> processing power or hardware budget or cost factors(paying for HSM's to store >>> private asymmetric keys), to implement asymmetric verification, in which case >>> using authenticated decryption to verify firmware authenticity and integrity is >>> perfectly valid. The attacks on devices that use symmetric keys to verify >>> firmware authenticity and integrity are usually related to exploiting firmware >>> flaws that leak the key or insiders leaking keys, but that is a different problem >>> and requires different solutions. Fundamentally, there is nothing wrong with >>> using symmetric keys for this purpose, so long as the key is well protected. Also >>> note, security requirements and guarantees are different for different systems. >>> The risk is taken by the system designer and should not be imposed by >>> framework code. I don't advocate doing this but it is an option that your >>> implementation does not provide(and perhaps rightly so). >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> How would this ensure integrity of ciphertext? >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> [RK] You sign the ciphertext. In your design, you pass bl31_enc.bin to >>> cert_tool to sign. You don't decrypt the encrypted cipher text until you have >>> verified the asymmetric signature(which provides integrity). As far as signature >>> verification is concerned, whether you sign the plain text or ciphertext is >>> immaterial, since you are simply verifying that the absolute bits you loaded >>> have not been modified(assuming you use a secure signature scheme). >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> Have a look at some defective sign and encrypt techniques here [2] >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> [RK] Again, very familiar with [2]. In the S/MIME case, you have multiple >>> parties. With secure boot, you have one party, effectively verifying its own >>> messages across time. There is only one key used to verify signatures. 1.1 and >>> 1.2 does not apply. Also you are encrypting and signing with completely >>> different keys and algorithms. Section 1.2 applies when you use RSA/El-gamal >>> encryption. Here you use symmetric encryption and asymmetric signing. >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> Why would one not use TBBR CoT here? >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> [RK] see above. Not all systems are designed equal. >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> and why would one like to hardcode in a device during >>> >>> >>>> >>> >>> >>>> provisioning to boot only either an encrypted or a plain firmware >>> >>> >>>> image? >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> [RK] Why would you not? You typically want to have the same security policy >>> for a class of devices and not be modifiable by an attacker. It isn't common for >>> the same class of devices to use encrypted firmware some times, and un- >>> encrypted firmware other times. If it is common, there is no problem with >>> setting the bit in the FIP header, as long as verified boot is mandatory. The only >>> concern(as my original email said) is the coupling of the FIP layer and the >>> crypto module, in the implementation. I still don't like that fact that the bit >>> saying the file is encrypted is not signed and this may require talking to the >>> TBBR spec writers. Page 22 of the TBBR spec calls out ToC as "Trusted Table of >>> Contents". The FIP header cannot be "trusted", if it is not in ROM or its integrity >>> is verified by some means! R010_TBBR_TOC should perhaps be mandatory >>> then. Also see R080_TBBR_TOC that says the TOC MUST be ROM'ed or tied by >>> hardware in readable registers. This requirement seems contradictory to >>> R010_TBBR_TOC, given that the FIP header(TOC) is copied from mutable NVM >>> by ROM or some boot stage and then ROM'd or loaded into registers. I may be >>> misunderstanding R080_TBBR_TOC, but i'd interpret it as the TOC(FIP header >>> in ATF implementation of TBBR) as being in ROM or integrity verified. >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> How would one handle a case where BL31 is in plain format and BL32 is in >>> encrypted format? >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> [RK]TBBR CoT is equipped to do this. The table is defined on a per image >>> basis. >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> If you are really paranoid about authentication of FIP header... >>> >>> >>>> >>> >>> >>>> [RK] I don't mean to pontificate but there are real world customers buying >>> real hardware, running ATF code, who care about such details and ask about >>> such things routinely. It is not just me being paranoid and is definitely not a >>> minor matter to think of such details. We should discuss more and consider the >>> implications of R080_TBBR_TOC and R010_TBBR_TOC, perhaps on a different >>> thread, without blocking your code review. Can somebody from ARM clarify >>> these requirements with the spec writers? >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> Thanks >>> >>> >>>> -Raghu >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> On January 23, 2020 at 12:38 AM, Sumit Garg <sumit.garg(a)linaro.org> >>> wrote: >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> Hi Raghu, >>> >>> >>>> >>> >>> >>>> I guess you have completely misunderstood this feature. This is an >>> >>> >>>> optional feature which allows to load encrypted FIP payloads using >>> >>> >>>> authenticated decryption which MUST be used along with signature >>> >>> >>>> verification (or TBBR CoT). >>> >>> >>>> >>> >>> >>>> So firstly I would suggest you to revisit TBBR spec [1], especially >>> >>> >>>> requirements: R040_TBBR_TOC, R060_TBBR_FUNCTION etc. >>> >>> >>>> >>> >>> >>>> On Thu, 23 Jan 2020 at 00:14, Raghupathy Krishnamurthy >>> >>> >>>> <raghu.ncstate(a)icloud.com> wrote: >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> Hello, >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> The patch stack looks good. The only comment i have is that the FIP layer has >>> now become security aware and supports authenticated decryption(only). This >>> is a deviation from the secure/signed/verified boot design, where we use the >>> TBBR COT to dictate the security operations on the file. This is nice, because >>> file IO is decoupled from the security policy. This may be a big deviation(i >>> apologize if this was considered and shot down for some other reason), but it >>> may be worthwhile to consider making authenticated decryption a part of the >>> authentication framework as opposed to coupling it with the FIP layer. >>> >>> >>>> >>> >>> >>>> It looks like you have mixed both TBBR CoT and this authenticated >>> >>> >>>> decryption feature. They both are completely different and rather >>> >>> >>>> complement each other where TBBR CoT establishes >>> >>> >>>> secure/signed/verified boot and this authenticated decryption feature >>> >>> >>>> provides confidentiality protection for FIP payloads. >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> At a high level, this would mean adding a new authentication >>> method(perhaps AUTH_METHOD_AUTHENTICATED_DECRYPTION), and having >>> the platform specify that the image is using authenticated encryption in the >>> TBBR COT. >>> >>> >>>> >>> >>> >>>> Why would one use authenticated decryption only to establish TBBR >>> >>> >>>> Chain of Trust providing device the capability to self sign its >>> >>> >>>> firmwares? We must use signature verification for TBBR CoT (see >>> >>> >>>> section: 2.1 Authentication of Code Images by Certificate in TBBR spec >>> >>> >>>> [1]). >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> The authentication framework is already well designed and well equipped to >>> handle these types of extensions. >>> >>> >>>> 1) This would make the change simpler, since you would not require changes >>> to the FIP tool and the FIP layer. >>> >>> >>>> 2) This would also allow for future cases where a platform may want to only >>> encrypt the file and use public key authentication on the encrypted file(for ex. >>> the soc does not have a crypto accelerator for aes-gcm but only for AES and >>> public key verification, for whatever reason). >>> >>> >>>> >>> >>> >>>> How would this ensure integrity of ciphertext? This approach may be >>> >>> >>>> vulnerable to Chosen Ciphertext Attacks (CCAs). Authentication tag as >>> >>> >>>> part of AES-GCM provides integrity protection for ciphertext. >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> 3) This would let you choose the order in which you want to do the >>> authenticated decryption(or just decryption) and signature verification, if you >>> use both, one or the other. >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> Have a look at some defective sign and encrypt techniques here [2]. >>> >>> >>>> The order can't be any arbitrary one, we need to be careful about >>> >>> >>>> this. >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> One other thing i'm not entirely comfortable with is that the flag indicating if >>> there are encrypted files or not in the FIP, is in the *unsigned* portion of the >>> FIP header. An attacker could simply flip bits that dictate security policy in the >>> header and avoid detection(in this case, the indication that the file needs >>> authenticated decryption). If a platform only uses authenticated encryption, but >>> not verified boot, an attacker could flip the bit in the FIP header and have any >>> image loaded on the platform. >>> >>> >>>> >>> >>> >>>> Why would one not use TBBR CoT here? >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> If authenticated encryption cannot be used without verified boot(which >>> requires build time flags), having a flag to indicate that there are encrypted >>> files in the FIP header is moot, since this can come at build time through the >>> TBBR COT. In any case, it seems like the security policy that firmware images >>> need to be decrypted or authenticated with authenticated decryption, seems >>> like a firmware build time or manufacturing time decision(perhaps a bit set in >>> the e-fuses). >>> >>> >>>> >>> >>> >>>> Again you are confusing TBBR CoT with authenticated decryption >>> >>> >>>> feature. And why would one like to hardcode in a device during >>> >>> >>>> provisioning to boot only either an encrypted or a plain firmware >>> >>> >>>> image? >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> There seems to be no benefit to having a flag in the FIP header. >>> >>> >>>> >>> >>> >>>> How would one handle a case where BL31 is in plain format and BL32 is >>> >>> >>>> in encrypted format? >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> Otherwise, I cant think of any attacks due to this and it may be completely >>> okay, but generally, consuming data that dictates security policy/operations >>> before verifying its integrity seems like a recipe for disaster. >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> If you are really paranoid about authentication of FIP header then you >>> >>> >>>> should look at implementing optional requirement: R010_TBBR_TOC as per >>> >>> >>>> TBBR spec [1]. >>> >>> >>>> >>> >>> >>>> [1] >>>> https://developer.arm.com/docs/den0006/latest/trusted-board-boot-requi >>>> rements-client-tbbr-client-armv8-a >>> >>> >>>> [2] http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html >>> >>> >>>> >>> >>> >>>> -Sumit >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> -Raghu >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> On January 22, 2020 at 3:51 AM, Sumit Garg via TF-A <tf- >>> a(a)lists.trustedfirmware.org> wrote: >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> Hi Sandrine, >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> On Wed, 22 Jan 2020 at 15:43, Sandrine Bailleux >>> >>> >>>> <Sandrine.Bailleux(a)arm.com> wrote: >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> Hello Sumit, >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> Thank you for reworking the patches and addressing all of my review >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> comments. I am happy with the latest version of these and consider >>>> them >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> ready to go. I plan to leave them in Gerrit for another week to give >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> extra time for other potential reviewers to have a look and comment. >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> Thanks for your review. >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> To everyone on the list: Please raise any concerns you may have about >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> these patches in the coming week. If I don't hear anything by 29th >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> January 2020, I will merge these patches. >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> @Sumit: One of the next actions for this patch stack would be to have >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> some level of testing in the CI system to detect any potential >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> regressions. We (at Arm) can quite easily add a few build tests but >>>> then >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> testing the software stack on QEMU is a bit more involved for various >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> reasons (first instance of QEMU testing, dependencies on OPTEE, UEFI, >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> ...) so this might have to wait for some time. >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> Okay, will wait for CI testing. >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> -Sumit >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> Regards, >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> Sandrine >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> -- >>> >>> >>>> TF-A mailing list >>> >>> >>>> TF-A(a)lists.trustedfirmware.org >>> >>> >>>> https://lists.trustedfirmware.org/mailman/listinfo/tf-a >>> >>> >>>> -- >>> >>> >>>> TF-A mailing list >>> >>> >>>> TF-A(a)lists.trustedfirmware.org >>> >>> >>>> https://lists.trustedfirmware.org/mailman/listinfo/tf-a >>> -- >>> TF-A mailing list >>> TF-A(a)lists.trustedfirmware.org >>> https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 3 months

1
0
0 0

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

by Soby Mathew

Adding back tf-a list, > Hi Everyone, > I have confirmation from the TBFU architect that both decrypt-then-verify and > verify-then-decrypt is acceptable and neither case affects boot integrity. So I > think the flexibility should be given to the platform to choose this. > > @Sumit Garg, could you please rework the patches as I mentioned in my > previous feedback and submit again? > > Best Regards > Soby Mathew > > > -----Original Message----- > > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of > > Raghupathy Krishnamurthy via TF-A > > Sent: 28 January 2020 14:58 > > To: Sumit Garg <sumit.garg(a)linaro.org> > > Cc: Daniel Thompson <daniel.thompson(a)linaro.org>; Miklos Balint > > <Miklos.Balint(a)arm.com>; Kiyoshi Owada <owada.kiyoshi(a)socionext.com>; > > tf- a(a)lists.trustedfirmware.org; Joakim Bech <joakim.bech(a)linaro.org>; > > nd <nd(a)arm.com>; Sandrine Bailleux <Sandrine.Bailleux(a)arm.com> > > Subject: Re: [TF-A] [RFC] New feature in TF-A to load encrypted FIP > > payloads > > > > Hi Sumit, > > > > > > I completely agree with you! All i'm asking for is that what you are > > proposing is ratified in the spec clearly, without any ambiguities and > > that we don't implement what we *think* is correct, but implement the > > spec. If the spec specifies encryption, we should implement > > encryption, not authenticated encryption. One is not a direct > > substitute for the other and requires careful thinking. Similarly, the > > order of signing, encryption, decryption and authentication must be > > specified and explained clearly, specifically to avoid these kinds of discussions. > > > > > > Thanks > > -Raghu > > > > On January 27, 2020 at 10:49 PM, Sumit Garg <sumit.garg(a)linaro.org> wrote: > > > > > > On Mon, 27 Jan 2020 at 22:54, Raghupathy Krishnamurthy > > <raghu.ncstate(a)icloud.com> wrote: > > > > > > > > Sumit, > > > > > > Great point. This perhaps needs to be added to the list of things that > > need clarification(Sandrine can you help with this too?) in the > > PSA-TBFU . I believe the answer to your concern lies in the PSA-TBFU > > in section 3.5, where it talks about optimizing the trusted boot > > process. To overcome the problem you're talking about, you would: > > 1) Verify asymmetric signature. > > 2) Decrypt firmware using SSK on successful signature verification. > > 3) Rekey the firmware using BSSK(or as the PSA specifies, a key > > derived from the HUK using a KDF). > > You will only verify the asymmetric signature on every firmware > > update, and use the rekeyed firmware(encrypted and mac;d with device > > specific key) on normal boot. > > > > > > > > Following is the quote from PSA-TBFU spec: > > > > "An implementation **can** optimize the trusted boot process at the > > expense of **simplicity**" > > > > It doesn't seems to be a recommended practice from spec. And > > especially for DRM use-cases, this approach is NOT recommended due to > > following concerns raised by DRM vendors (original concerns were with > > respect to TAs but will equally apply for firmware as well): > > - allows the device to self sign code authorized to run on the device. > > - increase the attack surface by having two different ways to load firmware. > > - allow a break once break forever situation, if you defeat the RSA > > 'install' once, no matter how hard it is, now your firmware is nicely > > transformed in a secure firmware and can be reused. > > > > Whereas on the other hand, considering > > "sign-then-encrypt-then-authenticate", it provides two mutually > > exclusive crypto layers (signature layer and authenticated encryption > > layer) which in turns provides implementation flexibility as follows: > > > > Firmware update: > > - Require both layers. > > > > Normal boot: > > - DRM use-case, require both layers. > > - Boot time optimization required, can use only authenticated encryption. > > - Platform provides secure on-chip NVM and boot time optimization > > required, can use only signature verification (or simply hash stored > > in secure on-chip NVM memory). > > > > -Sumit > > > > > > Thanks > > Raghu > > > > > > On January 26, 2020 at 10:34 PM, Sumit Garg <sumit.garg(a)linaro.org> wrote: > > > > > > On Fri, 24 Jan 2020 at 16:36, Sumit Garg <sumit.garg(a)linaro.org> wrote: > > > > > > > > > > On Fri, 24 Jan 2020 at 04:02, Raghupathy Krishnamurthy > > > > > > <raghu.ncstate(a)icloud.com> wrote: > > > > > > > > > > > > > > I also just realized that both the TBBR and ARM PSA only talk about > > encryption of the image, and not authenticated encryption. The > > guarantees provided by both are completely different. Your > > review(https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/ > > 2495/) talks about the requirement R060_TBBR_FUNCTION being > > implemented, which is technically not true(and potentially > > misleading). We must make a note of this difference and use the > > appropriate terminology, without mixing the two, in the documentation, > > commit messages, source code comments and error prints. > > The tool is also called 'encrypt_fw ' but should maybe be named > > appropriately to indicate it is doing authenticated encryption. > > > > > > > > > > I wouldn't call it misleading. Since firmware encryption feature > > > > > > essentially provides confidentiality protection and authenticated > > > > > > encryption is the type of crypto algorithm which we have used to > > > > > > implement it. > > > > > > > > > > > > > > > > > > BTW, ARM PSA(file:///home/raghu/repos/fvp/DEN0072-PSA_TBFU_1-0- > > REL.pdf) expects that the image manifest(X509 certificate) contain the > > hash of the ENCRYPTED image(Table 2 and as described in my answer to > > your question "How would this ensure integrity of ciphertext"). The > > TBBR spec completely misses this fact, and is a crucial detail if we > > only implement encryption(as opposed to authenticated > > encryption).Build_macros.mk, in your change, passes the un-encrypted > > image to cert-tool. You can get away with it in your implementation, > > since you are using authenticated encryption, not if you were only > implementing firmware encryption. > > > > > > > > > > I have already highlighted the issue with signing the ciphertext in my > > > > > > previous reply which deviates from security properties provided by > > > > > > signature verification of plain firmware. So I think we need to > > > > > > revisit ARM PSA TBFU spec. > > > > > > > > > > > > > > In addition to this, there are implementation specific issues with > > "signing the ciphertext" too. It simply makes the ciphertext immutable > > for device and disallows meeting following firmware re-encryption > > requirement as per TBBR > > spec: > > > > > > R070_TBBR_PROTECTION. The Trusted boot firmware may do the binding of > > software image updates at run- time by decrypting the updated SoC > > certificates and software images using the OTP/Fuse Secret Symmetric > > Key (SSK), followed by the re-encrypting these SoC certificates and > > software images using a reproducible secret unique per device > > symmetric key (BSSK), and then updating the ToC correspondingly. > > > > > > Also, externally signing every firmware image encrypted with BSSK > > doesn't seem scalable as well. It also hampers the case where > > encryption key is never exposed out from device eg. encryption key is > > only accessible to hardware crypto engine etc. > > > > > > -Sumit > > > > > > > > > > > > > > > > > > Is it possible for somebody from ARM to have the TBBR spec updated > > > to > > reflect this? Also perhaps talk to the spec writers about > > incorporating authenticated encryption into TBBR and PSA? This patch > > set is somewhat trailblazing in this regard. > > > > > > > > > > > > > > -Raghu > > > > > > > > > > > > > > > > > > > > > On January 23, 2020 at 12:08 PM, Raghupathy Krishnamurthy via TF-A > > > <tf- > > a(a)lists.trustedfirmware.org> wrote: > > > > > > > > > > > > > > Hi Sumit, > > > > > > > > > > > > > > > > > > > > > Thanks for your response. > > > > > > > > > > > > > > > > > > > > > So firstly I would suggest you to revisit TBBR spec [1], > > > > > > > > > > > > > > > > > > > > > > > > > > > > [RK] I'm very familiar with the TBBR spec and the requirements. Note > > > that not all SoC's adhere perfectly to the TBBR spec, since it does > > > not apply to devices in all market segments. However, these devices > > > do use arm trusted firmware and TBBR CoT in a slightly modified > > > form, which is still perfectly valid. Also, the TBBR spec can be > > > changed if required :) > > > > > > > > > > > > > > > > > > > > > Why would one use authenticated decryption only to establish TBBR > > > > > > > > > > > > > > Chain of Trust providing device the capability to self sign its firmware? > > > > > > > > > > > > > > [RK] Fair point. However, you may have devices that don't have the > > processing power or hardware budget or cost factors(paying for HSM's > > to store private asymmetric keys), to implement asymmetric > > verification, in which case using authenticated decryption to verify > > firmware authenticity and integrity is perfectly valid. The attacks on > > devices that use symmetric keys to verify firmware authenticity and > > integrity are usually related to exploiting firmware flaws that leak > > the key or insiders leaking keys, but that is a different problem and > > requires different solutions. Fundamentally, there is nothing wrong > > with using symmetric keys for this purpose, so long as the key is well > protected. Also note, security requirements and guarantees are different for > different systems. > > The risk is taken by the system designer and should not be imposed by > > framework code. I don't advocate doing this but it is an option that > > your implementation does not provide(and perhaps rightly so). > > > > > > > > > > > > > > > > > > > > > How would this ensure integrity of ciphertext? > > > > > > > > > > > > > > > > > > > > > > > > > > > > [RK] You sign the ciphertext. In your design, you pass bl31_enc.bin > > > to > > cert_tool to sign. You don't decrypt the encrypted cipher text until > > you have verified the asymmetric signature(which provides integrity). > > As far as signature verification is concerned, whether you sign the > > plain text or ciphertext is immaterial, since you are simply verifying > > that the absolute bits you loaded have not been modified(assuming you use a > secure signature scheme). > > > > > > > > > > > > > > > > > > > > > Have a look at some defective sign and encrypt techniques here [2] > > > > > > > > > > > > > > > > > > > > > > > > > > > > [RK] Again, very familiar with [2]. In the S/MIME case, you have > > > multiple > > parties. With secure boot, you have one party, effectively verifying > > its own messages across time. There is only one key used to verify > > signatures. 1.1 and > > 1.2 does not apply. Also you are encrypting and signing with > > completely different keys and algorithms. Section 1.2 applies when you > > use RSA/El-gamal encryption. Here you use symmetric encryption and > asymmetric signing. > > > > > > > > > > > > > > > > > > > > > Why would one not use TBBR CoT here? > > > > > > > > > > > > > > > > > > > > > > > > > > > > [RK] see above. Not all systems are designed equal. > > > > > > > > > > > > > > > > > > > > > > > > > > > > and why would one like to hardcode in a device during > > > > > > > > > > > > > > provisioning to boot only either an encrypted or a plain firmware > > > > > > > image? > > > > > > > > > > > > > > > > > > > > > [RK] Why would you not? You typically want to have the same security > > > policy > > for a class of devices and not be modifiable by an attacker. It isn't > > common for the same class of devices to use encrypted firmware some > > times, and un- encrypted firmware other times. If it is common, there > > is no problem with setting the bit in the FIP header, as long as > > verified boot is mandatory. The only concern(as my original email > > said) is the coupling of the FIP layer and the crypto module, in the > > implementation. I still don't like that fact that the bit saying the > > file is encrypted is not signed and this may require talking to the > > TBBR spec writers. Page 22 of the TBBR spec calls out ToC as "Trusted > > Table of Contents". The FIP header cannot be "trusted", if it is not > > in ROM or its integrity is verified by some means! R010_TBBR_TOC > > should perhaps be mandatory then. Also see R080_TBBR_TOC that says the > > TOC MUST be ROM'ed or tied by hardware in readable registers. This > > requirement seems contradictory to R010_TBBR_TOC, given that the FIP > > header(TOC) is copied from mutable NVM by ROM or some boot stage and > > then ROM'd or loaded into registers. I may be misunderstanding > R080_TBBR_TOC, but i'd interpret it as the TOC(FIP header in ATF > implementation of TBBR) as being in ROM or integrity verified. > > > > > > > > > > > > > > > > > > > > > How would one handle a case where BL31 is in plain format and BL32 > > > is in > > encrypted format? > > > > > > > > > > > > > > > > > > > > > > > > > > > > [RK]TBBR CoT is equipped to do this. The table is defined on a per > > > image > > basis. > > > > > > > > > > > > > > > > > > > > > If you are really paranoid about authentication of FIP header... > > > > > > > > > > > > > > [RK] I don't mean to pontificate but there are real world customers > > > buying > > real hardware, running ATF code, who care about such details and ask > > about such things routinely. It is not just me being paranoid and is > > definitely not a minor matter to think of such details. We should > > discuss more and consider the implications of R080_TBBR_TOC and > > R010_TBBR_TOC, perhaps on a different thread, without blocking your > > code review. Can somebody from ARM clarify these requirements with the > spec writers? > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > -Raghu > > > > > > > > > > > > > > > > > > > > > On January 23, 2020 at 12:38 AM, Sumit Garg <sumit.garg(a)linaro.org> > > wrote: > > > > > > > > > > > > > > > > > > > > > Hi Raghu, > > > > > > > > > > > > > > I guess you have completely misunderstood this feature. This is an > > > > > > > optional feature which allows to load encrypted FIP payloads using > > > > > > > authenticated decryption which MUST be used along with signature > > > > > > > verification (or TBBR CoT). > > > > > > > > > > > > > > So firstly I would suggest you to revisit TBBR spec [1], especially > > > > > > > requirements: R040_TBBR_TOC, R060_TBBR_FUNCTION etc. > > > > > > > > > > > > > > On Thu, 23 Jan 2020 at 00:14, Raghupathy Krishnamurthy > > > > > > > <raghu.ncstate(a)icloud.com> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > > > > > > > > > > The patch stack looks good. The only comment i have is that the FIP > > > layer has > > now become security aware and supports authenticated decryption(only). > > This is a deviation from the secure/signed/verified boot design, where > > we use the TBBR COT to dictate the security operations on the file. > > This is nice, because file IO is decoupled from the security policy. > > This may be a big deviation(i apologize if this was considered and > > shot down for some other reason), but it may be worthwhile to consider > > making authenticated decryption a part of the authentication framework as > opposed to coupling it with the FIP layer. > > > > > > > > > > > > > > It looks like you have mixed both TBBR CoT and this authenticated > > > > > > > decryption feature. They both are completely different and rather > > > > > > > complement each other where TBBR CoT establishes > > > > > > > secure/signed/verified boot and this authenticated decryption > > > feature > > > > > > > provides confidentiality protection for FIP payloads. > > > > > > > > > > > > > > > > > > > > > At a high level, this would mean adding a new authentication > > method(perhaps AUTH_METHOD_AUTHENTICATED_DECRYPTION), and > having the > > platform specify that the image is using authenticated encryption in > > the TBBR COT. > > > > > > > > > > > > > > Why would one use authenticated decryption only to establish TBBR > > > > > > > Chain of Trust providing device the capability to self sign its > > > > > > > firmwares? We must use signature verification for TBBR CoT (see > > > > > > > section: 2.1 Authentication of Code Images by Certificate in TBBR > > > spec > > > > > > > [1]). > > > > > > > > > > > > > > > > > > > > > The authentication framework is already well designed and well > > > equipped to > > handle these types of extensions. > > > > > > > 1) This would make the change simpler, since you would not require > > > changes > > to the FIP tool and the FIP layer. > > > > > > > 2) This would also allow for future cases where a platform may want > > > to only > > encrypt the file and use public key authentication on the encrypted file(for ex. > > the soc does not have a crypto accelerator for aes-gcm but only for > > AES and public key verification, for whatever reason). > > > > > > > > > > > > > > How would this ensure integrity of ciphertext? This approach may be > > > > > > > vulnerable to Chosen Ciphertext Attacks (CCAs). Authentication tag > > > as > > > > > > > part of AES-GCM provides integrity protection for ciphertext. > > > > > > > > > > > > > > > > > > > > > 3) This would let you choose the order in which you want to do the > > authenticated decryption(or just decryption) and signature > > verification, if you use both, one or the other. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Have a look at some defective sign and encrypt techniques here [2]. > > > > > > > The order can't be any arbitrary one, we need to be careful about > > > > > > > this. > > > > > > > > > > > > > > > > > > > > > One other thing i'm not entirely comfortable with is that the flag > > > indicating if > > there are encrypted files or not in the FIP, is in the *unsigned* > > portion of the FIP header. An attacker could simply flip bits that > > dictate security policy in the header and avoid detection(in this > > case, the indication that the file needs authenticated decryption). If > > a platform only uses authenticated encryption, but not verified boot, > > an attacker could flip the bit in the FIP header and have any image loaded on > the platform. > > > > > > > > > > > > > > Why would one not use TBBR CoT here? > > > > > > > > > > > > > > > > > > > > > If authenticated encryption cannot be used without verified > > > boot(which > > requires build time flags), having a flag to indicate that there are > > encrypted files in the FIP header is moot, since this can come at > > build time through the TBBR COT. In any case, it seems like the > > security policy that firmware images need to be decrypted or > > authenticated with authenticated decryption, seems like a firmware > > build time or manufacturing time decision(perhaps a bit set in the e-fuses). > > > > > > > > > > > > > > Again you are confusing TBBR CoT with authenticated decryption > > > > > > > feature. And why would one like to hardcode in a device during > > > > > > > provisioning to boot only either an encrypted or a plain firmware > > > > > > > image? > > > > > > > > > > > > > > > > > > > > > There seems to be no benefit to having a flag in the FIP header. > > > > > > > > > > > > > > How would one handle a case where BL31 is in plain format and BL32 > > > is > > > > > > > in encrypted format? > > > > > > > > > > > > > > > > > > > > > Otherwise, I cant think of any attacks due to this and it may be > > > completely > > okay, but generally, consuming data that dictates security > > policy/operations before verifying its integrity seems like a recipe for disaster. > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you are really paranoid about authentication of FIP header then > > > you > > > > > > > should look at implementing optional requirement: R010_TBBR_TOC as > > > per > > > > > > > TBBR spec [1]. > > > > > > > > > > > > > > [1] > > > https://developer.arm.com/docs/den0006/latest/trusted-board-boot-req > > > ui > > > rements-client-tbbr-client-armv8-a > > > > > > > [2] http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html > > > > > > > > > > > > > > -Sumit > > > > > > > > > > > > > > > > > > > > > -Raghu > > > > > > > > > > > > > > > > > > > > > On January 22, 2020 at 3:51 AM, Sumit Garg via TF-A <tf- > > a(a)lists.trustedfirmware.org> wrote: > > > > > > > > > > > > > > > > > > > > > Hi Sandrine, > > > > > > > > > > > > > > > > > > > > > On Wed, 22 Jan 2020 at 15:43, Sandrine Bailleux > > > > > > > <Sandrine.Bailleux(a)arm.com> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hello Sumit, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thank you for reworking the patches and addressing all of my review > > > > > > > > > > > > > > > > > > > > > comments. I am happy with the latest version of these and consider > > > them > > > > > > > > > > > > > > > > > > > > > ready to go. I plan to leave them in Gerrit for another week to give > > > > > > > > > > > > > > > > > > > > > extra time for other potential reviewers to have a look and comment. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks for your review. > > > > > > > > > > > > > > > > > > > > > To everyone on the list: Please raise any concerns you may have > > > about > > > > > > > > > > > > > > > > > > > > > these patches in the coming week. If I don't hear anything by 29th > > > > > > > > > > > > > > > > > > > > > January 2020, I will merge these patches. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > @Sumit: One of the next actions for this patch stack would be to > > > have > > > > > > > > > > > > > > > > > > > > > some level of testing in the CI system to detect any potential > > > > > > > > > > > > > > > > > > > > > regressions. We (at Arm) can quite easily add a few build tests but > > > then > > > > > > > > > > > > > > > > > > > > > testing the software stack on QEMU is a bit more involved for > > > various > > > > > > > > > > > > > > > > > > > > > reasons (first instance of QEMU testing, dependencies on OPTEE, > > > UEFI, > > > > > > > > > > > > > > > > > > > > > ...) so this might have to wait for some time. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Okay, will wait for CI testing. > > > > > > > > > > > > > > > > > > > > > -Sumit > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > > > > Sandrine > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > TF-A mailing list > > > > > > > TF-A(a)lists.trustedfirmware.org > > > > > > > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > > > > > > > -- > > > > > > > TF-A mailing list > > > > > > > TF-A(a)lists.trustedfirmware.org > > > > > > > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > > -- > > TF-A mailing list > > TF-A(a)lists.trustedfirmware.org > > https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 3 months

1
0
0 0

Re: [TF-A] Protecting Secure World Translation Tables

by Varun Wadekar

Thanks Raghu. I agree that this patch reduces the attack surface and would be a good addition, if we consider use cases where EL3 code runs in a silo. Since S-EL1 can contain any third party code, there is an opportunity to change memory contents without EL3 ever noticing the change. A hash for the RO page tables would improve this change immensely IMO. This change is not effective for platforms that use dynamic page tables e.g. Tegra platforms, so we won't be enabling it. But if other maintainers think this is a good addition to their platforms, I don’t have any objection. -----Original Message----- From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Raghu Krishnamurthy via TF-A Sent: Monday, February 17, 2020 4:16 PM To: tf-a(a)lists.trustedfirmware.org Subject: Re: [TF-A] Protecting Secure World Translation Tables External email: Use caution opening links or attachments I think it is worth implementing this to raise the bar for successful attacks. To Varun's point, in today's systems without S-EL2(<v8.4), it would be less effective as pointed out, since EL3 memory can be completely accessed by SEL1 and SEL1 code tends to have a larger code base on mobile devices(OPTEE, tlk etc). However, on systems with very thin SEL1 shims(typically servers), this would definitely raise the bar for attacks, since you effectively only have SEL0 and EL3. SEL1 cannot be exploited practically. For new SoCs with SEL2, this mitigation can still be very effective if we can ensure future SEL2 implementations have much smaller code bases and implements this mitigation itself. Effectively, i view SEL2 and EL3 as being equally privileged(it is no different than SEL1 because SEL2 can barf all over EL3 memory and TZ resources if exploited). SEL2 extensions, however, gives EL3 protection from SEL1 and can prevent SEL1 from accessing ALL TZ resources. If you view SEL2 and EL3 as equally privileged and view both together as a single entity, v8.4 systems effectively have EL3, SEL1, SEL0 AND the ability for EL3 to protect itself and other TZ resources from SEL1. In such a system, EL3(and SEL2) having this mitigation will definitely raise the bar for successful attacks. Also, the cost to implement this mitigation is relatively low for a fairly significant raise in the bar for successful attacks. PS - I say significantly raise the bar since an attacker will potentially require gadgets to modify TTBRx, invalidate TLB's, and enough gadgets in the code base to have a successful attack. If code in TF-A EL3 is fairly small, and code that writes to TTBR_EL3 can be in some section of the image that can be reclaimed/erased after initial setup, the attacker would have no gadget to modify TTBR_EL3, so there would be virtually no way to change TTBR_EL3. On a default build of FVP, there is a grand total of 1 instruction that writes to TTBR0_EL3 in enable_mmu_direct_el3. This might be a nice follow up change to this mitigation, if others think it is worth it. The same could be extended to other system registers that don't ever need to be changed(VBAR_EL3? SCTLR_EL3?). Thanks Raghu On 2/17/20 12:35 PM, Varun Wadekar via TF-A wrote: > Hello Petre, > > Thanks for the patch. Before I review the actual code, would like to understand how effective this patch will be and if you have seen a real world attack that this patch mitigates. > > AFAIU, the ARM architecture provides the TZ bit as the only protection to create "partitions" on a CPU core. So, potentially S-EL1 can access almost all TZ resources that EL3 can access. Thus, creating a silo inside EL3 exception mode is not an effective mitigation against any other TZ component writing to the physical memory where the page tables are stored. For the scope of this attack vector, are we assuming that the system cannot be compromised by attacking other TZ software components in the system? > > I feel until we have a way to distinguish between CPU realms (EL3 v S-EL2 v S-EL1) at the hardware bus level (ARM v9?), these mitigations are not that effective. > > Thoughts? > > -Varun > > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of > Petre-Ionut Tudor via TF-A > Sent: Monday, February 17, 2020 9:40 AM > To: tf-a(a)lists.trustedfirmware.org > Subject: [TF-A] Protecting Secure World Translation Tables > > External email: Use caution opening links or attachments > > > Hello Everyone, > > For quite some time I have been working on a security hardening feature that offers extra protection against tampering with the Secure world translation tables. An example would be using a gadget that can perform writes to arbitrary Secure memory locations to change memory attributes and/or the memory map. > > A real world exploit that uses read/write gadgets to tamper with translation tables can be found here: https://vimeo.com/335948808. If you only want the slide deck, it's available here: https://speakerdeck.com/hhj4ck/el3-tour-get-the-ultimate-privilege-of-andro…. > > A patch implementing this feature has been recently pushed upstream here: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3349. It extends v2 of the translation tables library with an API that can be called by a BL image any time after the initialization of the xlat tables to make them read-only. > > It would be great to hear your opinions about this, particularly whether or not it is a desirable feature to have in TF-A and what extra work needs to be done for it to meet the use cases that you consider most relevant. > > Best wishes > Petre > 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 > > ---------------------------------------------------------------------- > ------------- This email message is for the sole use of the intended > recipient(s) and may contain confidential information. Any > unauthorized review, use, disclosure or distribution is prohibited. > If you are not the intended recipient, please contact the sender by > reply email and destroy all copies of the original message. > ---------------------------------------------------------------------- > ------------- > -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 3 months

1
0
0 0

Re: [TF-A] Protecting Secure World Translation Tables

by Raghu Krishnamurthy

I think it is worth implementing this to raise the bar for successful attacks. To Varun's point, in today's systems without S-EL2(<v8.4), it would be less effective as pointed out, since EL3 memory can be completely accessed by SEL1 and SEL1 code tends to have a larger code base on mobile devices(OPTEE, tlk etc). However, on systems with very thin SEL1 shims(typically servers), this would definitely raise the bar for attacks, since you effectively only have SEL0 and EL3. SEL1 cannot be exploited practically. For new SoCs with SEL2, this mitigation can still be very effective if we can ensure future SEL2 implementations have much smaller code bases and implements this mitigation itself. Effectively, i view SEL2 and EL3 as being equally privileged(it is no different than SEL1 because SEL2 can barf all over EL3 memory and TZ resources if exploited). SEL2 extensions, however, gives EL3 protection from SEL1 and can prevent SEL1 from accessing ALL TZ resources. If you view SEL2 and EL3 as equally privileged and view both together as a single entity, v8.4 systems effectively have EL3, SEL1, SEL0 AND the ability for EL3 to protect itself and other TZ resources from SEL1. In such a system, EL3(and SEL2) having this mitigation will definitely raise the bar for successful attacks. Also, the cost to implement this mitigation is relatively low for a fairly significant raise in the bar for successful attacks. PS - I say significantly raise the bar since an attacker will potentially require gadgets to modify TTBRx, invalidate TLB's, and enough gadgets in the code base to have a successful attack. If code in TF-A EL3 is fairly small, and code that writes to TTBR_EL3 can be in some section of the image that can be reclaimed/erased after initial setup, the attacker would have no gadget to modify TTBR_EL3, so there would be virtually no way to change TTBR_EL3. On a default build of FVP, there is a grand total of 1 instruction that writes to TTBR0_EL3 in enable_mmu_direct_el3. This might be a nice follow up change to this mitigation, if others think it is worth it. The same could be extended to other system registers that don't ever need to be changed(VBAR_EL3? SCTLR_EL3?). Thanks Raghu On 2/17/20 12:35 PM, Varun Wadekar via TF-A wrote: > Hello Petre, > > Thanks for the patch. Before I review the actual code, would like to understand how effective this patch will be and if you have seen a real world attack that this patch mitigates. > > AFAIU, the ARM architecture provides the TZ bit as the only protection to create "partitions" on a CPU core. So, potentially S-EL1 can access almost all TZ resources that EL3 can access. Thus, creating a silo inside EL3 exception mode is not an effective mitigation against any other TZ component writing to the physical memory where the page tables are stored. For the scope of this attack vector, are we assuming that the system cannot be compromised by attacking other TZ software components in the system? > > I feel until we have a way to distinguish between CPU realms (EL3 v S-EL2 v S-EL1) at the hardware bus level (ARM v9?), these mitigations are not that effective. > > Thoughts? > > -Varun > > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Petre-Ionut Tudor via TF-A > Sent: Monday, February 17, 2020 9:40 AM > To: tf-a(a)lists.trustedfirmware.org > Subject: [TF-A] Protecting Secure World Translation Tables > > External email: Use caution opening links or attachments > > > Hello Everyone, > > For quite some time I have been working on a security hardening feature that offers extra protection against tampering with the Secure world translation tables. An example would be using a gadget that can perform writes to arbitrary Secure memory locations to change memory attributes and/or the memory map. > > A real world exploit that uses read/write gadgets to tamper with translation tables can be found here: https://vimeo.com/335948808. If you only want the slide deck, it's available here: https://speakerdeck.com/hhj4ck/el3-tour-get-the-ultimate-privilege-of-andro…. > > A patch implementing this feature has been recently pushed upstream here: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3349. It extends v2 of the translation tables library with an API that can be called by a BL image any time after the initialization of the xlat tables to make them read-only. > > It would be great to hear your opinions about this, particularly whether or not it is a desirable feature to have in TF-A and what extra work needs to be done for it to meet the use cases that you consider most relevant. > > Best wishes > Petre > 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 > > ----------------------------------------------------------------------------------- > This email message is for the sole use of the intended recipient(s) and may contain > confidential information. Any unauthorized review, use, disclosure or distribution > is prohibited. If you are not the intended recipient, please contact the sender by > reply email and destroy all copies of the original message. > ----------------------------------------------------------------------------------- >

5 years, 3 months

1
0
0 0

Protecting Secure World Translation Tables

by Petre-Ionut Tudor

Hello Everyone, For quite some time I have been working on a security hardening feature that offers extra protection against tampering with the Secure world translation tables. An example would be using a gadget that can perform writes to arbitrary Secure memory locations to change memory attributes and/or the memory map. A real world exploit that uses read/write gadgets to tamper with translation tables can be found here: https://vimeo.com/335948808. If you only want the slide deck, it's available here: https://speakerdeck.com/hhj4ck/el3-tour-get-the-ultimate-privilege-of-andro…. A patch implementing this feature has been recently pushed upstream here: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3349. It extends v2 of the translation tables library with an API that can be called by a BL image any time after the initialization of the xlat tables to make them read-only. It would be great to hear your opinions about this, particularly whether or not it is a desirable feature to have in TF-A and what extra work needs to be done for it to meet the use cases that you consider most relevant. Best wishes Petre 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.

5 years, 3 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. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 354061: Memory - illegal accesses (OVERRUN) /plat/amlogic/axg/axg_pm.c: 124 in axg_pwr_domain_off() ________________________________________________________________________________________________________ *** CID 354061: Memory - illegal accesses (OVERRUN) /plat/amlogic/axg/axg_pm.c: 124 in axg_pwr_domain_off() 118 PLAT_LOCAL_STATE_OFF); 119 120 axg_pm_reset(mpidr, -1); 121 122 gicv2_cpuif_disable(); 123 >>> CID 354061: Memory - illegal accesses (OVERRUN) >>> Overrunning array "target_state->pwr_domain_state" of 2 bytes at byte offset 2 using index "2ULL". 124 if (target_state->pwr_domain_state[MPIDR_AFFLVL2] == 125 PLAT_LOCAL_STATE_OFF) 126 system_state = SCPI_POWER_OFF; 127 128 if (target_state->pwr_domain_state[MPIDR_AFFLVL1] == 129 PLAT_LOCAL_STATE_OFF) ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/ls/click?upn=nJaKvJSIH-2FPAfmty-2BK5tYpPkl…

5 years, 3 months

1
0
0 0

TF-A on iMX8M Mini

by Iñigo Vicente Waliño

Hi, I am using an iMX8M mini, I have flashed the image with uuu.auto of L4.14.98_2.0.0_ga_images_MX8MMEVK and I have a Linux image with OP-TEE. Now I want to use TF-A but I don't know the steps to continue. I am reading this document ( https://source.codeaurora.org/external/imx/uboot-imx/tree/doc/imx/habv4/gui… and https : //trustedfirmware-a.readthedocs.io/en/latest/plat/imx8m.html <https://trustedfirmware-a.readthedocs.io/en/latest/plat/imx8m.html>) but I don't know how to get these files: u-boot.bin, u-boot-nodtb.bin, u-boot-spl.bin , DTB U-Boot file (for example, fsl-imx8mq-evk.dtb). Can anyone tell me the steps to follow? Thanks, best regards Iñigo.

5 years, 3 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. 2 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 2 of 2 defect(s) ** CID 354003: Integer handling issues (NO_EFFECT) /drivers/arm/css/scp/css_pm_scmi.c: 228 in css_scp_on() ________________________________________________________________________________________________________ *** CID 354003: Integer handling issues (NO_EFFECT) /drivers/arm/css/scp/css_pm_scmi.c: 228 in css_scp_on() 222 SCMI_SET_PWR_STATE_LVL(scmi_pwr_state, lvl, 223 scmi_power_state_on); 224 225 SCMI_SET_PWR_STATE_MAX_PWR_LVL(scmi_pwr_state, lvl - 1); 226 227 core_pos = plat_core_pos_by_mpidr(mpidr); >>> CID 354003: Integer handling issues (NO_EFFECT) >>> This greater-than-or-equal-to-zero comparison of an unsigned value is always true. "core_pos >= 0U". 228 assert(core_pos >= 0 && (core_pos < PLATFORM_CORE_COUNT)); 229 230 css_scp_core_pos_to_scmi_channel(core_pos, &domain_id, 231 &channel_id); 232 ret = scmi_pwr_state_set(scmi_handles[channel_id], 233 domain_id, scmi_pwr_state); ** CID 354002: Memory - corruptions (OVERRUN) /plat/arm/css/sgi/sgi_bl31_setup.c: 80 in plat_css_get_scmi_info() ________________________________________________________________________________________________________ *** CID 354002: Memory - corruptions (OVERRUN) /plat/arm/css/sgi/sgi_bl31_setup.c: 80 in plat_css_get_scmi_info() 74 scmi_channel_plat_info_t *plat_css_get_scmi_info(int channel_id) 75 { 76 if (sgi_plat_info.platform_id == RD_N1E1_EDGE_SID_VER_PART_NUM || 77 sgi_plat_info.platform_id == RD_DANIEL_SID_VER_PART_NUM) { 78 if (channel_id >= sizeof(rd_n1e1_edge_scmi_plat_info)) 79 panic(); >>> CID 354002: Memory - corruptions (OVERRUN) >>> "&rd_n1e1_edge_scmi_plat_info[channel_id]" evaluates to an address that is at byte offset 1560 of an array of 40 bytes. 80 return &rd_n1e1_edge_scmi_plat_info[channel_id]; 81 } 82 else if (sgi_plat_info.platform_id == SGI575_SSC_VER_PART_NUM) 83 return &sgi575_scmi_plat_info; 84 else 85 panic(); ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/ls/click?upn=nJaKvJSIH-2FPAfmty-2BK5tYpPkl…

5 years, 3 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. 2 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 2 of 2 defect(s) ** CID 353989: Integer handling issues (INCOMPATIBLE_CAST) ________________________________________________________________________________________________________ *** CID 353989: Integer handling issues (INCOMPATIBLE_CAST) /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 353989: Integer handling issues (INCOMPATIBLE_CAST) >>> Pointer "&intel_rsu_update_address" points to an object whose effective type is "unsigned long long" (64 bits, unsigned) but is dereferenced as a narrower "unsigned int" (32 bits, unsigned). This may lead to unexpected results depending on machine endianness. 138 mailbox_rsu_update((uint32_t *)&intel_rsu_update_address); 139 else 140 mailbox_reset_cold(); 141 142 while (1) 143 wfi(); ** CID 353988: Integer handling issues (INCOMPATIBLE_CAST) ________________________________________________________________________________________________________ *** CID 353988: Integer handling issues (INCOMPATIBLE_CAST) /plat/intel/soc/common/socfpga_sip_svc.c: 526 in sip_smc_handler() 520 521 case INTEL_SIP_SMC_RSU_NOTIFY: 522 status = intel_rsu_notify(x1); 523 SMC_RET1(handle, status); 524 525 case INTEL_SIP_SMC_RSU_RETRY_COUNTER: >>> CID 353988: Integer handling issues (INCOMPATIBLE_CAST) >>> Pointer "rsu_respbuf" points to an object whose effective type is "unsigned long long" (64 bits, unsigned) but is dereferenced as a narrower "unsigned int" (32 bits, unsigned). This may lead to unexpected results depending on machine endianness. 526 status = intel_rsu_retry_counter((uint32_t *)rsu_respbuf, 527 ARRAY_SIZE(rsu_respbuf), &val); 528 if (status) { 529 SMC_RET1(handle, status); 530 } else { 531 SMC_RET2(handle, status, val); ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/ls/click?upn=nJaKvJSIH-2FPAfmty-2BK5tYpPkl…

5 years, 3 months

1
0
0 0

FIP header flags available for feature selection

by Scott Branden

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

5 years, 3 months

1
0
0 0

Re: [TF-A] [EXT] RE: Issue with addition of NXP Platform support on TFA v2.2

by Alexei Fedorov

Hi Pankaj, Would it be possible to provide more information on your platform (what CPU, its revision, number of clusters/CPUs per cluster, etc.)? Is your platform code publically available? Regards. Alexei ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Pankaj Gupta via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 07 February 2020 10:57 To: Olivier Deprez <Olivier.Deprez(a)arm.com> Cc: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org>; nd <nd(a)arm.com> Subject: Re: [TF-A] [EXT] RE: Issue with addition of NXP Platform support on TFA v2.2 Hi, Please find the comments in-line. Regards Pankaj -----Original Message----- From: Olivier Deprez <Olivier.Deprez(a)arm.com> Sent: Wednesday, February 5, 2020 6:54 PM To: Pankaj Gupta <pankaj.gupta(a)nxp.com> Cc: nd <nd(a)arm.com>; tf-a(a)lists.trustedfirmware.org Subject: [EXT] RE: Issue with addition of NXP Platform support on TFA v2.2 >Caution: EXT Email >Hi Pankaj, >Can you pls provide a bit more background: >Which boot stage (BL1/BL2/BL31...) get affected? BL2 >Is there any crash report to console? No. But, using the external debugger, it is found that core gets to non-responding. >Is this an aarch64/or aarch32 platform? aarch64 >There can be different root causes to this e.g. >1. a stale translation in TLB, or a dirty cache line remnant from earlier boot stages. If this is the case, it would need invalidating TLB and/or caches on BL entry. >2. the empty table ptr given by xlat_table_get_empty is pointing nowhere sensible because of this specific platform layout >There are multiple calls to xlat_clean_dcache_range in this file, do you confirm the crash happen within xlat_tables_map_region? Yes. Basis of saying 'yes' is: if this function is commented, the BL2 comes up successfully. Flow in the code base is : mmap_add_dynamic_region -> mmap_add_dynamic_region_ctx -> xlat_tables_map_region-> xlat_table_get_empty //....issue is seen. >Can you try one or both statements below after the call to xlat_table_get_empty (and uncomment calls to clean_dcache_range): > > inv_dcache_range((uintptr_t)subtable, XLAT_TABLE_SIZE); > > xlat_arch_tlbi_va((uintptr_t)subtable, ctx->xlat_regime); > xlat_arch_tlbi_va_sync(); mmap_add_dynamic_region -> mmap_add_dynamic_region_ctx -> xlat_tables_map_region-> xlat_table_get_empty-> xlat_arch_tlbi_va //issue is resolved. The root cause of this issue is race condition. Please correct me if I am wrong. Another observation: mmap_add_dynamic_region -> mmap_add_dynamic_region_ctx (Putting console debug logs in this function)-> xlat_tables_map_region-> xlat_table_get_empty //issue is resolved. Please share your view for this observation as well. Regards, Olivier. -----Original Message----- From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Pankaj Gupta via TF-A Sent: 05 February 2020 11:45 To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] Issue with addition of NXP Platform support on TFA v2.2 Hi, In the TFA v2.2 code base, the file "lib/xlat_tables_v2/xlat_tables_core.c" has the implementation for function "xlat_tables_map_region()". The implementation for this function is changed in TFAv2.2 (compared TFAv1.5), with addition of function "xlat_clean_dcache_range()". Due to this addition, my earlier* working platform on TFAv1.5, is hanging here. If the function call for the function "xlat_clean_dcache_range()", is comment, then the platform works well. Code snippet: static inline __attribute__((unused)) void xlat_clean_dcache_range(uintptr_t addr, size_t size) { if (is_dcache_enabled()) clean_dcache_range(addr, size); // On commenting this line, my platform works fine with TFAv2.2 } Please share your views on what could I be missing here. Thanks. Regards Pankaj *Earlier raised patch for this platform was not merged due to review comments are not disposed-off in time; and TF-A got migrated from github to gerrit. -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- 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.

5 years, 3 months

1
0
0 0

Re: [TF-A] Issue with addition of NXP Platform support on TFA v2.2

by Olivier Deprez

Hi Pankaj, Can you pls provide a bit more background: Which boot stage (BL1/BL2/BL31...) get affected? Is there any crash report to console? Is this an aarch64/or aarch32 platform? There can be different root causes to this e.g. 1. a stale translation in TLB, or a dirty cache line remnant from earlier boot stages. If this is the case, it would need invalidating TLB and/or caches on BL entry. 2. the empty table ptr given by xlat_table_get_empty is pointing nowhere sensible because of this specific platform layout There are multiple calls to xlat_clean_dcache_range in this file, do you confirm the crash happen within xlat_tables_map_region? Can you try one or both statements below after the call to xlat_table_get_empty (and uncomment calls to clean_dcache_range): inv_dcache_range((uintptr_t)subtable, XLAT_TABLE_SIZE); xlat_arch_tlbi_va((uintptr_t)subtable, ctx->xlat_regime); xlat_arch_tlbi_va_sync(); Regards, Olivier. -----Original Message----- From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Pankaj Gupta via TF-A Sent: 05 February 2020 11:45 To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] Issue with addition of NXP Platform support on TFA v2.2 Hi, In the TFA v2.2 code base, the file "lib/xlat_tables_v2/xlat_tables_core.c" has the implementation for function "xlat_tables_map_region()". The implementation for this function is changed in TFAv2.2 (compared TFAv1.5), with addition of function "xlat_clean_dcache_range()". Due to this addition, my earlier* working platform on TFAv1.5, is hanging here. If the function call for the function "xlat_clean_dcache_range()", is comment, then the platform works well. Code snippet: static inline __attribute__((unused)) void xlat_clean_dcache_range(uintptr_t addr, size_t size) { if (is_dcache_enabled()) clean_dcache_range(addr, size); // On commenting this line, my platform works fine with TFAv2.2 } Please share your views on what could I be missing here. Thanks. Regards Pankaj *Earlier raised patch for this platform was not merged due to review comments are not disposed-off in time; and TF-A got migrated from github to gerrit. -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 3 months

2
1
0 0

Re: [TF-A] CI status update - end to end boot testing on Juno

by Matteo Carlini

Hi Fathi, Thanks for the below write-up, this is really great news! > Note: this is in silent mode (links to the build job are currently disabled, > and will be re-enableb today). Please go ahead in re-enabling those jobs, so that people can see the results of the build jobs (while we work on propagating back to Gerrit also the results of the LAVA boot jobs). Thanks Matteo > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Fathi > Boudra via TF-A > Sent: 05 February 2020 12:45 > To: TF-A(a)lists.trustedfirmware.org > Cc: Ryan Arnold <ryan.arnold(a)linaro.org> > Subject: [TF-A] CI status update - end to end boot testing on Juno > > Hi, > > The end-to-end testing prototype is now completed and enabled. > This encompases an end-to-end testing pipeline whereby TF-A code > submission to gerrit results in a TF build (based on the code submission) > being injected into a file system (recovery image) and booted on a Juno > device in the Linaro TF LAVA instance with the results of the boot test > available in the LAVA instance. > > Here's the explanation of the CI pipeline: > 1. Trigger - capture gerrit events: > https://ci.trustedfirmware.org/job/trigger-tf-a-builder/ > All changes made to the trusted-firmware A repository are captured by > the trigger event and result in a build. > e.g., triggering commit: > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3100 > Note: this is in silent mode (links to the build job are currently disabled, > and will be re-enableb today). > 2. Build Binary Artifacts - Binary artifacts built via: > https://ci.trustedfirmware.org/job/tf-a-builder/ > e.g., https://ci.trustedfirmware.org/job/tf-a-builder/631/ > (with a link to the accompanying LAVA job and a link to the trigger job in > gerrit) 3. Recovery/Flash submission to LAVA - Used to flash the binary to the > board: > https://ci.trustedfirmware.org/job/post-build-lava/ > 4. LAVA tests results > e.g., Specific example of the template applied to a specific build > (631 above) > https://tf.validation.linaro.org/scheduler/job/895/definition > Results: https://tf.validation.linaro.org/results/895 > Link to all jobs: https://tf.validation.linaro.org/scheduler/alljobs > > Some additional information: > * tf-a-ci-scripts git repository has been set up and contains the CI scripts for > TF-A. > https://git.trustedfirmware.org/ci/tf-a-ci-scripts.git/ > * tf-a-job-configs git repository has been set up and contains the Jenkins jobs > configurations automatically deployed on https://ci.trustedfirmware.org > Jenkins instance. > https://git.trustedfirmware.org/ci/tf-a-job-configs.git/ > > Cheers, > -- > Fathi Boudra > Linaro.org | Open source software for ARM SoCs > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 3 months

1
0
0 0

CI status update - end to end boot testing on Juno

by Fathi Boudra

Hi, The end-to-end testing prototype is now completed and enabled. This encompases an end-to-end testing pipeline whereby TF-A code submission to gerrit results in a TF build (based on the code submission) being injected into a file system (recovery image) and booted on a Juno device in the Linaro TF LAVA instance with the results of the boot test available in the LAVA instance. Here's the explanation of the CI pipeline: 1. Trigger - capture gerrit events: https://ci.trustedfirmware.org/job/trigger-tf-a-builder/ All changes made to the trusted-firmware A repository are captured by the trigger event and result in a build. e.g., triggering commit: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3100 Note: this is in silent mode (links to the build job are currently disabled, and will be re-enableb today). 2. Build Binary Artifacts - Binary artifacts built via: https://ci.trustedfirmware.org/job/tf-a-builder/ e.g., https://ci.trustedfirmware.org/job/tf-a-builder/631/ (with a link to the accompanying LAVA job and a link to the trigger job in gerrit) 3. Recovery/Flash submission to LAVA - Used to flash the binary to the board: https://ci.trustedfirmware.org/job/post-build-lava/ 4. LAVA tests results e.g., Specific example of the template applied to a specific build (631 above) https://tf.validation.linaro.org/scheduler/job/895/definition Results: https://tf.validation.linaro.org/results/895 Link to all jobs: https://tf.validation.linaro.org/scheduler/alljobs Some additional information: * tf-a-ci-scripts git repository has been set up and contains the CI scripts for TF-A. https://git.trustedfirmware.org/ci/tf-a-ci-scripts.git/ * tf-a-job-configs git repository has been set up and contains the Jenkins jobs configurations automatically deployed on https://ci.trustedfirmware.org Jenkins instance. https://git.trustedfirmware.org/ci/tf-a-job-configs.git/ Cheers, -- Fathi Boudra Linaro.org | Open source software for ARM SoCs

5 years, 3 months

1
0
0 0

Issue with addition of NXP Platform support on TFA v2.2

by Pankaj Gupta

Hi, In the TFA v2.2 code base, the file "lib/xlat_tables_v2/xlat_tables_core.c" has the implementation for function "xlat_tables_map_region()". The implementation for this function is changed in TFAv2.2 (compared TFAv1.5), with addition of function "xlat_clean_dcache_range()". Due to this addition, my earlier* working platform on TFAv1.5, is hanging here. If the function call for the function "xlat_clean_dcache_range()", is comment, then the platform works well. Code snippet: static inline __attribute__((unused)) void xlat_clean_dcache_range(uintptr_t addr, size_t size) { if (is_dcache_enabled()) clean_dcache_range(addr, size); // On commenting this line, my platform works fine with TFAv2.2 } Please share your views on what could I be missing here. Thanks. Regards Pankaj *Earlier raised patch for this platform was not merged due to review comments are not disposed-off in time; and TF-A got migrated from github to gerrit.

5 years, 3 months

1
0
0 0

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

by Sandrine Bailleux

Hi all, On Tue, 2020-01-28 at 14:57 +0000, Raghupathy Krishnamurthy via TF-A wrote: > I completely agree with you! All i'm asking for is that what you are > proposing is ratified in the spec clearly, without any ambiguities > and that we don't implement what we *think* is correct, but implement > the spec. If the spec specifies encryption, we should implement > encryption, not authenticated encryption. One is not a direct > substitute for the other and requires careful thinking. Similarly, > the order of signing, encryption, decryption and authentication must > be specified and explained clearly, specifically to avoid these kinds > of discussions. Just to keep everyone in the loop, we are currently having some internal discussions within Arm about TBBR/TBFU and all the questions/concerns that have been raised in this thread. I will update you ASAP. Best regards, Sandrine

5 years, 3 months

1
0
0 0

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

by Raghupathy Krishnamurthy

Hi Sumit, I completely agree with you! All i'm asking for is that what you are proposing is ratified in the spec clearly, without any ambiguities and that we don't implement what we *think* is correct, but implement the spec. If the spec specifies encryption, we should implement encryption, not authenticated encryption. One is not a direct substitute for the other and requires careful thinking. Similarly, the order of signing, encryption, decryption and authentication must be specified and explained clearly, specifically to avoid these kinds of discussions. Thanks -Raghu On January 27, 2020 at 10:49 PM, Sumit Garg <sumit.garg(a)linaro.org> wrote: On Mon, 27 Jan 2020 at 22:54, Raghupathy Krishnamurthy <raghu.ncstate(a)icloud.com> wrote: Sumit, Great point. This perhaps needs to be added to the list of things that need clarification(Sandrine can you help with this too?) in the PSA-TBFU . I believe the answer to your concern lies in the PSA-TBFU in section 3.5, where it talks about optimizing the trusted boot process. To overcome the problem you're talking about, you would: 1) Verify asymmetric signature. 2) Decrypt firmware using SSK on successful signature verification. 3) Rekey the firmware using BSSK(or as the PSA specifies, a key derived from the HUK using a KDF). You will only verify the asymmetric signature on every firmware update, and use the rekeyed firmware(encrypted and mac;d with device specific key) on normal boot. Following is the quote from PSA-TBFU spec: "An implementation **can** optimize the trusted boot process at the expense of **simplicity**" It doesn't seems to be a recommended practice from spec. And especially for DRM use-cases, this approach is NOT recommended due to following concerns raised by DRM vendors (original concerns were with respect to TAs but will equally apply for firmware as well): - allows the device to self sign code authorized to run on the device. - increase the attack surface by having two different ways to load firmware. - allow a break once break forever situation, if you defeat the RSA 'install' once, no matter how hard it is, now your firmware is nicely transformed in a secure firmware and can be reused. Whereas on the other hand, considering "sign-then-encrypt-then-authenticate", it provides two mutually exclusive crypto layers (signature layer and authenticated encryption layer) which in turns provides implementation flexibility as follows: Firmware update: - Require both layers. Normal boot: - DRM use-case, require both layers. - Boot time optimization required, can use only authenticated encryption. - Platform provides secure on-chip NVM and boot time optimization required, can use only signature verification (or simply hash stored in secure on-chip NVM memory). -Sumit Thanks Raghu On January 26, 2020 at 10:34 PM, Sumit Garg <sumit.garg(a)linaro.org> wrote: On Fri, 24 Jan 2020 at 16:36, Sumit Garg <sumit.garg(a)linaro.org> wrote: On Fri, 24 Jan 2020 at 04:02, Raghupathy Krishnamurthy <raghu.ncstate(a)icloud.com> wrote: > > I also just realized that both the TBBR and ARM PSA only talk about encryption of the image, and not authenticated encryption. The guarantees provided by both are completely different. Your review(https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2495/) talks about the requirement R060_TBBR_FUNCTION being implemented, which is technically not true(and potentially misleading). We must make a note of this difference and use the appropriate terminology, without mixing the two, in the documentation, commit messages, source code comments and error prints. The tool is also called 'encrypt_fw ' but should maybe be named appropriately to indicate it is doing authenticated encryption. I wouldn't call it misleading. Since firmware encryption feature essentially provides confidentiality protection and authenticated encryption is the type of crypto algorithm which we have used to implement it. > > BTW, ARM PSA(file:///home/raghu/repos/fvp/DEN0072-PSA_TBFU_1-0-REL.pdf) expects that the image manifest(X509 certificate) contain the hash of the ENCRYPTED image(Table 2 and as described in my answer to your question "How would this ensure integrity of ciphertext"). The TBBR spec completely misses this fact, and is a crucial detail if we only implement encryption(as opposed to authenticated encryption).Build_macros.mk, in your change, passes the un-encrypted image to cert-tool. You can get away with it in your implementation, since you are using authenticated encryption, not if you were only implementing firmware encryption. I have already highlighted the issue with signing the ciphertext in my previous reply which deviates from security properties provided by signature verification of plain firmware. So I think we need to revisit ARM PSA TBFU spec. In addition to this, there are implementation specific issues with "signing the ciphertext" too. It simply makes the ciphertext immutable for device and disallows meeting following firmware re-encryption requirement as per TBBR spec: R070_TBBR_PROTECTION. The Trusted boot firmware may do the binding of software image updates at run- time by decrypting the updated SoC certificates and software images using the OTP/Fuse Secret Symmetric Key (SSK), followed by the re-encrypting these SoC certificates and software images using a reproducible secret unique per device symmetric key (BSSK), and then updating the ToC correspondingly. Also, externally signing every firmware image encrypted with BSSK doesn't seem scalable as well. It also hampers the case where encryption key is never exposed out from device eg. encryption key is only accessible to hardware crypto engine etc. -Sumit > > Is it possible for somebody from ARM to have the TBBR spec updated to reflect this? Also perhaps talk to the spec writers about incorporating authenticated encryption into TBBR and PSA? This patch set is somewhat trailblazing in this regard. > > -Raghu > > > On January 23, 2020 at 12:08 PM, Raghupathy Krishnamurthy via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: > > Hi Sumit, > > > Thanks for your response. > > > So firstly I would suggest you to revisit TBBR spec [1], > > > > [RK] I'm very familiar with the TBBR spec and the requirements. Note that not all SoC's adhere perfectly to the TBBR spec, since it does not apply to devices in all market segments. However, these devices do use arm trusted firmware and TBBR CoT in a slightly modified form, which is still perfectly valid. Also, the TBBR spec can be changed if required :) > > > Why would one use authenticated decryption only to establish TBBR > > Chain of Trust providing device the capability to self sign its firmware? > > [RK] Fair point. However, you may have devices that don't have the processing power or hardware budget or cost factors(paying for HSM's to store private asymmetric keys), to implement asymmetric verification, in which case using authenticated decryption to verify firmware authenticity and integrity is perfectly valid. The attacks on devices that use symmetric keys to verify firmware authenticity and integrity are usually related to exploiting firmware flaws that leak the key or insiders leaking keys, but that is a different problem and requires different solutions. Fundamentally, there is nothing wrong with using symmetric keys for this purpose, so long as the key is well protected. Also note, security requirements and guarantees are different for different systems. The risk is taken by the system designer and should not be imposed by framework code. I don't advocate doing this but it is an option that your implementation does not provide(and perhaps rightly so). > > > How would this ensure integrity of ciphertext? > > > > [RK] You sign the ciphertext. In your design, you pass bl31_enc.bin to cert_tool to sign. You don't decrypt the encrypted cipher text until you have verified the asymmetric signature(which provides integrity). As far as signature verification is concerned, whether you sign the plain text or ciphertext is immaterial, since you are simply verifying that the absolute bits you loaded have not been modified(assuming you use a secure signature scheme). > > > Have a look at some defective sign and encrypt techniques here [2] > > > > [RK] Again, very familiar with [2]. In the S/MIME case, you have multiple parties. With secure boot, you have one party, effectively verifying its own messages across time. There is only one key used to verify signatures. 1.1 and 1.2 does not apply. Also you are encrypting and signing with completely different keys and algorithms. Section 1.2 applies when you use RSA/El-gamal encryption. Here you use symmetric encryption and asymmetric signing. > > > Why would one not use TBBR CoT here? > > > > [RK] see above. Not all systems are designed equal. > > > > and why would one like to hardcode in a device during > > provisioning to boot only either an encrypted or a plain firmware > image? > > > [RK] Why would you not? You typically want to have the same security policy for a class of devices and not be modifiable by an attacker. It isn't common for the same class of devices to use encrypted firmware some times, and un-encrypted firmware other times. If it is common, there is no problem with setting the bit in the FIP header, as long as verified boot is mandatory. The only concern(as my original email said) is the coupling of the FIP layer and the crypto module, in the implementation. I still don't like that fact that the bit saying the file is encrypted is not signed and this may require talking to the TBBR spec writers. Page 22 of the TBBR spec calls out ToC as "Trusted Table of Contents". The FIP header cannot be "trusted", if it is not in ROM or its integrity is verified by some means! R010_TBBR_TOC should perhaps be mandatory then. Also see R080_TBBR_TOC that says the TOC MUST be ROM'ed or tied by hardware in readable registers. This requirement seems contradictory to R010_TBBR_TOC, given that the FIP header(TOC) is copied from mutable NVM by ROM or some boot stage and then ROM'd or loaded into registers. I may be misunderstanding R080_TBBR_TOC, but i'd interpret it as the TOC(FIP header in ATF implementation of TBBR) as being in ROM or integrity verified. > > > How would one handle a case where BL31 is in plain format and BL32 is in encrypted format? > > > > [RK]TBBR CoT is equipped to do this. The table is defined on a per image basis. > > > If you are really paranoid about authentication of FIP header... > > [RK] I don't mean to pontificate but there are real world customers buying real hardware, running ATF code, who care about such details and ask about such things routinely. It is not just me being paranoid and is definitely not a minor matter to think of such details. We should discuss more and consider the implications of R080_TBBR_TOC and R010_TBBR_TOC, perhaps on a different thread, without blocking your code review. Can somebody from ARM clarify these requirements with the spec writers? > > > Thanks > -Raghu > > > On January 23, 2020 at 12:38 AM, Sumit Garg <sumit.garg(a)linaro.org> wrote: > > > Hi Raghu, > > I guess you have completely misunderstood this feature. This is an > optional feature which allows to load encrypted FIP payloads using > authenticated decryption which MUST be used along with signature > verification (or TBBR CoT). > > So firstly I would suggest you to revisit TBBR spec [1], especially > requirements: R040_TBBR_TOC, R060_TBBR_FUNCTION etc. > > On Thu, 23 Jan 2020 at 00:14, Raghupathy Krishnamurthy > <raghu.ncstate(a)icloud.com> wrote: > > > > Hello, > > > The patch stack looks good. The only comment i have is that the FIP layer has now become security aware and supports authenticated decryption(only). This is a deviation from the secure/signed/verified boot design, where we use the TBBR COT to dictate the security operations on the file. This is nice, because file IO is decoupled from the security policy. This may be a big deviation(i apologize if this was considered and shot down for some other reason), but it may be worthwhile to consider making authenticated decryption a part of the authentication framework as opposed to coupling it with the FIP layer. > > It looks like you have mixed both TBBR CoT and this authenticated > decryption feature. They both are completely different and rather > complement each other where TBBR CoT establishes > secure/signed/verified boot and this authenticated decryption feature > provides confidentiality protection for FIP payloads. > > > At a high level, this would mean adding a new authentication method(perhaps AUTH_METHOD_AUTHENTICATED_DECRYPTION), and having the platform specify that the image is using authenticated encryption in the TBBR COT. > > Why would one use authenticated decryption only to establish TBBR > Chain of Trust providing device the capability to self sign its > firmwares? We must use signature verification for TBBR CoT (see > section: 2.1 Authentication of Code Images by Certificate in TBBR spec > [1]). > > > The authentication framework is already well designed and well equipped to handle these types of extensions. > 1) This would make the change simpler, since you would not require changes to the FIP tool and the FIP layer. > 2) This would also allow for future cases where a platform may want to only encrypt the file and use public key authentication on the encrypted file(for ex. the soc does not have a crypto accelerator for aes-gcm but only for AES and public key verification, for whatever reason). > > How would this ensure integrity of ciphertext? This approach may be > vulnerable to Chosen Ciphertext Attacks (CCAs). Authentication tag as > part of AES-GCM provides integrity protection for ciphertext. > > > 3) This would let you choose the order in which you want to do the authenticated decryption(or just decryption) and signature verification, if you use both, one or the other. > > > > Have a look at some defective sign and encrypt techniques here [2]. > The order can't be any arbitrary one, we need to be careful about > this. > > > One other thing i'm not entirely comfortable with is that the flag indicating if there are encrypted files or not in the FIP, is in the *unsigned* portion of the FIP header. An attacker could simply flip bits that dictate security policy in the header and avoid detection(in this case, the indication that the file needs authenticated decryption). If a platform only uses authenticated encryption, but not verified boot, an attacker could flip the bit in the FIP header and have any image loaded on the platform. > > Why would one not use TBBR CoT here? > > > If authenticated encryption cannot be used without verified boot(which requires build time flags), having a flag to indicate that there are encrypted files in the FIP header is moot, since this can come at build time through the TBBR COT. In any case, it seems like the security policy that firmware images need to be decrypted or authenticated with authenticated decryption, seems like a firmware build time or manufacturing time decision(perhaps a bit set in the e-fuses). > > Again you are confusing TBBR CoT with authenticated decryption > feature. And why would one like to hardcode in a device during > provisioning to boot only either an encrypted or a plain firmware > image? > > > There seems to be no benefit to having a flag in the FIP header. > > How would one handle a case where BL31 is in plain format and BL32 is > in encrypted format? > > > Otherwise, I cant think of any attacks due to this and it may be completely okay, but generally, consuming data that dictates security policy/operations before verifying its integrity seems like a recipe for disaster. > > > > If you are really paranoid about authentication of FIP header then you > should look at implementing optional requirement: R010_TBBR_TOC as per > TBBR spec [1]. > > [1] https://developer.arm.com/docs/den0006/latest/trusted-board-boot-requiremen… > [2] http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html > > -Sumit > > > -Raghu > > > On January 22, 2020 at 3:51 AM, Sumit Garg via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: > > > Hi Sandrine, > > > On Wed, 22 Jan 2020 at 15:43, Sandrine Bailleux > <Sandrine.Bailleux(a)arm.com> wrote: > > > > > Hello Sumit, > > > > > Thank you for reworking the patches and addressing all of my review > > > comments. I am happy with the latest version of these and consider them > > > ready to go. I plan to leave them in Gerrit for another week to give > > > extra time for other potential reviewers to have a look and comment. > > > > > > > Thanks for your review. > > > To everyone on the list: Please raise any concerns you may have about > > > these patches in the coming week. If I don't hear anything by 29th > > > January 2020, I will merge these patches. > > > > > @Sumit: One of the next actions for this patch stack would be to have > > > some level of testing in the CI system to detect any potential > > > regressions. We (at Arm) can quite easily add a few build tests but then > > > testing the software stack on QEMU is a bit more involved for various > > > reasons (first instance of QEMU testing, dependencies on OPTEE, UEFI, > > > ...) so this might have to wait for some time. > > > > > > > Okay, will wait for CI testing. > > > -Sumit > > > Regards, > > > Sandrine > > > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 3 months

1
0
0 0

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

by Sumit Garg

On Mon, 27 Jan 2020 at 22:43, Raghupathy Krishnamurthy via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: > > Thanks Soby, Sumit, Sandrine and Joakim! > > > Agree with Joakim/Soby about encrypt then sign and sign then encrypt being okay, when authenticated encryption is used. I'd like to point out again, that the link provided by Sumit talks about encrypt-then-sign and sign-then-encrypt, using asymmetric encryption and asymmetric signing only, and as Joakim rightly pointed out(and as i did in my earlier email), does not necessarily apply here. They are not talking about symmetric encryption with asymmetric signing, which is what PSA-TBFU and TBBR are talking about. > I usually don't like signing plain text and encrypt(not authenticated encryption, just encryption like aes-cbc etc) plain text due to https://moxie.org/blog/the-cryptographic-doom-principle/(written by the creator of the the WhatsApp end-to-end encryption protocol, this applies to symmetric encryption and symmetric signing/MAC's, but it applies to any ciphertext that is decrypted without verifying its integrity). If we were to sign the plain text then encrypt the firmware, the size of the encrypted file needs to be integrity protected as well, not just the bit that indicates that the file is encrypted. If not, when we decrypt the firmware image, we can perform some creative attacks on symmetric encryption, as specified in the link, and requires careful implementation of error handling/reporting on decryption errors. Just to clarify here further that authenticated encryption (aes-gcm) follows “encrypt-then-authenticate” principal only, which is mentioned optimal as per https://moxie.org/blog/the-cryptographic-doom-principle/. -Sumit > > > I also like Soby's approach of having an attribute EP_ENCRYPTED and relying on platform_pre_image_load() and platform_post_image_load() to do the decryption and that addresses my non-spec related concerns. It also allows for decrypt-then-authenticate(which i wouldn't use) and authenticate-then-decrypt. It also puts the attribute that indicates firmware encryption in the image descriptor table which is integrity protected by virtue of it being in the ROM or being signed, and also leaves the FIP layer unaltered. > > > Thanks > -Raghu > > On January 27, 2020 at 6:42 AM, Soby Mathew <Soby.Mathew(a)arm.com> wrote: > > > On 27/01/2020 12:34, Joakim Bech via TF-A wrote: > > on raw binaries are there so we can be sure that > we're loading unmodified firmware coming from the one owning a private key > corresponding to the public key hardcoded into the device (or via a hash of > the public key). I think we all can agree > > OK, I have finally managed to catch up on this thread. Apologies for the > delayed response. > > As Joakim mentions, I think both the mentioned cases ie. encrypt plain > text -> sign and sign -> encrypt are valid and it depend on the threat > model and security requirement. > > I have had a brief look at the patch stack and coupling the feature to > the FIP does not seem like a good idea to me( + the added complexity > protecting the ToC). Currently meta data of the firmware images is > passed OOB via the `bl_mem_params_node_t` descriptor to the BL images > whereas this patch breaks that convention. It is better to follow the > set convention and avoid dependency on FIP format (btw platforms need > not use FIP format and can use other packaging formats). > > The iv data to decrypt seems to be prepended to the encrypted file in > the fip which is making custom manipulations file pointer manipulations > which is raising some red flags. > > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2495/8/drive… > > IMO, this should not visible to be FIP driver. I am not sure of the best > practice for sending iv data but if it has to be prepended, it should be > FIP agnostic. > > The TBBR assumes a single owner for all images whereas the TBFU > supercedes this spec by allowing multiple owners for different images. > We are in the process of enhancing the CoT for different Root of Trusts > for different images and there needs to be capability to encrypt with > different keys for different images based on ownership. The current > implementation has some limitations like introducing a platform API > invocation within the driver layer to get the single key which is not > ideal IMO. > > I haven't fully flushed out my ideas, but thoughts are based on > enhancements done by Masahiro for adding decompression support for BL > images. See https://github.com/ARM-software/arm-trusted-firmware/pull/1224 . > > Basically, this patch series allows any filter to be setup before/after > the images are loaded. It relies on pre-load and post load hooks which > are platform specific to perform the filter operation. So, if a new > image attribute `EP_ENCRYPTED` is added ep_info_exp.h, then BL2 needs to > do the following in bl2_plat_handle_pre_image_load() > { > if EP_ENCRYPTED is set : > load the image to SRAM and decrypt using crypto module > } > > This will cater for `decrypt-then-authenticate` flow. > > The fip_tool no longer needs to be aware of encryption and the build > process just needs to pipe the encrypted binaries to the fip_tool. > > Similarly if `authenticate-then-decrypt` needs to be supported, then all > that the platform needs to do is implement decrypt in > bl2_plat_handle_post_image_load(). > > The platform can now use different keys to use for different BL images > if it needs to do so. > > Some usecases require the firmware images to be re-encrypted using HUK > after firmware update (aka firmware binding) and following this design > will allow this to be done as well. > > > Best Regards > Soby Mathew > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 3 months

1
0
0 0

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

by Raghupathy Krishnamurthy

Sumit, Great point. This perhaps needs to be added to the list of things that need clarification(Sandrine can you help with this too?) in the PSA-TBFU . I believe the answer to your concern lies in the PSA-TBFU in section 3.5, where it talks about optimizing the trusted boot process. To overcome the problem you're talking about, you would: 1) Verify asymmetric signature. 2) Decrypt firmware using SSK on successful signature verification. 3) Rekey the firmware using BSSK(or as the PSA specifies, a key derived from the HUK using a KDF). You will only verify the asymmetric signature on every firmware update, and use the rekeyed firmware(encrypted and mac;d with device specific key) on normal boot. Thanks Raghu On January 26, 2020 at 10:34 PM, Sumit Garg <sumit.garg(a)linaro.org> wrote: On Fri, 24 Jan 2020 at 16:36, Sumit Garg <sumit.garg(a)linaro.org> wrote: On Fri, 24 Jan 2020 at 04:02, Raghupathy Krishnamurthy <raghu.ncstate(a)icloud.com> wrote: > > I also just realized that both the TBBR and ARM PSA only talk about encryption of the image, and not authenticated encryption. The guarantees provided by both are completely different. Your review(https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2495/) talks about the requirement R060_TBBR_FUNCTION being implemented, which is technically not true(and potentially misleading). We must make a note of this difference and use the appropriate terminology, without mixing the two, in the documentation, commit messages, source code comments and error prints. The tool is also called 'encrypt_fw ' but should maybe be named appropriately to indicate it is doing authenticated encryption. I wouldn't call it misleading. Since firmware encryption feature essentially provides confidentiality protection and authenticated encryption is the type of crypto algorithm which we have used to implement it. > > BTW, ARM PSA(file:///home/raghu/repos/fvp/DEN0072-PSA_TBFU_1-0-REL.pdf) expects that the image manifest(X509 certificate) contain the hash of the ENCRYPTED image(Table 2 and as described in my answer to your question "How would this ensure integrity of ciphertext"). The TBBR spec completely misses this fact, and is a crucial detail if we only implement encryption(as opposed to authenticated encryption).Build_macros.mk, in your change, passes the un-encrypted image to cert-tool. You can get away with it in your implementation, since you are using authenticated encryption, not if you were only implementing firmware encryption. I have already highlighted the issue with signing the ciphertext in my previous reply which deviates from security properties provided by signature verification of plain firmware. So I think we need to revisit ARM PSA TBFU spec. In addition to this, there are implementation specific issues with "signing the ciphertext" too. It simply makes the ciphertext immutable for device and disallows meeting following firmware re-encryption requirement as per TBBR spec: R070_TBBR_PROTECTION. The Trusted boot firmware may do the binding of software image updates at run- time by decrypting the updated SoC certificates and software images using the OTP/Fuse Secret Symmetric Key (SSK), followed by the re-encrypting these SoC certificates and software images using a reproducible secret unique per device symmetric key (BSSK), and then updating the ToC correspondingly. Also, externally signing every firmware image encrypted with BSSK doesn't seem scalable as well. It also hampers the case where encryption key is never exposed out from device eg. encryption key is only accessible to hardware crypto engine etc. -Sumit > > Is it possible for somebody from ARM to have the TBBR spec updated to reflect this? Also perhaps talk to the spec writers about incorporating authenticated encryption into TBBR and PSA? This patch set is somewhat trailblazing in this regard. > > -Raghu > > > On January 23, 2020 at 12:08 PM, Raghupathy Krishnamurthy via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: > > Hi Sumit, > > > Thanks for your response. > > > So firstly I would suggest you to revisit TBBR spec [1], > > > > [RK] I'm very familiar with the TBBR spec and the requirements. Note that not all SoC's adhere perfectly to the TBBR spec, since it does not apply to devices in all market segments. However, these devices do use arm trusted firmware and TBBR CoT in a slightly modified form, which is still perfectly valid. Also, the TBBR spec can be changed if required :) > > > Why would one use authenticated decryption only to establish TBBR > > Chain of Trust providing device the capability to self sign its firmware? > > [RK] Fair point. However, you may have devices that don't have the processing power or hardware budget or cost factors(paying for HSM's to store private asymmetric keys), to implement asymmetric verification, in which case using authenticated decryption to verify firmware authenticity and integrity is perfectly valid. The attacks on devices that use symmetric keys to verify firmware authenticity and integrity are usually related to exploiting firmware flaws that leak the key or insiders leaking keys, but that is a different problem and requires different solutions. Fundamentally, there is nothing wrong with using symmetric keys for this purpose, so long as the key is well protected. Also note, security requirements and guarantees are different for different systems. The risk is taken by the system designer and should not be imposed by framework code. I don't advocate doing this but it is an option that your implementation does not provide(and perhaps rightly so). > > > How would this ensure integrity of ciphertext? > > > > [RK] You sign the ciphertext. In your design, you pass bl31_enc.bin to cert_tool to sign. You don't decrypt the encrypted cipher text until you have verified the asymmetric signature(which provides integrity). As far as signature verification is concerned, whether you sign the plain text or ciphertext is immaterial, since you are simply verifying that the absolute bits you loaded have not been modified(assuming you use a secure signature scheme). > > > Have a look at some defective sign and encrypt techniques here [2] > > > > [RK] Again, very familiar with [2]. In the S/MIME case, you have multiple parties. With secure boot, you have one party, effectively verifying its own messages across time. There is only one key used to verify signatures. 1.1 and 1.2 does not apply. Also you are encrypting and signing with completely different keys and algorithms. Section 1.2 applies when you use RSA/El-gamal encryption. Here you use symmetric encryption and asymmetric signing. > > > Why would one not use TBBR CoT here? > > > > [RK] see above. Not all systems are designed equal. > > > > and why would one like to hardcode in a device during > > provisioning to boot only either an encrypted or a plain firmware > image? > > > [RK] Why would you not? You typically want to have the same security policy for a class of devices and not be modifiable by an attacker. It isn't common for the same class of devices to use encrypted firmware some times, and un-encrypted firmware other times. If it is common, there is no problem with setting the bit in the FIP header, as long as verified boot is mandatory. The only concern(as my original email said) is the coupling of the FIP layer and the crypto module, in the implementation. I still don't like that fact that the bit saying the file is encrypted is not signed and this may require talking to the TBBR spec writers. Page 22 of the TBBR spec calls out ToC as "Trusted Table of Contents". The FIP header cannot be "trusted", if it is not in ROM or its integrity is verified by some means! R010_TBBR_TOC should perhaps be mandatory then. Also see R080_TBBR_TOC that says the TOC MUST be ROM'ed or tied by hardware in readable registers. This requirement seems contradictory to R010_TBBR_TOC, given that the FIP header(TOC) is copied from mutable NVM by ROM or some boot stage and then ROM'd or loaded into registers. I may be misunderstanding R080_TBBR_TOC, but i'd interpret it as the TOC(FIP header in ATF implementation of TBBR) as being in ROM or integrity verified. > > > How would one handle a case where BL31 is in plain format and BL32 is in encrypted format? > > > > [RK]TBBR CoT is equipped to do this. The table is defined on a per image basis. > > > If you are really paranoid about authentication of FIP header... > > [RK] I don't mean to pontificate but there are real world customers buying real hardware, running ATF code, who care about such details and ask about such things routinely. It is not just me being paranoid and is definitely not a minor matter to think of such details. We should discuss more and consider the implications of R080_TBBR_TOC and R010_TBBR_TOC, perhaps on a different thread, without blocking your code review. Can somebody from ARM clarify these requirements with the spec writers? > > > Thanks > -Raghu > > > On January 23, 2020 at 12:38 AM, Sumit Garg <sumit.garg(a)linaro.org> wrote: > > > Hi Raghu, > > I guess you have completely misunderstood this feature. This is an > optional feature which allows to load encrypted FIP payloads using > authenticated decryption which MUST be used along with signature > verification (or TBBR CoT). > > So firstly I would suggest you to revisit TBBR spec [1], especially > requirements: R040_TBBR_TOC, R060_TBBR_FUNCTION etc. > > On Thu, 23 Jan 2020 at 00:14, Raghupathy Krishnamurthy > <raghu.ncstate(a)icloud.com> wrote: > > > > Hello, > > > The patch stack looks good. The only comment i have is that the FIP layer has now become security aware and supports authenticated decryption(only). This is a deviation from the secure/signed/verified boot design, where we use the TBBR COT to dictate the security operations on the file. This is nice, because file IO is decoupled from the security policy. This may be a big deviation(i apologize if this was considered and shot down for some other reason), but it may be worthwhile to consider making authenticated decryption a part of the authentication framework as opposed to coupling it with the FIP layer. > > It looks like you have mixed both TBBR CoT and this authenticated > decryption feature. They both are completely different and rather > complement each other where TBBR CoT establishes > secure/signed/verified boot and this authenticated decryption feature > provides confidentiality protection for FIP payloads. > > > At a high level, this would mean adding a new authentication method(perhaps AUTH_METHOD_AUTHENTICATED_DECRYPTION), and having the platform specify that the image is using authenticated encryption in the TBBR COT. > > Why would one use authenticated decryption only to establish TBBR > Chain of Trust providing device the capability to self sign its > firmwares? We must use signature verification for TBBR CoT (see > section: 2.1 Authentication of Code Images by Certificate in TBBR spec > [1]). > > > The authentication framework is already well designed and well equipped to handle these types of extensions. > 1) This would make the change simpler, since you would not require changes to the FIP tool and the FIP layer. > 2) This would also allow for future cases where a platform may want to only encrypt the file and use public key authentication on the encrypted file(for ex. the soc does not have a crypto accelerator for aes-gcm but only for AES and public key verification, for whatever reason). > > How would this ensure integrity of ciphertext? This approach may be > vulnerable to Chosen Ciphertext Attacks (CCAs). Authentication tag as > part of AES-GCM provides integrity protection for ciphertext. > > > 3) This would let you choose the order in which you want to do the authenticated decryption(or just decryption) and signature verification, if you use both, one or the other. > > > > Have a look at some defective sign and encrypt techniques here [2]. > The order can't be any arbitrary one, we need to be careful about > this. > > > One other thing i'm not entirely comfortable with is that the flag indicating if there are encrypted files or not in the FIP, is in the *unsigned* portion of the FIP header. An attacker could simply flip bits that dictate security policy in the header and avoid detection(in this case, the indication that the file needs authenticated decryption). If a platform only uses authenticated encryption, but not verified boot, an attacker could flip the bit in the FIP header and have any image loaded on the platform. > > Why would one not use TBBR CoT here? > > > If authenticated encryption cannot be used without verified boot(which requires build time flags), having a flag to indicate that there are encrypted files in the FIP header is moot, since this can come at build time through the TBBR COT. In any case, it seems like the security policy that firmware images need to be decrypted or authenticated with authenticated decryption, seems like a firmware build time or manufacturing time decision(perhaps a bit set in the e-fuses). > > Again you are confusing TBBR CoT with authenticated decryption > feature. And why would one like to hardcode in a device during > provisioning to boot only either an encrypted or a plain firmware > image? > > > There seems to be no benefit to having a flag in the FIP header. > > How would one handle a case where BL31 is in plain format and BL32 is > in encrypted format? > > > Otherwise, I cant think of any attacks due to this and it may be completely okay, but generally, consuming data that dictates security policy/operations before verifying its integrity seems like a recipe for disaster. > > > > If you are really paranoid about authentication of FIP header then you > should look at implementing optional requirement: R010_TBBR_TOC as per > TBBR spec [1]. > > [1] https://developer.arm.com/docs/den0006/latest/trusted-board-boot-requiremen… > [2] http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html > > -Sumit > > > -Raghu > > > On January 22, 2020 at 3:51 AM, Sumit Garg via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: > > > Hi Sandrine, > > > On Wed, 22 Jan 2020 at 15:43, Sandrine Bailleux > <Sandrine.Bailleux(a)arm.com> wrote: > > > > > Hello Sumit, > > > > > Thank you for reworking the patches and addressing all of my review > > > comments. I am happy with the latest version of these and consider them > > > ready to go. I plan to leave them in Gerrit for another week to give > > > extra time for other potential reviewers to have a look and comment. > > > > > > > Thanks for your review. > > > To everyone on the list: Please raise any concerns you may have about > > > these patches in the coming week. If I don't hear anything by 29th > > > January 2020, I will merge these patches. > > > > > @Sumit: One of the next actions for this patch stack would be to have > > > some level of testing in the CI system to detect any potential > > > regressions. We (at Arm) can quite easily add a few build tests but then > > > testing the software stack on QEMU is a bit more involved for various > > > reasons (first instance of QEMU testing, dependencies on OPTEE, UEFI, > > > ...) so this might have to wait for some time. > > > > > > > Okay, will wait for CI testing. > > > -Sumit > > > Regards, > > > Sandrine > > > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 3 months

2
1
0 0

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

by Raghupathy Krishnamurthy

Thanks Soby, Sumit, Sandrine and Joakim! Agree with Joakim/Soby about encrypt then sign and sign then encrypt being okay, when authenticated encryption is used. I'd like to point out again, that the link provided by Sumit talks about encrypt-then-sign and sign-then-encrypt, using asymmetric encryption and asymmetric signing only, and as Joakim rightly pointed out(and as i did in my earlier email), does not necessarily apply here. They are not talking about symmetric encryption with asymmetric signing, which is what PSA-TBFU and TBBR are talking about. I usually don't like signing plain text and encrypt(not authenticated encryption, just encryption like aes-cbc etc) plain text due to https://moxie.org/blog/the-cryptographic-doom-principle/(written by the creator of the the WhatsApp end-to-end encryption protocol, this applies to symmetric encryption and symmetric signing/MAC's, but it applies to any ciphertext that is decrypted without verifying its integrity). If we were to sign the plain text then encrypt the firmware, the size of the encrypted file needs to be integrity protected as well, not just the bit that indicates that the file is encrypted. If not, when we decrypt the firmware image, we can perform some creative attacks on symmetric encryption, as specified in the link, and requires careful implementation of error handling/reporting on decryption errors. I also like Soby's approach of having an attribute EP_ENCRYPTED and relying on platform_pre_image_load() and platform_post_image_load() to do the decryption and that addresses my non-spec related concerns. It also allows for decrypt-then-authenticate(which i wouldn't use) and authenticate-then-decrypt. It also puts the attribute that indicates firmware encryption in the image descriptor table which is integrity protected by virtue of it being in the ROM or being signed, and also leaves the FIP layer unaltered. Thanks -Raghu On January 27, 2020 at 6:42 AM, Soby Mathew <Soby.Mathew(a)arm.com> wrote: On 27/01/2020 12:34, Joakim Bech via TF-A wrote: on raw binaries are there so we can be sure that we're loading unmodified firmware coming from the one owning a private key corresponding to the public key hardcoded into the device (or via a hash of the public key). I think we all can agree OK, I have finally managed to catch up on this thread. Apologies for the delayed response. As Joakim mentions, I think both the mentioned cases ie. encrypt plain text -> sign and sign -> encrypt are valid and it depend on the threat model and security requirement. I have had a brief look at the patch stack and coupling the feature to the FIP does not seem like a good idea to me( + the added complexity protecting the ToC). Currently meta data of the firmware images is passed OOB via the `bl_mem_params_node_t` descriptor to the BL images whereas this patch breaks that convention. It is better to follow the set convention and avoid dependency on FIP format (btw platforms need not use FIP format and can use other packaging formats). The iv data to decrypt seems to be prepended to the encrypted file in the fip which is making custom manipulations file pointer manipulations which is raising some red flags. https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2495/8/drive… IMO, this should not visible to be FIP driver. I am not sure of the best practice for sending iv data but if it has to be prepended, it should be FIP agnostic. The TBBR assumes a single owner for all images whereas the TBFU supercedes this spec by allowing multiple owners for different images. We are in the process of enhancing the CoT for different Root of Trusts for different images and there needs to be capability to encrypt with different keys for different images based on ownership. The current implementation has some limitations like introducing a platform API invocation within the driver layer to get the single key which is not ideal IMO. I haven't fully flushed out my ideas, but thoughts are based on enhancements done by Masahiro for adding decompression support for BL images. See https://github.com/ARM-software/arm-trusted-firmware/pull/1224 . Basically, this patch series allows any filter to be setup before/after the images are loaded. It relies on pre-load and post load hooks which are platform specific to perform the filter operation. So, if a new image attribute `EP_ENCRYPTED` is added ep_info_exp.h, then BL2 needs to do the following in bl2_plat_handle_pre_image_load() { if EP_ENCRYPTED is set : load the image to SRAM and decrypt using crypto module } This will cater for `decrypt-then-authenticate` flow. The fip_tool no longer needs to be aware of encryption and the build process just needs to pipe the encrypted binaries to the fip_tool. Similarly if `authenticate-then-decrypt` needs to be supported, then all that the platform needs to do is implement decrypt in bl2_plat_handle_post_image_load(). The platform can now use different keys to use for different BL images if it needs to do so. Some usecases require the firmware images to be re-encrypted using HUK after firmware update (aka firmware binding) and following this design will allow this to be done as well. Best Regards Soby Mathew

5 years, 3 months

1
0
0 0

Re: [TF-A] What prevents BL1 FWU SMC's from being called on multiple cores ?

by Soby Mathew

On 24/01/2020 20:20, Raghupathy Krishnamurthy via TF-A wrote: > It appears that the BL1 FWU SMC's are written under the assumption that only one core can call the SMC's at any given time but i don't see anything enforcing it. What prevent's this ? > > > -Raghu > Hi Raghu The BL1 itself is uni-processor [except the early assembly code which differentiates primary core from secondaries]. Hence it makes no attempt to provide protection for the SMCs from multiple cores. Best Regards Soby Mathew

5 years, 3 months

1
0
0 0

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

by Raghupathy Krishnamurthy

Thanks Sumit. We are beginning to go off topic and i don't think you and i agree entirely. I'll lay out my concerns, to see if others on the list share my opinion/concerns, so i hope you can let them respond. If nobody else shares my concerns or responds, the patch will be merged soon anyway, so no point dragging this out :) I apologize for the long email. I don't know how to keep this topic short and detailed. :) Here are my concerns: 1) The patch set claims to implement R060_TBBR_FUNCTION from the TBBR spec. I don't agree with this. The patch is using authenticated encryption(which does provide confidentiality) but is different from implementing firmware encryption as described in the TBBR(and PSA) in my view. If we are implementing R060_TBBR_FUNCTION, in my view, this should be implemented such that the firmware is first encrypted(symmetric), and the encrypted firmware should be asymmetrically signed(as per PSA). Also, the order for verification should be asymmetric signature verification and then decryption(symmetric). In this patch, plain text firmware is asymmetrically signed, plain text firmware is encrypted and authenticated with a symmetric key using authenticated encryption. The order for verification in this patch is authenticate and decrypt using the symmetric key and THEN asymmetric signature verification on the decryted(and now plain text) firmware. The ordering of verification and decryption are subtly different from what the spec(TBBR and PSA) expects. Security does not *seem* to be broken as far as i can tell, but the patch is not strictly an implementation of the spec, as it claims. This can throw off people reading the spec and trying to match code to spec. This is not good when someone wants to audit and gain confidence in the security of the implementation. At a minimum, we need someone writing the spec to address this. 2) The TBBR spec does not talk about authenticated encryption of firmware and only talks about encryption of firmware. It also does not specify if the encrypted firmware needs to be signed or the plain text need to be signed. This is critical detail. It also does not specify the order in which encryption and signing, decryption and verification must be done. These are important details and need to be addressed explicitly(perhaps in both TBBR and PSA). Use of authenticated encryption needs to be explicitly discussed as well. 3) TBBR specifies that the TOC(table of contents) *may* be authenticated. The TOC contains bits that dictate security policy, in this case, if the firmware is encrypted or not. I don't think it is good to consume security policy from unauthenticated data. In my view, this information must be in the signed image manifest(certificate in ATF) since an attacker can at-least cause simple DoS attacks by flipping bits in the FIP header, undetected. If the bit is flipped, a firmware image going out to a million devices may not boot, since an attacker decided to flip a bit, and signature verification fails, since the boot loader decided not decrypt the firmware based in an unsigned bit of information. PSA appears to have a better approach and makes no provision such data to be outside the image manifest, which is always signed. 4) This last one is a matter of opinion and can live with the current design. The FIP layer is now aware of the crypto module. FIP has also become coupled with authenticated encryption(If we do this, why not have the FIP layer call auth_mod_verify_img() and why stop at cyrpto_mod_auth_decrypt()) . FIP is security aware. I'd like to keep things the way they are today, where IO and security are separate modules and glued together by another layer(load_auth_image() for example). This is cleaner in my view since security policy(should i decrypt? should i verify signatures? should i apply any security at all?) is separate from IO. Thanks Raghu On January 24, 2020 at 3:06 AM, Sumit Garg <sumit.garg(a)linaro.org> wrote: On Fri, 24 Jan 2020 at 04:02, Raghupathy Krishnamurthy <raghu.ncstate(a)icloud.com> wrote: I also just realized that both the TBBR and ARM PSA only talk about encryption of the image, and not authenticated encryption. The guarantees provided by both are completely different. Your review(https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2495/) talks about the requirement R060_TBBR_FUNCTION being implemented, which is technically not true(and potentially misleading). We must make a note of this difference and use the appropriate terminology, without mixing the two, in the documentation, commit messages, source code comments and error prints. The tool is also called 'encrypt_fw ' but should maybe be named appropriately to indicate it is doing authenticated encryption. I wouldn't call it misleading. Since firmware encryption feature essentially provides confidentiality protection and authenticated encryption is the type of crypto algorithm which we have used to implement it. BTW, ARM PSA(file:///home/raghu/repos/fvp/DEN0072-PSA_TBFU_1-0-REL.pdf) expects that the image manifest(X509 certificate) contain the hash of the ENCRYPTED image(Table 2 and as described in my answer to your question "How would this ensure integrity of ciphertext"). The TBBR spec completely misses this fact, and is a crucial detail if we only implement encryption(as opposed to authenticated encryption).Build_macros.mk, in your change, passes the un-encrypted image to cert-tool. You can get away with it in your implementation, since you are using authenticated encryption, not if you were only implementing firmware encryption. I have already highlighted the issue with signing the ciphertext in my previous reply which deviates from security properties provided by signature verification of plain firmware. So I think we need to revisit ARM PSA TBFU spec. -Sumit Is it possible for somebody from ARM to have the TBBR spec updated to reflect this? Also perhaps talk to the spec writers about incorporating authenticated encryption into TBBR and PSA? This patch set is somewhat trailblazing in this regard. -Raghu On January 23, 2020 at 12:08 PM, Raghupathy Krishnamurthy via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: Hi Sumit, Thanks for your response. So firstly I would suggest you to revisit TBBR spec [1], [RK] I'm very familiar with the TBBR spec and the requirements. Note that not all SoC's adhere perfectly to the TBBR spec, since it does not apply to devices in all market segments. However, these devices do use arm trusted firmware and TBBR CoT in a slightly modified form, which is still perfectly valid. Also, the TBBR spec can be changed if required :) Why would one use authenticated decryption only to establish TBBR Chain of Trust providing device the capability to self sign its firmware? [RK] Fair point. However, you may have devices that don't have the processing power or hardware budget or cost factors(paying for HSM's to store private asymmetric keys), to implement asymmetric verification, in which case using authenticated decryption to verify firmware authenticity and integrity is perfectly valid. The attacks on devices that use symmetric keys to verify firmware authenticity and integrity are usually related to exploiting firmware flaws that leak the key or insiders leaking keys, but that is a different problem and requires different solutions. Fundamentally, there is nothing wrong with using symmetric keys for this purpose, so long as the key is well protected. Also note, security requirements and guarantees are different for different systems. The risk is taken by the system designer and should not be imposed by framework code. I don't advocate doing this but it is an option that your implementation does not provide(and perhaps rightly so). How would this ensure integrity of ciphertext? [RK] You sign the ciphertext. In your design, you pass bl31_enc.bin to cert_tool to sign. You don't decrypt the encrypted cipher text until you have verified the asymmetric signature(which provides integrity). As far as signature verification is concerned, whether you sign the plain text or ciphertext is immaterial, since you are simply verifying that the absolute bits you loaded have not been modified(assuming you use a secure signature scheme). Have a look at some defective sign and encrypt techniques here [2] [RK] Again, very familiar with [2]. In the S/MIME case, you have multiple parties. With secure boot, you have one party, effectively verifying its own messages across time. There is only one key used to verify signatures. 1.1 and 1.2 does not apply. Also you are encrypting and signing with completely different keys and algorithms. Section 1.2 applies when you use RSA/El-gamal encryption. Here you use symmetric encryption and asymmetric signing. Why would one not use TBBR CoT here? [RK] see above. Not all systems are designed equal. and why would one like to hardcode in a device during provisioning to boot only either an encrypted or a plain firmware image? [RK] Why would you not? You typically want to have the same security policy for a class of devices and not be modifiable by an attacker. It isn't common for the same class of devices to use encrypted firmware some times, and un-encrypted firmware other times. If it is common, there is no problem with setting the bit in the FIP header, as long as verified boot is mandatory. The only concern(as my original email said) is the coupling of the FIP layer and the crypto module, in the implementation. I still don't like that fact that the bit saying the file is encrypted is not signed and this may require talking to the TBBR spec writers. Page 22 of the TBBR spec calls out ToC as "Trusted Table of Contents". The FIP header cannot be "trusted", if it is not in ROM or its integrity is verified by some means! R010_TBBR_TOC should perhaps be mandatory then. Also see R080_TBBR_TOC that says the TOC MUST be ROM'ed or tied by hardware in readable registers. This requirement seems contradictory to R010_TBBR_TOC, given that the FIP header(TOC) is copied from mutable NVM by ROM or some boot stage and then ROM'd or loaded into registers. I may be misunderstanding R080_TBBR_TOC, but i'd interpret it as the TOC(FIP header in ATF implementation of TBBR) as being in ROM or integrity verified. How would one handle a case where BL31 is in plain format and BL32 is in encrypted format? [RK]TBBR CoT is equipped to do this. The table is defined on a per image basis. If you are really paranoid about authentication of FIP header... [RK] I don't mean to pontificate but there are real world customers buying real hardware, running ATF code, who care about such details and ask about such things routinely. It is not just me being paranoid and is definitely not a minor matter to think of such details. We should discuss more and consider the implications of R080_TBBR_TOC and R010_TBBR_TOC, perhaps on a different thread, without blocking your code review. Can somebody from ARM clarify these requirements with the spec writers? Thanks -Raghu On January 23, 2020 at 12:38 AM, Sumit Garg <sumit.garg(a)linaro.org> wrote: Hi Raghu, I guess you have completely misunderstood this feature. This is an optional feature which allows to load encrypted FIP payloads using authenticated decryption which MUST be used along with signature verification (or TBBR CoT). So firstly I would suggest you to revisit TBBR spec [1], especially requirements: R040_TBBR_TOC, R060_TBBR_FUNCTION etc. On Thu, 23 Jan 2020 at 00:14, Raghupathy Krishnamurthy <raghu.ncstate(a)icloud.com> wrote: Hello, The patch stack looks good. The only comment i have is that the FIP layer has now become security aware and supports authenticated decryption(only). This is a deviation from the secure/signed/verified boot design, where we use the TBBR COT to dictate the security operations on the file. This is nice, because file IO is decoupled from the security policy. This may be a big deviation(i apologize if this was considered and shot down for some other reason), but it may be worthwhile to consider making authenticated decryption a part of the authentication framework as opposed to coupling it with the FIP layer. It looks like you have mixed both TBBR CoT and this authenticated decryption feature. They both are completely different and rather complement each other where TBBR CoT establishes secure/signed/verified boot and this authenticated decryption feature provides confidentiality protection for FIP payloads. At a high level, this would mean adding a new authentication method(perhaps AUTH_METHOD_AUTHENTICATED_DECRYPTION), and having the platform specify that the image is using authenticated encryption in the TBBR COT. Why would one use authenticated decryption only to establish TBBR Chain of Trust providing device the capability to self sign its firmwares? We must use signature verification for TBBR CoT (see section: 2.1 Authentication of Code Images by Certificate in TBBR spec [1]). The authentication framework is already well designed and well equipped to handle these types of extensions. 1) This would make the change simpler, since you would not require changes to the FIP tool and the FIP layer. 2) This would also allow for future cases where a platform may want to only encrypt the file and use public key authentication on the encrypted file(for ex. the soc does not have a crypto accelerator for aes-gcm but only for AES and public key verification, for whatever reason). How would this ensure integrity of ciphertext? This approach may be vulnerable to Chosen Ciphertext Attacks (CCAs). Authentication tag as part of AES-GCM provides integrity protection for ciphertext. 3) This would let you choose the order in which you want to do the authenticated decryption(or just decryption) and signature verification, if you use both, one or the other. Have a look at some defective sign and encrypt techniques here [2]. The order can't be any arbitrary one, we need to be careful about this. One other thing i'm not entirely comfortable with is that the flag indicating if there are encrypted files or not in the FIP, is in the *unsigned* portion of the FIP header. An attacker could simply flip bits that dictate security policy in the header and avoid detection(in this case, the indication that the file needs authenticated decryption). If a platform only uses authenticated encryption, but not verified boot, an attacker could flip the bit in the FIP header and have any image loaded on the platform. Why would one not use TBBR CoT here? If authenticated encryption cannot be used without verified boot(which requires build time flags), having a flag to indicate that there are encrypted files in the FIP header is moot, since this can come at build time through the TBBR COT. In any case, it seems like the security policy that firmware images need to be decrypted or authenticated with authenticated decryption, seems like a firmware build time or manufacturing time decision(perhaps a bit set in the e-fuses). Again you are confusing TBBR CoT with authenticated decryption feature. And why would one like to hardcode in a device during provisioning to boot only either an encrypted or a plain firmware image? There seems to be no benefit to having a flag in the FIP header. How would one handle a case where BL31 is in plain format and BL32 is in encrypted format? Otherwise, I cant think of any attacks due to this and it may be completely okay, but generally, consuming data that dictates security policy/operations before verifying its integrity seems like a recipe for disaster. If you are really paranoid about authentication of FIP header then you should look at implementing optional requirement: R010_TBBR_TOC as per TBBR spec [1]. [1] https://developer.arm.com/docs/den0006/latest/trusted-board-boot-requiremen… [2] http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html -Sumit -Raghu On January 22, 2020 at 3:51 AM, Sumit Garg via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: Hi Sandrine, On Wed, 22 Jan 2020 at 15:43, Sandrine Bailleux <Sandrine.Bailleux(a)arm.com> wrote: Hello Sumit, Thank you for reworking the patches and addressing all of my review comments. I am happy with the latest version of these and consider them ready to go. I plan to leave them in Gerrit for another week to give extra time for other potential reviewers to have a look and comment. Thanks for your review. To everyone on the list: Please raise any concerns you may have about these patches in the coming week. If I don't hear anything by 29th January 2020, I will merge these patches. @Sumit: One of the next actions for this patch stack would be to have some level of testing in the CI system to detect any potential regressions. We (at Arm) can quite easily add a few build tests but then testing the software stack on QEMU is a bit more involved for various reasons (first instance of QEMU testing, dependencies on OPTEE, UEFI, ...) so this might have to wait for some time. Okay, will wait for CI testing. -Sumit Regards, Sandrine -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 3 months

3
2
0 0

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

by Soby Mathew

On 27/01/2020 12:34, Joakim Bech via TF-A wrote: > on raw binaries are there so we can be sure that > we're loading unmodified firmware coming from the one owning a private key > corresponding to the public key hardcoded into the device (or via a hash of > the public key). I think we all can agree OK, I have finally managed to catch up on this thread. Apologies for the delayed response. As Joakim mentions, I think both the mentioned cases ie. encrypt plain text -> sign and sign -> encrypt are valid and it depend on the threat model and security requirement. I have had a brief look at the patch stack and coupling the feature to the FIP does not seem like a good idea to me( + the added complexity protecting the ToC). Currently meta data of the firmware images is passed OOB via the `bl_mem_params_node_t` descriptor to the BL images whereas this patch breaks that convention. It is better to follow the set convention and avoid dependency on FIP format (btw platforms need not use FIP format and can use other packaging formats). The iv data to decrypt seems to be prepended to the encrypted file in the fip which is making custom manipulations file pointer manipulations which is raising some red flags. https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2495/8/drive… IMO, this should not visible to be FIP driver. I am not sure of the best practice for sending iv data but if it has to be prepended, it should be FIP agnostic. The TBBR assumes a single owner for all images whereas the TBFU supercedes this spec by allowing multiple owners for different images. We are in the process of enhancing the CoT for different Root of Trusts for different images and there needs to be capability to encrypt with different keys for different images based on ownership. The current implementation has some limitations like introducing a platform API invocation within the driver layer to get the single key which is not ideal IMO. I haven't fully flushed out my ideas, but thoughts are based on enhancements done by Masahiro for adding decompression support for BL images. See https://github.com/ARM-software/arm-trusted-firmware/pull/1224 . Basically, this patch series allows any filter to be setup before/after the images are loaded. It relies on pre-load and post load hooks which are platform specific to perform the filter operation. So, if a new image attribute `EP_ENCRYPTED` is added ep_info_exp.h, then BL2 needs to do the following in bl2_plat_handle_pre_image_load() { if EP_ENCRYPTED is set : load the image to SRAM and decrypt using crypto module } This will cater for `decrypt-then-authenticate` flow. The fip_tool no longer needs to be aware of encryption and the build process just needs to pipe the encrypted binaries to the fip_tool. Similarly if `authenticate-then-decrypt` needs to be supported, then all that the platform needs to do is implement decrypt in bl2_plat_handle_post_image_load(). The platform can now use different keys to use for different BL images if it needs to do so. Some usecases require the firmware images to be re-encrypted using HUK after firmware update (aka firmware binding) and following this design will allow this to be done as well. Best Regards Soby Mathew

5 years, 3 months

1
0
0 0

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

by Sandrine Bailleux

On Mon, 2020-01-27 at 12:04 +0000, Sandrine Bailleux via TF-A wrote: > I share this concern. I was actually surprised to see that the TBBR > specification advocates putting this security policy bit in the > unencrypted part of the FIP, I do not know the rationale for that. Sorry, I meant: in the *unsigned* part of the FIP. This bit itself cannot be encrypted, as it indicates how to decrypt data!

5 years, 3 months

1
0
0 0

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

by Sandrine Bailleux

Hi, On Fri, 2020-01-24 at 18:39 +0000, Raghupathy Krishnamurthy via TF-A wrote: > Here are my concerns: > 1) The patch set claims to implement R060_TBBR_FUNCTION from the TBBR > spec. I don't agree with this. The patch is using authenticated > encryption(which does provide confidentiality) but is different from > implementing firmware encryption as described in the TBBR(and PSA) in > my view. If we are implementing R060_TBBR_FUNCTION, in my view, this > should be implemented such that the firmware is first > encrypted(symmetric), and the encrypted firmware should be > asymmetrically signed(as per PSA). Also, the order for verification > should be asymmetric signature verification and then > decryption(symmetric). In this patch, plain text firmware is > asymmetrically signed, plain text firmware is encrypted and > authenticated with a symmetric key using authenticated encryption. > The order for verification in this patch is authenticate and decrypt > using the symmetric key and THEN asymmetric signature verification on > the decryted(and now plain text) firmware. The ordering of > verification and decryption are subtly different from what the > spec(TBBR and PSA) expects. Security does not *seem* to be broken as > far as i can tell, but the patch is not strictly an implementation of > the spec, as it claims. This can throw off people reading the spec > and trying to match code to spec. This is not good when someone wants > to audit and gain confidence in the security of the implementation. > At a minimum, we need someone writing the spec to address this. I do not have a strong opinion on this one. As I mentioned at the start of this email thread, I am quite new to the concept of authenticated decryption and naively thought this would not differ too much from using decryption + signature verification separately. However, if these are fundamentally different things like you say, I get your point and I too am worried about the confusion this could create. > 2) The TBBR spec does not talk about authenticated encryption of > firmware and only talks about encryption of firmware. It also does > not specify if the encrypted firmware needs to be signed or the plain > text need to be signed. This is critical detail. It also does not > specify the order in which encryption and signing, decryption and > verification must be done. These are important details and need to be > addressed explicitly(perhaps in both TBBR and PSA). Use of > authenticated encryption needs to be explicitly discussed as well. TBBR is quite an old specification and it is unlikely that it will ever be updated. PSA-TBFU is meant to supersede it so I think any update/clarification/addition would only apply to TBFU. I agree that it would be good for PSA-TBFU to provide some guidance around encryption and signature together, in which order they should be done and what security properties they bring together. I can raise this to the PSA architects. > 3) TBBR specifies that the TOC(table of contents) *may* be > authenticated. The TOC contains bits that dictate security policy, in > this case, if the firmware is encrypted or not. I don't think it is > good to consume security policy from unauthenticated data. In my > view, this information must be in the signed image > manifest(certificate in ATF) since an attacker can at-least cause > simple DoS attacks by flipping bits in the FIP header, undetected. If > the bit is flipped, a firmware image going out to a million devices > may not boot, since an attacker decided to flip a bit, and signature > verification fails, since the boot loader decided not decrypt the > firmware based in an unsigned bit of information. PSA appears to have > a better approach and makes no provision such data to be outside the > image manifest, which is always signed. I share this concern. I was actually surprised to see that the TBBR specification advocates putting this security policy bit in the unencrypted part of the FIP, I do not know the rationale for that. Given that TBBR will be deprecated in the future, I wonder whether it would be better to adopt PSA's approach here and move this security policy bit in the signed part of the FIP. This will make this part of the implementation non-TBBR compliant but again, I don't see that as a big concern, as we should look at PSA-TBFU as the future and not worry too much about TBBR if we have good reasons to diverge. > 4) This last one is a matter of opinion and can live with the current > design. The FIP layer is now aware of the crypto module. FIP has also > become coupled with authenticated encryption(If we do this, why not > have the FIP layer call auth_mod_verify_img() and why stop at > cyrpto_mod_auth_decrypt()) . FIP is security aware. I'd like to keep > things the way they are today, where IO and security are separate > modules and glued together by another layer(load_auth_image() for > example). This is cleaner in my view since security policy(should i > decrypt? should i verify signatures? should i apply any security at > all?) is separate from IO. I agree with you. I too found it more elegant and cleaner to have the FIP layer and crypto layer as 2 independent modules. I too feel slightly uncomfortable about introducing such a dependency. But I could not think of a way to avoid it while keeping the security policy bit in the FIP ToC header. That said, if the latter is something we're considering to redesign then we might be able to remove this dependency and keep the design as it is. Regards, Sandrine

5 years, 3 months

1
0
0 0

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

by Sumit Garg

On Fri, 24 Jan 2020 at 04:02, Raghupathy Krishnamurthy <raghu.ncstate(a)icloud.com> wrote: > > I also just realized that both the TBBR and ARM PSA only talk about encryption of the image, and not authenticated encryption. The guarantees provided by both are completely different. Your review(https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2495/) talks about the requirement R060_TBBR_FUNCTION being implemented, which is technically not true(and potentially misleading). We must make a note of this difference and use the appropriate terminology, without mixing the two, in the documentation, commit messages, source code comments and error prints. The tool is also called 'encrypt_fw ' but should maybe be named appropriately to indicate it is doing authenticated encryption. I wouldn't call it misleading. Since firmware encryption feature essentially provides confidentiality protection and authenticated encryption is the type of crypto algorithm which we have used to implement it. > > BTW, ARM PSA(file:///home/raghu/repos/fvp/DEN0072-PSA_TBFU_1-0-REL.pdf) expects that the image manifest(X509 certificate) contain the hash of the ENCRYPTED image(Table 2 and as described in my answer to your question "How would this ensure integrity of ciphertext"). The TBBR spec completely misses this fact, and is a crucial detail if we only implement encryption(as opposed to authenticated encryption).Build_macros.mk, in your change, passes the un-encrypted image to cert-tool. You can get away with it in your implementation, since you are using authenticated encryption, not if you were only implementing firmware encryption. I have already highlighted the issue with signing the ciphertext in my previous reply which deviates from security properties provided by signature verification of plain firmware. So I think we need to revisit ARM PSA TBFU spec. -Sumit > > Is it possible for somebody from ARM to have the TBBR spec updated to reflect this? Also perhaps talk to the spec writers about incorporating authenticated encryption into TBBR and PSA? This patch set is somewhat trailblazing in this regard. > > -Raghu > > > On January 23, 2020 at 12:08 PM, Raghupathy Krishnamurthy via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: > > Hi Sumit, > > > Thanks for your response. > > > So firstly I would suggest you to revisit TBBR spec [1], > > > > [RK] I'm very familiar with the TBBR spec and the requirements. Note that not all SoC's adhere perfectly to the TBBR spec, since it does not apply to devices in all market segments. However, these devices do use arm trusted firmware and TBBR CoT in a slightly modified form, which is still perfectly valid. Also, the TBBR spec can be changed if required :) > > > Why would one use authenticated decryption only to establish TBBR > > Chain of Trust providing device the capability to self sign its firmware? > > [RK] Fair point. However, you may have devices that don't have the processing power or hardware budget or cost factors(paying for HSM's to store private asymmetric keys), to implement asymmetric verification, in which case using authenticated decryption to verify firmware authenticity and integrity is perfectly valid. The attacks on devices that use symmetric keys to verify firmware authenticity and integrity are usually related to exploiting firmware flaws that leak the key or insiders leaking keys, but that is a different problem and requires different solutions. Fundamentally, there is nothing wrong with using symmetric keys for this purpose, so long as the key is well protected. Also note, security requirements and guarantees are different for different systems. The risk is taken by the system designer and should not be imposed by framework code. I don't advocate doing this but it is an option that your implementation does not provide(and perhaps rightly so). > > > How would this ensure integrity of ciphertext? > > > > [RK] You sign the ciphertext. In your design, you pass bl31_enc.bin to cert_tool to sign. You don't decrypt the encrypted cipher text until you have verified the asymmetric signature(which provides integrity). As far as signature verification is concerned, whether you sign the plain text or ciphertext is immaterial, since you are simply verifying that the absolute bits you loaded have not been modified(assuming you use a secure signature scheme). > > > Have a look at some defective sign and encrypt techniques here [2] > > > > [RK] Again, very familiar with [2]. In the S/MIME case, you have multiple parties. With secure boot, you have one party, effectively verifying its own messages across time. There is only one key used to verify signatures. 1.1 and 1.2 does not apply. Also you are encrypting and signing with completely different keys and algorithms. Section 1.2 applies when you use RSA/El-gamal encryption. Here you use symmetric encryption and asymmetric signing. > > > Why would one not use TBBR CoT here? > > > > [RK] see above. Not all systems are designed equal. > > > > and why would one like to hardcode in a device during > > provisioning to boot only either an encrypted or a plain firmware > image? > > > [RK] Why would you not? You typically want to have the same security policy for a class of devices and not be modifiable by an attacker. It isn't common for the same class of devices to use encrypted firmware some times, and un-encrypted firmware other times. If it is common, there is no problem with setting the bit in the FIP header, as long as verified boot is mandatory. The only concern(as my original email said) is the coupling of the FIP layer and the crypto module, in the implementation. I still don't like that fact that the bit saying the file is encrypted is not signed and this may require talking to the TBBR spec writers. Page 22 of the TBBR spec calls out ToC as "Trusted Table of Contents". The FIP header cannot be "trusted", if it is not in ROM or its integrity is verified by some means! R010_TBBR_TOC should perhaps be mandatory then. Also see R080_TBBR_TOC that says the TOC MUST be ROM'ed or tied by hardware in readable registers. This requirement seems contradictory to R010_TBBR_TOC, given that the FIP header(TOC) is copied from mutable NVM by ROM or some boot stage and then ROM'd or loaded into registers. I may be misunderstanding R080_TBBR_TOC, but i'd interpret it as the TOC(FIP header in ATF implementation of TBBR) as being in ROM or integrity verified. > > > How would one handle a case where BL31 is in plain format and BL32 is in encrypted format? > > > > [RK]TBBR CoT is equipped to do this. The table is defined on a per image basis. > > > If you are really paranoid about authentication of FIP header... > > [RK] I don't mean to pontificate but there are real world customers buying real hardware, running ATF code, who care about such details and ask about such things routinely. It is not just me being paranoid and is definitely not a minor matter to think of such details. We should discuss more and consider the implications of R080_TBBR_TOC and R010_TBBR_TOC, perhaps on a different thread, without blocking your code review. Can somebody from ARM clarify these requirements with the spec writers? > > > Thanks > -Raghu > > > On January 23, 2020 at 12:38 AM, Sumit Garg <sumit.garg(a)linaro.org> wrote: > > > Hi Raghu, > > I guess you have completely misunderstood this feature. This is an > optional feature which allows to load encrypted FIP payloads using > authenticated decryption which MUST be used along with signature > verification (or TBBR CoT). > > So firstly I would suggest you to revisit TBBR spec [1], especially > requirements: R040_TBBR_TOC, R060_TBBR_FUNCTION etc. > > On Thu, 23 Jan 2020 at 00:14, Raghupathy Krishnamurthy > <raghu.ncstate(a)icloud.com> wrote: > > > > Hello, > > > The patch stack looks good. The only comment i have is that the FIP layer has now become security aware and supports authenticated decryption(only). This is a deviation from the secure/signed/verified boot design, where we use the TBBR COT to dictate the security operations on the file. This is nice, because file IO is decoupled from the security policy. This may be a big deviation(i apologize if this was considered and shot down for some other reason), but it may be worthwhile to consider making authenticated decryption a part of the authentication framework as opposed to coupling it with the FIP layer. > > It looks like you have mixed both TBBR CoT and this authenticated > decryption feature. They both are completely different and rather > complement each other where TBBR CoT establishes > secure/signed/verified boot and this authenticated decryption feature > provides confidentiality protection for FIP payloads. > > > At a high level, this would mean adding a new authentication method(perhaps AUTH_METHOD_AUTHENTICATED_DECRYPTION), and having the platform specify that the image is using authenticated encryption in the TBBR COT. > > Why would one use authenticated decryption only to establish TBBR > Chain of Trust providing device the capability to self sign its > firmwares? We must use signature verification for TBBR CoT (see > section: 2.1 Authentication of Code Images by Certificate in TBBR spec > [1]). > > > The authentication framework is already well designed and well equipped to handle these types of extensions. > 1) This would make the change simpler, since you would not require changes to the FIP tool and the FIP layer. > 2) This would also allow for future cases where a platform may want to only encrypt the file and use public key authentication on the encrypted file(for ex. the soc does not have a crypto accelerator for aes-gcm but only for AES and public key verification, for whatever reason). > > How would this ensure integrity of ciphertext? This approach may be > vulnerable to Chosen Ciphertext Attacks (CCAs). Authentication tag as > part of AES-GCM provides integrity protection for ciphertext. > > > 3) This would let you choose the order in which you want to do the authenticated decryption(or just decryption) and signature verification, if you use both, one or the other. > > > > Have a look at some defective sign and encrypt techniques here [2]. > The order can't be any arbitrary one, we need to be careful about > this. > > > One other thing i'm not entirely comfortable with is that the flag indicating if there are encrypted files or not in the FIP, is in the *unsigned* portion of the FIP header. An attacker could simply flip bits that dictate security policy in the header and avoid detection(in this case, the indication that the file needs authenticated decryption). If a platform only uses authenticated encryption, but not verified boot, an attacker could flip the bit in the FIP header and have any image loaded on the platform. > > Why would one not use TBBR CoT here? > > > If authenticated encryption cannot be used without verified boot(which requires build time flags), having a flag to indicate that there are encrypted files in the FIP header is moot, since this can come at build time through the TBBR COT. In any case, it seems like the security policy that firmware images need to be decrypted or authenticated with authenticated decryption, seems like a firmware build time or manufacturing time decision(perhaps a bit set in the e-fuses). > > Again you are confusing TBBR CoT with authenticated decryption > feature. And why would one like to hardcode in a device during > provisioning to boot only either an encrypted or a plain firmware > image? > > > There seems to be no benefit to having a flag in the FIP header. > > How would one handle a case where BL31 is in plain format and BL32 is > in encrypted format? > > > Otherwise, I cant think of any attacks due to this and it may be completely okay, but generally, consuming data that dictates security policy/operations before verifying its integrity seems like a recipe for disaster. > > > > If you are really paranoid about authentication of FIP header then you > should look at implementing optional requirement: R010_TBBR_TOC as per > TBBR spec [1]. > > [1] https://developer.arm.com/docs/den0006/latest/trusted-board-boot-requiremen… > [2] http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html > > -Sumit > > > -Raghu > > > On January 22, 2020 at 3:51 AM, Sumit Garg via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: > > > Hi Sandrine, > > > On Wed, 22 Jan 2020 at 15:43, Sandrine Bailleux > <Sandrine.Bailleux(a)arm.com> wrote: > > > > > Hello Sumit, > > > > > Thank you for reworking the patches and addressing all of my review > > > comments. I am happy with the latest version of these and consider them > > > ready to go. I plan to leave them in Gerrit for another week to give > > > extra time for other potential reviewers to have a look and comment. > > > > > > > Thanks for your review. > > > To everyone on the list: Please raise any concerns you may have about > > > these patches in the coming week. If I don't hear anything by 29th > > > January 2020, I will merge these patches. > > > > > @Sumit: One of the next actions for this patch stack would be to have > > > some level of testing in the CI system to detect any potential > > > regressions. We (at Arm) can quite easily add a few build tests but then > > > testing the software stack on QEMU is a bit more involved for various > > > reasons (first instance of QEMU testing, dependencies on OPTEE, UEFI, > > > ...) so this might have to wait for some time. > > > > > > > Okay, will wait for CI testing. > > > -Sumit > > > Regards, > > > Sandrine > > > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 3 months

1
1
0 0

Re: [TF-A] What prevents BL1 FWU SMC's from being called on multiple cores ?

by Raghupathy Krishnamurthy

Never mind. No PSCI SMC's will be available. On January 24, 2020 at 12:20 PM, Raghupathy Krishnamurthy via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: It appears that the BL1 FWU SMC's are written under the assumption that only one core can call the SMC's at any given time but i don't see anything enforcing it. What prevent's this ? -Raghu -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 3 months

1
0
0 0

What prevents BL1 FWU SMC's from being called on multiple cores ?

by Raghupathy Krishnamurthy

It appears that the BL1 FWU SMC's are written under the assumption that only one core can call the SMC's at any given time but i don't see anything enforcing it. What prevent's this ? -Raghu

5 years, 3 months

1
0
0 0

Re: [TF-A] Please revert "Remove RSA PKCS#1 v1.5 support from cert_tool"

by Soby Mathew

On 22/01/2020 12:29, Scott Branden via TF-A wrote: > Please revert the removal of RSA PKCS#1 v1.5 support from cert_tool: > > https://github.com/ARM-software/arm-trusted-firmware/commit/6a415a508ea6ace… > > We have products shipping with such support. I think this problem came > up before when somebody tried removing such support. > They still need to run with the latest yocto codebase. > > Regards, > Scott > Hi Scott, It is untenable for us as maintainers to keep supporting deprecated features in the tree. We need to be able to move the codebase forward. As the commit message says, the RSA PKCS#1.5 support was removed from BL1/BL2 images before this patch, and it no longer made sense to keep the support for just the cert_tool. Seems that you are not using the latest TF-A code for your platform (since PKCS#1.5 is not supported), it does not make sense to pull the latest master just for the tool. So my suggestion would be pin your yocto scripts to a TF-A release that had the support for PKCS#1.5. Best Regards Soby Mathew

5 years, 3 months

2
3
0 0

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

by Raghupathy Krishnamurthy

Hi Sumit, Thanks for your response. >>So firstly I would suggest you to revisit TBBR spec [1], [RK] I'm very familiar with the TBBR spec and the requirements. Note that not all SoC's adhere perfectly to the TBBR spec, since it does not apply to devices in all market segments. However, these devices do use arm trusted firmware and TBBR CoT in a slightly modified form, which is still perfectly valid. Also, the TBBR spec can be changed if required :) >>Why would one use authenticated decryption only to establish TBBR Chain of Trust providing device the capability to self sign its firmware? [RK] Fair point. However, you may have devices that don't have the processing power or hardware budget or cost factors(paying for HSM's to store private asymmetric keys), to implement asymmetric verification, in which case using authenticated decryption to verify firmware authenticity and integrity is perfectly valid. The attacks on devices that use symmetric keys to verify firmware authenticity and integrity are usually related to exploiting firmware flaws that leak the key or insiders leaking keys, but that is a different problem and requires different solutions. Fundamentally, there is nothing wrong with using symmetric keys for this purpose, so long as the key is well protected. Also note, security requirements and guarantees are different for different systems. The risk is taken by the system designer and should not be imposed by framework code. I don't advocate doing this but it is an option that your implementation does not provide(and perhaps rightly so). >>How would this ensure integrity of ciphertext? [RK] You sign the ciphertext. In your design, you pass bl31_enc.bin to cert_tool to sign. You don't decrypt the encrypted cipher text until you have verified the asymmetric signature(which provides integrity). As far as signature verification is concerned, whether you sign the plain text or ciphertext is immaterial, since you are simply verifying that the absolute bits you loaded have not been modified(assuming you use a secure signature scheme). >>Have a look at some defective sign and encrypt techniques here [2] [RK] Again, very familiar with [2]. In the S/MIME case, you have multiple parties. With secure boot, you have one party, effectively verifying its own messages across time. There is only one key used to verify signatures. 1.1 and 1.2 does not apply. Also you are encrypting and signing with completely different keys and algorithms. Section 1.2 applies when you use RSA/El-gamal encryption. Here you use symmetric encryption and asymmetric signing. >>Why would one not use TBBR CoT here? [RK] see above. Not all systems are designed equal. >>and why would one like to hardcode in a device during provisioning to boot only either an encrypted or a plain firmware image? [RK] Why would you not? You typically want to have the same security policy for a class of devices and not be modifiable by an attacker. It isn't common for the same class of devices to use encrypted firmware some times, and un-encrypted firmware other times. If it is common, there is no problem with setting the bit in the FIP header, as long as verified boot is mandatory. The only concern(as my original email said) is the coupling of the FIP layer and the crypto module, in the implementation. I still don't like that fact that the bit saying the file is encrypted is not signed and this may require talking to the TBBR spec writers. Page 22 of the TBBR spec calls out ToC as "Trusted Table of Contents". The FIP header cannot be "trusted", if it is not in ROM or its integrity is verified by some means! R010_TBBR_TOC should perhaps be mandatory then. Also see R080_TBBR_TOC that says the TOC MUST be ROM'ed or tied by hardware in readable registers. This requirement seems contradictory to R010_TBBR_TOC, given that the FIP header(TOC) is copied from mutable NVM by ROM or some boot stage and then ROM'd or loaded into registers. I may be misunderstanding R080_TBBR_TOC, but i'd interpret it as the TOC(FIP header in ATF implementation of TBBR) as being in ROM or integrity verified. >>How would one handle a case where BL31 is in plain format and BL32 is in encrypted format? [RK]TBBR CoT is equipped to do this. The table is defined on a per image basis. >>If you are really paranoid about authentication of FIP header... [RK] I don't mean to pontificate but there are real world customers buying real hardware, running ATF code, who care about such details and ask about such things routinely. It is not just me being paranoid and is definitely not a minor matter to think of such details. We should discuss more and consider the implications of R080_TBBR_TOC and R010_TBBR_TOC, perhaps on a different thread, without blocking your code review. Can somebody from ARM clarify these requirements with the spec writers? Thanks -Raghu On January 23, 2020 at 12:38 AM, Sumit Garg <sumit.garg(a)linaro.org> wrote: Hi Raghu, I guess you have completely misunderstood this feature. This is an optional feature which allows to load encrypted FIP payloads using authenticated decryption which MUST be used along with signature verification (or TBBR CoT). So firstly I would suggest you to revisit TBBR spec [1], especially requirements: R040_TBBR_TOC, R060_TBBR_FUNCTION etc. On Thu, 23 Jan 2020 at 00:14, Raghupathy Krishnamurthy <raghu.ncstate(a)icloud.com> wrote: Hello, The patch stack looks good. The only comment i have is that the FIP layer has now become security aware and supports authenticated decryption(only). This is a deviation from the secure/signed/verified boot design, where we use the TBBR COT to dictate the security operations on the file. This is nice, because file IO is decoupled from the security policy. This may be a big deviation(i apologize if this was considered and shot down for some other reason), but it may be worthwhile to consider making authenticated decryption a part of the authentication framework as opposed to coupling it with the FIP layer. It looks like you have mixed both TBBR CoT and this authenticated decryption feature. They both are completely different and rather complement each other where TBBR CoT establishes secure/signed/verified boot and this authenticated decryption feature provides confidentiality protection for FIP payloads. At a high level, this would mean adding a new authentication method(perhaps AUTH_METHOD_AUTHENTICATED_DECRYPTION), and having the platform specify that the image is using authenticated encryption in the TBBR COT. Why would one use authenticated decryption only to establish TBBR Chain of Trust providing device the capability to self sign its firmwares? We must use signature verification for TBBR CoT (see section: 2.1 Authentication of Code Images by Certificate in TBBR spec [1]). The authentication framework is already well designed and well equipped to handle these types of extensions. 1) This would make the change simpler, since you would not require changes to the FIP tool and the FIP layer. 2) This would also allow for future cases where a platform may want to only encrypt the file and use public key authentication on the encrypted file(for ex. the soc does not have a crypto accelerator for aes-gcm but only for AES and public key verification, for whatever reason). How would this ensure integrity of ciphertext? This approach may be vulnerable to Chosen Ciphertext Attacks (CCAs). Authentication tag as part of AES-GCM provides integrity protection for ciphertext. 3) This would let you choose the order in which you want to do the authenticated decryption(or just decryption) and signature verification, if you use both, one or the other. Have a look at some defective sign and encrypt techniques here [2]. The order can't be any arbitrary one, we need to be careful about this. One other thing i'm not entirely comfortable with is that the flag indicating if there are encrypted files or not in the FIP, is in the *unsigned* portion of the FIP header. An attacker could simply flip bits that dictate security policy in the header and avoid detection(in this case, the indication that the file needs authenticated decryption). If a platform only uses authenticated encryption, but not verified boot, an attacker could flip the bit in the FIP header and have any image loaded on the platform. Why would one not use TBBR CoT here? If authenticated encryption cannot be used without verified boot(which requires build time flags), having a flag to indicate that there are encrypted files in the FIP header is moot, since this can come at build time through the TBBR COT. In any case, it seems like the security policy that firmware images need to be decrypted or authenticated with authenticated decryption, seems like a firmware build time or manufacturing time decision(perhaps a bit set in the e-fuses). Again you are confusing TBBR CoT with authenticated decryption feature. And why would one like to hardcode in a device during provisioning to boot only either an encrypted or a plain firmware image? There seems to be no benefit to having a flag in the FIP header. How would one handle a case where BL31 is in plain format and BL32 is in encrypted format? Otherwise, I cant think of any attacks due to this and it may be completely okay, but generally, consuming data that dictates security policy/operations before verifying its integrity seems like a recipe for disaster. If you are really paranoid about authentication of FIP header then you should look at implementing optional requirement: R010_TBBR_TOC as per TBBR spec [1]. [1] https://developer.arm.com/docs/den0006/latest/trusted-board-boot-requiremen… [2] http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html -Sumit -Raghu On January 22, 2020 at 3:51 AM, Sumit Garg via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: Hi Sandrine, On Wed, 22 Jan 2020 at 15:43, Sandrine Bailleux <Sandrine.Bailleux(a)arm.com> wrote: Hello Sumit, Thank you for reworking the patches and addressing all of my review comments. I am happy with the latest version of these and consider them ready to go. I plan to leave them in Gerrit for another week to give extra time for other potential reviewers to have a look and comment. Thanks for your review. To everyone on the list: Please raise any concerns you may have about these patches in the coming week. If I don't hear anything by 29th January 2020, I will merge these patches. @Sumit: One of the next actions for this patch stack would be to have some level of testing in the CI system to detect any potential regressions. We (at Arm) can quite easily add a few build tests but then testing the software stack on QEMU is a bit more involved for various reasons (first instance of QEMU testing, dependencies on OPTEE, UEFI, ...) so this might have to wait for some time. Okay, will wait for CI testing. -Sumit Regards, Sandrine -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 3 months

2
1
0 0

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

by Raghupathy Krishnamurthy

+tf a list On January 23, 2020 at 2:32 PM, Raghupathy Krishnamurthy <raghu.ncstate(a)icloud.com> wrote: I also just realized that both the TBBR and ARM PSA only talk about encryption of the image, and not authenticated encryption. The guarantees provided by both are completely different. Your review(https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2495/) talks about the requirement R060_TBBR_FUNCTION being implemented, which is technically not true(and potentially misleading). We must make a note of this difference and use the appropriate terminology, without mixing the two, in the documentation, commit messages, source code comments and error prints. The tool is also called 'encrypt_fw ' but should maybe be named appropriately to indicate it is doing authenticated encryption. BTW, ARM PSA(file:///home/raghu/repos/fvp/DEN0072-PSA_TBFU_1-0-REL.pdf) expects that the image manifest(X509 certificate) contain the hash of the ENCRYPTED image(Table 2 and as described in my answer to your question "How would this ensure integrity of ciphertext"). The TBBR spec completely misses this fact, and is a crucial detail if we only implement encryption(as opposed to authenticated encryption).Build_macros.mk, in your change, passes the un-encrypted image to cert-tool. You can get away with it in your implementation, since you are using authenticated encryption, not if you were only implementing firmware encryption. Is it possible for somebody from ARM to have the TBBR spec updated to reflect this? Also perhaps talk to the spec writers about incorporating authenticated encryption into TBBR and PSA? This patch set is somewhat trailblazing in this regard. -Raghu On January 23, 2020 at 12:08 PM, Raghupathy Krishnamurthy via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: Hi Sumit, Thanks for your response. So firstly I would suggest you to revisit TBBR spec [1], [RK] I'm very familiar with the TBBR spec and the requirements. Note that not all SoC's adhere perfectly to the TBBR spec, since it does not apply to devices in all market segments. However, these devices do use arm trusted firmware and TBBR CoT in a slightly modified form, which is still perfectly valid. Also, the TBBR spec can be changed if required :) Why would one use authenticated decryption only to establish TBBR Chain of Trust providing device the capability to self sign its firmware? [RK] Fair point. However, you may have devices that don't have the processing power or hardware budget or cost factors(paying for HSM's to store private asymmetric keys), to implement asymmetric verification, in which case using authenticated decryption to verify firmware authenticity and integrity is perfectly valid. The attacks on devices that use symmetric keys to verify firmware authenticity and integrity are usually related to exploiting firmware flaws that leak the key or insiders leaking keys, but that is a different problem and requires different solutions. Fundamentally, there is nothing wrong with using symmetric keys for this purpose, so long as the key is well protected. Also note, security requirements and guarantees are different for different systems. The risk is taken by the system designer and should not be imposed by framework code. I don't advocate doing this but it is an option that your implementation does not provide(and perhaps rightly so). How would this ensure integrity of ciphertext? [RK] You sign the ciphertext. In your design, you pass bl31_enc.bin to cert_tool to sign. You don't decrypt the encrypted cipher text until you have verified the asymmetric signature(which provides integrity). As far as signature verification is concerned, whether you sign the plain text or ciphertext is immaterial, since you are simply verifying that the absolute bits you loaded have not been modified(assuming you use a secure signature scheme). Have a look at some defective sign and encrypt techniques here [2] [RK] Again, very familiar with [2]. In the S/MIME case, you have multiple parties. With secure boot, you have one party, effectively verifying its own messages across time. There is only one key used to verify signatures. 1.1 and 1.2 does not apply. Also you are encrypting and signing with completely different keys and algorithms. Section 1.2 applies when you use RSA/El-gamal encryption. Here you use symmetric encryption and asymmetric signing. Why would one not use TBBR CoT here? [RK] see above. Not all systems are designed equal. and why would one like to hardcode in a device during provisioning to boot only either an encrypted or a plain firmware image? [RK] Why would you not? You typically want to have the same security policy for a class of devices and not be modifiable by an attacker. It isn't common for the same class of devices to use encrypted firmware some times, and un-encrypted firmware other times. If it is common, there is no problem with setting the bit in the FIP header, as long as verified boot is mandatory. The only concern(as my original email said) is the coupling of the FIP layer and the crypto module, in the implementation. I still don't like that fact that the bit saying the file is encrypted is not signed and this may require talking to the TBBR spec writers. Page 22 of the TBBR spec calls out ToC as "Trusted Table of Contents". The FIP header cannot be "trusted", if it is not in ROM or its integrity is verified by some means! R010_TBBR_TOC should perhaps be mandatory then. Also see R080_TBBR_TOC that says the TOC MUST be ROM'ed or tied by hardware in readable registers. This requirement seems contradictory to R010_TBBR_TOC, given that the FIP header(TOC) is copied from mutable NVM by ROM or some boot stage and then ROM'd or loaded into registers. I may be misunderstanding R080_TBBR_TOC, but i'd interpret it as the TOC(FIP header in ATF implementation of TBBR) as being in ROM or integrity verified. How would one handle a case where BL31 is in plain format and BL32 is in encrypted format? [RK]TBBR CoT is equipped to do this. The table is defined on a per image basis. If you are really paranoid about authentication of FIP header... [RK] I don't mean to pontificate but there are real world customers buying real hardware, running ATF code, who care about such details and ask about such things routinely. It is not just me being paranoid and is definitely not a minor matter to think of such details. We should discuss more and consider the implications of R080_TBBR_TOC and R010_TBBR_TOC, perhaps on a different thread, without blocking your code review. Can somebody from ARM clarify these requirements with the spec writers? Thanks -Raghu On January 23, 2020 at 12:38 AM, Sumit Garg <sumit.garg(a)linaro.org> wrote: Hi Raghu, I guess you have completely misunderstood this feature. This is an optional feature which allows to load encrypted FIP payloads using authenticated decryption which MUST be used along with signature verification (or TBBR CoT). So firstly I would suggest you to revisit TBBR spec [1], especially requirements: R040_TBBR_TOC, R060_TBBR_FUNCTION etc. On Thu, 23 Jan 2020 at 00:14, Raghupathy Krishnamurthy <raghu.ncstate(a)icloud.com> wrote: Hello, The patch stack looks good. The only comment i have is that the FIP layer has now become security aware and supports authenticated decryption(only). This is a deviation from the secure/signed/verified boot design, where we use the TBBR COT to dictate the security operations on the file. This is nice, because file IO is decoupled from the security policy. This may be a big deviation(i apologize if this was considered and shot down for some other reason), but it may be worthwhile to consider making authenticated decryption a part of the authentication framework as opposed to coupling it with the FIP layer. It looks like you have mixed both TBBR CoT and this authenticated decryption feature. They both are completely different and rather complement each other where TBBR CoT establishes secure/signed/verified boot and this authenticated decryption feature provides confidentiality protection for FIP payloads. At a high level, this would mean adding a new authentication method(perhaps AUTH_METHOD_AUTHENTICATED_DECRYPTION), and having the platform specify that the image is using authenticated encryption in the TBBR COT. Why would one use authenticated decryption only to establish TBBR Chain of Trust providing device the capability to self sign its firmwares? We must use signature verification for TBBR CoT (see section: 2.1 Authentication of Code Images by Certificate in TBBR spec [1]). The authentication framework is already well designed and well equipped to handle these types of extensions. 1) This would make the change simpler, since you would not require changes to the FIP tool and the FIP layer. 2) This would also allow for future cases where a platform may want to only encrypt the file and use public key authentication on the encrypted file(for ex. the soc does not have a crypto accelerator for aes-gcm but only for AES and public key verification, for whatever reason). How would this ensure integrity of ciphertext? This approach may be vulnerable to Chosen Ciphertext Attacks (CCAs). Authentication tag as part of AES-GCM provides integrity protection for ciphertext. 3) This would let you choose the order in which you want to do the authenticated decryption(or just decryption) and signature verification, if you use both, one or the other. Have a look at some defective sign and encrypt techniques here [2]. The order can't be any arbitrary one, we need to be careful about this. One other thing i'm not entirely comfortable with is that the flag indicating if there are encrypted files or not in the FIP, is in the *unsigned* portion of the FIP header. An attacker could simply flip bits that dictate security policy in the header and avoid detection(in this case, the indication that the file needs authenticated decryption). If a platform only uses authenticated encryption, but not verified boot, an attacker could flip the bit in the FIP header and have any image loaded on the platform. Why would one not use TBBR CoT here? If authenticated encryption cannot be used without verified boot(which requires build time flags), having a flag to indicate that there are encrypted files in the FIP header is moot, since this can come at build time through the TBBR COT. In any case, it seems like the security policy that firmware images need to be decrypted or authenticated with authenticated decryption, seems like a firmware build time or manufacturing time decision(perhaps a bit set in the e-fuses). Again you are confusing TBBR CoT with authenticated decryption feature. And why would one like to hardcode in a device during provisioning to boot only either an encrypted or a plain firmware image? There seems to be no benefit to having a flag in the FIP header. How would one handle a case where BL31 is in plain format and BL32 is in encrypted format? Otherwise, I cant think of any attacks due to this and it may be completely okay, but generally, consuming data that dictates security policy/operations before verifying its integrity seems like a recipe for disaster. If you are really paranoid about authentication of FIP header then you should look at implementing optional requirement: R010_TBBR_TOC as per TBBR spec [1]. [1] https://developer.arm.com/docs/den0006/latest/trusted-board-boot-requiremen… [2] http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html -Sumit -Raghu On January 22, 2020 at 3:51 AM, Sumit Garg via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: Hi Sandrine, On Wed, 22 Jan 2020 at 15:43, Sandrine Bailleux <Sandrine.Bailleux(a)arm.com> wrote: Hello Sumit, Thank you for reworking the patches and addressing all of my review comments. I am happy with the latest version of these and consider them ready to go. I plan to leave them in Gerrit for another week to give extra time for other potential reviewers to have a look and comment. Thanks for your review. To everyone on the list: Please raise any concerns you may have about these patches in the coming week. If I don't hear anything by 29th January 2020, I will merge these patches. @Sumit: One of the next actions for this patch stack would be to have some level of testing in the CI system to detect any potential regressions. We (at Arm) can quite easily add a few build tests but then testing the software stack on QEMU is a bit more involved for various reasons (first instance of QEMU testing, dependencies on OPTEE, UEFI, ...) so this might have to wait for some time. Okay, will wait for CI testing. -Sumit Regards, Sandrine -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 3 months

1
0
0 0

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

by Sumit Garg

Hi Raghu, I guess you have completely misunderstood this feature. This is an optional feature which allows to load encrypted FIP payloads using authenticated decryption which MUST be used along with signature verification (or TBBR CoT). So firstly I would suggest you to revisit TBBR spec [1], especially requirements: R040_TBBR_TOC, R060_TBBR_FUNCTION etc. On Thu, 23 Jan 2020 at 00:14, Raghupathy Krishnamurthy <raghu.ncstate(a)icloud.com> wrote: > > Hello, > > The patch stack looks good. The only comment i have is that the FIP layer has now become security aware and supports authenticated decryption(only). This is a deviation from the secure/signed/verified boot design, where we use the TBBR COT to dictate the security operations on the file. This is nice, because file IO is decoupled from the security policy. This may be a big deviation(i apologize if this was considered and shot down for some other reason), but it may be worthwhile to consider making authenticated decryption a part of the authentication framework as opposed to coupling it with the FIP layer. It looks like you have mixed both TBBR CoT and this authenticated decryption feature. They both are completely different and rather complement each other where TBBR CoT establishes secure/signed/verified boot and this authenticated decryption feature provides confidentiality protection for FIP payloads. > At a high level, this would mean adding a new authentication method(perhaps AUTH_METHOD_AUTHENTICATED_DECRYPTION), and having the platform specify that the image is using authenticated encryption in the TBBR COT. Why would one use authenticated decryption only to establish TBBR Chain of Trust providing device the capability to self sign its firmwares? We must use signature verification for TBBR CoT (see section: 2.1 Authentication of Code Images by Certificate in TBBR spec [1]). > The authentication framework is already well designed and well equipped to handle these types of extensions. > 1) This would make the change simpler, since you would not require changes to the FIP tool and the FIP layer. > 2) This would also allow for future cases where a platform may want to only encrypt the file and use public key authentication on the encrypted file(for ex. the soc does not have a crypto accelerator for aes-gcm but only for AES and public key verification, for whatever reason). How would this ensure integrity of ciphertext? This approach may be vulnerable to Chosen Ciphertext Attacks (CCAs). Authentication tag as part of AES-GCM provides integrity protection for ciphertext. > 3) This would let you choose the order in which you want to do the authenticated decryption(or just decryption) and signature verification, if you use both, one or the other. > Have a look at some defective sign and encrypt techniques here [2]. The order can't be any arbitrary one, we need to be careful about this. > One other thing i'm not entirely comfortable with is that the flag indicating if there are encrypted files or not in the FIP, is in the *unsigned* portion of the FIP header. An attacker could simply flip bits that dictate security policy in the header and avoid detection(in this case, the indication that the file needs authenticated decryption). If a platform only uses authenticated encryption, but not verified boot, an attacker could flip the bit in the FIP header and have any image loaded on the platform. Why would one not use TBBR CoT here? > If authenticated encryption cannot be used without verified boot(which requires build time flags), having a flag to indicate that there are encrypted files in the FIP header is moot, since this can come at build time through the TBBR COT. In any case, it seems like the security policy that firmware images need to be decrypted or authenticated with authenticated decryption, seems like a firmware build time or manufacturing time decision(perhaps a bit set in the e-fuses). Again you are confusing TBBR CoT with authenticated decryption feature. And why would one like to hardcode in a device during provisioning to boot only either an encrypted or a plain firmware image? > There seems to be no benefit to having a flag in the FIP header. How would one handle a case where BL31 is in plain format and BL32 is in encrypted format? > Otherwise, I cant think of any attacks due to this and it may be completely okay, but generally, consuming data that dictates security policy/operations before verifying its integrity seems like a recipe for disaster. > If you are really paranoid about authentication of FIP header then you should look at implementing optional requirement: R010_TBBR_TOC as per TBBR spec [1]. [1] https://developer.arm.com/docs/den0006/latest/trusted-board-boot-requiremen… [2] http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html -Sumit > -Raghu > > On January 22, 2020 at 3:51 AM, Sumit Garg via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: > > Hi Sandrine, > > On Wed, 22 Jan 2020 at 15:43, Sandrine Bailleux > <Sandrine.Bailleux(a)arm.com> wrote: > > > Hello Sumit, > > > Thank you for reworking the patches and addressing all of my review > > comments. I am happy with the latest version of these and consider them > > ready to go. I plan to leave them in Gerrit for another week to give > > extra time for other potential reviewers to have a look and comment. > > > > Thanks for your review. > > To everyone on the list: Please raise any concerns you may have about > > these patches in the coming week. If I don't hear anything by 29th > > January 2020, I will merge these patches. > > > @Sumit: One of the next actions for this patch stack would be to have > > some level of testing in the CI system to detect any potential > > regressions. We (at Arm) can quite easily add a few build tests but then > > testing the software stack on QEMU is a bit more involved for various > > reasons (first instance of QEMU testing, dependencies on OPTEE, UEFI, > > ...) so this might have to wait for some time. > > > > Okay, will wait for CI testing. > > -Sumit > > Regards, > > Sandrine > > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 3 months

1
0
0 0

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

by Raghupathy Krishnamurthy

Forgot to add TF-A list(why is it not automatically on when you hit reply all ?) On January 22, 2020 at 10:44 AM, Raghupathy Krishnamurthy <raghu.ncstate(a)icloud.com> wrote: Hello, The patch stack looks good. The only comment i have is that the FIP layer has now become security aware and supports authenticated decryption(only). This is a deviation from the secure/signed/verified boot design, where we use the TBBR COT to dictate the security operations on the file. This is nice, because file IO is decoupled from the security policy. This may be a big deviation(i apologize if this was considered and shot down for some other reason), but it may be worthwhile to consider making authenticated decryption a part of the authentication framework as opposed to coupling it with the FIP layer. At a high level, this would mean adding a new authentication method(perhaps AUTH_METHOD_AUTHENTICATED_DECRYPTION), and having the platform specify that the image is using authenticated encryption in the TBBR COT. The authentication framework is already well designed and well equipped to handle these types of extensions. 1) This would make the change simpler, since you would not require changes to the FIP tool and the FIP layer. 2) This would also allow for future cases where a platform may want to only encrypt the file and use public key authentication on the encrypted file(for ex. the soc does not have a crypto accelerator for aes-gcm but only for AES and public key verification, for whatever reason). 3) This would let you choose the order in which you want to do the authenticated decryption(or just decryption) and signature verification, if you use both, one or the other. One other thing i'm not entirely comfortable with is that the flag indicating if there are encrypted files or not in the FIP, is in the *unsigned* portion of the FIP header. An attacker could simply flip bits that dictate security policy in the header and avoid detection(in this case, the indication that the file needs authenticated decryption). If a platform only uses authenticated encryption, but not verified boot, an attacker could flip the bit in the FIP header and have any image loaded on the platform. If authenticated encryption cannot be used without verified boot(which requires build time flags), having a flag to indicate that there are encrypted files in the FIP header is moot, since this can come at build time through the TBBR COT. In any case, it seems like the security policy that firmware images need to be decrypted or authenticated with authenticated decryption, seems like a firmware build time or manufacturing time decision(perhaps a bit set in the e-fuses). There seems to be no benefit to having a flag in the FIP header. Otherwise, I cant think of any attacks due to this and it may be completely okay, but generally, consuming data that dictates security policy/operations before verifying its integrity seems like a recipe for disaster. -Raghu On January 22, 2020 at 3:51 AM, Sumit Garg via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: Hi Sandrine, On Wed, 22 Jan 2020 at 15:43, Sandrine Bailleux <Sandrine.Bailleux(a)arm.com> wrote: Hello Sumit, Thank you for reworking the patches and addressing all of my review comments. I am happy with the latest version of these and consider them ready to go. I plan to leave them in Gerrit for another week to give extra time for other potential reviewers to have a look and comment. Thanks for your review. To everyone on the list: Please raise any concerns you may have about these patches in the coming week. If I don't hear anything by 29th January 2020, I will merge these patches. @Sumit: One of the next actions for this patch stack would be to have some level of testing in the CI system to detect any potential regressions. We (at Arm) can quite easily add a few build tests but then testing the software stack on QEMU is a bit more involved for various reasons (first instance of QEMU testing, dependencies on OPTEE, UEFI, ...) so this might have to wait for some time. Okay, will wait for CI testing. -Sumit Regards, Sandrine -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 3 months

1
0
0 0

GCC toolchain upgrade in CI

by Madhukar Pappireddy

Hi, We have upgraded Trusted Firmware-A CI to use the GCC toolchain version 9.2.-2019.12 publicly available through developer.arm.com [1]. The relevant documentation has been updated [2] to reflect the use of these cross compilers. We request the platform maintainers to update their respective platform documentation ( trusted-firmware-a/docs/plat/*.rst) as needed. AArch32 bare-metal target (arm-none-eabi) AArch64 ELF bare-metal target (aarch64-none-elf) [1] https://developer.arm.com/tools-and-software/open-source-software/developer… [2] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=f35e… Thanks, Madhukar

5 years, 3 months

1
0
0 0

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

by Sandrine Bailleux

Hello Sumit, Thank you for reworking the patches and addressing all of my review comments. I am happy with the latest version of these and consider them ready to go. I plan to leave them in Gerrit for another week to give extra time for other potential reviewers to have a look and comment. To everyone on the list: Please raise any concerns you may have about these patches in the coming week. If I don't hear anything by 29th January 2020, I will merge these patches. @Sumit: One of the next actions for this patch stack would be to have some level of testing in the CI system to detect any potential regressions. We (at Arm) can quite easily add a few build tests but then testing the software stack on QEMU is a bit more involved for various reasons (first instance of QEMU testing, dependencies on OPTEE, UEFI, ...) so this might have to wait for some time. Regards, Sandrine

5 years, 3 months

2
1
0 0

Re: [TF-A] Who better implements a safe environment: cortex-M or cortex-A?

by Joanna Farley

Hi Iñigo, We needs a little bit more information to know how best to answer your question. Is this just an academic question of is there a real use case you are trying to decide on which way to go? Its not so much a question of which architecture is easier its just that they are different with Cortex-M powering the most energy-efficient embedded devices where as Cortex-A is offering supreme performance at optimal power. Each architecture offers different hardware constraints and the secure TrustZone is implemented to handle each and an ecosystem of solutions surrounds each. If this is an academic question I would refer you to Arm's pages on TrustZone as a starting point: https://www.arm.com/why-arm/technologies/trustzone-for-cortex-m https://www.arm.com/why-arm/technologies/trustzone-for-cortex-a If there is need for guidance on a specific solution or difficulties you are trying to overcome while building a solution please give us some more details. Thanks Joanna On 22/01/2020, 08:07, "TF-A on behalf of Iñigo Vicente Waliño via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: Hi, Can someone explain to me why it is easier to implement a secure TrustZone environment with secure boot and storage and PSA certificate in cortex-M than in cortex-A? Who better implements a safe environment: cortex-M or cortex-A? Why? Thanks. -- 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. 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.

5 years, 3 months

1
0
0 0

Who better implements a safe environment: cortex-M or cortex-A?

by Iñigo Vicente Waliño

Hi, Can someone explain to me why it is easier to implement a secure TrustZone environment with secure boot and storage and PSA certificate in cortex-M than in cortex-A? Who better implements a safe environment: cortex-M or cortex-A? Why? Thanks.

5 years, 3 months

1
0
0 0

Please revert "Remove RSA PKCS#1 v1.5 support from cert_tool"

by Scott Branden

Please revert the removal of RSA PKCS#1 v1.5 support from cert_tool: https://github.com/ARM-software/arm-trusted-firmware/commit/6a415a508ea6ace… We have products shipping with such support. I think this problem came up before when somebody tried removing such support. They still need to run with the latest yocto codebase. Regards, Scott

5 years, 3 months

1
0
0 0

Re: [TF-A] Gerrit review latency

by Joanna Farley

Hi Varun, It can be a challenge to keep on top of the reviews and we are aware of the backlog increase after the end of year break and trying different approaches to get reviews completed. Any suggestions on process improvements from the developer community at large are welcome. Cheers Joanna On 16/01/2020, 17:34, "TF-A on behalf of Varun Wadekar via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: Hello, We (NVIDIA) frequently post changes on the TF-A gerrit dashboard and wait for the maintainers to gradually get to them. This is very time consuming and non-deterministic. Curious to know if other developers face the same problems or are we missing something when asking for reviews? If most of us face the same problems, then we should try to formulate a process to reduce the latency. Thoughts? -Varun ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ----------------------------------------------------------------------------------- -- 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. 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.

5 years, 4 months

2
1
0 0

Gerrit review latency

by Varun Wadekar

Hello, We (NVIDIA) frequently post changes on the TF-A gerrit dashboard and wait for the maintainers to gradually get to them. This is very time consuming and non-deterministic. Curious to know if other developers face the same problems or are we missing something when asking for reviews? If most of us face the same problems, then we should try to formulate a process to reduce the latency. Thoughts? -Varun ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. -----------------------------------------------------------------------------------

5 years, 4 months

1
0
0 0

Re: [TF-A] SMC to intentionally trigger a panic in TF-A

by Soby Mathew

On 13/12/2019 22:04, Julius Werner via TF-A wrote: > On Fri, Dec 13, 2019 at 6:20 AM Joanna Farley <Joanna.Farley(a)arm.com> wrote: >> On the subject of DebugFS's purpose it was envisages and is today as Sandrine describes as a debug build only capability. Saying that though there has been some early thoughts that it could evolve into a Secure Debug feature where this type of capability or something like it is always on requiring debug certificates for authenticated access. This is something very much for a possible future evolution and is not in the patches available today. We would welcome any thoughts on such an evolution in this space. > > I guess this gets into a bit of a philosophy discussion and becomes a > matter of opinion, so there's probably no one right answer. > Personally, adding authentication on top of this doesn't really > resolve my concerns and adds yet more on top. I'm a strong proponent > of the concept of a minimal Trusted Computing Base, i.e. keeping the > amount of code executing at the highest privilege level as small and > low-complexity as possible. Any code can have bugs, so the idea is > that the more complicated the code you run in EL3 is (and the more > complicated APIs it exposes), the more likely it becomes that you > accidentally have an exploitable vulnerability in there. Like a p9 > filesystem driver, a certificate-based authentication system > (especially if it's based on x509/ASN.1 which are notoriously hard to > implement safely) is a pretty complex piece of code with a pretty > large attack surface that I'd rather not have in my EL3 firmware if I > can avoid it. I understand that for certain use cases you may need > something like this (if you really want a very extensive and > extensible debugging API that must be restricted to a few > authenticated actors), but in my use case I really just need the > ability to trigger one small debugging feature and that feature itself > doesn't need to be restricted, so a minimal SMC interface would work > much better for that case. Hi Julius, Just to trying to understand, if TF-A were to expose a crash inducing SMC, this would still be restricted to special builds for your test runs ? This would not make it to production for Chromebook right ? I agree 9p filesystem is not desirable in a EL3 runtime firmware. We could enhance it to use a more tight data structure, if there is a desire in that direction. If that is the case, leaving aside the 9p filesystem issues, can DebugFS serve this requirement (we can remove the limitation that it is restricted to only Debug builds) ? The intention that DebugFS can prove useful atleast in the verification/testing space and if there is more we can do to get there, it would be good to know. > >> On 13/12/2019, 13:01, "TF-A on behalf of Sandrine Bailleux via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: >> Going back to the SMC-based solution then, I am not quite convinced >> SYSTEM_RESET2 is the right interface for intentionally triggering a >> panic in TF-A. I think the semantics do not quite match. If anything, a >> firmware crash seems more like a shutdown operation to me rather than a >> reset (we don't recover from a firmware crash). I am not even sure we >> should look into the PSCI SMC range, as it's not a power-management >> operation. > > Crash recovery behavior is platform dependent (via > plat_panic_handler()). On all the platforms we use in Chrome OS we > have that implemented as a system reboot. I think for most systems > (whether it's a Chromebook, a server or some embedded device) that's > probably what you want for random runtime crashes (and least in a > production environment), but I agree that TF doesn't enforce any > standard behavior so it's hard to clearly match it to one or the other > SMC. > >> So it sounds like it's not the first time that you hit this issue, is >> it? Do you have any other example of Normal World OS feature you would >> have liked to expose through a generic SMC interface? I am wondering >> whether this could help choosing the right SMC range, if we can identify >> some common criteria among a set of such features. > > No, it's the first time I've really run into this. But I think we > might quickly come up with more uses for a "non-secure OS" SMC range > if we had one. We often see roughly the same SMC again on different > platforms, because fundamentally they usually need to do the same > kinds of things -- for example, most platforms have some kind of DDR > frequency scaling which always needs part of it implemented in EL3, so > they all need some kind of SMC to switch to a new DDR frequency. Many > also need some kind of "write value to secure register" SMC that just > allows the non-secure OS to write a few whitelisted registers that are > only accessible in EL3 for some reason. If we could standardize these > interfaces in a non-vendor-specific SMC range, we might be able to > reduce some code duplication both on the TF and the Linux side. > > I guess none of these things are really Linux-specific, now that I > think of it. So really, I guess the problem is that it would be great > to have a range of "generic" SMC IDs that can be easily and > unbureaucratically allocated to try out new features, without having > to ask Arm to write a big specification document about it every time. > It's sort of a development velocity issue. > We have utilized the ARM SiP range for some "generic" purposes in the past (see PMF and the execution state switch SMCs). This could be direction for the some of use-cases. But if the SMCs are meant to be truly generic and to be relied on for use by generic normal world software components, it would need to be properly specified I would think. For dynamically modifying some EL3 registers, it would be good to get these requirements out. Perhaps there is scope for architecting some of them as an ARM specification. If not, we could revert to a TF-A standard if there is enough pull for them (perhaps utilizing the ARM SiP range). Best Regards Soby Mathew

5 years, 4 months

2
1
0 0

Re: [TF-A] 回复：回复： MMU Table in ARM Trust-Firmware-A

by Dan Handley

Hi Just to add to this: Given that: * Your BL31 is nearly 64KB on its own, and * DDR attacks are more feasible on runtime resident code (e.g. BL31) Perhaps another more secure solution would be to do DDR init in BL1 or a new transient BL1.5 stage in SRAM. That way you could run BL31 in SRAM, and BL2 and other boot stages in DDR. You would still need to cut down the BL1_RW size though for this to work. One way to cut down the memory used for page tables is to map all the required memory/devices in larger/fewer address ranges, and align the ranges on block boundaries (i.e. 2MB or 1GB for 4KB translation granules). Although this means mapping in unused address space, which might be less secure, it uses less memory for page tables. Regards Dan. > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Soby Mathew > via TF-A > Sent: 13 January 2020 15:13 > To: Raghupathy Krishnamurthy <raghu.ncstate(a)icloud.com>; "严鸿亮(鸿先)" > <hongxian.yhl(a)alibaba-inc.com>; tf-a(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: Re: [TF-A] 回复：回复： MMU Table in ARM Trust-Firmware-A > > [Adding back TF-A list] > Hi Raghu > Since the same DRAM is partitioned to run both non-secure and secure software, > it is susceptible to Row Hammer attacks. Also depending on how accessible the > DRAM interface is, the DDR PHY can be probed for transactions. If the DRAM is > removable, then it can be deep frozen to retain values and plugged into > another system to extract contents. Hence the less `secure` comment. > > Best Regards > Soby Mathew > > From: Raghupathy Krishnamurthy <raghu.ncstate(a)icloud.com> > Sent: 13 January 2020 14:36 > To: "严鸿亮(鸿先)" <hongxian.yhl(a)alibaba-inc.com> > Cc: Soby Mathew <Soby.Mathew(a)arm.com>; Xie, Shaolin <shaolin.xie@alibaba- > inc.com>; nd <nd(a)arm.com> > Subject: Re: [TF-A] 回复：回复： MMU Table in ARM Trust-Firmware-A > > Hi Soby, > > >>It is possible to create a secure carve-out in DDR and execute BL31 > >>from there. It is less `secure` than running from SRAM but it is > >>acceptable for some market segments depending on the threat model. > > > Can you elaborate on why you say it is less "secure" to run out of DDR? > > > -Raghu > > On January 13, 2020 at 4:36 AM, "严鸿亮(鸿先) via TF-A" <tf- > a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> wrote: > Hi Soby, > > Many thanks for your advice. I will try to RUN BL2 as Boot ROM and try to > reduce the BL31 size. Hope BL2_NOPROGBITS+BL31 can be restricted below 64KB. > Wish me good luck:). > > Best Regards > Yan Hongliang > > > > > > > > ------------------------------------------------------------------ > 发件人：Soby Mathew <Soby.Mathew(a)arm.com<mailto:Soby.Mathew@arm.com>> > 发送时间：2020年1月13日(星期一) 19:37 > 收件人：严鸿亮(鸿先) <hongxian.yhl(a)alibaba-inc.com<mailto:hongxian.yhl@alibaba- > inc.com>>; "Xie, Shaolin" <shaolin.xie@alibaba- > inc.com<mailto:shaolin.xie@alibaba-inc.com>>; tf- > a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <tf- > a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> > 抄　送：nd <nd(a)arm.com<mailto:nd@arm.com>>; Ash Wilding > <Ash.Wilding(a)arm.com<mailto:Ash.Wilding@arm.com>> > 主　题：RE: 回复：[TF-A] MMU Table in ARM Trust-Firmware-A > > Hi Yan, > OK, sounds good. From your description of the platform, having BL2 as the > Boot ROM is worth exploring. This way, you avoid the BL1_RW , BL2_PROGBITS > memory overhead. BL2_NOPROGBITS will need to be in SRAM. See the BL2_AT_EL3 > and BL2_IN_XIP_MEM build flags for details. This depends on BL31 being able > to fit in the free space available after this is done. One option is using > the RECLAIM_INIT_CODE option which reclaims BL31 init-only code for runtime > data but it needs platform specific linker script support. There are other > ways to reduce the BL31 size, but trading security like > SEPARATE_CODE_AND_RODATA=0 or trading performance like USE_COHERENT_MEM=0. > Hope that helps. > Best Regards > Soby Mathew > From: 严鸿亮(鸿先) <hongxian.yhl(a)alibaba-inc.com<mailto:hongxian.yhl@alibaba- > inc.com>> > Sent: 11 January 2020 06:04 > To: Soby Mathew <Soby.Mathew(a)arm.com<mailto:Soby.Mathew@arm.com>>; Xie, > Shaolin <shaolin.xie(a)alibaba-inc.com<mailto:shaolin.xie@alibaba-inc.com>>; > tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> > Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>; Ash Wilding > <Ash.Wilding(a)arm.com<mailto:Ash.Wilding@arm.com>> > Subject: 回复：[TF-A] MMU Table in ARM Trust-Firmware-A Hi Soby, Thanks for > your replies. > Currently, out BL2 size is 60KB, BL1_RW is 28KB, BL31_PROGBITS is 48KB, > BL31_NOPROGBITS is 24KB. For our testchip, we don't have too strictly > security requirement, so maybe putting BL31 into DDR is a way to save SRAM > and we don't need to worry about PROGBITS limit between BL31 and BL2. > For BL1_RW and BL2, there is 40KB used for MMU table. After I disable the MMU > related code in arm_bl1_plat_arch_setup()/arm_bl2_plat_arch_setup() and also > disable the build of xlat_table_lib, this 40KB space is saved. If the > consequence is decreasing performance and losing MMU protection without any > other functionality problem, then we might try this. > > Best Regards > Yan Hongliang > > > > > > > ------------------------------------------------------------------ > 发件人：Soby Mathew <Soby.Mathew(a)arm.com<mailto:Soby.Mathew@arm.com>> > 发送时间：2020年1月10日(星期五) 18:27 > 收件人："Xie, Shaolin" <shaolin.xie@alibaba- > inc.com<mailto:shaolin.xie@alibaba-inc.com>>; tf- > a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <tf- > a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> > 抄　送：nd <nd(a)arm.com<mailto:nd@arm.com>>; 严鸿亮(鸿先) <hongxian.yhl@alibaba- > inc.com<mailto:hongxian.yhl@alibaba-inc.com>>; Ash Wilding > <Ash.Wilding(a)arm.com<mailto:Ash.Wilding@arm.com>> > 主　题：Re: [TF-A] MMU Table in ARM Trust-Firmware-A > > On 10/01/2020 09:05, shaolin.xie via TF-A wrote: > > Hey all: > > > > We are trying to port ARM Trust-Firmware-A to our design, however, we are > facing serious SRAM size problem. > > > > Our target SRAM is 64KB, but the compiled BL2 already taken 60K: > > > > After some evaluation, we found that the MMU table take most of the space. > Our questions are: > Hi Shaolin, > There are some options to reduce the memory used for page-tables like using > non-identity virtual to physical mappings. But given your SRAM size, I > suspect you may not save enough to fit BL31. > > > > > 1. Can we disable the MMU so we can fit the BL2 into 64KB space? > > (However, in ARM's porting guide, enable MMU and icache/dcache is > > mandatory. Refer to chapter 7.3 in > > https://trustedfirmware-a.readthedocs.io/en/latest/getting_started/por > > ting-guide.html#introduction > > <https://trustedfirmware-a.readthedocs.io/en/latest/getting_started/po > > rting-guide.html#introduction>.） > > This is a possibility although not recommended for performance reasons and > you lose the protection of MMU during BL2 execution. This is not a > configuration we support an I suspect some changes to BL2 code may be > required for this. > > > > > 2. In current design, BL31 is run in SRAM. If we enable DDR in BL2 and load > BL31 image to DDR, is there any potential issue? > > > > Thanks in advances, > > > > > > It is possible to create a secure carve-out in DDR and execute BL31 from > there. It is less `secure` than running from SRAM but it is acceptable for > some market segments depending on the threat model. > > You target SRAM of 64 KB is on the lower side and fitting both BL2 and > BL31 in that space could be a challenge. > > Could you let us know your BL2 and BL31 size and could you break down the > size in terms of PROGBITS and NOPROG BITS? The BL31 NOPROG BITS are usually > overlayed on top of BL2 memory and this will let us know whether fitting both > in SRAM is even possible. If both cannot fit together in SRAM, there are > other options you can explore like loading BL31 directly from BootROM or > using BL2 as an XIP BootROM image. > > Best Regards > Soby Mathew > > > > > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org<mailto:TF-A@lists.trustedfirmware.org> > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > -- > 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. 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.

5 years, 4 months

1
0
0 0

Re: [TF-A] 回复：回复： MMU Table in ARM Trust-Firmware-A

by Soby Mathew

[Adding back TF-A list] Hi Raghu Since the same DRAM is partitioned to run both non-secure and secure software, it is susceptible to Row Hammer attacks. Also depending on how accessible the DRAM interface is, the DDR PHY can be probed for transactions. If the DRAM is removable, then it can be deep frozen to retain values and plugged into another system to extract contents. Hence the less `secure` comment. Best Regards Soby Mathew From: Raghupathy Krishnamurthy <raghu.ncstate(a)icloud.com> Sent: 13 January 2020 14:36 To: "严鸿亮(鸿先)" <hongxian.yhl(a)alibaba-inc.com> Cc: Soby Mathew <Soby.Mathew(a)arm.com>; Xie, Shaolin <shaolin.xie(a)alibaba-inc.com>; nd <nd(a)arm.com> Subject: Re: [TF-A] 回复：回复： MMU Table in ARM Trust-Firmware-A Hi Soby, >>It is possible to create a secure carve-out in DDR and execute BL31 from >>there. It is less `secure` than running from SRAM but it is acceptable >>for some market segments depending on the threat model. Can you elaborate on why you say it is less "secure" to run out of DDR? -Raghu On January 13, 2020 at 4:36 AM, "严鸿亮(鸿先) via TF-A" <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> wrote: Hi Soby, Many thanks for your advice. I will try to RUN BL2 as Boot ROM and try to reduce the BL31 size. Hope BL2_NOPROGBITS+BL31 can be restricted below 64KB. Wish me good luck:). Best Regards Yan Hongliang ------------------------------------------------------------------ 发件人：Soby Mathew <Soby.Mathew(a)arm.com<mailto:Soby.Mathew@arm.com>> 发送时间：2020年1月13日(星期一) 19:37 收件人：严鸿亮(鸿先) <hongxian.yhl(a)alibaba-inc.com<mailto:hongxian.yhl@alibaba-inc.com>>; "Xie, Shaolin" <shaolin.xie(a)alibaba-inc.com<mailto:shaolin.xie@alibaba-inc.com>>; tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> 抄　送：nd <nd(a)arm.com<mailto:nd@arm.com>>; Ash Wilding <Ash.Wilding(a)arm.com<mailto:Ash.Wilding@arm.com>> 主　题：RE: 回复：[TF-A] MMU Table in ARM Trust-Firmware-A Hi Yan, OK, sounds good. From your description of the platform, having BL2 as the Boot ROM is worth exploring. This way, you avoid the BL1_RW , BL2_PROGBITS memory overhead. BL2_NOPROGBITS will need to be in SRAM. See the BL2_AT_EL3 and BL2_IN_XIP_MEM build flags for details. This depends on BL31 being able to fit in the free space available after this is done. One option is using the RECLAIM_INIT_CODE option which reclaims BL31 init-only code for runtime data but it needs platform specific linker script support. There are other ways to reduce the BL31 size, but trading security like SEPARATE_CODE_AND_RODATA=0 or trading performance like USE_COHERENT_MEM=0. Hope that helps. Best Regards Soby Mathew From: 严鸿亮(鸿先) <hongxian.yhl(a)alibaba-inc.com<mailto:hongxian.yhl@alibaba-inc.com>> Sent: 11 January 2020 06:04 To: Soby Mathew <Soby.Mathew(a)arm.com<mailto:Soby.Mathew@arm.com>>; Xie, Shaolin <shaolin.xie(a)alibaba-inc.com<mailto:shaolin.xie@alibaba-inc.com>>; tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>; Ash Wilding <Ash.Wilding(a)arm.com<mailto:Ash.Wilding@arm.com>> Subject: 回复：[TF-A] MMU Table in ARM Trust-Firmware-A Hi Soby, Thanks for your replies. Currently, out BL2 size is 60KB, BL1_RW is 28KB, BL31_PROGBITS is 48KB, BL31_NOPROGBITS is 24KB. For our testchip, we don't have too strictly security requirement, so maybe putting BL31 into DDR is a way to save SRAM and we don't need to worry about PROGBITS limit between BL31 and BL2. For BL1_RW and BL2, there is 40KB used for MMU table. After I disable the MMU related code in arm_bl1_plat_arch_setup()/arm_bl2_plat_arch_setup() and also disable the build of xlat_table_lib, this 40KB space is saved. If the consequence is decreasing performance and losing MMU protection without any other functionality problem, then we might try this. Best Regards Yan Hongliang ------------------------------------------------------------------ 发件人：Soby Mathew <Soby.Mathew(a)arm.com<mailto:Soby.Mathew@arm.com>> 发送时间：2020年1月10日(星期五) 18:27 收件人："Xie, Shaolin" <shaolin.xie(a)alibaba-inc.com<mailto:shaolin.xie@alibaba-inc.com>>; tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> 抄　送：nd <nd(a)arm.com<mailto:nd@arm.com>>; 严鸿亮(鸿先) <hongxian.yhl(a)alibaba-inc.com<mailto:hongxian.yhl@alibaba-inc.com>>; Ash Wilding <Ash.Wilding(a)arm.com<mailto:Ash.Wilding@arm.com>> 主　题：Re: [TF-A] MMU Table in ARM Trust-Firmware-A On 10/01/2020 09:05, shaolin.xie via TF-A wrote: > Hey all: > > We are trying to port ARM Trust-Firmware-A to our design, however, we are facing serious SRAM size problem. > > Our target SRAM is 64KB, but the compiled BL2 already taken 60K: > > After some evaluation, we found that the MMU table take most of the space. Our questions are: Hi Shaolin, There are some options to reduce the memory used for page-tables like using non-identity virtual to physical mappings. But given your SRAM size, I suspect you may not save enough to fit BL31. > > 1. Can we disable the MMU so we can fit the BL2 into 64KB space? > (However, in ARM's porting guide, enable MMU and icache/dcache is mandatory. Refer to chapter 7.3 in https://trustedfirmware-a.readthedocs.io/en/latest/getting_started/porting-… <https://trustedfirmware-a.readthedocs.io/en/latest/getting_started/porting-…>.） This is a possibility although not recommended for performance reasons and you lose the protection of MMU during BL2 execution. This is not a configuration we support an I suspect some changes to BL2 code may be required for this. > > 2. In current design, BL31 is run in SRAM. If we enable DDR in BL2 and load BL31 image to DDR, is there any potential issue? > > Thanks in advances, > > It is possible to create a secure carve-out in DDR and execute BL31 from there. It is less `secure` than running from SRAM but it is acceptable for some market segments depending on the threat model. You target SRAM of 64 KB is on the lower side and fitting both BL2 and BL31 in that space could be a challenge. Could you let us know your BL2 and BL31 size and could you break down the size in terms of PROGBITS and NOPROG BITS? The BL31 NOPROG BITS are usually overlayed on top of BL2 memory and this will let us know whether fitting both in SRAM is even possible. If both cannot fit together in SRAM, there are other options you can explore like loading BL31 directly from BootROM or using BL2 as an XIP BootROM image. Best Regards Soby Mathew -- TF-A mailing list TF-A(a)lists.trustedfirmware.org<mailto:TF-A@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 4 months

1
0
0 0

Re: [TF-A] MMU Table in ARM Trust-Firmware-A

by Soby Mathew

On 10/01/2020 09:05, shaolin.xie via TF-A wrote: > Hey all: > > We are trying to port ARM Trust-Firmware-A to our design, however, we are facing serious SRAM size problem. > > Our target SRAM is 64KB, but the compiled BL2 already taken 60K: > > After some evaluation, we found that the MMU table take most of the space. Our questions are: Hi Shaolin, There are some options to reduce the memory used for page-tables like using non-identity virtual to physical mappings. But given your SRAM size, I suspect you may not save enough to fit BL31. > > 1. Can we disable the MMU so we can fit the BL2 into 64KB space? > (However, in ARM's porting guide, enable MMU and icache/dcache is mandatory. Refer to chapter 7.3 in https://trustedfirmware-a.readthedocs.io/en/latest/getting_started/porting-… <https://trustedfirmware-a.readthedocs.io/en/latest/getting_started/porting-…>.） This is a possibility although not recommended for performance reasons and you lose the protection of MMU during BL2 execution. This is not a configuration we support an I suspect some changes to BL2 code may be required for this. > > 2. In current design, BL31 is run in SRAM. If we enable DDR in BL2 and load BL31 image to DDR, is there any potential issue? > > Thanks in advances, > > It is possible to create a secure carve-out in DDR and execute BL31 from there. It is less `secure` than running from SRAM but it is acceptable for some market segments depending on the threat model. You target SRAM of 64 KB is on the lower side and fitting both BL2 and BL31 in that space could be a challenge. Could you let us know your BL2 and BL31 size and could you break down the size in terms of PROGBITS and NOPROG BITS? The BL31 NOPROG BITS are usually overlayed on top of BL2 memory and this will let us know whether fitting both in SRAM is even possible. If both cannot fit together in SRAM, there are other options you can explore like loading BL31 directly from BootROM or using BL2 as an XIP BootROM image. Best Regards Soby Mathew

5 years, 4 months

2
3
0 0

Re: [TF-A] MMU Table in ARM Trust-Firmware-A

by Marek

Another option to BL31 in system memory (DDR) is, which we are exploring, is loading an image (in our case BL33/Uboot) to system caches (inner L1/L2 & outer LLC/L3 which ever) and initialize the DDR from within it. This is not trivial though but working successfully with us for Cortex-A15, A53 and A57 with CCN (Cache Coherent Network 504 and 512) featuring the Last Level Cache on three of our SoCs. Marek On Fri, 10 Jan 2020 at 11:12, Soby Mathew via TF-A < tf-a(a)lists.trustedfirmware.org> wrote: > On 10/01/2020 09:05, shaolin.xie via TF-A wrote: > > Hey all: > > > > We are trying to port ARM Trust-Firmware-A to our design, however, we > are facing serious SRAM size problem. > > > > Our target SRAM is 64KB, but the compiled BL2 already taken 60K: > > > > After some evaluation, we found that the MMU table take most of the > space. Our questions are: > Hi Shaolin, > There are some options to reduce the memory used for page-tables like > using non-identity virtual to physical mappings. But given your SRAM > size, I suspect you may not save enough to fit BL31. > > > > > 1. Can we disable the MMU so we can fit the BL2 into 64KB space? > > (However, in ARM's porting guide, enable MMU and icache/dcache is > mandatory. Refer to chapter 7.3 in > https://trustedfirmware-a.readthedocs.io/en/latest/getting_started/porting-… > < > https://trustedfirmware-a.readthedocs.io/en/latest/getting_started/porting-… > >.） > > This is a possibility although not recommended for performance reasons > and you lose the protection of MMU during BL2 execution. This is not a > configuration we support an I suspect some changes to BL2 code may be > required for this. > > > > > 2. In current design, BL31 is run in SRAM. If we enable DDR in BL2 and > load BL31 image to DDR, is there any potential issue? > > > > Thanks in advances, > > > > > > It is possible to create a secure carve-out in DDR and execute BL31 from > there. It is less `secure` than running from SRAM but it is acceptable > for some market segments depending on the threat model. > > You target SRAM of 64 KB is on the lower side and fitting both BL2 and > BL31 in that space could be a challenge. > > Could you let us know your BL2 and BL31 size and could you break down > the size in terms of PROGBITS and NOPROG BITS? The BL31 NOPROG BITS are > usually overlayed on top of BL2 memory and this will let us know whether > fitting both in SRAM is even possible. If both cannot fit together in > SRAM, there are other options you can explore like loading BL31 directly > from BootROM or using BL2 as an XIP BootROM image. > > Best Regards > Soby Mathew > > > > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > -- Slán, Marek

5 years, 4 months

1
0
0 0

MMU Table in ARM Trust-Firmware-A

by shaolin.xie

Hey all: We are trying to port ARM Trust-Firmware-A to our design, however, we are facing serious SRAM size problem. Our target SRAM is 64KB, but the compiled BL2 already taken 60K: After some evaluation, we found that the MMU table take most of the space. Our questions are: 1. Can we disable the MMU so we can fit the BL2 into 64KB space? (However, in ARM's porting guide, enable MMU and icache/dcache is mandatory. Refer to chapter 7.3 in https://trustedfirmware-a.readthedocs.io/en/latest/getting_started/porting-… <https://trustedfirmware-a.readthedocs.io/en/latest/getting_started/porting-…>.） 2. In current design, BL31 is run in SRAM. If we enable DDR in BL2 and load BL31 image to DDR, is there any potential issue? Thanks in advances,

5 years, 4 months

1
1
0 0

Re: [TF-A] Does ARMv8 TrustZone provide a secure ROM?

by Matteo Carlini

Back on-list. > One more question, the operation of TrustZone is the same in the armv7-A and Armv8-A architectures, right? Not exactly…for a description about TZ differences between the Armv7-A and Armv8-A architecture please have a look at this presentation: https://www.youtube.com/watch?v=q32BEMMxmfw https://www.slideshare.net/linaroorg/arm-trusted-firmareforarmv8alcu13 As a reference, all public talks and presentations on TF-A over the years are listed here: https://developer.trustedfirmware.org/w/tf_a/ Thanks Matteo > From: Iñigo Vicente Waliño <inigovicentewalino(a)gmail.com> > Sent: 09 January 2020 11:21 > To: Matteo Carlini <Matteo.Carlini(a)arm.com> > Subject: Re: [TF-A] Does ARMv8 TrustZone provide a secure ROM? > One more question, the operation of TrustZone is the same in the armv7-A and Armv8-A architectures, right? > Thanks for your answers, > Iñigo.

5 years, 4 months

1
0
0 0

Re: [TF-A] Does ARMv8 TrustZone provide a secure ROM?

by Matteo Carlini

Another option is to look at the 96boards platforms: https://www.96boards.org/product/developerbox/ (that's supported upstream by TF-A https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/plat/socio… ) and the Secure96 mezzanine board https://www.96boards.org/product/secure96/ https://www.96boards.org/blog/getting-started-with-the-secure96-tpm/ but the boot flow with TF-A and this mezzanine board hasn't been officially proved. Ard and Stuart (cc-ed) have done some investigations and experiment in this direction and might add something. Thanks Matteo > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Dan > Handley via TF-A > Sent: 09 January 2020 09:56 > To: tf-a(a)lists.trustedfirmware.org > Subject: Re: [TF-A] Does ARMv8 TrustZone provide a secure ROM? > > (Back on the list) > > Sorry Iñigo, I don't know enough about the hw capabilities of Raspberry Pi > and its boot flow to be able to help you further. Olivier gave some more > pointers. > > Dan. > > > From: Iñigo Vicente Waliño <inigovicentewalino(a)gmail.com> > Sent: 09 January 2020 07:42 > To: Dan Handley <Dan.Handley(a)arm.com> > Subject: Re: [TF-A] Does ARMv8 TrustZone provide a secure ROM? > > Yes, thank you very much. > > Then, what I'm trying to say is that if I want a secure boot, I need a trust root. > If Raspberry Pi cannot provide that trusted root, can I use a TPM? > > Iñigo > > El mié., 8 ene. 2020 a las 16:32, Dan Handley via TF-A (<tf- > a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>>) > escribió: > (Back on the list) > > By rpi I guess you mean Raspberry Pi? > > > How do we ensure that the ROM is safe? > I'm not sure what you mean by "safe". By definition the ROM is non- > modifiable but maybe you also want it to be non-readable by normal world > software? > > Although Raspberry Pi contains CPUs that implement TrustZone, I believe > there is no TrustZone Controller IP policing access to memory so there is > nothing preventing normal world software from accessing memory that is > mapped in as secure. Perhaps that is what you mean by "rpi does not provide > security"? I also don't know what you mean by "a TPM does not work". > > Dan. > > From: Iñigo Vicente Waliño > <inigovicentewalino(a)gmail.com<mailto:inigovicentewalino@gmail.com>> > Sent: 08 January 2020 14:54 > To: Dan Handley <Dan.Handley(a)arm.com<mailto:Dan.Handley@arm.com>> > Subject: Re: [TF-A] Does ARMv8 TrustZone provide a secure ROM? > > Assuming that BL1 is used and implemented in ROM, for example, with an rpi. > How do we ensure that the ROM is safe? He sought that rpi does not provide > security and that a TPM does not work. Why? > > Thanks. > > El mié., 8 ene. 2020 a las 13:21, Dan Handley via TF-A (<tf- > a(a)lists.trustedfirmware.org<mailto:tf- > a(a)lists.trustedfirmware.org><mailto:tf- > a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>>>) > escribió: > Hi Inigo > > TrustZone is a trademark referring to the security extensions of the Arm > architecture. That is separate to BL1, which is the first boot stage of Trusted > Firmware-A (or some other equivalent boot firmware). The expectation is > that BL1, if used, is implemented in ROM to provide the Root of Trust for the > Application Processor (AP). > > An alternative flow is for a separate "security processor" to authenticate the > AP firmware before the AP is released from reset. In such a flow, there is no > need for BL1 and BL2 since that functionality is provided by the security > processor. In such a flow, the TF-A RESET_TO_BL31 config can be used (see > in-source documentation). > > A TPM can provide additional security by storing secrets not even visible to > TrustZone software (e.g. root keys or boot measurements). However, TPMs > typically don't do firmware authentication on their own; some other > software will need to use the secrets it stores, e.g. boot firmware may ask > the TPM verify a signature corresponding to the next boot stage. > > > If the TPM is changed to another, is the boot performed? > That depends on your system design. > > Dan. > > > -----Original Message----- > > From: TF-A > > <tf-a-bounces(a)lists.trustedfirmware.org<mailto:tf-a-bounces@lists.trus > > tedfirmware.org><mailto:tf-a-bounces@lists.trustedfirmware.org<mailto: > > tf-a-bounces(a)lists.trustedfirmware.org>>> On Behalf Of Iñigo Vicente > > Waliño via TF-A > > Sent: 08 January 2020 10:33 > > To: > > tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>< > > mailto:tf-a@lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmwar > > e.org>> > > Subject: [TF-A] Does ARMv8 TrustZone provide a secure ROM? > > > > Hi, > > > > Does ARMv8 TrustZone provide BL1 in a secure ROM? Can a TPM be used > as > > a trusted root or is it useless? > > If the TPM is changed to another, is the boot performed? > > > > Thanks, > > Inigo. > > -- > > TF-A mailing list > > TF-A(a)lists.trustedfirmware.org<mailto:TF-A@lists.trustedfirmware.org>< > > mailto:TF-A@lists.trustedfirmware.org<mailto:TF-A@lists.trustedfirmwar > > e.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. > 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<mailto:TF- > A(a)lists.trustedfirmware.org><mailto:TF- > A(a)lists.trustedfirmware.org<mailto:TF-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. 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<mailto:TF-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. 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

5 years, 4 months

2
1
0 0

Re: [TF-A] Does ARMv8 TrustZone provide a secure ROM?

by Dan Handley

(Back on the list) Sorry Iñigo, I don't know enough about the hw capabilities of Raspberry Pi and its boot flow to be able to help you further. Olivier gave some more pointers. Dan. From: Iñigo Vicente Waliño <inigovicentewalino(a)gmail.com> Sent: 09 January 2020 07:42 To: Dan Handley <Dan.Handley(a)arm.com> Subject: Re: [TF-A] Does ARMv8 TrustZone provide a secure ROM? Yes, thank you very much. Then, what I'm trying to say is that if I want a secure boot, I need a trust root. If Raspberry Pi cannot provide that trusted root, can I use a TPM? Iñigo El mié., 8 ene. 2020 a las 16:32, Dan Handley via TF-A (<tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>>) escribió: (Back on the list) By rpi I guess you mean Raspberry Pi? > How do we ensure that the ROM is safe? I'm not sure what you mean by "safe". By definition the ROM is non-modifiable but maybe you also want it to be non-readable by normal world software? Although Raspberry Pi contains CPUs that implement TrustZone, I believe there is no TrustZone Controller IP policing access to memory so there is nothing preventing normal world software from accessing memory that is mapped in as secure. Perhaps that is what you mean by "rpi does not provide security"? I also don't know what you mean by "a TPM does not work". Dan. From: Iñigo Vicente Waliño <inigovicentewalino(a)gmail.com<mailto:inigovicentewalino@gmail.com>> Sent: 08 January 2020 14:54 To: Dan Handley <Dan.Handley(a)arm.com<mailto:Dan.Handley@arm.com>> Subject: Re: [TF-A] Does ARMv8 TrustZone provide a secure ROM? Assuming that BL1 is used and implemented in ROM, for example, with an rpi. How do we ensure that the ROM is safe? He sought that rpi does not provide security and that a TPM does not work. Why? Thanks. El mié., 8 ene. 2020 a las 13:21, Dan Handley via TF-A (<tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org><mailto:tf-a@lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>>>) escribió: Hi Inigo TrustZone is a trademark referring to the security extensions of the Arm architecture. That is separate to BL1, which is the first boot stage of Trusted Firmware-A (or some other equivalent boot firmware). The expectation is that BL1, if used, is implemented in ROM to provide the Root of Trust for the Application Processor (AP). An alternative flow is for a separate "security processor" to authenticate the AP firmware before the AP is released from reset. In such a flow, there is no need for BL1 and BL2 since that functionality is provided by the security processor. In such a flow, the TF-A RESET_TO_BL31 config can be used (see in-source documentation). A TPM can provide additional security by storing secrets not even visible to TrustZone software (e.g. root keys or boot measurements). However, TPMs typically don't do firmware authentication on their own; some other software will need to use the secrets it stores, e.g. boot firmware may ask the TPM verify a signature corresponding to the next boot stage. > If the TPM is changed to another, is the boot performed? That depends on your system design. Dan. > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org<mailto:tf-a-bounces@lists.trustedfirmware.org><mailto:tf-a-bounces@lists.trustedfirmware.org<mailto:tf-a-bounces@lists.trustedfirmware.org>>> On Behalf Of Iñigo > Vicente Waliño via TF-A > Sent: 08 January 2020 10:33 > To: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org><mailto:tf-a@lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> > Subject: [TF-A] Does ARMv8 TrustZone provide a secure ROM? > > Hi, > > Does ARMv8 TrustZone provide BL1 in a secure ROM? Can a TPM be used as a > trusted root or is it useless? > If the TPM is changed to another, is the boot performed? > > Thanks, > Inigo. > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org<mailto:TF-A@lists.trustedfirmware.org><mailto:TF-A@lists.trustedfirmware.org<mailto:TF-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. 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<mailto:TF-A@lists.trustedfirmware.org><mailto:TF-A@lists.trustedfirmware.org<mailto:TF-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. 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<mailto:TF-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. 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.

5 years, 4 months

1
0
0 0

Re: [TF-A] Does ARMv8 TrustZone provide a secure ROM?

by Olivier Deprez

Hi, To add to Dan's observation about rpi lacking TZ memory controller: Notice the first subsystem to boot on BCM SoC is the VideoCore (which itself releases ARM cores resets). Thus, there are early boot stages running even before TF-A gets handed over. So it needs trusting the VC ROM and VC bootloader (residing on SD card, or EEPROM from rpi4). As to whether those early components get verified by the BCM chip, this is not documented publicly AFAIK. I extrapolate "TPM does not work" means the "public rpi" is good for prototyping TZ and/or a TPM solution. Although it is eventually not directly usable as a production platform for such use cases. Regards, Olivier. ________________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Dan Handley via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 08 January 2020 16:32 To: tf-a(a)lists.trustedfirmware.org Subject: Re: [TF-A] Does ARMv8 TrustZone provide a secure ROM? (Back on the list) By rpi I guess you mean Raspberry Pi? > How do we ensure that the ROM is safe? I'm not sure what you mean by "safe". By definition the ROM is non-modifiable but maybe you also want it to be non-readable by normal world software? Although Raspberry Pi contains CPUs that implement TrustZone, I believe there is no TrustZone Controller IP policing access to memory so there is nothing preventing normal world software from accessing memory that is mapped in as secure. Perhaps that is what you mean by "rpi does not provide security"? I also don't know what you mean by "a TPM does not work". Dan. From: Iñigo Vicente Waliño <inigovicentewalino(a)gmail.com> Sent: 08 January 2020 14:54 To: Dan Handley <Dan.Handley(a)arm.com> Subject: Re: [TF-A] Does ARMv8 TrustZone provide a secure ROM? Assuming that BL1 is used and implemented in ROM, for example, with an rpi. How do we ensure that the ROM is safe? He sought that rpi does not provide security and that a TPM does not work. Why? Thanks. El mié., 8 ene. 2020 a las 13:21, Dan Handley via TF-A (<tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>>) escribió: Hi Inigo TrustZone is a trademark referring to the security extensions of the Arm architecture. That is separate to BL1, which is the first boot stage of Trusted Firmware-A (or some other equivalent boot firmware). The expectation is that BL1, if used, is implemented in ROM to provide the Root of Trust for the Application Processor (AP). An alternative flow is for a separate "security processor" to authenticate the AP firmware before the AP is released from reset. In such a flow, there is no need for BL1 and BL2 since that functionality is provided by the security processor. In such a flow, the TF-A RESET_TO_BL31 config can be used (see in-source documentation). A TPM can provide additional security by storing secrets not even visible to TrustZone software (e.g. root keys or boot measurements). However, TPMs typically don't do firmware authentication on their own; some other software will need to use the secrets it stores, e.g. boot firmware may ask the TPM verify a signature corresponding to the next boot stage. > If the TPM is changed to another, is the boot performed? That depends on your system design. Dan. > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org<mailto:tf-a-bounces@lists.trustedfirmware.org>> On Behalf Of Iñigo > Vicente Waliño via TF-A > Sent: 08 January 2020 10:33 > To: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> > Subject: [TF-A] Does ARMv8 TrustZone provide a secure ROM? > > Hi, > > Does ARMv8 TrustZone provide BL1 in a secure ROM? Can a TPM be used as a > trusted root or is it useless? > If the TPM is changed to another, is the boot performed? > > Thanks, > Inigo. > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org<mailto:TF-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. 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<mailto:TF-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. 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

5 years, 4 months

1
0
0 0

Updates to the Change Log process

by Lauren Wehrmeister

Hi, We are intending to move the updates to the change log from completely release based to more rolling updates. I have created a new change log file in the docs directory (change-log-upcoming.rst) for changes that need to be included for the upcoming release: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3081. The intention is for individual developers to update the document with the relevant patch as the code change is being made. The usual change log document (docs/change-log.rst) will be updated at release time to include all changes for each release. Thanks, Lauren

5 years, 4 months

1
0
0 0

Re: [TF-A] Does ARMv8 TrustZone provide a secure ROM?

by Dan Handley

(Back on the list) By rpi I guess you mean Raspberry Pi? > How do we ensure that the ROM is safe? I'm not sure what you mean by "safe". By definition the ROM is non-modifiable but maybe you also want it to be non-readable by normal world software? Although Raspberry Pi contains CPUs that implement TrustZone, I believe there is no TrustZone Controller IP policing access to memory so there is nothing preventing normal world software from accessing memory that is mapped in as secure. Perhaps that is what you mean by "rpi does not provide security"? I also don't know what you mean by "a TPM does not work". Dan. From: Iñigo Vicente Waliño <inigovicentewalino(a)gmail.com> Sent: 08 January 2020 14:54 To: Dan Handley <Dan.Handley(a)arm.com> Subject: Re: [TF-A] Does ARMv8 TrustZone provide a secure ROM? Assuming that BL1 is used and implemented in ROM, for example, with an rpi. How do we ensure that the ROM is safe? He sought that rpi does not provide security and that a TPM does not work. Why? Thanks. El mié., 8 ene. 2020 a las 13:21, Dan Handley via TF-A (<tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>>) escribió: Hi Inigo TrustZone is a trademark referring to the security extensions of the Arm architecture. That is separate to BL1, which is the first boot stage of Trusted Firmware-A (or some other equivalent boot firmware). The expectation is that BL1, if used, is implemented in ROM to provide the Root of Trust for the Application Processor (AP). An alternative flow is for a separate "security processor" to authenticate the AP firmware before the AP is released from reset. In such a flow, there is no need for BL1 and BL2 since that functionality is provided by the security processor. In such a flow, the TF-A RESET_TO_BL31 config can be used (see in-source documentation). A TPM can provide additional security by storing secrets not even visible to TrustZone software (e.g. root keys or boot measurements). However, TPMs typically don't do firmware authentication on their own; some other software will need to use the secrets it stores, e.g. boot firmware may ask the TPM verify a signature corresponding to the next boot stage. > If the TPM is changed to another, is the boot performed? That depends on your system design. Dan. > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org<mailto:tf-a-bounces@lists.trustedfirmware.org>> On Behalf Of Iñigo > Vicente Waliño via TF-A > Sent: 08 January 2020 10:33 > To: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> > Subject: [TF-A] Does ARMv8 TrustZone provide a secure ROM? > > Hi, > > Does ARMv8 TrustZone provide BL1 in a secure ROM? Can a TPM be used as a > trusted root or is it useless? > If the TPM is changed to another, is the boot performed? > > Thanks, > Inigo. > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org<mailto:TF-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. 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<mailto:TF-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. 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.

5 years, 4 months

1
0
0 0

Re: [TF-A] Does ARMv8 TrustZone provide a secure ROM?

by Dan Handley

Hi Inigo TrustZone is a trademark referring to the security extensions of the Arm architecture. That is separate to BL1, which is the first boot stage of Trusted Firmware-A (or some other equivalent boot firmware). The expectation is that BL1, if used, is implemented in ROM to provide the Root of Trust for the Application Processor (AP). An alternative flow is for a separate "security processor" to authenticate the AP firmware before the AP is released from reset. In such a flow, there is no need for BL1 and BL2 since that functionality is provided by the security processor. In such a flow, the TF-A RESET_TO_BL31 config can be used (see in-source documentation). A TPM can provide additional security by storing secrets not even visible to TrustZone software (e.g. root keys or boot measurements). However, TPMs typically don't do firmware authentication on their own; some other software will need to use the secrets it stores, e.g. boot firmware may ask the TPM verify a signature corresponding to the next boot stage. > If the TPM is changed to another, is the boot performed? That depends on your system design. Dan. > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Iñigo > Vicente Waliño via TF-A > Sent: 08 January 2020 10:33 > To: tf-a(a)lists.trustedfirmware.org > Subject: [TF-A] Does ARMv8 TrustZone provide a secure ROM? > > Hi, > > Does ARMv8 TrustZone provide BL1 in a secure ROM? Can a TPM be used as a > trusted root or is it useless? > If the TPM is changed to another, is the boot performed? > > Thanks, > Inigo. > -- > 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. 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.

5 years, 4 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-A