- TF-A - lists.trustedfirmware.org

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 355446: (SIZEOF_MISMATCH) /mbedtls/library/x509_crt.c: 1713 in x509_get_other_name() /mbedtls/library/x509_crt.c: 1691 in x509_get_other_name() /mbedtls/library/x509_crt.c: 1728 in x509_get_other_name() ________________________________________________________________________________________________________ *** CID 355446: (SIZEOF_MISMATCH) /mbedtls/library/x509_crt.c: 1713 in x509_get_other_name() 1707 other_name->value.hardware_module_name.oid.tag = MBEDTLS_ASN1_OID; 1708 other_name->value.hardware_module_name.oid.p = p; 1709 other_name->value.hardware_module_name.oid.len = len; 1710 1711 if( p + len >= end ) 1712 { >>> CID 355446: (SIZEOF_MISMATCH) >>> Passing argument "other_name" of type "mbedtls_x509_san_other_name *" and argument "8UL /* sizeof (other_name) */" to function "mbedtls_platform_zeroize" is suspicious. 1713 mbedtls_platform_zeroize( other_name, sizeof( other_name ) ); 1714 return( MBEDTLS_ERR_X509_INVALID_EXTENSIONS + 1715 MBEDTLS_ERR_ASN1_LENGTH_MISMATCH ); 1716 } 1717 p += len; 1718 if( ( ret = mbedtls_asn1_get_tag( &p, end, &len, /mbedtls/library/x509_crt.c: 1691 in x509_get_other_name() 1685 { 1686 return( MBEDTLS_ERR_X509_FEATURE_UNAVAILABLE ); 1687 } 1688 1689 if( p + len >= end ) 1690 { >>> CID 355446: (SIZEOF_MISMATCH) >>> Passing argument "other_name" of type "mbedtls_x509_san_other_name *" and argument "8UL /* sizeof (other_name) */" to function "mbedtls_platform_zeroize" is suspicious. 1691 mbedtls_platform_zeroize( other_name, sizeof( other_name ) ); 1692 return( MBEDTLS_ERR_X509_INVALID_EXTENSIONS + 1693 MBEDTLS_ERR_ASN1_LENGTH_MISMATCH ); 1694 } 1695 p += len; 1696 if( ( ret = mbedtls_asn1_get_tag( &p, end, &len, /mbedtls/library/x509_crt.c: 1728 in x509_get_other_name() 1722 other_name->value.hardware_module_name.val.tag = MBEDTLS_ASN1_OCTET_STRING; 1723 other_name->value.hardware_module_name.val.p = p; 1724 other_name->value.hardware_module_name.val.len = len; 1725 p += len; 1726 if( p != end ) 1727 { >>> CID 355446: (SIZEOF_MISMATCH) >>> Passing argument "other_name" of type "mbedtls_x509_san_other_name *" and argument "8UL /* sizeof (other_name) */" to function "mbedtls_platform_zeroize" is suspicious. 1728 mbedtls_platform_zeroize( other_name, 1729 sizeof( other_name ) ); 1730 return( MBEDTLS_ERR_X509_INVALID_EXTENSIONS + 1731 MBEDTLS_ERR_ASN1_LENGTH_MISMATCH ); 1732 } 1733 return( 0 ); ________________________________________________________________________________________________________ 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] [TF-TSC] [TF-M] Project Maintenance Proposal for tf.org Projects

by Sandrine Bailleux

Hi Joakim, On 4/1/20 10:08 AM, Joakim Bech via TSC wrote: > Hi Christian, Sandrine, all, > > On Thu, Mar 26, 2020 at 10:27:14AM +0100, Sandrine Bailleux wrote: >> 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. >> > +1 for that, after silence for X weeks it should be OK to merge the > patch. X would need to be number that is high enough for people to have > a chance to find it and look into it, but shouldn't be too high, since > there is a risk that it'll force the contributor to pile up things that > might be dependent on this patch. To throw something out, I'd say ~2 > weeks sounds like a good number to me. > >> 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 > +1 > >> , 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. >> > At one point in time in the OP-TEE project we tried to keep track of > maintained platforms, by simply saying maintained "Yes" if they are > maintained. However they're not maintained, we indicated that by stating > the last known version where a platform was maintained. People can still > find that information here [1] (not up-to-date). The intention was to > give future users of an old platform a chance to know if it ever has > been supported and what version that was. That could serve as a starting > point in case someone is interested in bring a device/platform back to > life. Yes, I think such information can be very useful. It saves some "git archeology" effort to try and dig this information afterwards. Also, when someone starts looking at a project, I would expect this to be one of the first thing they look up, they would want to know in which shape the project is for the particular platform they are interested in. That's almost as important in my eyes as a "getting started" guide. We could have such a high-level table that just says whether a platform is supported or not (just a yes/no) and have complementary, per-platform documentation that goes into the details of what features are supported exactly. > How that works in practice is that all OP-TEE maintainers are adding > their "Tested-by" (see example [2]) tag for the platform they maintain > when we're doing a release. If there are platforms with no "Tested-by" > tag, then they simply end up with the "last known version". I think that's a very good idea! > However, to keep that up-to-date, it requires some discipline from the > people maintaining such a table ... something that we in the OP-TEE > project haven't been very good at :) Can't this be automated, such that it doesn't need to be manually kept up-to-date? I imagine we could have some tools generating the platform support table out of such a commit message. > So, I'm not proposing something, it's just that I wanted to share what > we've tried and it "works", but not easy to maintain (a release > checklist could fix that). > > [1] https://optee.readthedocs.io/en/latest/general/platforms.html > [2] https://github.com/OP-TEE/optee_os/pull/3309/commits/765b92604459240bed7fcf… >

5 years, 2 months

2
1
0 0

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

by Raghu Krishnamurthy

Hi Alexei, I second Varun on this. The patch is huge. I recommend breaking it up into multiple commits. I've reviewed it but since it is a large patch, it might require a few more sittings to grasp all the changes(which also means there may be some stupid review comments :)). -Raghu On 3/31/20 10:28 AM, Varun Wadekar via TF-A wrote: > 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, 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. 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 355291: Memory - corruptions (NEGATIVE_RETURNS) /plat/arm/board/arm_fpga/fpga_pm.c: 50 in fpga_pwr_domain_on() ________________________________________________________________________________________________________ *** CID 355291: Memory - corruptions (NEGATIVE_RETURNS) /plat/arm/board/arm_fpga/fpga_pm.c: 50 in fpga_pwr_domain_on() 44 unsigned int pos = plat_core_pos_by_mpidr(mpidr); 45 unsigned long current_mpidr = read_mpidr_el1(); 46 47 if (mpidr == current_mpidr) { 48 return PSCI_E_ALREADY_ON; 49 } >>> CID 355291: Memory - corruptions (NEGATIVE_RETURNS) >>> Using variable "pos" as an index to array "hold_base". 50 hold_base[pos] = PLAT_FPGA_HOLD_STATE_GO; 51 flush_dcache_range((uintptr_t)&hold_base[pos], sizeof(uint64_t)); 52 sev(); /* Wake any CPUs from wfe */ 53 54 return PSCI_E_SUCCESS; 55 } ** CID 355290: Memory - corruptions (OVERRUN) /plat/arm/board/arm_fpga/fpga_pm.c: 50 in fpga_pwr_domain_on() ________________________________________________________________________________________________________ *** CID 355290: Memory - corruptions (OVERRUN) /plat/arm/board/arm_fpga/fpga_pm.c: 50 in fpga_pwr_domain_on() 44 unsigned int pos = plat_core_pos_by_mpidr(mpidr); 45 unsigned long current_mpidr = read_mpidr_el1(); 46 47 if (mpidr == current_mpidr) { 48 return PSCI_E_ALREADY_ON; 49 } >>> CID 355290: Memory - corruptions (OVERRUN) >>> Overrunning array "hold_base" of 64 8-byte elements at element index 4294967295 (byte offset 34359738367) using index "pos" (which evaluates to 4294967295). 50 hold_base[pos] = PLAT_FPGA_HOLD_STATE_GO; 51 flush_dcache_range((uintptr_t)&hold_base[pos], sizeof(uint64_t)); 52 sev(); /* Wake any CPUs from wfe */ 53 54 return PSCI_E_SUCCESS; 55 } ________________________________________________________________________________________________________ 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

Patch-set review request: Adding Broadcom Platform support

by Sheetal Tigadoli

Hello TF-A, I understand most devs/reviewers will be busy working towards code freeze, but if its possible can this patch-set be reviewed. The patch-set is about "Add support for Broadcom platform". Patch-set link https://review.trustedfirmware.org/q/topic:%2522brcm_initial_support%2522 Thanks Sheetal

5 years, 2 months

1
0
0 0

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

by Shreve, Erik

Sandrine, Really glad to see this being pulled together. A couple of areas of feedback around the Platform Support Life Cycle. As previously mentioned there are two orthogonal concerns captured in the current life cycle: Support and Functionality. I'd like to see these split out. For functionality, chip vendors may not have a business case for supporting all features on a given platform but they may provide full support for the features they have chosen to include. A simple example would be supporting PSA FF Isolation Level 1 only due to lack of HW isolation support needed to achieve Isolation Level 2 or greater. Also, I'd like to see a stronger standard put forth for platform documentation. If a platform is "supported," I believe the documentation should be complete and accurate. A lack of complete and clear documentation leaves open a wide door for misuse/misconfiguration which could result in a vulnerable system. Here is a more concrete proposal: Functional Support: Each project shall provide a standard feature or functionality list. Each platform shall include in its documentation a copy of this list with the supported functionality marked as supported. The platform documentation may reference a ticket if support is planned but not yet present. The platform documentation shall explicitly state if a feature or function has no plans for support. The feature/functionality list shall be versioned, with the version tied to the release version(s) of the project. In this way, it will be clear if a platform was last officially updated for version X but the project is currently at version Y > X. Note: projects will need to adopt (if they have not already) a version scheme that distinguishes between feature updates and bug fixes. Each project and platform shall use tags or similar functionality on tickets to associate tickets to features/functionality and platforms. If the names of tags can't match the name of the feature or platform exactly then a mapping shall be provided in the appropriate document(s). Life Cycle State Fully Supported There is (at least) one active code owner for this platform. All supported features build and either all tests pass or failures are associated with tracked known issues. Other (not associated to a test) Known Issues are tracked Documentation is up to date Note: Projects should document standards on how "active" code ownership is measured and further document standards on how code owners are warned about impending life cycle state changes. Orphan There is no active code owner All supported features build and either all tests pass or failures are associated with tracked known issues. Other (not associated to a test) Known Issues may not have been maintained (as there is no active code owner) Documentation status is unclear since there is no active code owner. There has been no change to the feature/functionality list in the project since the platform was last "Fully Supported" Out of date Same as orphan, but either: there have been changes to the feature/functionality list, or there are failing tests without tracked tickets, or there are known documentation issues. Deprecated Same as Out of Date, but the build is broken. Platform may be removed from the project codebase in the future. Erik Shreve, PSEM Software Security Engineer & Architect (CMCU Platform Development) -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Sandrine Bailleux via TF-M Sent: Tuesday, March 24, 2020 4:42 AM To: tf-a; tf-m(a)lists.trustedfirmware.org; tsc(a)lists.trustedfirmware.org; op-tee(a)linaro.org Cc: nd(a)arm.com Subject: [EXTERNAL] [TF-M] Project Maintenance Proposal for tf.org Projects 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 -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 2 months

2
2
0 0

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

by Sandrine Bailleux

Hi Andrej, On 3/26/20 10:54 AM, Andrej Butok via TF-A wrote: >> 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 for the feedback. That's not good, patches can't realistically stay in review for weeks and even months, that's just not workable. Worse, it might discourage developers to contribute to the project. I can see that cumulating maintainer & owner roles would solve the problem here but perhaps enlarging the pool of maintainers would as well? Presumably, the situation is like that today because the current maintainers of the project are overloaded and cannot get all reviews done in a timely manner? I am skeptical about a post-merge review process... Once a patch is merged there is less urge and motivation (if any) for people to take a look at it. I am worried that patches might never get reviewed that way. Regards, Sandrine

5 years, 2 months

2
2
0 0

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

by Christian Daudt

Hi Sandrine, > 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. 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). 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. 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. 4. The platform lifecycle state machine has too many transitions. "Fully maintained" <-> "orphan" -> "out" seems sufficient to me. Thanks, Christian. This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

5 years, 2 months

3
2
0 0

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, 2 months

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, 2 months

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, 2 months

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, 2 months

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, 2 months

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, 2 months

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, 2 months

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, 2 months

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, 2 months

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, 2 months

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, 2 months

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, 2 months

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, 2 months

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, 2 months

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, 2 months

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, 2 months

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, 2 months

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, 2 months

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, 2 months

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, 2 months

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, 3 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, 3 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, 3 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, 3 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, 3 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, 3 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, 3 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, 3 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, 3 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, 3 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, 3 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, 3 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, 3 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, 3 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, 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. 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, 3 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, 3 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-A