- TF-A - lists.trustedfirmware.org

Re: [TF-A] Change in ...trusted-firmware-a[integration]: Check for out-of-bound accesses in the CoT description

by Raghu Krishnamurthy

Thanks Sandrine. Patches look good. I realized after looking at things a little closer that i had misunderstood how fconf works for io policies. I thought the image id's themselves came from the config files and not just the UUID's, which is why i was worried about bounds check, since the id was coming from an external source(trusted or untrusted, depending on if it is signed data or not). This also made me realize that we are using another table built into code, to convert from image id to UUID for io policies. Is there a reason image id's also can't be discovered from the config file? -Raghu On 4/2/20 7:17 AM, Sandrine Bailleux (Code Review) wrote: > Hi guys, > > This is the patch I mentioned last Thursday at the TF-A tech call. Sorry > it took me so long to post it. > > View Change > <https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3836> > > To view, visit change 3836 > <https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3836>. > To unsubscribe, or for help writing mail filters, visit settings > <https://review.trustedfirmware.org/settings>. > > Gerrit-Project: TF-A/trusted-firmware-a > Gerrit-Branch: integration > Gerrit-Change-Id: Ic5ea20e43cf8ca959bb7f9b60de7c0839b390add > Gerrit-Change-Number: 3836 > Gerrit-PatchSet: 1 > Gerrit-Owner: Sandrine Bailleux <sandrine.bailleux(a)arm.com> > Gerrit-Reviewer: Louis Mayencourt <louis.mayencourt(a)arm.com> > Gerrit-Reviewer: Raghu K <raghu.ncstate(a)icloud.com> > Gerrit-Reviewer: Sandrine Bailleux <sandrine.bailleux(a)arm.com> > Gerrit-Comment-Date: Thu, 02 Apr 2020 14:17:12 +0000 > Gerrit-HasComments: No > Gerrit-Has-Labels: No > Gerrit-MessageType: comment

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

Need to synchronize pending EA

by Madhukar Pappireddy

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

5 years, 3 months

1
0
0 0

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

by Petre-Ionut Tudor

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

5 years, 3 months

2
5
0 0

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

by Petre-Ionut Tudor

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

5 years, 3 months

2
2
0 0

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

by Varun Wadekar

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

5 years, 3 months

2
1
0 0

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

by Soby Mathew

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

5 years, 3 months

1
0
0 0

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

by Soby Mathew

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

5 years, 3 months

1
0
0 0

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

by Soby Mathew

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

5 years, 3 months

1
0
0 0

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

by Varun Wadekar

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

5 years, 3 months

1
0
0 0

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

by Raghu Krishnamurthy

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

5 years, 3 months

1
0
0 0

Protecting Secure World Translation Tables

by Petre-Ionut Tudor

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

5 years, 3 months

1
0
0 0

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

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 1 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 354061: Memory - illegal accesses (OVERRUN) /plat/amlogic/axg/axg_pm.c: 124 in axg_pwr_domain_off() ________________________________________________________________________________________________________ *** CID 354061: Memory - illegal accesses (OVERRUN) /plat/amlogic/axg/axg_pm.c: 124 in axg_pwr_domain_off() 118 PLAT_LOCAL_STATE_OFF); 119 120 axg_pm_reset(mpidr, -1); 121 122 gicv2_cpuif_disable(); 123 >>> CID 354061: Memory - illegal accesses (OVERRUN) >>> Overrunning array "target_state->pwr_domain_state" of 2 bytes at byte offset 2 using index "2ULL". 124 if (target_state->pwr_domain_state[MPIDR_AFFLVL2] == 125 PLAT_LOCAL_STATE_OFF) 126 system_state = SCPI_POWER_OFF; 127 128 if (target_state->pwr_domain_state[MPIDR_AFFLVL1] == 129 PLAT_LOCAL_STATE_OFF) ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/ls/click?upn=nJaKvJSIH-2FPAfmty-2BK5tYpPkl…

5 years, 3 months

1
0
0 0

TF-A on iMX8M Mini

by Iñigo Vicente Waliño

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

5 years, 4 months

1
0
0 0

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

by scan-admin＠coverity.com

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

5 years, 4 months

1
0
0 0

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

by scan-admin＠coverity.com

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

5 years, 4 months

1
0
0 0

FIP header flags available for feature selection

by Scott Branden

Hello, The fip header has reserved fields available for platform specific use. The fiptool allows these header fields to be filled in using the --plat-toc-flags. A call needs to be available in the ATF framework to get these flags without accessing the FIP file again to get these flags. We have a solution we've used for ATF for quite some time to access these flags. It's finally being upstreamed here: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2839 If there are any other efficient methods to access these flags or a better proposal please suggest. Thanks, Scott

5 years, 4 months

1
0
0 0

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

by Alexei Fedorov

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

5 years, 4 months

1
0
0 0

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

by Olivier Deprez

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

5 years, 4 months

2
1
0 0

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

by Matteo Carlini

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

5 years, 4 months

1
0
0 0

CI status update - end to end boot testing on Juno

by Fathi Boudra

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

5 years, 4 months

1
0
0 0

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

by Pankaj Gupta

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

5 years, 4 months

1
0
0 0

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

by Sandrine Bailleux

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

5 years, 4 months

1
0
0 0

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

by Raghupathy Krishnamurthy

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

5 years, 4 months

1
0
0 0

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

by Sumit Garg

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

5 years, 4 months

1
0
0 0

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

by Raghupathy Krishnamurthy

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

5 years, 4 months

2
1
0 0

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

by Raghupathy Krishnamurthy

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

5 years, 4 months

1
0
0 0

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

by Soby Mathew

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

5 years, 4 months

1
0
0 0

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

by Raghupathy Krishnamurthy

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

5 years, 4 months

3
2
0 0

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

by Soby Mathew

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

5 years, 4 months

1
0
0 0

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

by Sandrine Bailleux

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

5 years, 4 months

1
0
0 0

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

by Sandrine Bailleux

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

5 years, 4 months

1
0
0 0

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

by Sumit Garg

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

5 years, 4 months

1
1
0 0

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

by Raghupathy Krishnamurthy

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

5 years, 4 months

1
0
0 0

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

by Raghupathy Krishnamurthy

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

5 years, 4 months

1
0
0 0

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

by Soby Mathew

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

5 years, 4 months

2
3
0 0

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

by Raghupathy Krishnamurthy

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

5 years, 4 months

2
1
0 0

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

by Raghupathy Krishnamurthy

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

5 years, 4 months

1
0
0 0

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

by Sumit Garg

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

5 years, 4 months

1
0
0 0

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

by Raghupathy Krishnamurthy

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

5 years, 4 months

1
0
0 0

GCC toolchain upgrade in CI

by Madhukar Pappireddy

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

5 years, 4 months

1
0
0 0

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

by Sandrine Bailleux

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

5 years, 4 months

2
1
0 0

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

by Joanna Farley

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

5 years, 4 months

1
0
0 0

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

by Iñigo Vicente Waliño

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

5 years, 4 months

1
0
0 0

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

by Scott Branden

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

5 years, 4 months

1
0
0 0

Re: [TF-A] Gerrit review latency

by Joanna Farley

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

5 years, 4 months

2
1
0 0

Gerrit review latency

by Varun Wadekar

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

5 years, 4 months

1
0
0 0

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

by Soby Mathew

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

5 years, 5 months

2
1
0 0

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

by Dan Handley

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

5 years, 5 months

1
0
0 0

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

by Soby Mathew

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

5 years, 5 months

1
0
0 0

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

by Soby Mathew

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

5 years, 5 months

2
3
0 0

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

by Marek

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

5 years, 5 months

1
0
0 0

MMU Table in ARM Trust-Firmware-A

by shaolin.xie

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

5 years, 5 months

1
1
0 0

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

by Matteo Carlini

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

5 years, 5 months

1
0
0 0

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

by Matteo Carlini

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

5 years, 5 months

2
1
0 0

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

by Dan Handley

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

5 years, 5 months

1
0
0 0

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

by Olivier Deprez

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

5 years, 5 months

1
0
0 0

Updates to the Change Log process

by Lauren Wehrmeister

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

5 years, 5 months

1
0
0 0

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

by Dan Handley

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

5 years, 5 months

1
0
0 0

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

by Dan Handley

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

5 years, 5 months

1
0
0 0

Does ARMv8 TrustZone provide a secure ROM?

by Iñigo Vicente Waliño

Hi, Does ARMv8 TrustZone provide BL1 in a secure ROM? Can a TPM be used as a trusted root or is it useless? If the TPM is changed to another, is the boot performed? Thanks, Inigo.

5 years, 5 months

1
0
0 0

(no subject)

by Iñigo Vicente Waliño

Hi, Does ARMv8 TrustZone provide BL1 in a secure ROM? Can a TPM be used as a trusted root or is it useless? If the TPM is changed to another, is the boot performed? Thanks, Inigo.

5 years, 5 months

1
0
0 0

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

by Sandrine Bailleux

Hi Sumit, On 1/8/20 7:09 AM, Sumit Garg via TF-A wrote: > Hi Sandrine, > > On Fri, 20 Dec 2019 at 12:29, Sumit Garg <sumit.garg(a)linaro.org> wrote: >> >> Hi Sandrine, >> >> On Wed, 18 Dec 2019 at 21:07, Sandrine Bailleux >> <Sandrine.Bailleux(a)arm.com> wrote: >>> >>> Hi Sumit, >>> >>> I've started providing some early review comments on your patches in >>> Gerrit but these are mainly about implementation details. I would like >>> to continue the higher-level design discussions here in parallel on the >>> mailing list, if that's fine with you. >>> >> >> Yes that's perfectly fine with me. >> > > Do you have any further comments? As I have already incorporated most > of the your comments related to design and implementation details in > latest v4 patch-set [1]. > > [1] https://review.trustedfirmware.org/q/topic:%22tbbr%252Ffw_enc%22+(status:op… Apologies, with the Christmas break, I haven't had a chance to look at your patches again. I will allocate some time for it this week and get back to you. Regards, Sandrine

5 years, 5 months

1
0
0 0

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

by Sandrine Bailleux

Hi Sumit, I've started providing some early review comments on your patches in Gerrit but these are mainly about implementation details. I would like to continue the higher-level design discussions here in parallel on the mailing list, if that's fine with you. On 12/6/19 1:29 PM, Sumit Garg via TF-A wrote: > Hi Sandrine, > > On Thu, 5 Dec 2019 at 20:31, Sandrine Bailleux > <Sandrine.Bailleux(a)arm.com> wrote: >>>> Also, I am still trying to get my head around how this would integrate >>>> with a cryptographic engine where the key does not leave the chip. I can >>>> imagine that we could get the address of the encrypted firmware image >>>> from the FIP, pass that to a cryptographic engine, request it to decrypt >>>> it and store the result somewhere in Trusted RAM. In this case, we >>>> wouldn't call plat_get_fip_encryption_key(). Do you have any idea how we >>>> would pull this off? Like how the different modules (IO layer, crypto >>>> module, image parser module, ...) would integrate together? >>> >>> In this case, I would expect platform to provide key identifier rather >>> than actual key as part of plat_get_fip_encryption_key() which is then >>> passed onto auth_decrypt() that is implementation specific to >>> cryptographic engine in similar terms as currently done for mbedTLS >>> backend. >> >> Ah I see, so plat_get_fip_encryption_key() could return either the key >> itself or a key identifier. Just like plat_get_rotpk_info() can return >> either the key or a hash of it today. However, in the case of >> plat_get_rotpk_info(), it also returns some flags indicating which one >> it is. Don't we need something similar for >> plat_get_fip_encryption_key()? How will the crypto module be able to >> tell the difference between a key and a key ID otherwise? Or would you >> expect a given crypto module backend to always use either keys or key >> IDs, but not both? >> > > It perfectly makes sense for crypto module backend to support both key > ID and actual key. But I was thinking from use-case perspective that > why would one like to expose key to the firmware if the crypto module > could better protect it. And I could come up with one use-case where > the SSK (burnt in SoC fuses) is provided as an actual key and BSSK > (accessible only to crypto module) is provided via a key ID. Yes, that makes sense to me. > So yes I agree with you to provide additional flags field along with > key buffer. Also, I think it makes sense to rename > "plat_get_fip_encryption_key()" to "plat_get_fip_enc_key_info()". Agree. >>>> I have some concerns around the generation of the initialization vectors >>>> in the encrypt_fw tool. Right now, IVs are simply a random sequence of >>>> bytes (obtained through a call to OpenSSL's RAND_bytes() API). Now, I >>>> would imagine that RAND_bytes() is typically based on a good random >>>> number generator and thus will generate different sequences every time >>>> it is called. At least, as long as it is called from the same machine >>>> every time. But what if we encrypt a new FIP bundle from a different >>>> machine, say in the context of a firmware update? Is it not possible >>>> that it might choose the same IV out of bad luck? >>>> >>>> Perhaps that's an issue left to provisioning/manufacturing time and is >>>> out of the scope here. But it worries me because AFAIU, the security of >>>> AES-GCM is critically undermined if the same nonce is used multiple >>>> times with the same key (see section 5.1.1. "Nonce reuse" in RFC 5116). >>>> If the encryption key is the SSK (rather than the BSSK) then I guess the >>>> probability is even higher, as it is shared amongst a class of devices. >>>> >>> >>> Agree that "nonce" should be unique and using a random number >>> generator available on build machine was an effort towards that. But >>> thinking about the case that you have mentioned, I think we could have >>> an optional user provided "nonce" as an input to "encrypt_fw" tool, so >>> that the user is aware to randomly generate and provide a unique >>> nonce. >> >> Yes, I like your suggestion of specifying the nonce to the tool. But I >> think it should be the default behaviour then. You mention an *optional* >> user-provided nonce, I would like to suggest we make this mandatory >> instead. We could provide an option to request the tool to generate the >> nonce, intended for development purposes. >> > > Making nonce as default and mandatory command line option seems to be > overkill for a user. It may also lead to unsafe practices of > hardcoding a nonce in Makefile, shell scripts etc. So I think we > should keep this as optional only for a narrow use-case where people > might not trust uniqueness property of RNG from multiple build > machines. I don't know... Hard-coding a nonce in the makefile is unsafe for sure but I would think that a nonce generated by the tool is also unsafe without proper management of these nonces across keys and devices, but in a much more subtle manner. I still think the nonce generation would be better left outside of the scope of this tool. > BTW, I have already added nonce command line option as part of v3 > patch-set [1]. Please have a look. > > [1] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2496/2..3 > >>>> Impact on memory footprint and performance >>>> ------------------------------------------ >>>> >>>> Do you know what the performance impact is when this feature is enabled >>>> in TF-A, to decrypt images at boot time? Obviously it depends on the >>>> platform and whether there is a dedicated cryptographic engine, and I >>>> suppose you cannot really get any relevant measurements out of QEMU but >>>> I would be interested if you've got any rough numbers. >>> >>> Following are measurements based on qemu for mbedTLS software library >>> based authenticated decryption: >>> >>> BL31 plain: >>> NOTICE: Load image time: 137us, size: 28KB >>> BL31 encrypted: >>> NOTICE: Load image time: 3979us, size: 28KB >>> >>> BL32 plain: >>> NOTICE: Load image time: 1791us, size: 360KB >>> BL32 encrypted: >>> NOTICE: Load image time: 36339us, size: 360KB >> >> Thanks. So it's a 29% increase for BL31 and 20% for BL32. I would have >> naively expected similar percentages, any idea why we get such a >> difference between BL31 and BL32? I am just curious. Maybe it's down to >> how the crypto algorithm/mode of operation works under the hood? > > Yes this additional increase for BL31 seems to be due to one time > initialization operations carried on first invocation of mbedTLS gcm > APIs, especially time taken to generate AES tables (see call to > aes_gen_tables() in mbedtls/library/aes.c +576). Ah I see, thanks for the explanation. Regarding the memory impact, given that it's adding quite a bit of code and data (around 9KB for BL1 and 12KB for BL2 from what you were saying in a previous email), I think we need to make this feature optional and wrap it under a build flag. Not everyone will need to encrypt firmware images, having only authentication is a valid use case as well. If I am not mistaken, your patches right now unconditionally pull the mbedTLS primitives into BL1 and BL2 (as long as TBBR is enabled of course). As a matter of fact, I am not able to build BL1 on FVP platform with your patches, presumably due to the unconditional size increase. The following build command: > make TRUSTED_BOARD_BOOT=1 ARM_ROTPK_LOCATION=devel_rsa MBEDTLS_DIR=mbedtls bl1 ... fails at link time: aarch64-linux-gnu-ld.bfd: build/fvp/release/bl1/bl1.elf section `xlat_table' will not fit in region `RAM' aarch64-linux-gnu-ld.bfd: BL1's RW section has exceeded its limit. aarch64-linux-gnu-ld.bfd: region `RAM' overflowed by 4096 bytes Makefile:889: recipe for target 'build/fvp/release/bl1/bl1.elf' failed Regards, Sandrine

5 years, 5 months

2
2
0 0

Re: [TF-A] [Question] Why are the log related macros defined in multiple of 10's

by Dan Handley

Hi > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Soby Mathew > via TF-A > Sent: 06 January 2020 12:34 > To: Olivier Deprez <Olivier.Deprez(a)arm.com>; tf-a(a)lists.trustedfirmware.org; > Sheetal Tigadoli <sheetal.tigadoli(a)broadcom.com> > Cc: nd <nd(a)arm.com> > Subject: Re: [TF-A] [Question] Why are the log related macros defined in > multiple of 10's > > > Hi All, > > > > I wanted to understand the reason behind defining LOG_LEVEL_* macros > > as multiple of 10's, also same goes with LOG_MARKER_* macros. > > If we set the LOG macros to 1,2,3 and so on, we can avoid the mod and > > division operation when printing the msgs to console. > > > > Please let me your thoughts on this. > > > > Link to this question on Phabricator - > > https://developer.trustedfirmware.org/T624 > > > > Thanks > > Sheetal > As Sandrine said in Phabricator, the reason was simply to leave space between the levels to allow adding intermediate levels without breaking compatibility. Compatibility was a possible concern if external tools used the log level and you only rebuilt some of the TF-A components (components could end up using different values). However, I suspect the actual level value is never emitted in practice (just the text prefix) so this may not be a real concern. > Hi Sheetal > I didn't quite get reason for the optimization from multiples of 10 to > consecutive numbers. The mod operation you refer to are assertions which will > be compiled out when DEBUG=0 or when ENABLE_ASSSERTIONS=0. Other than that > there is a single divide by 10 operation within the default implementation of > plat_log_get_prefix(). > > > If the logging utility is considered performance critical, removing the > single divide by 10 will not result in any gain. Usually the bottleneck for > logs are UART baudrates and the CPU spends most of time spinning in a wait > loop for UART to be free. Hence I don't see any need for change for log > levels macro if the intent is performance optimization. > +1. Unless there's an actual performance gain, this sounds like an unnecessary change. Dan. 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, 5 months

1
0
0 0

Re: [TF-A] [Question] Why are the log related macros defined in multiple of 10's

by Soby Mathew

On 06/01/2020 12:34, Soby Mathew via TF-A wrote: >> Hi All, >> >> I wanted to understand the reason behind defining LOG_LEVEL_* macros as >> multiple of 10's, also same goes with LOG_MARKER_* macros. >> If we set the LOG macros to 1,2,3 and so on, we can avoid the mod and >> division operation when printing the msgs to console. >> >> Please let me your thoughts on this. >> >> Link to this question on Phabricator - >> https://developer.trustedfirmware.org/T624 >> >> Thanks >> Sheetal > > Hi Sheetal > I didn't quite get reason for the optimization from multiples of 10 to > consecutive numbers. The mod operation you refer to are assertions which > will be compiled out when DEBUG=0 or when ENABLE_ASSSERTIONS=0. Other > than that there is a single divide by 10 operation within the default > implementation of plat_log_get_prefix(). > > > If the logging utility is considered performance critical, removing the > single divide by 10 will not result in any gain. Usually the bottleneck > for logs are UART baudrates and the CPU spends most of time spinning in > a wait loop for UART to be free. Hence I don't see any need for change > for log levels macro if the intent is performance optimization. > > Best Regards > Soby Mathew > Hi Sheetal There is some discussion related to this here : https://github.com/ARM-software/tf-issues/issues/462 and see associated issues and PRs for more details. Best Regards Soby Mathew >> -- >> TF-A mailing list >> TF-A(a)lists.trustedfirmware.org >> https://lists.trustedfirmware.org/mailman/listinfo/tf-a >> >

5 years, 5 months

1
0
0 0

Re: [TF-A] [Question] Why are the log related macros defined in multiple of 10's

by Soby Mathew

> Hi All, > > I wanted to understand the reason behind defining LOG_LEVEL_* macros as > multiple of 10's, also same goes with LOG_MARKER_* macros. > If we set the LOG macros to 1,2,3 and so on, we can avoid the mod and > division operation when printing the msgs to console. > > Please let me your thoughts on this. > > Link to this question on Phabricator - > https://developer.trustedfirmware.org/T624 > > Thanks > Sheetal Hi Sheetal I didn't quite get reason for the optimization from multiples of 10 to consecutive numbers. The mod operation you refer to are assertions which will be compiled out when DEBUG=0 or when ENABLE_ASSSERTIONS=0. Other than that there is a single divide by 10 operation within the default implementation of plat_log_get_prefix(). If the logging utility is considered performance critical, removing the single divide by 10 will not result in any gain. Usually the bottleneck for logs are UART baudrates and the CPU spends most of time spinning in a wait loop for UART to be free. Hence I don't see any need for change for log levels macro if the intent is performance optimization. Best Regards Soby Mathew > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a >

5 years, 5 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. 9 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 13 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 9 of 9 defect(s) ** CID 353233: Control flow issues (NO_EFFECT) /plat/intel/soc/common/socfpga_sip_svc.c: 235 in is_address_in_ddr_range() ________________________________________________________________________________________________________ *** CID 353233: Control flow issues (NO_EFFECT) /plat/intel/soc/common/socfpga_sip_svc.c: 235 in is_address_in_ddr_range() 229 return false; 230 return true; 231 } 232 233 static bool is_address_in_ddr_range(uint64_t addr) 234 { >>> CID 353233: Control flow issues (NO_EFFECT) >>> This greater-than-or-equal-to-zero comparison of an unsigned value is always true. "addr >= 0ULL". 235 if (addr >= DRAM_BASE && addr <= DRAM_BASE + DRAM_SIZE) 236 return true; 237 238 return false; 239 } 240 ** CID 353232: Memory - corruptions (OVERRUN) /plat/rockchip/common/drivers/parameter/ddr_parameter.c: 124 in ddr_region_usage_parse() ________________________________________________________________________________________________________ *** CID 353232: Memory - corruptions (OVERRUN) /plat/rockchip/common/drivers/parameter/ddr_parameter.c: 124 in ddr_region_usage_parse() 118 * that means s-regions are all parsed yet, so finsh. 119 */ 120 if (p.ns_top[i] == p.boundary) 121 goto out; 122 123 /* s-region's base starts from previous ns-region's top */ >>> CID 353232: Memory - corruptions (OVERRUN) >>> Overrunning array "p.s_base" of 10 8-byte elements at element index 10 (byte offset 87) using index "p.s_nr" (which evaluates to 10). 124 p.s_base[p.s_nr] = p.ns_top[i]; 125 126 /* s-region's top ends with next ns-region's base */ 127 if (i + 1 < p.ns_nr) 128 p.s_top[p.s_nr] = p.ns_base[i + 1]; 129 else ** CID 353231: (DIVIDE_BY_ZERO) /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 374 in mv_ddr4_dq_vref_calibration() /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 380 in mv_ddr4_dq_vref_calibration() /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 378 in mv_ddr4_dq_vref_calibration() /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 376 in mv_ddr4_dq_vref_calibration() ________________________________________________________________________________________________________ *** CID 353231: (DIVIDE_BY_ZERO) /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 374 in mv_ddr4_dq_vref_calibration() 368 VALIDATE_BUS_ACTIVE(tm->bus_act_mask, subphy_num); 369 vref_avg += center_vref[if_id][subphy_num]; 370 dq_vref_vec[subphy_num] = center_vref[if_id][subphy_num]; 371 vref_subphy_num++; 372 } 373 >>> CID 353231: (DIVIDE_BY_ZERO) >>> In expression "vref_avg / vref_subphy_num", division by expression "vref_subphy_num" which may be zero has undefined behavior. 374 mv_ddr4_vref_tap_set(dev_num, if_id, ACCESS_TYPE_UNICAST, 375 vref_avg / vref_subphy_num, MV_DDR4_VREF_TAP_START); 376 mv_ddr4_vref_tap_set(dev_num, if_id, ACCESS_TYPE_UNICAST, 377 vref_avg / vref_subphy_num, MV_DDR4_VREF_TAP_END); 378 DEBUG_CALIBRATION(DEBUG_LEVEL_INFO, ("final vref average %d\n", vref_avg / vref_subphy_num)); 379 /* run centralization again with optimal vref to update global structures */ /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 380 in mv_ddr4_dq_vref_calibration() 374 mv_ddr4_vref_tap_set(dev_num, if_id, ACCESS_TYPE_UNICAST, 375 vref_avg / vref_subphy_num, MV_DDR4_VREF_TAP_START); 376 mv_ddr4_vref_tap_set(dev_num, if_id, ACCESS_TYPE_UNICAST, 377 vref_avg / vref_subphy_num, MV_DDR4_VREF_TAP_END); 378 DEBUG_CALIBRATION(DEBUG_LEVEL_INFO, ("final vref average %d\n", vref_avg / vref_subphy_num)); 379 /* run centralization again with optimal vref to update global structures */ >>> CID 353231: (DIVIDE_BY_ZERO) >>> In expression "vref_avg / vref_subphy_num", division by expression "vref_subphy_num" which may be zero has undefined behavior. 380 mv_ddr4_centralization(dev_num, pbs_tap_factor, c_opt_per_bus, pbs_res_per_bus, valid_win_size, 381 TX_DIR, vref_avg / vref_subphy_num, duty_cycle); 382 } 383 384 /* return dram from vref DRAM from vref training mode */ 385 mv_ddr4_vref_training_mode_ctrl(dev_num, 0, ACCESS_TYPE_MULTICAST, 0); /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 378 in mv_ddr4_dq_vref_calibration() 372 } 373 374 mv_ddr4_vref_tap_set(dev_num, if_id, ACCESS_TYPE_UNICAST, 375 vref_avg / vref_subphy_num, MV_DDR4_VREF_TAP_START); 376 mv_ddr4_vref_tap_set(dev_num, if_id, ACCESS_TYPE_UNICAST, 377 vref_avg / vref_subphy_num, MV_DDR4_VREF_TAP_END); >>> CID 353231: (DIVIDE_BY_ZERO) >>> In expression "vref_avg / vref_subphy_num", division by expression "vref_subphy_num" which may be zero has undefined behavior. 378 DEBUG_CALIBRATION(DEBUG_LEVEL_INFO, ("final vref average %d\n", vref_avg / vref_subphy_num)); 379 /* run centralization again with optimal vref to update global structures */ 380 mv_ddr4_centralization(dev_num, pbs_tap_factor, c_opt_per_bus, pbs_res_per_bus, valid_win_size, 381 TX_DIR, vref_avg / vref_subphy_num, duty_cycle); 382 } 383 /drivers/marvell/mv_ddr/mv_ddr4_training_calibration.c: 376 in mv_ddr4_dq_vref_calibration() 370 dq_vref_vec[subphy_num] = center_vref[if_id][subphy_num]; 371 vref_subphy_num++; 372 } 373 374 mv_ddr4_vref_tap_set(dev_num, if_id, ACCESS_TYPE_UNICAST, 375 vref_avg / vref_subphy_num, MV_DDR4_VREF_TAP_START); >>> CID 353231: (DIVIDE_BY_ZERO) >>> In expression "vref_avg / vref_subphy_num", division by expression "vref_subphy_num" which may be zero has undefined behavior. 376 mv_ddr4_vref_tap_set(dev_num, if_id, ACCESS_TYPE_UNICAST, 377 vref_avg / vref_subphy_num, MV_DDR4_VREF_TAP_END); 378 DEBUG_CALIBRATION(DEBUG_LEVEL_INFO, ("final vref average %d\n", vref_avg / vref_subphy_num)); 379 /* run centralization again with optimal vref to update global structures */ 380 mv_ddr4_centralization(dev_num, pbs_tap_factor, c_opt_per_bus, pbs_res_per_bus, valid_win_size, 381 TX_DIR, vref_avg / vref_subphy_num, duty_cycle); ** CID 353230: Memory - corruptions (OVERRUN) ________________________________________________________________________________________________________ *** CID 353230: Memory - corruptions (OVERRUN) /drivers/marvell/mv_ddr/ddr3_debug.c: 1570 in run_xsb_test() 1564 if (write_type != 0) { 1565 CHECK_STATUS(ddr3_tip_ext_write 1566 (dev_num, if_id, addr, 1, 1567 xsb_test_table[seq])); 1568 } 1569 if (read_type != 0) { >>> CID 353230: Memory - corruptions (OVERRUN) >>> Overrunning array "data_read" of 1 4-byte elements by passing it to a function which accesses it at element index 7 (byte offset 31) using argument "1U". 1570 CHECK_STATUS(ddr3_tip_ext_read 1571 (dev_num, if_id, addr, 1, 1572 data_read)); 1573 } 1574 if ((read_type != 0) && (write_type != 0)) { 1575 ret_tmp = ** CID 353229: Memory - corruptions (OVERRUN) /plat/rockchip/common/drivers/parameter/ddr_parameter.c: 130 in ddr_region_usage_parse() ________________________________________________________________________________________________________ *** CID 353229: Memory - corruptions (OVERRUN) /plat/rockchip/common/drivers/parameter/ddr_parameter.c: 130 in ddr_region_usage_parse() 124 p.s_base[p.s_nr] = p.ns_top[i]; 125 126 /* s-region's top ends with next ns-region's base */ 127 if (i + 1 < p.ns_nr) 128 p.s_top[p.s_nr] = p.ns_base[i + 1]; 129 else >>> CID 353229: Memory - corruptions (OVERRUN) >>> Overrunning array "p.s_top" of 10 8-byte elements at element index 10 (byte offset 87) using index "p.s_nr" (which evaluates to 10). 130 p.s_top[p.s_nr] = p.boundary; 131 p.s_nr++; 132 } 133 out: 134 return p; ** CID 353228: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /lib/debugfs/devfip.c: 106 in get_entry() ________________________________________________________________________________________________________ *** CID 353228: Integer handling issues (CONSTANT_EXPRESSION_RESULT) /lib/debugfs/devfip.c: 106 in get_entry() 100 } 101 102 if (n != sizeof(struct fip_entry)) { 103 return -1; 104 } 105 >>> CID 353228: Integer handling issues (CONSTANT_EXPRESSION_RESULT) >>> "entry->size > 9223372036854775807L" is always false regardless of the values of its operands. This occurs as the logical first operand of "||". 106 if ((entry->size > LONG_MAX) || (entry->offset_address > LONG_MAX)) { 107 return -1; 108 } 109 110 if (entry->size == 0) { 111 return 0; ** CID 353227: Parse warnings (PARSE_ERROR) /services/std_svc/spm_mm/spm_mm_xlat.c: 26 in () ________________________________________________________________________________________________________ *** CID 353227: Parse warnings (PARSE_ERROR) /services/std_svc/spm_mm/spm_mm_xlat.c: 26 in () 20 /* Place translation tables by default along with the ones used by BL31. */ 21 #ifndef PLAT_SP_IMAGE_XLAT_SECTION_NAME 22 #define PLAT_SP_IMAGE_XLAT_SECTION_NAME "xlat_table" 23 #endif 24 25 /* Allocate and initialise the translation context for the secure partitions. */ >>> CID 353227: Parse warnings (PARSE_ERROR) >>> expected a string literal 26 REGISTER_XLAT_CONTEXT2(sp, 27 PLAT_SP_IMAGE_MMAP_REGIONS, 28 PLAT_SP_IMAGE_MAX_XLAT_TABLES, 29 PLAT_VIRT_ADDR_SPACE_SIZE, PLAT_PHY_ADDR_SPACE_SIZE, 30 EL1_EL0_REGIME, PLAT_SP_IMAGE_XLAT_SECTION_NAME); 31 ** CID 353226: (VARARGS) /lib/libc/snprintf.c: 110 in snprintf() /lib/libc/snprintf.c: 93 in snprintf() /lib/libc/snprintf.c: 114 in snprintf() ________________________________________________________________________________________________________ *** CID 353226: (VARARGS) /lib/libc/snprintf.c: 110 in snprintf() 104 unum = (unsigned int)num; 105 } 106 107 unsigned_dec_print(&s, n, &chars_printed, unum); 108 break; 109 case 's': >>> CID 353226: (VARARGS) >>> Calling va_arg on va_list "args", which has not been prepared with va_start(). 110 str = va_arg(args, char *); 111 string_print(&s, n, &chars_printed, str); 112 break; 113 case 'u': 114 unum = va_arg(args, unsigned int); 115 unsigned_dec_print(&s, n, &chars_printed, unum); /lib/libc/snprintf.c: 93 in snprintf() 87 if (*fmt == '%') { 88 fmt++; 89 /* Check the format specifier. */ 90 switch (*fmt) { 91 case 'i': 92 case 'd': >>> CID 353226: (VARARGS) >>> Calling va_arg on va_list "args", which has not been prepared with va_start(). 93 num = va_arg(args, int); 94 95 if (num < 0) { 96 if (chars_printed < n) { 97 *s = '-'; 98 s++; /lib/libc/snprintf.c: 114 in snprintf() 108 break; 109 case 's': 110 str = va_arg(args, char *); 111 string_print(&s, n, &chars_printed, str); 112 break; 113 case 'u': >>> CID 353226: (VARARGS) >>> Calling va_arg on va_list "args", which has not been prepared with va_start(). 114 unum = va_arg(args, unsigned int); 115 unsigned_dec_print(&s, n, &chars_printed, unum); 116 break; 117 default: 118 /* Panic on any other format specifier. */ 119 ERROR("snprintf: specifier with ASCII code '%d' not supported.", ** CID 353225: Control flow issues (NO_EFFECT) /plat/intel/soc/common/soc/socfpga_mailbox.c: 298 in intel_mailbox_get_config_status() ________________________________________________________________________________________________________ *** CID 353225: Control flow issues (NO_EFFECT) /plat/intel/soc/common/soc/socfpga_mailbox.c: 298 in intel_mailbox_get_config_status() 292 uint32_t status, res; 293 uint32_t response[6]; 294 295 status = mailbox_send_cmd(1, cmd, NULL, 0, 0, response, 296 sizeof(response) / sizeof(response[0])); 297 >>> CID 353225: Control flow issues (NO_EFFECT) >>> This less-than-zero comparison of an unsigned value is never true. "status < 0U". 298 if (status < 0) 299 return status; 300 301 res = response[RECONFIG_STATUS_STATE]; 302 if (res && res != MBOX_CFGSTAT_STATE_CONFIG) 303 return res; ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

5 years, 5 months

1
0
0 0

Re: [TF-A] New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by Alexei Fedorov

Hi Varun Could you take a look at the Nvidia driver defect reported by the Coverity scan? Regards. Alexei. ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of scan-admin--- via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 03 January 2020 08:19 To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware 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 352832: Uninitialized variables (UNINIT) /plat/nvidia/tegra/soc/t194/drivers/mce/nvg.c: 197 in nvg_update_ccplex_gsc() ________________________________________________________________________________________________________ *** CID 352832: Uninitialized variables (UNINIT) /plat/nvidia/tegra/soc/t194/drivers/mce/nvg.c: 197 in nvg_update_ccplex_gsc() 191 ret = EINVAL; 192 } else { 193 nvg_set_request_data((uint64_t)TEGRA_NVG_CHANNEL_UPDATE_CCPLEX_GSC, 194 (uint64_t)gsc_idx); 195 } 196 >>> CID 352832: Uninitialized variables (UNINIT) >>> Using uninitialized value "ret". 197 return ret; 198 } 199 200 /* 201 * Cache clean operation for all CCPLEX caches. 202 */ ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0… -- 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, 5 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 352832: Uninitialized variables (UNINIT) /plat/nvidia/tegra/soc/t194/drivers/mce/nvg.c: 197 in nvg_update_ccplex_gsc() ________________________________________________________________________________________________________ *** CID 352832: Uninitialized variables (UNINIT) /plat/nvidia/tegra/soc/t194/drivers/mce/nvg.c: 197 in nvg_update_ccplex_gsc() 191 ret = EINVAL; 192 } else { 193 nvg_set_request_data((uint64_t)TEGRA_NVG_CHANNEL_UPDATE_CCPLEX_GSC, 194 (uint64_t)gsc_idx); 195 } 196 >>> CID 352832: Uninitialized variables (UNINIT) >>> Using uninitialized value "ret". 197 return ret; 198 } 199 200 /* 201 * Cache clean operation for all CCPLEX caches. 202 */ ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

5 years, 5 months

1
0
0 0

Re: [TF-A] [Question] Why are the log related macros defined in multiple of 10's

by Olivier Deprez

Hi Sheetal, Your remark/question makes sense. The original requirement is described here: https://github.com/ARM-software/tf-issues/issues/232 We may get further update from Dan, but I sense this was to provision for intermediate log levels (as stated by Sandrine on phabricator). Will you be able to submit a patch for this? Regards, Olivier. ________________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Sheetal Tigadoli via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 20 December 2019 15:48 To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] [Question] Why are the log related macros defined in multiple of 10's Hi All, I wanted to understand the reason behind defining LOG_LEVEL_* macros as multiple of 10's, also same goes with LOG_MARKER_* macros. If we set the LOG macros to 1,2,3 and so on, we can avoid the mod and division operation when printing the msgs to console. Please let me your thoughts on this. Link to this question on Phabricator - https://developer.trustedfirmware.org/T624 Thanks Sheetal -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 5 months

2
1
0 0

[Question] Why are the log related macros defined in multiple of 10's

by Sheetal Tigadoli

Hi All, I wanted to understand the reason behind defining LOG_LEVEL_* macros as multiple of 10's, also same goes with LOG_MARKER_* macros. If we set the LOG macros to 1,2,3 and so on, we can avoid the mod and division operation when printing the msgs to console. Please let me your thoughts on this. Link to this question on Phabricator - https://developer.trustedfirmware.org/T624 Thanks Sheetal

5 years, 5 months

1
0
0 0

[Question] Why are the log related macros defined in multiple of 10's

by Sheetal Tigadoli

Hi All, I wanted to understand the reason behind defining LOG_LEVEL_* macros as multiple of 10's, also same goes with LOG_MARKER_* macros. If we set the LOG macros to 1,2,3 and so on, we can avoid the mod and division operation when printing the msgs to console. Please let me your thoughts on this. Link to this question on Phabricator - https://developer.trustedfirmware.org/T624 Thanks Sheetal

5 years, 5 months

1
0
0 0

Re: [TF-A] RPi4 and CPU hotplugging

by Soby Mathew

> > Subject: [PATCH] rpi3/4: Add support for offlining CPUs > From: Jan Kiszka <jan.kiszka(a)siemens.com> > > The hooks were populated but the power down left the CPU in limbo-land. > What we need to do - until there is a way to actually power off - is to > turn off the MMU and enter the spinning loop as if we were cold-booted. > This allows the on-call to pick up the CPU again. > > Signed-off-by: Jan Kiszka <jan.kiszka(a)siemens.com> > --- > plat/rpi/common/rpi3_pm.c | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/plat/rpi/common/rpi3_pm.c b/plat/rpi/common/rpi3_pm.c > index 8c2d070c4..2a6bf076b 100644 > --- a/plat/rpi/common/rpi3_pm.c > +++ b/plat/rpi/common/rpi3_pm.c > @@ -123,6 +123,15 @@ static void rpi3_pwr_domain_off(const psci_power_state_t *target_state) > #endif > } > > +void __dead2 plat_secondary_cold_boot_setup(void); > + > +static void __dead2 > +rpi3_pwr_domain_pwr_down_wfi(const psci_power_state_t *target_state) > +{ > + disable_mmu_el3(); > + plat_secondary_cold_boot_setup(); > +} > + > /******************************************************************************* > * Platform handler called when a power domain is about to be turned on. The > * mpidr determines the CPU to be turned on. > @@ -224,6 +233,7 @@ static void __dead2 rpi3_system_off(void) > static const plat_psci_ops_t plat_rpi3_psci_pm_ops = { > .cpu_standby = rpi3_cpu_standby, > .pwr_domain_off = rpi3_pwr_domain_off, > + .pwr_domain_pwr_down_wfi = rpi3_pwr_domain_pwr_down_wfi, > .pwr_domain_on = rpi3_pwr_domain_on, > .pwr_domain_on_finish = rpi3_pwr_domain_on_finish, > .system_off = rpi3_system_off, > -- > 2.16.4 > Hi Jan, I have put in a suggestion for the change. Basically, if you are able to do a `reset` before spinning in `plat_secondary_cold_boot_setup()`, that would be ideal. Also, if `plat_secondary_cold_boot_setup()` can trap the primary CPU as well if it were to be offlined, then I think your changes should be good. Best Regards Soby Mathew

5 years, 5 months

2
2
0 0

Re: [TF-A] About disable gic cpuif in psci suspend or off

by Soby Mathew

Hi Jisheng, This is due to the power management requirement of GICv3. In section 7.1 of GICv3 specification : https://static.docs.arm.com/ihi0069/c/IHI0069C_gic_architecture_specificati… It says the that " Before powering down the CPU interface and the PE when the Redistributor is powered up, software must put the interface between the CPU interface and the Redistributor into the quiescent state or the system will become UNPREDICTABLE". In order to put the Redistributor in a quiescent state, all the group enables in CPU interface must be disabled , otherwise "setting GICR_WAKER.ProcessorSleep to 1 when the physical group enables in the CPU interface are set to 1 results in UNPREDICTABLE behavior." Hope that clarifies. Best Regards Soby Mathew > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Jisheng > Zhang via TF-A > Sent: 05 December 2019 10:31 > To: tf-a(a)lists.trustedfirmware.org > Subject: [TF-A] About disable gic cpuif in psci suspend or off > > Hi, > > In ATF-A, I usually see below code in psci suspend or off code path: > > /* Prevent interrupts from spuriously waking up this cpu */ > plat_arm_gic_cpuif_disable(); > > But per my understanding, before calling psci_suspend(), the NW, e.g linux > kernel has disabled all interrupts from cpu level, so here preventing interrupt is > to prevent the interrupts from secure world? > > Another question is: for Cortex A55, this is not necessary. Because > CA55 TRM says when the core_pwrdn_en bit is set, executing WFI > automatically masks all interrupts and wake-up events in the core. Am I right? > > Thanks in advance > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 6 months

2
1
0 0

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

by Joanna Farley

Julius, On the subject of DebugFS's purpose it was envisages and is today as Sandrine describes as a debug build only capability. Saying that though there has been some early thoughts that it could evolve into a Secure Debug feature where this type of capability or something like it is always on requiring debug certificates for authenticated access. This is something very much for a possible future evolution and is not in the patches available today. We would welcome any thoughts on such an evolution in this space. Joanna On 13/12/2019, 13:01, "TF-A on behalf of Sandrine Bailleux via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: Hi Julius, OK, in that case I can see that a solution based on TF-A's DebugFS interface might not be desirable. Indeed, our original intention was to make the whole DebugFS system a debug-only feature (hence its name!). As such, I agree that it is likely not to get the same level of scrutiny and testing as other features intended for production systems. One of the main use cases we have in mind for DebugFS is, being able to peek and poke into the firmware for testing purposes. Today, when doing functional testing from the normal world (for example, using TF-A Tests), we are limited to what's exposed through the SMC interface. And even then, we have limited visibility on what really happened in the firmware, as we can only deduce so much from the SMC return value(s). DebugFS could be used to bridge this gap, by providing a side channel for getting internal firmware state information. Going back to the SMC-based solution then, I am not quite convinced SYSTEM_RESET2 is the right interface for intentionally triggering a panic in TF-A. I think the semantics do not quite match. If anything, a firmware crash seems more like a shutdown operation to me rather than a reset (we don't recover from a firmware crash). I am not even sure we should look into the PSCI SMC range, as it's not a power-management operation. Julius, you wrote: > It's the same problem that the SMC/PSCI spec and the TF repository layout is only designed to deal with generic vs. SoC-vendor-specific differentiation. If the normal world OS needs a feature, we can only make it generic or duplicate it across all vendors running that OS. So it sounds like it's not the first time that you hit this issue, is it? Do you have any other example of Normal World OS feature you would have liked to expose through a generic SMC interface? I am wondering whether this could help choosing the right SMC range, if we can identify some common criteria among a set of such features. Regards, Sandrine -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 6 months

2
1
0 0

Re: [TF-A] Design proposal: Property Access Layer

by Abhishek Pandit

Hi Louis, The term PAL is also used for platform abstraction layer so it "could" be confusing to have this being used for something different. Not necessarily suggesting to change anything but it might be worth considering this aspect. Thanks, Abhishek -----Original Message----- From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Louis Mayencourt via TF-A Sent: 19 November 2019 13:40 To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] Design proposal: Property Access Layer Hi everyone, Please let me introduce the `Property Access Layer` prototype: The Property Access Layer (PAL) is an abstraction layer for platform specific data, allowing a "property" to be queried and a value retrieved without the requesting entity knowing what backing store is being used to hold the data. It is used to bridge new and old ways of providing platform-specific data: Today, information like the Chain of Trust is held within several, nested platform-defined tables. In the future, it may be provided as part of a device tree blob, along with the information about images to load. Introducing this abstraction layer will make migration easier and will preserve functionality for platforms that cannot / don't want to use device tree. Please have a look at the patches: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2559/1 Regards, Louis IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 6 months

2
2
0 0

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

by Sandrine Bailleux

Hi Julius, OK, in that case I can see that a solution based on TF-A's DebugFS interface might not be desirable. Indeed, our original intention was to make the whole DebugFS system a debug-only feature (hence its name!). As such, I agree that it is likely not to get the same level of scrutiny and testing as other features intended for production systems. One of the main use cases we have in mind for DebugFS is, being able to peek and poke into the firmware for testing purposes. Today, when doing functional testing from the normal world (for example, using TF-A Tests), we are limited to what's exposed through the SMC interface. And even then, we have limited visibility on what really happened in the firmware, as we can only deduce so much from the SMC return value(s). DebugFS could be used to bridge this gap, by providing a side channel for getting internal firmware state information. Going back to the SMC-based solution then, I am not quite convinced SYSTEM_RESET2 is the right interface for intentionally triggering a panic in TF-A. I think the semantics do not quite match. If anything, a firmware crash seems more like a shutdown operation to me rather than a reset (we don't recover from a firmware crash). I am not even sure we should look into the PSCI SMC range, as it's not a power-management operation. Julius, you wrote: > It's the same problem that the SMC/PSCI spec and the TF repository layout is only designed to deal with generic vs. SoC-vendor-specific differentiation. If the normal world OS needs a feature, we can only make it generic or duplicate it across all vendors running that OS. So it sounds like it's not the first time that you hit this issue, is it? Do you have any other example of Normal World OS feature you would have liked to expose through a generic SMC interface? I am wondering whether this could help choosing the right SMC range, if we can identify some common criteria among a set of such features. Regards, Sandrine

5 years, 6 months

1
0
0 0

Re: [TF-A] [RFC] BL2 MTD frameworks

by Olivier Deprez

Hi, Thanks George and Lionel for your answers. Following up and closing on this, the approach used in mentioned patch (https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2283) looks ok provided it should now build on all platforms. The original concern was about api breakage in the generic code, and that there might exist inconsistencies among platforms (ones depending on a 32b offset, others on 64 bits). Changing the generic seek api offset parameter from ssize_t to signed long long everywhere as a default makes it better compliant to using larger density storage chips in the long term. This is fine as long as it also still support older lower density chips. Regards, Olivier. ________________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Lionel DEBIEVE via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 08 November 2019 18:34 To: tf-a(a)lists.trustedfirmware.org Subject: Re: [TF-A] [RFC] BL2 MTD frameworks Hi, Just to clarify a little bit more. There is no link here about a 32/64 bit architecture. The content of this change is to take care about new memory introduce (mtd devices) that are not based on size * LBA (where LBA=512) but size * LBA where (LBA=1) and in such case, the size could exceed the 4GB. It is not platform dependent and not architecture dependent, it's link to the connected MTD device only. I'm not sure that a new type is useful except if you want a type is modified regarding a platform flag such as USE_LARGE_MTD_DEVICE. Hope it's more clear. BR, Lionel On 11/5/19 3:20 PM, Gyorgy Szing via TF-A wrote: > Hi, > > I did not investigated all the details so what stays below may contain mistakes, but still I would like to add some comments. > > "using a type for the offset" > The type we use for this purpose seems to be a configuration parameter for the IO layer as it depends on the upper layer being used with the IO library. For example libc uses "long int" to specify the file offset (fseek, ftell), using a different type while running below libc does not seem to be a good idea. > The best option seems to be to define a type like (as Olivier mentioned) lib/zlib does. How we set this configuration parameter during the build is a question. The offset type could be dictated by the platform, the architecture (aarch32 or aarch64) or by the user. Which one is worth to implement needs investigation. > > If it is a good idea to use the same name "off_t" as zlib uses (or even the same type) is be questionable. It may give us more flexibility if we use a dedicated name, and the configuration maps the IO type to the one used by the upper layer. > > "32 bit backward compatibility" > Another angle worth to consider is the 32/64 bit compatibility. I.e.: newlib can use 64 bit offsets even on 32 bit architectures, and they use some wrappers to maintain binary compatibility with old builds. When built in a compatible manner, functions using the standardized names use 32 bit wide offsets and call the real 64 bit implementation as a wrapper. > To solve compatibility issues we could use a similar pattern. Instead of changing the existing function, we could add a new one (i.e. seek64). Then new 64 bit aware code could use the new function if available, and legacy code could call the old one. Longer term it is an option to deprecate the 32 bit version. > > "use stdint.h types" > And a finally: when selecting the type used for off_t (or whatever we are going to call it) please consider using stdint.h types (i.e. int_fast64_t). > > /George > > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Olivier Deprez via TF-A > Sent: 25 October 2019 14:42 > To: tf-a(a)lists.trustedfirmware.org; Lionel DEBIEVE <lionel.debieve(a)st.com> > Subject: Re: [TF-A] [RFC] BL2 MTD frameworks > > Hi Lionel, > > On https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2283 > I'm extending the discussion to the TF-A ML, to get people's opinion. > > The idea is to extend the io_seek offset parameter from ssize_t to unsigned long long. > There are indeed good reasons for that as flash storage density grows over the years. > > Now on the change, the struct io_dev_funcs seek function pointer is generic for the whole codebase / drivers. > So currently the change breaks the builds for at least rcar, stratix10 (did not check others from that point). > > An alternative is defining offset as an off_t type which is ssize_t by default, and only unsigned long long based on the platform (using _FILE_OFFSET_BITS=64). This pattern actually already exists in lib/zlib > > Other option is to change the generic prototype for all platform drivers (then we ensure all platforms build and supply platform patches). > > What do ML people think? > > Regards, > Olivier. > > > > ________________________________ > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Lionel DEBIEVE via TF-A <tf-a(a)lists.trustedfirmware.org> > Sent: 18 October 2019 17:26 > To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> > Subject: [TF-A] [RFC] BL2 MTD frameworks > > Hello Maintainers, > > I've sent a patch series around MTD framework management into BL2 stage (cf https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2283). > > This patch series will add following frameworks: > > - a raw NAND framework implementation to support SLC NAND devices. Current implementation is limited to read operations without ECC corrections. Overrides are available to use hardware ECC from controller or low-level drivers. It also supports ONFI detection management but this can also be disabled or overridden by platform specific data. > - a SPI-MEM framework (inspired from kernel/u-boot implementation) that encapsulates all SPI operations to SPI low level drivers. > - a SPI-NAND framework based on SPI-MEM to support SPI NAND devices. This framework is also limited to the read operation. It uses single command, address and data bus width as legacy but can be overridden by platform. > - a SPI-NOR framework based on SPI-MEM to manage SPI NOR devices. It is also limited to read operations using single command, address and data bus width as legacy (override still possible by platform). The framework embeds some specific implementations for manufacturers specific behavior in case of quad mode configuration activation. > > This patch series also includes: > > - a new io_mtd interface to manage a generic access to all these frameworks. > - a NAND core driver that accesses independently to raw NAND or SPI-NAND framework. This core driver requires a scratch buffer defined by platform to manage unaligned pages (could be defined to 0 in case of aligned page) and limits access to a single NAND instance management. > - a complete integration is available based on STM32MP1 platform. > > Tests have been performed with the following devices: > > SLC NAND: > - Micron MT29F8G08ABACAH4 (ONFI) > - Micron MT29F8G16ABACAH4 (ONFI) > - Toshiba TH58NVG3S0HTAI0 (Non ONFI) > - Toshiba TC58BVG1S3HTAI0 (On die ECC) > > SPI NOR: > - Macronix MX25L51245G > - Cypress/Spansion S25FL512 > - Micron n25q512ax3 > > SPI-NAND: > - Micron MT29F2G01ABAGD > > Waiting for your comments. > > Best regards, Lionel > -- > 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. -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 6 months

1
0
0 0

Re: [TF-A] psci shutdown do not follow graceful power off sequence

by Andreas Färber

Hi S*deeps, Am 10.12.19 um 16:08 schrieb Sudeep Holla via TF-A: > The more we discuss, I think we will get to know all sorts of CENH(as you put) > are done all over the place and expecting system is work just fine even > when lots of interface/contracts are broken is just .....(fill your own word :)) > > I promise not to discuss these CENH any further after this email :) > > On Tue, Dec 10, 2019 at 03:59:01PM +0530, Sandeep Tripathy wrote: >> Hi Sudeep, >> >> On Mon, Dec 9, 2019 at 10:40 PM Sudeep Holla <sudeep.holla(a)arm.com> wrote: >>> >>> The application has to terminate cleanly when SIGTERM is sent(may be using >>> appropriate handler. And can intimate the same to the consumers so that they >>> can consume the data before it's lost. >> The DDR is not powered off ever in this scenario. So when to/how to consume >> the log is up to the (consumer) application design. > > CENH#1 > >> Assume its an incrementing log ie. after reboot this (producer) master again >> will continue to dump more records on to it. > > CENH#2 > > (I see the roles being exchanged, OS was slave + producer and not sure > what you are referring has master above. Anyways use KDUMP and features > like that if you need RAM dump for portions of memory given to the kernel. Sorry to barge in, but it sounds like you're not quite understanding each other in this ever-growing thread: Sandeep said his use case was a SmartNIC, so I assume the logging direction is from SoC on the SmartNIC to host SoC via PCIe? Think dmesg-like logs, from one host for another - I fail to see how Sudeep's kdump suggestion could help here. But maybe I'm not understanding properly, in which case I'll just blame your abstract master/slave discussions. :) To me and my ignorance however it sounds like this use case has nothing really to do with shutdown? If the log producer does not flush their logs after say each line ending, then also without shutdown you have no guarantee of the logs reaching the consumer in a timely manner through all the producer's caches, no? Think of watchdogs, power loss or other irregular resets that PSCI can do nothing about. Especially for logs, those error conditions would be the most important to receive data of. Cheers, Andreas >> How would you suggest to handle this. In this case both producer and >> consumer deliberately asked for coherent memory so why it should also >> consider a possible data loss due to platforms not giving the coherency >> because it will add some time to flush the core caches. > > CENH#3, not sure if such flexibility should be given to applications. > >> If they get non-cached(coherent) memory range they don't have to do anything >> isn't it ? > > Applications must not try that, kernel mostly provides cached memory from > it's memory allocator. I get a sense that this is some magic pre-allocated > memory that is either reserved or taken out of kernel memory, but the > application (along with its driver) maps it coherent in some magic way. > > -- > Regards, > Sudeep > -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg)

5 years, 6 months

3
2
0 0

Re: [TF-A] RPi4 and CPU hotplugging

by Andreas Färber

Hi Andre, Am 09.12.19 um 11:08 schrieb Andre Przywara via TF-A: > On Mon, 9 Dec 2019 08:41:47 +0100 > Jan Kiszka <jan.kiszka(a)web.de> wrote: >> How should we continue with the patch below? > > If you want to go into the lion's den that is gerrit, please feel free to submit this. Shouldn't be too hard for a single patch. Otherwise I need to look into some RPi4 TF-A stuff this week anyway, so could pick up your patch as well. [...] >> Subject: [PATCH] rpi3/4: Add support for offlining CPUs Seeing the "rpi3/4" here again: It's been some time since I pitched TF-A to the Foundation for RPi4 in vein, and my 2.1 based RPi3 test setup broke with some firmware update. Not seeing any message from Matthias here yet, are you aware that U-Boot has combined rpi3 and rpi4 targets into one? Are you looking into combining the PLAT=rpi{3,4} TF-A targets, too? We're targeting to use a single Linux image for both, so needing two different TF-A binaries would make TF-A adoption more difficult for us. Regards, Andreas -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg)

5 years, 6 months

2
2
0 0

Re: [TF-A] psci shutdown do not follow graceful power off sequence

by Dan Handley

Hi Sandeep (I accidentally dropped the TF-A list in my last reply - now re-adding). > -----Original Message----- > From: Sandeep Tripathy <sandeep.tripathy(a)broadcom.com> > Sent: 05 December 2019 17:17 > > On Thu, Dec 5, 2019 at 9:54 PM Dan Handley <Dan.Handley(a)arm.com> wrote: > > > > Hi Sandeep > > > > > -----Original Message----- > > > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of > > > Sandeep Tripathy via TF-A > > > Sent: 05 December 2019 12:00 > > > > > > My query is more on the spec. > > > The OS (eg: linux) and atf and psci spec seem to have assumed that > > > it is managing an independent system or managing 'all' the masters > > > in a coherent domain. > > > What other > > > reason could possibly encourage to not to follow a shutdown sequence. > > > > > Do you mean "to not follow a *graceful* shutdown sequence"? > Yes, exactly. Thanks! > > If so I can think of 3 reasons: > > 1. It's much slower than a non-graceful shutdown. > But this is certainly not a concern for smaller embedded systems. True, but TF-A tries to be a reference for all systems. > > 2. There is no observable difference between a graceful and non-graceful > > shutdown from the calling OS's point of view. The OS presumably has no > > knowledge of other masters it does not manage. > > Can CCN state machine go bad because one participating entity just goes off > without marking its exit ? > Please note I have not seen the issue and it is my assumption. > It depends on the interconnect. Arm interconnects designed for pre-v8.2 systems required explicit programming to take the master our of the coherency domain. Arm interconnects for v8.2+ systems do this automatically via hardware system coherency signals. The TF-A off/reset platform interfaces have provision to do this programming if necessary, but only for the running cluster, which is another reason not to use these PSCI functions in this scenario. > > 3. It's hard for firmware to implement in the multicore situation. > Agree. It is complex to initiate and ensure 'other cores' power down in > firmware. > > > > I haven't yet seen a reason why SYSTEM_SUSPEND won't work instead. > > > I think you are suggesting to use psci system suspend hook in reboot /power > off path Or use system suspend from the OS itself ? Should work. > I'm suggesting to just do a normal SYSTEM_SUSPEND (suspend to RAM) from the OS. > @Sudeep, I agree alternate approaches to solve data loss problem works and > may be those are the best suited. > The past thread[1] is somewhat related but diverged in multiple directions. > I wanted to know and focus the above 3 points especially point 2. Regards Dan. 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, 6 months

3
14
0 0

RPi4 and CPU hotplugging

by Jan Kiszka

Hi Andre, I'm trying to get CPU offlining work for Linux on the RPi4. In fact, this is working already with current ATF master and the Raspberry kernel 4.19.85. Not it would be "nice" if onlining worked as well: [ 94.959294] CPU1: shutdown [ 94.959311] psci: CPU1 killed. [ 106.750960] CPU1: failed to come online [ 106.755425] CPU1: failed in unknown state : 0x0 Is this a known limitation? Or am I using the wrong kernel (obviously, it's a downstream one ;) )? Thanks, Jan PS: Current RPi firmware requires an explicit "armstub=armstub8.bin" in config.txt, no automatic pickup.

5 years, 6 months

3
6
0 0

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

by Sandrine Bailleux

Hi Sumit, Thanks for your answer. On 12/2/19 2:22 PM, Sumit Garg via TF-A wrote: > First of all, the authenticated encryption framework for FIP payloads > allows for algorithm parameter to be passed in the header (see struct > fip_toc_dec_data here [1]). So it should be easy to add support for > CCM algorithm too. > > Now coming on to additional reason to choose AES-GCM only (apart from > reasons that you have already mentioned) being: > - Currently mbedTLS only exposes partial decryption APIs for GCM > (mbedtls_gcm_starts(), mbedtls_gcm_update() and mbedtls_gcm_finish()) > but not CCM. And we need to rely on stack based partial decryption > approach (see gcm_decrypt() here [2]) as I think we can't afford large > buffers for both encrypted and plain firmware image. > > [1] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2495/2/inclu… > [2] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2494/2/drive… I see, that makes sense to me. >> Also, I am still trying to get my head around how this would integrate >> with a cryptographic engine where the key does not leave the chip. I can >> imagine that we could get the address of the encrypted firmware image >> from the FIP, pass that to a cryptographic engine, request it to decrypt >> it and store the result somewhere in Trusted RAM. In this case, we >> wouldn't call plat_get_fip_encryption_key(). Do you have any idea how we >> would pull this off? Like how the different modules (IO layer, crypto >> module, image parser module, ...) would integrate together? > > In this case, I would expect platform to provide key identifier rather > than actual key as part of plat_get_fip_encryption_key() which is then > passed onto auth_decrypt() that is implementation specific to > cryptographic engine in similar terms as currently done for mbedTLS > backend. Ah I see, so plat_get_fip_encryption_key() could return either the key itself or a key identifier. Just like plat_get_rotpk_info() can return either the key or a hash of it today. However, in the case of plat_get_rotpk_info(), it also returns some flags indicating which one it is. Don't we need something similar for plat_get_fip_encryption_key()? How will the crypto module be able to tell the difference between a key and a key ID otherwise? Or would you expect a given crypto module backend to always use either keys or key IDs, but not both? >> I have some concerns around the generation of the initialization vectors >> in the encrypt_fw tool. Right now, IVs are simply a random sequence of >> bytes (obtained through a call to OpenSSL's RAND_bytes() API). Now, I >> would imagine that RAND_bytes() is typically based on a good random >> number generator and thus will generate different sequences every time >> it is called. At least, as long as it is called from the same machine >> every time. But what if we encrypt a new FIP bundle from a different >> machine, say in the context of a firmware update? Is it not possible >> that it might choose the same IV out of bad luck? >> >> Perhaps that's an issue left to provisioning/manufacturing time and is >> out of the scope here. But it worries me because AFAIU, the security of >> AES-GCM is critically undermined if the same nonce is used multiple >> times with the same key (see section 5.1.1. "Nonce reuse" in RFC 5116). >> If the encryption key is the SSK (rather than the BSSK) then I guess the >> probability is even higher, as it is shared amongst a class of devices. >> > > Agree that "nonce" should be unique and using a random number > generator available on build machine was an effort towards that. But > thinking about the case that you have mentioned, I think we could have > an optional user provided "nonce" as an input to "encrypt_fw" tool, so > that the user is aware to randomly generate and provide a unique > nonce. Yes, I like your suggestion of specifying the nonce to the tool. But I think it should be the default behaviour then. You mention an *optional* user-provided nonce, I would like to suggest we make this mandatory instead. We could provide an option to request the tool to generate the nonce, intended for development purposes. >> Impact on memory footprint and performance >> ------------------------------------------ >> >> Do you know what the performance impact is when this feature is enabled >> in TF-A, to decrypt images at boot time? Obviously it depends on the >> platform and whether there is a dedicated cryptographic engine, and I >> suppose you cannot really get any relevant measurements out of QEMU but >> I would be interested if you've got any rough numbers. > > Following are measurements based on qemu for mbedTLS software library > based authenticated decryption: > > BL31 plain: > NOTICE: Load image time: 137us, size: 28KB > BL31 encrypted: > NOTICE: Load image time: 3979us, size: 28KB > > BL32 plain: > NOTICE: Load image time: 1791us, size: 360KB > BL32 encrypted: > NOTICE: Load image time: 36339us, size: 360KB Thanks. So it's a 29% increase for BL31 and 20% for BL32. I would have naively expected similar percentages, any idea why we get such a difference between BL31 and BL32? I am just curious. Maybe it's down to how the crypto algorithm/mode of operation works under the hood? > Following is the patch I used to take measurements in case someone is > interested to try it out on actual platform: > > diff --git a/common/bl_common.c b/common/bl_common.c > index e6f9802..d7303d2 100644 > --- a/common/bl_common.c > +++ b/common/bl_common.c > @@ -148,6 +148,7 @@ static int load_auth_image_internal(unsigned int image_id, > int is_parent_image) > { > int rc; > + unsigned long int ticks; > > #if TRUSTED_BOARD_BOOT > if (dyn_is_auth_disabled() == 0) { > @@ -164,11 +165,16 @@ static int load_auth_image_internal(unsigned int image_id, > } > #endif /* TRUSTED_BOARD_BOOT */ > > + ticks = read_cntpct_el0(); > /* Load the image */ > rc = load_image(image_id, image_data); > if (rc != 0) { > return rc; > } > +#define SYS_COUNTER_FREQ_IN_TICKS ((1000 * 1000 * 1000) / 16) > + NOTICE("Load image time: %ldus, size: %dKB\n", > + (read_cntpct_el0() - ticks) * 1000000 / > SYS_COUNTER_FREQ_IN_TICKS, > + image_data->image_size / 1024); > > #if TRUSTED_BOARD_BOOT > if (dyn_is_auth_disabled() == 0) { > >> >> And what's the memory footprint impact? IIUC, AES-GCM almost does not >> inflate the size of the data it encrypts. The size of the ciphertext >> seems to be the same as the plaintext + the size of the authentication >> tag. So I guess there's no real impact on flash storage and Trusted RAM >> usage to hold decrypted firmware. But what about the mbedTLS primitives >> to decrypt the images? How much code and data does this add? > > Following is my analysis on code and data increase due to mbedTLS primitives: > > Binary size: > ========= > > $ ls -lh build/qemu/release/*.bin > -rwxrwxr-x 1 sumit sumit 58K Dec 2 12:53 build/qemu/release/bl1.bin > -rwxrwxr-x 1 sumit sumit 66K Dec 2 12:53 build/qemu/release/bl2.bin > -rwxrwxr-x 1 sumit sumit 29K Dec 2 12:53 build/qemu/release/bl31.bin > -rw-rw-r-- 1 sumit sumit 2.5M Dec 2 12:53 build/qemu/release/fip.bin > -rw-rw-r-- 1 sumit sumit 32 Dec 2 12:53 build/qemu/release/rotpk_sha256.bin > > After importing mbedTLS primitives to support AES-GCM algo: > > $ ls -lh build/qemu/release/*.bin > -rwxrwxr-x 1 sumit sumit 67K Dec 2 12:56 build/qemu/release/bl1.bin > -rwxrwxr-x 1 sumit sumit 78K Dec 2 12:56 build/qemu/release/bl2.bin > -rwxrwxr-x 1 sumit sumit 29K Dec 2 12:56 build/qemu/release/bl31.bin > -rw-rw-r-- 1 sumit sumit 2.5M Dec 2 12:56 build/qemu/release/fip.bin > -rw-rw-r-- 1 sumit sumit 32 Dec 2 12:53 build/qemu/release/rotpk_sha256.bin > > Stack and heap: Works fine with default allocations on qemu. > ============ OK thanks. >> encrypt_fw tool >> --------------- >> >> We have some floating ideas around re-implementing the tools (fiptool, >> certtool) in a scripting language (possibly python) in the future and >> also doing a better job at sharing a common description of the list of >> images to boot/authenticate between the firmware and the host tools. But >> we're not there yet, so I agree that implementing this new tool in C >> from the same "mold" as fiptool and certtool is what makes the most >> sense today. It's just another tool we will have to rework if and when >> we get there. > > Sounds like a good idea to have these tools being python based. BTW, we noticed some copyright headers attributed to both Arm and Linaro and pre-dating year 2019, e.g. in https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2496/3/tools… : * Copyright (c) 2015, ARM Limited and Contributors. All rights reserved. * Copyright (c) 2019, Linaro Limited I am guessing this is because this tool was derived from the existing cert_create tool code, is that right? >> I did not understand why this new tool needs to know what image it is >> encrypting. For example, one possible invocation could be: >> >> tools/encrypt_fw/encrypt_fw \ >> -k 1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef \ >> --soc-fw bl31.bin \ >> --soc-fw-enc bl31_enc.bin \ >> --tos-fw bl32.bin \ >> --tos-fw-enc bl32_enc.bin >> >> Why not invoking the tool once per image instead? As in: >> >> encrypt_fw -k key -in ifile -out ofile >> >> for BL31, then for BL32? Does the tool do anything different based on >> the type of image it receives? > > "encrypt_fw" tool doesn't infer anything based on image type but image > types were added for more user visibility and ease of use as follows: > - Provides the capability to encrypt multiple firmwares on single invocation. I am not really convinced that this is a useful feature. I would rather have an external script (or the build system) invoking the tool multiple times, once per firmware image. Putting that complexity in the tool itself seems unnecessary to me. Also, it makes the tool TBBR specific, as it has to know the list of images it's allowed to encrypt. Unfortunately, we already have this TBBR knowledge embedded into the fiptool/cert_create tool today but we would like to change that in the future. It does not scale well with new images or alternative chains of trust. > - Restricts usage of tool for FIP payloads only. Why would we want that? > - Better align with Makefile framework to build command line args > while building different images and finally invoke tool at once before > creating FIP payload. Could we not invoke the tool for each image as we go along? As in, we build BL31 and just after we generate the encrypted version of it. Then we build BL32 and its encrypted version. And so on. While we do that, we build the fiptool command line that will indeed put all the encrypted images in the final FIP image. How does that sound? Regards, Sandrine

5 years, 6 months

2
1
0 0

Re: [TF-A] psci shutdown do not follow graceful power off sequence

by Sudeep Holla

On Thu, Dec 05, 2019 at 10:47:14PM +0530, Sandeep Tripathy wrote: > On Thu, Dec 5, 2019 at 9:54 PM Dan Handley <Dan.Handley(a)arm.com> wrote: > > > > Hi Sandeep > > > > > -----Original Message----- > > > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Sandeep > > > Tripathy via TF-A > > > Sent: 05 December 2019 12:00 > > > > > > My query is more on the spec. > > > The OS (eg: linux) and atf and psci spec seem to have assumed that it is > > > managing an independent system or managing 'all' the masters in a coherent > > > domain. > > > What other > > > reason could possibly encourage to not to follow a shutdown sequence. > > > > > Do you mean "to not follow a *graceful* shutdown sequence"? > Yes, exactly. Thanks! > If so I can think of 3 reasons: > > 1. It's much slower than a non-graceful shutdown. > But this is certainly not a concern for smaller embedded systems. But we are talking about generic solution here, aren't we ? If so, it remains concern. [..] > I think you are suggesting to use psci system suspend hook in reboot > /power off path Or use system suspend from the OS itself ? Should work. > Just suspend, don't try to use PSCI SYSTEM_SUSPEND in reboot/poweroff path, not at-least in the generic code. If you think it works fine to address your issue, you can use it in your custom solution :) > @Sudeep, I agree alternate approaches to solve data loss problem works > and may be those are the best suited. No, the data loss issue had more open questions and I haven't understood the solution you have there. > The past thread[1] is somewhat related but diverged in multiple directions. OK, details again ? -- Regards, Sudeep

5 years, 6 months

1
0
0 0

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

by Sandrine Bailleux

Hi Julius, As you were mentioning that the Linux kernel uses /proc/sysrq-trigger for a similar purpose, I was wondering whether you'd be open to a solution based on a "DebugFS" entry. As you may have seen on the mailing list, Olivier posted a proposal for introducing a firmware debug interface, which has many similarities to how /proc or /sys works in the kernel world: https://lists.trustedfirmware.org/pipermail/tf-a/2019-October/000120.html TF-A patches for this feature are up for review right now and Olivier has also posted some TF-A Tests patches that demonstrate how this can be used from normal world. In addition, we are also working on a Linux driver for this. As you can imagine, DebugFS uses an SMC interface under the hood (currently allocated in the SiP range). But being an abstraction over the SMC layer, which specific SMC function ID is used does not matter so much and it does not need to be standardized by any Arm specification. You'd need to mandate all Chrome OS devices to have this DebugFS entry in the firmware but the backend could vary from platform to platform. Would that suit your use case? Regards, Sandrine 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, 6 months

2
1
0 0

Build config tool

by Balint Dobszay

Hi All, In TF-A we have a large set of build options (over 90). Dependency and incompatibility checks for these are currently done in the Makefile system. This can be hard to follow and difficult to maintain. We are investigating if there is a better way to describe the build options in a structured way, handle the dependencies/relations between them, and provide a more user-friendly configuration interface. A possible good solution for this is Kconfig, more specifically a Python implementation called Kconfiglib [1]. We plan to do more prototyping work in this area. Any feedback or comments on this topic are welcome. Regards, Balint [1] https://github.com/ulfalizer/Kconfiglib

5 years, 6 months

1
0
0 0

Re: [TF-A] psci shutdown do not follow graceful power off sequence

by Sudeep Holla

On Tue, Dec 3, 2019 at 4:58 PM Sandeep Tripathy via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: > > Hi, > system shutdown or system reset PSCI calls are invoked by the last > core in the system. PSCI lib does not do cache flush for the last core > /cluster and does not follow the core / cluster power down sequence. > This may cause issue in a system if the system is not standalone one > ie if the system is a slave or node in a bigger system with other > coherent masters/PEs. > I am not sure if system off/reset is the right API to call in such a setup. > Please suggest if the PSCI spec expected 'shutdown/reset/reset2' to > deliberately skip the core/cluster shutdown sequence. > Yes and IIRC this has been discussed in the past[1]. I expect to get some closure on open question on that thread. Quite a few questions were raised by few people and I am not sure if all were answered. I need to dig but but AFAIK it wasn't all answered. -- Regards, Sudeep [1] https://lkml.org/lkml/2019/1/18/16

5 years, 6 months

2
2
0 0

About disable gic cpuif in psci suspend or off

by Jisheng Zhang

Hi, In ATF-A, I usually see below code in psci suspend or off code path: /* Prevent interrupts from spuriously waking up this cpu */ plat_arm_gic_cpuif_disable(); But per my understanding, before calling psci_suspend(), the NW, e.g linux kernel has disabled all interrupts from cpu level, so here preventing interrupt is to prevent the interrupts from secure world? Another question is: for Cortex A55, this is not necessary. Because CA55 TRM says when the core_pwrdn_en bit is set, executing WFI automatically masks all interrupts and wake-up events in the core. Am I right? Thanks in advance

5 years, 6 months

1
0
0 0

Re: [TF-A] Insufficient ordering guarantees in bakery_lock_get() and bakery_lock_release() in bakery_lock_coherent.c

by Raghupathy Krishnamurthy

Hi Soby, Thanks for your response. >>it is needed to ensure the ordering of the succeeding sev(). Agree. Thanks for the clarification. >>Was this an issue that actually manifested on a hardware or is this something that you caught while reviewing the code? Noticed it while reviewing code and I have not observed it on hardware. Thanks -Raghu On November 26, 2019 at 8:55 AM, Soby Mathew <Soby.Mathew(a)arm.com> wrote: On 26/11/2019 16:30, Raghupathy Krishnamurthy via TF-A wrote: Hello! Reposting this from (https://developer.trustedfirmware.org/T589). bakery_lock_get() uses a dmbld() after lock acquisition which is insufficient in a lock acquire situation. With just dmbld(), stores in a critical section can be reordered before the dmbld() and indeed before the lock acquisition has taken place. similarly, bakery_lock_release() only uses dmbst(). A load in the critical section could be reordered after the dmbst() and write to the lock data structure releasing the lock. This is likely less of a problem but lock release needs to provide release semantics, and dmbst() is insufficient. For ex: A load in the critical section of CPU1 can be reordered after the store for the lock release, and it could read from a store that is executed on CPU2 in the same critical section, since CPU2 saw the store for the lock release first, and raced into the critical section. Hi Raghu, You are right on this. The dmbld() and dmbst() does not provide sufficient guarantees in the cases you mention. Was this an issue that actually manifested on a hardware or is this something that you caught while reviewing the code ? Also the dsb() after the write to the lock seems unnecessary. Am I missing something here ? It looks like the same issue is present even in bakery_lock_normal. If you are referring to the dsb() at this line : https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/lib/locks/… it is needed to ensure the ordering of the succeeding sev(). Best Regards Soby Mathew Thanks Raghu

5 years, 6 months

2
2
0 0

Re: [TF-A] psci shutdown do not follow graceful power off sequence

by Dan Handley

Hi Sandeep > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Sandeep > Tripathy via TF-A > Sent: 03 December 2019 16:59 > > Hi, > system shutdown or system reset PSCI calls are invoked by the last core in > the system. That may be the case in practice but these functions can be called by any core in the system at any time, not just the last core. > PSCI lib does not do cache flush for the last core /cluster and > does not follow the core / cluster power down sequence. Correct. Not only that, it doesn't do anything with the other cores in the system that may be running at that time. > This may cause issue in a system if the system is not standalone one ie if > the system is a slave or node in a bigger system with other coherent > masters/PEs. > What issue specifically? Are the other coherent masters expecting to have the same view of the node's memory that the node had prior to calling system off/suspend? If so, then the node is not really independent to the wider system and system off/reset are probably not the right calls to use. Perhaps SYSTEM_SUSPEND is what you're looking for? That function requires all other cores to be off before the call and will perform cache maintenance on the last core. > Please suggest if the PSCI spec expected 'shutdown/reset/reset2' to > deliberately skip the core/cluster shutdown sequence. > Yes, the spec was deliberately relaxed between version 0.2 and 1.0 to allow implementations to just "pull the plug" since there would be no observable difference to the normal world caller between this behaviour and attempting to shutdown cleanly, which would be difficult and inherently racy anyway. > Otherwise in case it makes sense following is a patch to take care of this. > https://review.trustedfirmware.org/#/c/TF-A/trusted-firmware-a/+/2364/ > issue: https://developer.trustedfirmware.org/T566 Thanks but I don't think we want this. Regards Dan. 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, 6 months

1
0
0 0

psci shutdown do not follow graceful power off sequence

by Sandeep Tripathy

Hi, system shutdown or system reset PSCI calls are invoked by the last core in the system. PSCI lib does not do cache flush for the last core /cluster and does not follow the core / cluster power down sequence. This may cause issue in a system if the system is not standalone one ie if the system is a slave or node in a bigger system with other coherent masters/PEs. Please suggest if the PSCI spec expected 'shutdown/reset/reset2' to deliberately skip the core/cluster shutdown sequence. Otherwise in case it makes sense following is a patch to take care of this. https://review.trustedfirmware.org/#/c/TF-A/trusted-firmware-a/+/2364/ issue: https://developer.trustedfirmware.org/T566 Thanks Sandeep

5 years, 6 months

1
0
0 0

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

by Sandrine Bailleux

Hello Sumit, Sorry for not getting back to you earlier on this. I started looking at your patches and although I've not completely got my head around them yet, I've got some early comments and questions. I've tried to classify them by themes below. First of all, let me say that I'm no security expert and I did not know about the concept of authenticated encryption/decryption before looking at your patches. I spent a couple of hours reading about such algorithms in general and AES-GCM in particular. Most of what I've learned so far is based on my understanding of RFC 5116 [1]. What's the motivation for choosing GCM to start with? I've seen that it is free of patent [2], which I am guessing was a strong argument for it. I've also read that it is supposed to be quite lightweight and can take full advantage of parallel processing, although I've not looked into the details. Were these the reasons? Any other reasons? Key management -------------- fip_file_read() retrieves the key from the platform and stores it in a buffer on the stack. I don't see any code wiping it out of memory once we're done with it. Did I miss it? Unlike the root of trust public key, this is a (symmetric) secret key so it is sensitive data that we must not leave for grabs, even if the stack is in Trusted RAM and that it's likely to be overwritten by subsequent stack usage. Also, I am still trying to get my head around how this would integrate with a cryptographic engine where the key does not leave the chip. I can imagine that we could get the address of the encrypted firmware image from the FIP, pass that to a cryptographic engine, request it to decrypt it and store the result somewhere in Trusted RAM. In this case, we wouldn't call plat_get_fip_encryption_key(). Do you have any idea how we would pull this off? Like how the different modules (IO layer, crypto module, image parser module, ...) would integrate together? I have some concerns around the generation of the initialization vectors in the encrypt_fw tool. Right now, IVs are simply a random sequence of bytes (obtained through a call to OpenSSL's RAND_bytes() API). Now, I would imagine that RAND_bytes() is typically based on a good random number generator and thus will generate different sequences every time it is called. At least, as long as it is called from the same machine every time. But what if we encrypt a new FIP bundle from a different machine, say in the context of a firmware update? Is it not possible that it might choose the same IV out of bad luck? Perhaps that's an issue left to provisioning/manufacturing time and is out of the scope here. But it worries me because AFAIU, the security of AES-GCM is critically undermined if the same nonce is used multiple times with the same key (see section 5.1.1. "Nonce reuse" in RFC 5116). If the encryption key is the SSK (rather than the BSSK) then I guess the probability is even higher, as it is shared amongst a class of devices. Impact on memory footprint and performance ------------------------------------------ Do you know what the performance impact is when this feature is enabled in TF-A, to decrypt images at boot time? Obviously it depends on the platform and whether there is a dedicated cryptographic engine, and I suppose you cannot really get any relevant measurements out of QEMU but I would be interested if you've got any rough numbers. And what's the memory footprint impact? IIUC, AES-GCM almost does not inflate the size of the data it encrypts. The size of the ciphertext seems to be the same as the plaintext + the size of the authentication tag. So I guess there's no real impact on flash storage and Trusted RAM usage to hold decrypted firmware. But what about the mbedTLS primitives to decrypt the images? How much code and data does this add? encrypt_fw tool --------------- We have some floating ideas around re-implementing the tools (fiptool, certtool) in a scripting language (possibly python) in the future and also doing a better job at sharing a common description of the list of images to boot/authenticate between the firmware and the host tools. But we're not there yet, so I agree that implementing this new tool in C from the same "mold" as fiptool and certtool is what makes the most sense today. It's just another tool we will have to rework if and when we get there. I did not understand why this new tool needs to know what image it is encrypting. For example, one possible invocation could be: tools/encrypt_fw/encrypt_fw \ -k 1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef \ --soc-fw bl31.bin \ --soc-fw-enc bl31_enc.bin \ --tos-fw bl32.bin \ --tos-fw-enc bl32_enc.bin Why not invoking the tool once per image instead? As in: encrypt_fw -k key -in ifile -out ofile for BL31, then for BL32? Does the tool do anything different based on the type of image it receives? Regards, Sandrine [1] https://tools.ietf.org/html/rfc5116 [2] https://csrc.nist.gov/csrc/media/projects/block-cipher-techniques/documents…

5 years, 6 months

2
1
0 0

Design proposal: new buildsystem

by Balint Dobszay

Hi All, The buildsystem of TF-A became complex and loaded with technical debt during the years, and it's time to do something about this. We made some plans and prototyping work to move to a CMake based solution and we would like to get feedback on the idea. Why CMake? In summary CMake is a mature tool having a wide acceptance in C and C++ projects. Also it has benefits of decreasing fragmentation in the developer community if we sync up with TF-M. How will it happen? This will be a slow process where the old build system will co-exist for a period with the new one. How long that period will be is an open question. For a more detailed summary please see https://developer.trustedfirmware.org/w/tf_a/cmake-buildsystem-proposal/ The design discussion will follow the design review proposal process of TF.org, as described on this page: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu… You can find the patch for capturing the design decisions and discussion here: https://review.trustedfirmware.org/#/c/TF-A/trusted-firmware-a/+/2662/ If you would like to contribute or have an opinion or any ideas please reply to this email or add a comment on Gerrit (link above). Regards, Balint 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, 6 months

1
0
0 0

Re: [TF-A] Insufficient ordering guarantees in bakery_lock_get() and bakery_lock_release() in bakery_lock_coherent.c

by Soby Mathew

On 26/11/2019 16:30, Raghupathy Krishnamurthy via TF-A wrote: > Hello! > > Reposting this from (https://developer.trustedfirmware.org/T589). > > bakery_lock_get() uses a dmbld() after lock acquisition which is insufficient in a lock acquire situation. With just dmbld(), stores in a critical section can be reordered before the dmbld() and indeed before the lock acquisition has taken place. similarly, bakery_lock_release() only uses dmbst(). A load in the critical section could be reordered after the dmbst() and write to the lock data structure releasing the lock. This is likely less of a problem but lock release needs to provide release semantics, and dmbst() is insufficient. For ex: A load in the critical section of CPU1 can be reordered after the store for the lock release, and it could read from a store that is executed on CPU2 in the same critical section, since CPU2 saw the store for the lock release first, and raced into the critical section. Hi Raghu, You are right on this. The dmbld() and dmbst() does not provide sufficient guarantees in the cases you mention. Was this an issue that actually manifested on a hardware or is this something that you caught while reviewing the code ? > Also the dsb() after the write to the lock seems unnecessary. Am I missing something here ? It looks like the same issue is present even in bakery_lock_normal. > If you are referring to the dsb() at this line : https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/lib/locks/… it is needed to ensure the ordering of the succeeding sev(). Best Regards Soby Mathew > Thanks > Raghu >

5 years, 6 months

1
0
0 0

Insufficient ordering guarantees in bakery_lock_get() and bakery_lock_release() in bakery_lock_coherent.c

by Raghupathy Krishnamurthy

Hello! Reposting this from (https://developer.trustedfirmware.org/T589). bakery_lock_get() uses a dmbld() after lock acquisition which is insufficient in a lock acquire situation. With just dmbld(), stores in a critical section can be reordered before the dmbld() and indeed before the lock acquisition has taken place. similarly, bakery_lock_release() only uses dmbst(). A load in the critical section could be reordered after the dmbst() and write to the lock data structure releasing the lock. This is likely less of a problem but lock release needs to provide release semantics, and dmbst() is insufficient. For ex: A load in the critical section of CPU1 can be reordered after the store for the lock release, and it could read from a store that is executed on CPU2 in the same critical section, since CPU2 saw the store for the lock release first, and raced into the critical section. Also the dsb() after the write to the lock seems unnecessary. Am I missing something here ? It looks like the same issue is present even in bakery_lock_normal. Thanks Raghu

5 years, 6 months

1
0
0 0

Review hiccups

by Julius Werner

Hi Soby (and others), We've had a couple of MT8183 platform patches on Gerrit waiting for review/merge for a while (one over a week). Could you please help make sure they are in someone's queue at Arm? https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2379 (passed CI) https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2175 (passed CI) https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2401 (need kick off CI) Let me know if there's anything else we can do to help increase turnaround time on Gerrit. Thanks, Julius

5 years, 6 months

2
1
0 0

How to verify image BL1

by Iñigo Vicente Waliño

Hi, I am using QEMu to simulate the ARMv8 platform. How can I verify that the BL1 image is in the ROM? And if not, can I not find it? Thanks, Iñigo.

5 years, 6 months

1
0
0 0

TF-A Public Presentations collection

by Matteo Carlini

Hi all, I finally got round to collating links to all TF-A public presentations done over the years in our wiki page here https://developer.trustedfirmware.org/w/tf_a/ I intend to keep the list updated with all future appearances as well. Let me know if you spot any error or inconsistency. Thanks Matteo

5 years, 6 months

1
0
0 0

Design proposal: Property Access Layer

by Louis Mayencourt

Hi everyone, Please let me introduce the `Property Access Layer` prototype: The Property Access Layer (PAL) is an abstraction layer for platform specific data, allowing a "property" to be queried and a value retrieved without the requesting entity knowing what backing store is being used to hold the data. It is used to bridge new and old ways of providing platform-specific data: Today, information like the Chain of Trust is held within several, nested platform-defined tables. In the future, it may be provided as part of a device tree blob, along with the information about images to load. Introducing this abstraction layer will make migration easier and will preserve functionality for platforms that cannot / don't want to use device tree. Please have a look at the patches: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2559/1 Regards, Louis 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, 6 months

1
0
0 0

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

by Sumit Garg

Hi Everyone, The motivation behind this new feature comes from DRM robustness rules. DRM content vendors want to make it even harder to reverse engineer Trusted Execution Environment (TEE) and therefore would like to see that Trusted OS (BL32 payload) is not just signed, but also encrypted. Dan, Matteo, In continuation to our discussions at Linaro Connect SAN19 regarding support for encrypted firmwares (especially encrypted Trusted OS as BL32 payload) in TF-A. I have tried to come up with below RFC patch-set based on TBBR [1] optional requirement: R070_TBBR_FUNCTION. RFC patch-set: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2494 https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2495 https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2496 https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2497 https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2498 https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2499 https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2500 https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2501 https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2502 Also, I have used QEMU as a reference platform to test this feature (instructions documented as part of "[PATCH 9/9] docs: qemu: Add instructions to boot using FIP image"). So that it's easier for people interested in this feature to test. I look forward to hear feedback/comments on this new feature. [1] https://developer.arm.com/docs/den0006/latest/trusted-board-boot-requiremen… Regards, Sumit

5 years, 7 months

1
0
0 0

Notice of SPCI-SPM Prototype Removal

by Paul Beesley

Hello, This message is to provide advance notice that the experimental Secure Partition Manager (SPM) component - based around the SPCI Alpha 1 specification - will be removed from the codebase within the next few weeks. This component was deprecated for the v2.2 release. Normally a component stays in the codebase for one full release cycle after being deprecated but that does not apply to experimental and/or prototype features such as this one. The intention is not to replace this component directly with a similar SPM component but to instead implement an EL3 SPCI dispatcher component that enables the use of secure partitions with an SPM at either S-EL1 or at S-EL2 (v8.4 or later). This dispatcher would be compliant with the latest public draft of the Secure Partition Client Interface (SPCI) specification at the time. Please note that the SPM-MM (Management Mode) component is *not* going to be removed as part of this work. If you have any questions or concerns about this change then please get in touch either via this mailing list or via your Arm partner manager (where applicable). Thanks, Paul

5 years, 7 months

1
0
0 0

Re: [TF-A] [RFC] BL2 MTD frameworks

by Lionel DEBIEVE

Hi, Just to clarify a little bit more. There is no link here about a 32/64 bit architecture. The content of this change is to take care about new memory introduce (mtd devices) that are not based on size * LBA (where LBA=512) but size * LBA where (LBA=1) and in such case, the size could exceed the 4GB. It is not platform dependent and not architecture dependent, it's link to the connected MTD device only. I'm not sure that a new type is useful except if you want a type is modified regarding a platform flag such as USE_LARGE_MTD_DEVICE. Hope it's more clear. BR, Lionel On 11/5/19 3:20 PM, Gyorgy Szing via TF-A wrote: > Hi, > > I did not investigated all the details so what stays below may contain mistakes, but still I would like to add some comments. > > "using a type for the offset" > The type we use for this purpose seems to be a configuration parameter for the IO layer as it depends on the upper layer being used with the IO library. For example libc uses "long int" to specify the file offset (fseek, ftell), using a different type while running below libc does not seem to be a good idea. > The best option seems to be to define a type like (as Olivier mentioned) lib/zlib does. How we set this configuration parameter during the build is a question. The offset type could be dictated by the platform, the architecture (aarch32 or aarch64) or by the user. Which one is worth to implement needs investigation. > > If it is a good idea to use the same name "off_t" as zlib uses (or even the same type) is be questionable. It may give us more flexibility if we use a dedicated name, and the configuration maps the IO type to the one used by the upper layer. > > "32 bit backward compatibility" > Another angle worth to consider is the 32/64 bit compatibility. I.e.: newlib can use 64 bit offsets even on 32 bit architectures, and they use some wrappers to maintain binary compatibility with old builds. When built in a compatible manner, functions using the standardized names use 32 bit wide offsets and call the real 64 bit implementation as a wrapper. > To solve compatibility issues we could use a similar pattern. Instead of changing the existing function, we could add a new one (i.e. seek64). Then new 64 bit aware code could use the new function if available, and legacy code could call the old one. Longer term it is an option to deprecate the 32 bit version. > > "use stdint.h types" > And a finally: when selecting the type used for off_t (or whatever we are going to call it) please consider using stdint.h types (i.e. int_fast64_t). > > /George > > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Olivier Deprez via TF-A > Sent: 25 October 2019 14:42 > To: tf-a(a)lists.trustedfirmware.org; Lionel DEBIEVE <lionel.debieve(a)st.com> > Subject: Re: [TF-A] [RFC] BL2 MTD frameworks > > Hi Lionel, > > On https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2283 > I'm extending the discussion to the TF-A ML, to get people's opinion. > > The idea is to extend the io_seek offset parameter from ssize_t to unsigned long long. > There are indeed good reasons for that as flash storage density grows over the years. > > Now on the change, the struct io_dev_funcs seek function pointer is generic for the whole codebase / drivers. > So currently the change breaks the builds for at least rcar, stratix10 (did not check others from that point). > > An alternative is defining offset as an off_t type which is ssize_t by default, and only unsigned long long based on the platform (using _FILE_OFFSET_BITS=64). This pattern actually already exists in lib/zlib > > Other option is to change the generic prototype for all platform drivers (then we ensure all platforms build and supply platform patches). > > What do ML people think? > > Regards, > Olivier. > > > > ________________________________ > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Lionel DEBIEVE via TF-A <tf-a(a)lists.trustedfirmware.org> > Sent: 18 October 2019 17:26 > To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> > Subject: [TF-A] [RFC] BL2 MTD frameworks > > Hello Maintainers, > > I've sent a patch series around MTD framework management into BL2 stage (cf https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2283). > > This patch series will add following frameworks: > > - a raw NAND framework implementation to support SLC NAND devices. Current implementation is limited to read operations without ECC corrections. Overrides are available to use hardware ECC from controller or low-level drivers. It also supports ONFI detection management but this can also be disabled or overridden by platform specific data. > - a SPI-MEM framework (inspired from kernel/u-boot implementation) that encapsulates all SPI operations to SPI low level drivers. > - a SPI-NAND framework based on SPI-MEM to support SPI NAND devices. This framework is also limited to the read operation. It uses single command, address and data bus width as legacy but can be overridden by platform. > - a SPI-NOR framework based on SPI-MEM to manage SPI NOR devices. It is also limited to read operations using single command, address and data bus width as legacy (override still possible by platform). The framework embeds some specific implementations for manufacturers specific behavior in case of quad mode configuration activation. > > This patch series also includes: > > - a new io_mtd interface to manage a generic access to all these frameworks. > - a NAND core driver that accesses independently to raw NAND or SPI-NAND framework. This core driver requires a scratch buffer defined by platform to manage unaligned pages (could be defined to 0 in case of aligned page) and limits access to a single NAND instance management. > - a complete integration is available based on STM32MP1 platform. > > Tests have been performed with the following devices: > > SLC NAND: > - Micron MT29F8G08ABACAH4 (ONFI) > - Micron MT29F8G16ABACAH4 (ONFI) > - Toshiba TH58NVG3S0HTAI0 (Non ONFI) > - Toshiba TC58BVG1S3HTAI0 (On die ECC) > > SPI NOR: > - Macronix MX25L51245G > - Cypress/Spansion S25FL512 > - Micron n25q512ax3 > > SPI-NAND: > - Micron MT29F2G01ABAGD > > Waiting for your comments. > > Best regards, Lionel > -- > 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, 7 months

1
0
0 0

[RFC] Multiple Signing Domains

by Sandrine Bailleux

Hello all, As you may know, the Trusted Board Boot (TBB) code relies on the platform to define a chain of trust (CoT). Today, the only example of CoT present in the code base is the one used on Arm platforms, which is described: - in the TBBR specification [1]. - in the TF-A documentation [2] [3]. The entire TBBR CoT is built upon the root-of-trust public key (ROTPK), which is used to authenticate all subsequent firmware binaries and certificates, either directly or indirectly through some intermediate certificates. The TBBR CoT is only one example of a possible certificate chain and key ownership model. It might not suit all platforms and market segments but the TBBR implementation in TF-A leaves some freedom for other CoTs. Today, we are publishing some proof-of-concept code that shows one way the existing TBBR CoT may be modified in order to detach the BL33 image from the rest of the CoT. This effectively splits it into 2 CoTs: - 1 CoT for all secure world images (BL2, BL31, BL32). - 1 CoT for the normal world bootloader (BL33). If you are interested, please have a look at the related patch as well as the companion documentation: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2443 https://developer.trustedfirmware.org/w/tf_a/poc-multiple-signing-domains/ Note that at this stage, this is only prototype code and we do not plan to integrate it in the code base as is, because it does not implement what we would consider as a clean solution and uses a number of workarounds. We are considering cleaning this patch up and providing it as an alternate CoT on FVP platform in the future. For now, the intent is to provide some material, which we can base a discussion on. We're hoping to gather feedback from interested parties on the suitability of this approach. Regards, Sandrine [1] https://developer.arm.com/docs/den0006/d/trusted-board-boot-requirements-cl… (see page 21) [2] https://trustedfirmware-a.readthedocs.io/en/latest/design/trusted-board-boo… [3] https://trustedfirmware-a.readthedocs.io/en/latest/design/auth-framework.ht…

5 years, 7 months

1
0
0 0

Re: [TF-A] [RFC] BL2 MTD frameworks

by Gyorgy Szing

Hi, I did not investigated all the details so what stays below may contain mistakes, but still I would like to add some comments. "using a type for the offset" The type we use for this purpose seems to be a configuration parameter for the IO layer as it depends on the upper layer being used with the IO library. For example libc uses "long int" to specify the file offset (fseek, ftell), using a different type while running below libc does not seem to be a good idea. The best option seems to be to define a type like (as Olivier mentioned) lib/zlib does. How we set this configuration parameter during the build is a question. The offset type could be dictated by the platform, the architecture (aarch32 or aarch64) or by the user. Which one is worth to implement needs investigation. If it is a good idea to use the same name "off_t" as zlib uses (or even the same type) is be questionable. It may give us more flexibility if we use a dedicated name, and the configuration maps the IO type to the one used by the upper layer. "32 bit backward compatibility" Another angle worth to consider is the 32/64 bit compatibility. I.e.: newlib can use 64 bit offsets even on 32 bit architectures, and they use some wrappers to maintain binary compatibility with old builds. When built in a compatible manner, functions using the standardized names use 32 bit wide offsets and call the real 64 bit implementation as a wrapper. To solve compatibility issues we could use a similar pattern. Instead of changing the existing function, we could add a new one (i.e. seek64). Then new 64 bit aware code could use the new function if available, and legacy code could call the old one. Longer term it is an option to deprecate the 32 bit version. "use stdint.h types" And a finally: when selecting the type used for off_t (or whatever we are going to call it) please consider using stdint.h types (i.e. int_fast64_t). /George -----Original Message----- From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Olivier Deprez via TF-A Sent: 25 October 2019 14:42 To: tf-a(a)lists.trustedfirmware.org; Lionel DEBIEVE <lionel.debieve(a)st.com> Subject: Re: [TF-A] [RFC] BL2 MTD frameworks Hi Lionel, On https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2283 I'm extending the discussion to the TF-A ML, to get people's opinion. The idea is to extend the io_seek offset parameter from ssize_t to unsigned long long. There are indeed good reasons for that as flash storage density grows over the years. Now on the change, the struct io_dev_funcs seek function pointer is generic for the whole codebase / drivers. So currently the change breaks the builds for at least rcar, stratix10 (did not check others from that point). An alternative is defining offset as an off_t type which is ssize_t by default, and only unsigned long long based on the platform (using _FILE_OFFSET_BITS=64). This pattern actually already exists in lib/zlib Other option is to change the generic prototype for all platform drivers (then we ensure all platforms build and supply platform patches). What do ML people think? Regards, Olivier. ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Lionel DEBIEVE via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 18 October 2019 17:26 To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] [RFC] BL2 MTD frameworks Hello Maintainers, I've sent a patch series around MTD framework management into BL2 stage (cf https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2283). This patch series will add following frameworks: - a raw NAND framework implementation to support SLC NAND devices. Current implementation is limited to read operations without ECC corrections. Overrides are available to use hardware ECC from controller or low-level drivers. It also supports ONFI detection management but this can also be disabled or overridden by platform specific data. - a SPI-MEM framework (inspired from kernel/u-boot implementation) that encapsulates all SPI operations to SPI low level drivers. - a SPI-NAND framework based on SPI-MEM to support SPI NAND devices. This framework is also limited to the read operation. It uses single command, address and data bus width as legacy but can be overridden by platform. - a SPI-NOR framework based on SPI-MEM to manage SPI NOR devices. It is also limited to read operations using single command, address and data bus width as legacy (override still possible by platform). The framework embeds some specific implementations for manufacturers specific behavior in case of quad mode configuration activation. This patch series also includes: - a new io_mtd interface to manage a generic access to all these frameworks. - a NAND core driver that accesses independently to raw NAND or SPI-NAND framework. This core driver requires a scratch buffer defined by platform to manage unaligned pages (could be defined to 0 in case of aligned page) and limits access to a single NAND instance management. - a complete integration is available based on STM32MP1 platform. Tests have been performed with the following devices: SLC NAND: - Micron MT29F8G08ABACAH4 (ONFI) - Micron MT29F8G16ABACAH4 (ONFI) - Toshiba TH58NVG3S0HTAI0 (Non ONFI) - Toshiba TC58BVG1S3HTAI0 (On die ECC) SPI NOR: - Macronix MX25L51245G - Cypress/Spansion S25FL512 - Micron n25q512ax3 SPI-NAND: - Micron MT29F2G01ABAGD Waiting for your comments. Best regards, Lionel -- 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. -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 7 months

1
0
0 0

New "memory map" tool

by Louis Mayencourt

Hi all, We are introducing a new "memory map" tool part of the build system. The tool parse the blx.map files and print a representation of the memory layout for the latest build. It can be invoked by adding "memmap" in the make build command. If you are interested, please have a look at the related patch: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2413/1 Regards, Louis 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, 7 months

1
0
0 0

Design proposal: firmware debugfs interface

by Olivier Deprez

Hi All, We are proposing a new firmware debug interface in the form of a "debug filesystem". The intent is to expose live firmware data or firmware driver HAL to the upper layers, in debug builds. For people interested, please review and comment the design proposal: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2381 The design is not closed, the intent is to collect opinions, and have a discussion on options and implications. Thanks & Regards, Olivier. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

5 years, 7 months

1
0
0 0

Re: [TF-A] [RFC] BL2 MTD frameworks

by Olivier Deprez

Hi Lionel, On https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2283 I'm extending the discussion to the TF-A ML, to get people's opinion. The idea is to extend the io_seek offset parameter from ssize_t to unsigned long long. There are indeed good reasons for that as flash storage density grows over the years. Now on the change, the struct io_dev_funcs seek function pointer is generic for the whole codebase / drivers. So currently the change breaks the builds for at least rcar, stratix10 (did not check others from that point). An alternative is defining offset as an off_t type which is ssize_t by default, and only unsigned long long based on the platform (using _FILE_OFFSET_BITS=64). This pattern actually already exists in lib/zlib Other option is to change the generic prototype for all platform drivers (then we ensure all platforms build and supply platform patches). What do ML people think? Regards, Olivier. ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Lionel DEBIEVE via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 18 October 2019 17:26 To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] [RFC] BL2 MTD frameworks Hello Maintainers, I've sent a patch series around MTD framework management into BL2 stage (cf https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2283). This patch series will add following frameworks: - a raw NAND framework implementation to support SLC NAND devices. Current implementation is limited to read operations without ECC corrections. Overrides are available to use hardware ECC from controller or low-level drivers. It also supports ONFI detection management but this can also be disabled or overridden by platform specific data. - a SPI-MEM framework (inspired from kernel/u-boot implementation) that encapsulates all SPI operations to SPI low level drivers. - a SPI-NAND framework based on SPI-MEM to support SPI NAND devices. This framework is also limited to the read operation. It uses single command, address and data bus width as legacy but can be overridden by platform. - a SPI-NOR framework based on SPI-MEM to manage SPI NOR devices. It is also limited to read operations using single command, address and data bus width as legacy (override still possible by platform). The framework embeds some specific implementations for manufacturers specific behavior in case of quad mode configuration activation. This patch series also includes: - a new io_mtd interface to manage a generic access to all these frameworks. - a NAND core driver that accesses independently to raw NAND or SPI-NAND framework. This core driver requires a scratch buffer defined by platform to manage unaligned pages (could be defined to 0 in case of aligned page) and limits access to a single NAND instance management. - a complete integration is available based on STM32MP1 platform. Tests have been performed with the following devices: SLC NAND: - Micron MT29F8G08ABACAH4 (ONFI) - Micron MT29F8G16ABACAH4 (ONFI) - Toshiba TH58NVG3S0HTAI0 (Non ONFI) - Toshiba TC58BVG1S3HTAI0 (On die ECC) SPI NOR: - Macronix MX25L51245G - Cypress/Spansion S25FL512 - Micron n25q512ax3 SPI-NAND: - Micron MT29F2G01ABAGD Waiting for your comments. Best regards, Lionel -- 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, 7 months

1
0
0 0

Re: [TF-A] compile toolchain

by Alexei Fedorov

Hi Feng, user-guide.rst references GCC 9.1 and later versions. The code was also tested with GCC 10.0.0. Regards. Alexei ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Chen Feng via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 24 October 2019 14:32 To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] compile toolchain hi expects， from the atf2.2 release notes,I can see the tf-a already supported pac bti and mte feature. I want to enable and test it on fvp platform. I want to know which tool chain to use for compiling code for theses. Cheers Feng -- 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, 7 months

1
0
0 0

compile toolchain

by Chen Feng

hi expects， from the atf2.2 release notes,I can see the tf-a already supported pac bti and mte feature. I want to enable and test it on fvp platform. I want to know which tool chain to use for compiling code for theses. Cheers Feng

5 years, 7 months

1
0
0 0

Trusted Firmware version 2.2 is now available

by Bipin Ravi

Hi all, Trusted Firmware version 2.2 is now available and can be found here: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tag/?h=v2.2 Please refer to the readme and change log for further information. Thanks & best regards, [cid:image001.jpg@01D588EA.577B7090] Bipin Ravi | Principal Design Engineer Bipin.Ravi(a)arm.com<mailto:Joshua.Sunil@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, 7 months

1
0
0 0

[RFC] BL2 MTD frameworks

by Lionel DEBIEVE

Hello Maintainers, I've sent a patch series around MTD framework management into BL2 stage (cf https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2283). This patch series will add following frameworks: - a raw NAND framework implementation to support SLC NAND devices. Current implementation is limited to read operations without ECC corrections. Overrides are available to use hardware ECC from controller or low-level drivers. It also supports ONFI detection management but this can also be disabled or overridden by platform specific data. - a SPI-MEM framework (inspired from kernel/u-boot implementation) that encapsulates all SPI operations to SPI low level drivers. - a SPI-NAND framework based on SPI-MEM to support SPI NAND devices. This framework is also limited to the read operation. It uses single command, address and data bus width as legacy but can be overridden by platform. - a SPI-NOR framework based on SPI-MEM to manage SPI NOR devices. It is also limited to read operations using single command, address and data bus width as legacy (override still possible by platform). The framework embeds some specific implementations for manufacturers specific behavior in case of quad mode configuration activation. This patch series also includes: - a new io_mtd interface to manage a generic access to all these frameworks. - a NAND core driver that accesses independently to raw NAND or SPI-NAND framework. This core driver requires a scratch buffer defined by platform to manage unaligned pages (could be defined to 0 in case of aligned page) and limits access to a single NAND instance management. - a complete integration is available based on STM32MP1 platform. Tests have been performed with the following devices: SLC NAND: - Micron MT29F8G08ABACAH4 (ONFI) - Micron MT29F8G16ABACAH4 (ONFI) - Toshiba TH58NVG3S0HTAI0 (Non ONFI) - Toshiba TC58BVG1S3HTAI0 (On die ECC) SPI NOR: - Macronix MX25L51245G - Cypress/Spansion S25FL512 - Micron n25q512ax3 SPI-NAND: - Micron MT29F2G01ABAGD Waiting for your comments. Best regards, Lionel

5 years, 7 months

1
0
0 0

Re: [TF-A] Boot getting stuck on RK3399 Rockpro64 board

by Joanna Farley

Hi Hugh, Ccing the Rockchip maintainers from https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/docs/maint… as neither appear to be subscribed to this mailing list. Joanna On 08/10/2019, 21:45, "TF-A on behalf of Hugh Cole-Baker via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: Hi folks, I've been using TF-A with mainline U-Boot recently as firmware & boot loader for a RK3399 Rockpro64 board. I'm compiling TF-A and U-boot based on this guide [1], using gcc 8.3.0 from Debian. TF-A v2.1 works fine for this, but I recently tried to switch to TF-A latest master and found U-Boot gets stuck with this version. The symptoms are: U-Boot TPL and SPL print starting messages like this: U-Boot TPL 2019.10-rc4-00037-gdac51e9aaf (Oct 06 2019 - 21:42:50) Trying to boot from BOOTROM Returning to boot ROM... U-Boot SPL 2019.10-rc4-00037-gdac51e9aaf (Oct 06 2019 - 21:42:50 +0000) Trying to boot from MMC2 ...and then there is no more output when normally U-Boot proper would start, and go on to load the Linux kernel, etc. Starting from v2.1, with git bisect I found the first 'bad' commit is: 0aad563c7480 rockchip: Update BL31_BASE to 0x40000 and that commit does change some RK3399-related files so seems likely. I'm not sure how to debug further, any ideas on why boot is hanging after that change or how to get more debugging information? Best regards, Hugh Cole-Baker [1] https://github.com/u-boot/u-boot/blob/master/doc/README.rockchip -- 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, 8 months

2
1
0 0

Re: [TF-A] Hercules-AE I$ problems

by Olivier Deprez

Hi Varun, TF-A v1.4 is rather old codebase, can you provide the exact patchset you cherry-picked on top of it? e.g. you need the Hercules CPU support patch (a4668c36f1fca75b), but possibly also all which is related to HW_ASSISTED_COHERENCY option? Also, can you pls provide your build cmd line? Thanks & Regards, Olivier. ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Soby Mathew via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 11 October 2019 11:21 To: Varun Wadekar <vwadekar(a)nvidia.com>; Joanna Farley <Joanna.Farley(a)arm.com>; Matteo Carlini <Matteo.Carlini(a)arm.com> Cc: Julius Werner via TF-A <tf-a(a)lists.trustedfirmware.org>; nd <nd(a)arm.com> Subject: Re: [TF-A] Hercules-AE I$ problems On 10/10/2019 20:46, Varun Wadekar wrote: > Hello, > > First of all, thanks a lot for posting the Hercules-AE patches. > > We picked them up and used them internally. Unfortunately, the CPU sees > garbage in it's I$ when we enable the I cache for the processor. If we > keep I$ disabled, TF-A boots properly. We are using TF-A v1.4 for > verification. > > We booted Linux kernel v4.14 on the processor and don't see this problem > there. So, we suspect something going wrong inside TF-A. Have you seen > this problem internally? Any hints or clues to solve it would be helpful. > > Thanks. Hi Varun, As indicated in the commit message of the patch, we have not tested the CPU support internally due to non-availability of FVP for the CPU. TF-A assumes that I$ will be invalidated when CPU is reset. Perhaps this is not true for your setup. Could you try adding a `IC IALLU` in the CPU reset handler prior to I$ enable and see if that improves anything ? Best Regards Soby Mathew > > > ------------------------------------------------------------------------ > This email message is for the sole use of the intended recipient(s) and > may contain confidential information. Any unauthorized review, use, > disclosure or distribution is prohibited. If you are not the intended > recipient, please contact the sender by reply email and destroy all > copies of the original message. > ------------------------------------------------------------------------ -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

5 years, 8 months

1
0
0 0

Hercules-AE I$ problems

by Varun Wadekar

Hello, First of all, thanks a lot for posting the Hercules-AE patches. We picked them up and used them internally. Unfortunately, the CPU sees garbage in it's I$ when we enable the I cache for the processor. If we keep I$ disabled, TF-A boots properly. We are using TF-A v1.4 for verification. We booted Linux kernel v4.14 on the processor and don't see this problem there. So, we suspect something going wrong inside TF-A. Have you seen this problem internally? Any hints or clues to solve it would be helpful. 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, 8 months

2
1
0 0

Documentation and Website Updates

by Paul Beesley

Hi everyone, This post is to let you know about some changes to the TrustedFirmware.org website and to the TF-A documentation. It briefly covers what's new, what has moved, and what happens to any existing resources you may be using. First of all, we are making it more obvious where to access the documentation and the Gerrit review system. The front page of trustedfirmware.org has grown new "Documentation" and "Review" menus with links to this content. Dashboard and Wiki items have moved under the Documentation menu. Secondly, the online version of the documentation has moved to www.trustedfirmware.org/docs/tf-a<http://www.trustedfirmware.org/docs/tf-a>. This is a pre-rendered, HTML copy of the content that is found under the "docs" directory of the TF-A repository. The content here will remain synchronised with the master branch of the repository. Following the v2.2 release, you will also be able to access a static version of the documentation that corresponds to that tag, via a version selection drop-down menu on the site. The intention behind this change is to make it easier to find the docs, to improve the output quality and to make the content more modular and readable. The new setup has a persistent table of contents (displayed to the left of the page content) and a search feature, making it easier to find what you're looking for and easier to move between documents and topics. You may be used to viewing the docs through either the git viewer (https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/about/) or through the Github mirror (https://github.com/ARM-software/arm-trusted-firmware/). The landing pages of these sites now contain links to the new content. While you can still use these sites to access other documentation content, you may find that there are some formatting warnings displayed if you do so. Finally, if you prefer to read a local copy of the documentation on your machine then you can build the same HTML output following the instructions at https://trustedfirmware-a.readthedocs.io/en/latest/getting_started/docs-bui… (or docs/getting_started/docs-build.rst, for the equivalent file in the repository). As always, let us know if you have any comments or if there are other changes you would like to see. Thanks, Paul

5 years, 8 months

1
0
0 0

Boot getting stuck on RK3399 Rockpro64 board

by Hugh Cole-Baker

Hi folks, I've been using TF-A with mainline U-Boot recently as firmware & boot loader for a RK3399 Rockpro64 board. I'm compiling TF-A and U-boot based on this guide [1], using gcc 8.3.0 from Debian. TF-A v2.1 works fine for this, but I recently tried to switch to TF-A latest master and found U-Boot gets stuck with this version. The symptoms are: U-Boot TPL and SPL print starting messages like this: U-Boot TPL 2019.10-rc4-00037-gdac51e9aaf (Oct 06 2019 - 21:42:50) Trying to boot from BOOTROM Returning to boot ROM... U-Boot SPL 2019.10-rc4-00037-gdac51e9aaf (Oct 06 2019 - 21:42:50 +0000) Trying to boot from MMC2 ...and then there is no more output when normally U-Boot proper would start, and go on to load the Linux kernel, etc. Starting from v2.1, with git bisect I found the first 'bad' commit is: 0aad563c7480 rockchip: Update BL31_BASE to 0x40000 and that commit does change some RK3399-related files so seems likely. I'm not sure how to debug further, any ideas on why boot is hanging after that change or how to get more debugging information? Best regards, Hugh Cole-Baker [1] https://github.com/u-boot/u-boot/blob/master/doc/README.rockchip

5 years, 8 months

1
0
0 0

Forthcoming Trusted Firmware-A 2.2 release

by Bipin Ravi

Hi, This is to notify that we are planning to target the Trusted Firmware-A 2.2 release during the third week of October as part of the regular 6 month cadence. The aim is to consolidate all TF-A work since the 2.1 release. As part of this, a release candidate tag will be created and release activities will commence from Monday October 7th. 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 October 4th. Any major enhancement PR's still open after that date will not be merged until after the release. Thanks & best regards, [cid:image001.jpg@01D57244.98C07530] Bipin Ravi | Principal Design Engineer Bipin.Ravi(a)arm.com<mailto:Joshua.Sunil@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, 8 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 349459: (ARRAY_VS_SINGLETON) ________________________________________________________________________________________________________ *** CID 349459: (ARRAY_VS_SINGLETON) /plat/mediatek/mt8183/drivers/sspm/sspm.c: 150 in sspm_alive_show() 144 145 if (sspm_ipi_send_non_blocking(IPI_ID_PLATFORM, &ipi_data) != 0) { 146 ERROR("sspm init send fail! ret=%d\n", ret); 147 return -1; 148 } 149 >>> CID 349459: (ARRAY_VS_SINGLETON) >>> Passing "&ipi_data" to function "sspm_ipi_recv_non_blocking" which uses it as an array. This might corrupt or misinterpret adjacent memory locations. 150 while (sspm_ipi_recv_non_blocking(IPI_ID_PLATFORM, 151 &ipi_data, 152 sizeof(ipi_data)) 153 && count) { 154 mdelay(100); 155 count--; 156 } 157 158 return (ipi_data == 1) ? 0 : -1; /plat/mediatek/mt8183/drivers/sspm/sspm.c: 145 in sspm_alive_show() 139 uint32_t ipi_data, count; 140 int ret = 0; 141 142 count = 5; 143 ipi_data = 0xdead; 144 >>> CID 349459: (ARRAY_VS_SINGLETON) >>> Passing "&ipi_data" to function "sspm_ipi_send_non_blocking" which uses it as an array. This might corrupt or misinterpret adjacent memory locations. 145 if (sspm_ipi_send_non_blocking(IPI_ID_PLATFORM, &ipi_data) != 0) { 146 ERROR("sspm init send fail! ret=%d\n", ret); 147 return -1; 148 } 149 150 while (sspm_ipi_recv_non_blocking(IPI_ID_PLATFORM, ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

5 years, 8 months

1
0
0 0

Coverity Scan subscription confirmation

by scan-admin＠coverity.com

Hi tf-a(a)lists.trustedfirmware.org, Your email was added by sandrine.bailleux(a)arm.com to receive software defect notifications from [1]Coverity Scan for the ARM-software/arm-trusted-firmware project. To confirm and activate these notifications, [2]click here. If you do not wish to receive these emails, you may safely ignore this message. References 1. https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0… 2. https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

5 years, 8 months

1
0
0 0

Re: [TF-A] Defects detected by Coverity Scan Online

by Sandrine Bailleux

Hi, We are going to configure Coverity Scan Online to make it send notifications to this mailing list. This way, everyone subscribed on this mailing list will be aware of newly detected/eliminated defects found by the tool. The report will provide a summary of the findings (their nature, location in the source code). In order to look up the details or to triage them, you will still need to access the database through the web portal on https://scan.coverity.com/projects/arm-software-arm-trusted-firmware . As a reminder, you will need to create an account to view the defects there (it's possible to use your Github account). This is expected to generate a low volume of emails, as we typically do 1 analysis per week day. As a heads up, the web interface mentions that "an authorization confirmation will be sent to each newly provided email address and must be acknowledged before notifications will be sent". In which case, please ignore these emails. Regards, Sandrine

5 years, 8 months

1
0
0 0

Re: [TF-A] License

by Joanna Farley

Hi Tristan, Can you please clarify what your exact concern is? Which files and what text exactly? That will help us answer your concern. Thanks Joanna On 16/09/2019, 23:48, "TF-A on behalf of Tristan Muntsinger via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: Hello all, It looks like the copyright guidance on this project changed about a year ago (Nov 13, 2018) to a placeholder and hasn't been corrected yet. Can this be fixed to make the license valid so the project can be legally redistributed per BSD-3 as intended? Thanks, Tristan Muntsinger -- 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, 8 months

2
2
0 0

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

by Julius Werner

Hi Dan, Whoops, sorry, this fell through the cracks for me since I wasn't on the to: line. Thanks for your response! > OK I can see the use of that, although I'd be a bit concerned about such a thing being available as a general service in case it gets used as an attack vector. For example, a test program could aggressively use this service to try to get the firmware to leak secure world information or something about its behaviour. Yes, of course, we can gate this with a build option so it would only be available where desired. > However, I think there might already be support for what you need. PSCI is part of the standard service and the function SYSTEM_RESET2 allows for both architectural and vendor-specific resets. The latter allows for vendor-specific semantics, which could include crashing the firmware as you suggest. > > Chrome OS could specify what such a vendor-specific reset looks like and each Chromebook's platform PSCI hooks could be implemented accordingly. Right, but defining a separate vendor-specific reset type for each platform is roughly the same as defining a separate SiP SMC for each of them. It's the same problem that the SMC/PSCI spec and the TF repository layout is only designed to deal with generic vs. SoC-vendor-specific differentiation. If the normal world OS needs a feature, we can only make it generic or duplicate it across all vendors running that OS. > Alternatively, this could potentially be defined as an additional architectural reset. This would enable a generic implementation but would require approval/definition by Arm's Architecture team. Like me they might have concerns about this being defined at a generic architectural level. Yes, I think that would be the best option. Could you kick off that process with the Architecture team? Or tell me who I should talk to about this? Thanks, Julius

5 years, 8 months

2
1
0 0

License

by Tristan Muntsinger

Hello all, It looks like the copyright guidance on this project changed about a year ago (Nov 13, 2018) to a placeholder and hasn't been corrected yet. Can this be fixed to make the license valid so the project can be legally redistributed per BSD-3 as intended? Thanks, Tristan Muntsinger

5 years, 9 months

1
0
0 0

Re: [TF-A] About next release

by Joanna Farley

Hi Yann, You are quite correct. We will be looking to create a v2.2 tag release sometime early to mid October. You can expect a more formal notification and a request to get any patches submitted in the next week or so. As in previous releases master will be generally locked for a week or so while closedown testing is performed although we will assess incoming patches to see if they can be taken with low risk. Joanna On 16/09/2019, 13:19, "TF-A on behalf of Yann GAUTIER via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: Hi, From the wiki page https://developer.trustedfirmware.org/w/tf_a/tf-a_release_information/, the next v2.2 tag may be released soon. But the exact timeframe is not yet published. The wiki page might be updated if you have more information. When do you expect to release tag v2.2? What will be the deadline to send patches upstream? Thanks, Yann -- 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, 9 months

1
0
0 0

About next release

by Yann GAUTIER

Hi, >From the wiki page https://developer.trustedfirmware.org/w/tf_a/tf-a_release_information/, the next v2.2 tag may be released soon. But the exact timeframe is not yet published. The wiki page might be updated if you have more information. When do you expect to release tag v2.2? What will be the deadline to send patches upstream? Thanks, Yann

5 years, 9 months

1
0
0 0

Re: [TF-A] On supporting unmaintained platforms and downstream projects

by Julius Werner

Hi Soby, > Hi Julius, > Apologize for the radio silence as I was on sabbatical. Yes, I agree the > project needs to have a clear policy around platforms. We will get this > started on our end and send a policy proposal for review. No problem, thanks to Sandrine for taking care of it so quickly. Unfortunately we now discovered that we're still stuck on the same issue with MT8173. Could one of you please help getting https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/990/31 landed to fix that too? Thanks, Julius

5 years, 9 months

1
0
0 0

Merge Tegra platform changes

by Varun Wadekar

Hello Soby/Joanna, We would like to upstream support for a new Tegra platform along with some other changes. The last time I checked, there were more than 400 changes waiting to be upstreamed. Can someone help me with the best/fastest approach to start upstreaming? Previously, we would upstream changes in big chunks (as branches) but I don't know if that approach still works. 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, 9 months

3
6
0 0

Re: [TF-A] On supporting unmaintained platforms and downstream projects

by Julius Werner

Hi Soby, > Hmm, if we merge a non-trivial patch and ensure the build works, then we > do not know whether it runs correctly, whether there are any runtime > effects that would affect stability/robustness of the platform that even > might have security implications. Hence, in my view, it is better to > have a broken build for the platform, rather than have runtime problems. > > The project could form a policy that if a platform remains broken for > more than 2 releases (1 year by current release intervals), then it will > get removed from the tree after giving enough notifications. Thanks, yes, I think it would be good to have a clear policy on this, whatever it is. I would still like to make a case for keeping these platforms in the tree on a best-effort basis. You're right that there's a chance for untested patches to cause all sorts of runtime errors, but I think that may still be better than a platform that doesn't build at all. A platform that doesn't build doesn't benefit anyone. A platform that may have errors still has a chance of working, and even if it doesn't it gives a third-party contributor or hobby developer who wants to start using it a chance to fix it up again. This is something we occasionally see happening with some of our older, less maintained platforms in coreboot. But if it doesn't even build, the chance of someone coming along to fix it seem very slim, because then more and more build issues will keep piling up over time. (In fact, I doubt there's even any point in keeping broken stuff in the tree for another year as you proposed... likely all that would do is confuse people who are trying to refactor project-wide APIs. Code that's never build-tested just bit rots very quickly. I think at that point you might as well remove it from the repo immediately.) It's true that there may also be security issues (which is more serious), but I'm skeptical that this really makes a lot of difference. After all, this may happen even while the platform is still actively maintained. Just testing whether it boots doesn't make sure you have no security issues anyway. Maybe a way to make this more visible instead could be to introduce a new ALLOW_UNMAINTAINED_PLATFORM=1 make variable that the user has to explicitly set to build a platform without active maintainer? That could serve as a warning that the code may not be safe to use for critical applications anymore while still giving developers access to something if they're willing to deal with possible issues. Anyway, whatever the policy may be, a more defined process would help. I think the initial messaging around the console deprecation plan was fine, but it would have been good to have another explicit announcement when the CI actually gets turned off for a platform.

5 years, 9 months

2
1
0 0

Re: [TF-A] broken link in phabricator wiki

by Sandrine Bailleux

Hi Leif, On 9/3/19 3:16 AM, Leif Lindholm via TF-A wrote: > On page https://developer.trustedfirmware.org/w/tf_a/gerrit-getting-started/ > the link to "new TF-A Contribution Guidelines" points at > https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/about/contribut…, > which is a dead link. > I expect it is meant to be pointing to > https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/about/docs/proc…. You're right, thanks for pointing it out. We forgot to update this page when the docs hierarchy got restructured some time ago. This is now fixed. Regards, Sandrine

5 years, 9 months

1
0
0 0

broken link in phabricator wiki

by Leif Lindholm

Hi there, On page https://developer.trustedfirmware.org/w/tf_a/gerrit-getting-started/ the link to "new TF-A Contribution Guidelines" points at https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/about/contribut…, which is a dead link. I expect it is meant to be pointing to https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/about/docs/proc…. Best Regards, Leif

5 years, 9 months

1
0
0 0

Re: [TF-A] On supporting unmaintained platforms and downstream projects

by Sandrine Bailleux

Hi Julius, On 8/27/19 9:55 PM, Julius Werner via TF-A wrote: > Could either of you please help get the Tegra fix in > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1192 > landed (and subsequently CI for Tegra re-enabled)? It has been > reviewed and approved for two weeks but nobody is merging it. This is > blocking more and more work across all coreboot-based platforms so I > would appreciate if we could get it resolved quickly. Apologies for the delay. As you may have seen, the patch has now been merged, and we've also re-enabled the Tegra builds in the CI. Regards, Sandrine

5 years, 9 months

2
1
0 0

Re: [TF-A] On supporting unmaintained platforms and downstream projects

by Julius Werner

Hi Soby, Joanna, Could either of you please help get the Tegra fix in https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1192 landed (and subsequently CI for Tegra re-enabled)? It has been reviewed and approved for two weeks but nobody is merging it. This is blocking more and more work across all coreboot-based platforms so I would appreciate if we could get it resolved quickly. Thanks, Julius

5 years, 9 months

2
1
0 0

Ultra96-V1 stops booting since b8e39f49e634

by Jan Kiszka

Hi all, I've bisected a boot issue of my Ultra96 version 1 down to commit [1]. U-Boot plays no role, I tried current master, 2019.07 and 2019.01. What might be related: I'm using pre-built fsbl, pmu-fw and bitstream from Alex' OpenSUSE packages [2][3][4]. Build steps are as described in [5]. Meanwhile, I rebuilt at least the pmu-fw from current embeddedsw git (c12743e5d7b0), but also without any impact on the issue. Any idea what could be wrong and why specifically this commit triggers it? I'd like to lift everything to a recent ATF version because of compilation issues with currently used 1.6 and newer gcc releases. Thanks, Jan [1] https://github.com/ARM-software/arm-trusted-firmware/commit/b8e39f49e634 [2] https://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/Zy… [3] https://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/Zy… [4] https://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/Zy… [5] https://github.com/siemens/jailhouse-images/blob/v0.11/recipes-bsp/u-boot/f…

5 years, 9 months

2
2
0 0

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

by Dan Handley

Hi Julius > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Julius > Werner via TF-A > Sent: 20 August 2019 02:15 > > Hi Soby et. al., > > I'd like to implement a small new feature and ask some guidance for how to go > about it: Chrome OS has the ability to automatically collect crash reports > from runtime crashes in Trusted Firmware, and we would like to set up > automated tests to ensure this feature stays working. > In order to do this we need a way for the non-secure OS to intentionally > trigger a panic in EL3. The obvious solution would be to implement a new SMC > for that. (It's common for operating systems to have similar facilities, e.g. > Linux can force a kernel panic by writing 'c' into /proc/sysrq-trigger.) > OK I can see the use of that, although I'd be a bit concerned about such a thing being available as a general service in case it gets used as an attack vector. For example, a test program could aggressively use this service to try to get the firmware to leak secure world information or something about its behaviour. > My main question is: where should I get an SMC function ID for this? > This is not a silicon or OEM specific feature, so the SiP Service Calls and > OEM Service Calls ID ranges seem inappropriate (or do you think it would make > sense to treat Google or Chrome OS as the "OEM" > here, even though that's not quite accurate?). I guess in theory you could mandate that all Chrome OS SiPs provide a specific function ID in their own specific SiP service, but I don't think that's the right solution here... > There are ranges for Trusted > Applications and the Trusted OS but unfortunately none for the normal world > OS. I don't think the TOS range is right either. > Is this something that would make sense to allocate under Standard > Service Calls? Could you just find an ID for me to use there or does > everything in that range need a big specification document written by Arm? > For sure everything in the standard or architectural ranges require specification by Arm, although this does not necessarily need to be big. However, I think there might already be support for what you need. PSCI is part of the standard service and the function SYSTEM_RESET2 allows for both architectural and vendor-specific resets. The latter allows for vendor-specific semantics, which could include crashing the firmware as you suggest. Chrome OS could specify what such a vendor-specific reset looks like and each Chromebook's platform PSCI hooks could be implemented accordingly. Alternatively, this could potentially be defined as an additional architectural reset. This would enable a generic implementation but would require approval/definition by Arm's Architecture team. Like me they might have concerns about this being defined at a generic architectural level. Regards Dan. 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, 9 months

1
0
0 0

SMC to intentionally trigger a panic in TF-A

by Julius Werner

Hi Soby et. al., I'd like to implement a small new feature and ask some guidance for how to go about it: Chrome OS has the ability to automatically collect crash reports from runtime crashes in Trusted Firmware, and we would like to set up automated tests to ensure this feature stays working. In order to do this we need a way for the non-secure OS to intentionally trigger a panic in EL3. The obvious solution would be to implement a new SMC for that. (It's common for operating systems to have similar facilities, e.g. Linux can force a kernel panic by writing 'c' into /proc/sysrq-trigger.) My main question is: where should I get an SMC function ID for this? This is not a silicon or OEM specific feature, so the SiP Service Calls and OEM Service Calls ID ranges seem inappropriate (or do you think it would make sense to treat Google or Chrome OS as the "OEM" here, even though that's not quite accurate?). There are ranges for Trusted Applications and the Trusted OS but unfortunately none for the normal world OS. Is this something that would make sense to allocate under Standard Service Calls? Could you just find an ID for me to use there or does everything in that range need a big specification document written by Arm? Thanks, Julius

5 years, 9 months

1
0
0 0

Re: [TF-A] Advisory TFV 5 to CVE-2017-15031 only saves/stores the PMCR_EL0 across world switching

by Alexei Fedorov

Hi Marek The patch is available at https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1789 Regards. Alexei ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Joanna Farley via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 19 August 2019 11:41 To: Marek <marek.bykowski(a)gmail.com> Cc: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: Re: [TF-A] Advisory TFV 5 to CVE-2017-15031 only saves/stores the PMCR_EL0 across world switching Hi Marek, Changes are in review so hopefully soon. Joanna On 19/08/2019, 10:56, "TF-A on behalf of Marek via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: Hi Dan, Are there any time estimates when the fix should be in? Thanks, Marek On Sat, 10 Aug 2019 at 22:46, Marek via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: > > Thank you Dan for checking this out. Looking forward into the fix. > > Marek > > On Thu, 8 Aug 2019 at 17:52, Dan Handley via TF-A > <tf-a(a)lists.trustedfirmware.org> wrote: > > > > Hi Marek > > > > Thanks for pointing this out. Typically we expect any timing sensitive secure operations to be implemented at Secure-EL1 or lower, which the current code does protect. However, you are correct that all secure world code including EL3 should not expose timing information. A fix is in progress to address this. > > > > Regards > > > > Dan. > > > > > -----Original Message----- > > > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Marek > > > Bykowski via TF-A > > > Sent: 03 August 2019 07:37 > > > To: tf-a(a)lists.trustedfirmware.org; David Cunado <David.Cunado(a)arm.com> > > > Subject: [TF-A] Advisory TFV 5 to CVE-2017-15031 only saves/stores the > > > PMCR_EL0 across world switching > > > > > > Hi David/ATF Support, > > > > > > An excerpt from the commit message to CVE-2017-15031 is "Additionally, > > > PMCR_EL0 is added to the list of registers that are saved and restored during > > > a world switch." > > > > > > My question is why it is only being saved/restored across the world switch > > > and not during a "normal" SMC call? When I do modify the > > > PMCR_EL0 in EL2 or NonSecure-EL1 and run the smc call the PMCCNTR counter > > > counts during the smc call and does expose secure world timing information to > > > NonSecure in that matter. > > > > > > Thanks, > > > Marek > > > -- > > > 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. > > -- > > TF-A mailing list > > TF-A(a)lists.trustedfirmware.org > > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > > > > -- > Slán, > Marek > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a -- Slán, Marek -- 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. -- 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, 9 months

1
0
0 0

Re: [TF-A] Advisory TFV 5 to CVE-2017-15031 only saves/stores the PMCR_EL0 across world switching

by Joanna Farley

Hi Marek, Changes are in review so hopefully soon. Joanna On 19/08/2019, 10:56, "TF-A on behalf of Marek via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: Hi Dan, Are there any time estimates when the fix should be in? Thanks, Marek On Sat, 10 Aug 2019 at 22:46, Marek via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: > > Thank you Dan for checking this out. Looking forward into the fix. > > Marek > > On Thu, 8 Aug 2019 at 17:52, Dan Handley via TF-A > <tf-a(a)lists.trustedfirmware.org> wrote: > > > > Hi Marek > > > > Thanks for pointing this out. Typically we expect any timing sensitive secure operations to be implemented at Secure-EL1 or lower, which the current code does protect. However, you are correct that all secure world code including EL3 should not expose timing information. A fix is in progress to address this. > > > > Regards > > > > Dan. > > > > > -----Original Message----- > > > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Marek > > > Bykowski via TF-A > > > Sent: 03 August 2019 07:37 > > > To: tf-a(a)lists.trustedfirmware.org; David Cunado <David.Cunado(a)arm.com> > > > Subject: [TF-A] Advisory TFV 5 to CVE-2017-15031 only saves/stores the > > > PMCR_EL0 across world switching > > > > > > Hi David/ATF Support, > > > > > > An excerpt from the commit message to CVE-2017-15031 is "Additionally, > > > PMCR_EL0 is added to the list of registers that are saved and restored during > > > a world switch." > > > > > > My question is why it is only being saved/restored across the world switch > > > and not during a "normal" SMC call? When I do modify the > > > PMCR_EL0 in EL2 or NonSecure-EL1 and run the smc call the PMCCNTR counter > > > counts during the smc call and does expose secure world timing information to > > > NonSecure in that matter. > > > > > > Thanks, > > > Marek > > > -- > > > 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. > > -- > > TF-A mailing list > > TF-A(a)lists.trustedfirmware.org > > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > > > > -- > Slán, > Marek > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a -- Slán, Marek -- 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, 9 months

1
0
0 0

Re: [TF-A] Advisory TFV 5 to CVE-2017-15031 only saves/stores the PMCR_EL0 across world switching

by Marek

Hi Dan, Are there any time estimates when the fix should be in? Thanks, Marek On Sat, 10 Aug 2019 at 22:46, Marek via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: > > Thank you Dan for checking this out. Looking forward into the fix. > > Marek > > On Thu, 8 Aug 2019 at 17:52, Dan Handley via TF-A > <tf-a(a)lists.trustedfirmware.org> wrote: > > > > Hi Marek > > > > Thanks for pointing this out. Typically we expect any timing sensitive secure operations to be implemented at Secure-EL1 or lower, which the current code does protect. However, you are correct that all secure world code including EL3 should not expose timing information. A fix is in progress to address this. > > > > Regards > > > > Dan. > > > > > -----Original Message----- > > > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Marek > > > Bykowski via TF-A > > > Sent: 03 August 2019 07:37 > > > To: tf-a(a)lists.trustedfirmware.org; David Cunado <David.Cunado(a)arm.com> > > > Subject: [TF-A] Advisory TFV 5 to CVE-2017-15031 only saves/stores the > > > PMCR_EL0 across world switching > > > > > > Hi David/ATF Support, > > > > > > An excerpt from the commit message to CVE-2017-15031 is "Additionally, > > > PMCR_EL0 is added to the list of registers that are saved and restored during > > > a world switch." > > > > > > My question is why it is only being saved/restored across the world switch > > > and not during a "normal" SMC call? When I do modify the > > > PMCR_EL0 in EL2 or NonSecure-EL1 and run the smc call the PMCCNTR counter > > > counts during the smc call and does expose secure world timing information to > > > NonSecure in that matter. > > > > > > Thanks, > > > Marek > > > -- > > > 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. > > -- > > TF-A mailing list > > TF-A(a)lists.trustedfirmware.org > > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > > > > -- > Slán, > Marek > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a -- Slán, Marek

5 years, 9 months

1
0
0 0

Re: [TF-A] Advisory TFV 5 to CVE-2017-15031 only saves/stores the PMCR_EL0 across world switching

by Marek

Thank you Dan for checking this out. Looking forward into the fix. Marek On Thu, 8 Aug 2019 at 17:52, Dan Handley via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: > > Hi Marek > > Thanks for pointing this out. Typically we expect any timing sensitive secure operations to be implemented at Secure-EL1 or lower, which the current code does protect. However, you are correct that all secure world code including EL3 should not expose timing information. A fix is in progress to address this. > > Regards > > Dan. > > > -----Original Message----- > > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Marek > > Bykowski via TF-A > > Sent: 03 August 2019 07:37 > > To: tf-a(a)lists.trustedfirmware.org; David Cunado <David.Cunado(a)arm.com> > > Subject: [TF-A] Advisory TFV 5 to CVE-2017-15031 only saves/stores the > > PMCR_EL0 across world switching > > > > Hi David/ATF Support, > > > > An excerpt from the commit message to CVE-2017-15031 is "Additionally, > > PMCR_EL0 is added to the list of registers that are saved and restored during > > a world switch." > > > > My question is why it is only being saved/restored across the world switch > > and not during a "normal" SMC call? When I do modify the > > PMCR_EL0 in EL2 or NonSecure-EL1 and run the smc call the PMCCNTR counter > > counts during the smc call and does expose secure world timing information to > > NonSecure in that matter. > > > > Thanks, > > Marek > > -- > > 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. > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a -- Slán, Marek

5 years, 10 months

1
0
0 0

Re: [TF-A] Advisory TFV 5 to CVE-2017-15031 only saves/stores the PMCR_EL0 across world switching

by Dan Handley

Hi Marek Thanks for pointing this out. Typically we expect any timing sensitive secure operations to be implemented at Secure-EL1 or lower, which the current code does protect. However, you are correct that all secure world code including EL3 should not expose timing information. A fix is in progress to address this. Regards Dan. > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Marek > Bykowski via TF-A > Sent: 03 August 2019 07:37 > To: tf-a(a)lists.trustedfirmware.org; David Cunado <David.Cunado(a)arm.com> > Subject: [TF-A] Advisory TFV 5 to CVE-2017-15031 only saves/stores the > PMCR_EL0 across world switching > > Hi David/ATF Support, > > An excerpt from the commit message to CVE-2017-15031 is "Additionally, > PMCR_EL0 is added to the list of registers that are saved and restored during > a world switch." > > My question is why it is only being saved/restored across the world switch > and not during a "normal" SMC call? When I do modify the > PMCR_EL0 in EL2 or NonSecure-EL1 and run the smc call the PMCCNTR counter > counts during the smc call and does expose secure world timing information to > NonSecure in that matter. > > Thanks, > Marek > -- > 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, 10 months

1
0
0 0

On supporting unmaintained platforms and downstream projects

by Julius Werner

Hi Soby et. al., I wanna kick off a little discussion about how TF-A intends to deal with in-tree platform ports as they get older and the interest in maintaining them drops off. Concretely, I noticed that the plat/nvidia/tegra platforms no longer build since the removal of the deprecated console API in https://review.trustedfirmware.org/842 last month. There has been a patch suggestion to fix it uploaded at https://review.trustedfirmware.org/1192 for two months, but it hasn't moved forward because it seems that Arm thinks it's on the platform maintainer (Nvidia) to finish up and test the patch, and they don't seem to be responding. This creates a problem for downstream projects like coreboot and Chrome OS that use Trusted Firmware on Tegra chips and build-test them in their CI systems. My assumption when setting up the Trusted Firmware integration for them was that the Trusted Firmware CI would build test all in-tree platforms for every commit anyway, so we could always assume that all platforms build on the current master... but clearly, that assumption broke in this case. (I guess because you manually overrode the CI in https://review.trustedfirmware.org/842? Or does it not test all platforms anyway?) So now, coreboot is stuck on an old TF-A version and cannot move forward for any platform until we either kick out the Tegra SoCs or get the problem fixed in TF-A (which is a problem with the testing because I don't have a Tegra board on hand either). How do you think we should solve issues like this? Is keeping platforms that don't build in the tree an intended state? Is there some deadline after which you intend to remove the platform completely? Or would it be better to just merge "best effort" commits like https://review.trustedfirmware.org/1192 that we think should do the right thing for the platform (and at least makes it build again), even if nobody is around to test it on real hardware? To give some experience from the coreboot project, I think it's an unfortunate truth that SoC vendors just tend to lose interest in maintaining hardware once it's more than 2-3 years old. At that point the open-source community has to jump in to continue maintenance, and they can only do it on a best effort basis. It's not possible to always find someone with the right hardware and time to test it for all these old platforms whenever you're trying to do some large, project wide API change, so eventually you'll just have to accept patches that haven't been tested for them. Most of the times (if reviewers pay attention) it works well, sometimes they break. If they do, eventually someone will notice and then they'll have to bisect and fix it. I believe Linux is essentially doing the same thing for lesser-used hardware. It's either that, or you have to constantly kick out old platforms after a few years. (From the coreboot point of view, kicking the Tegra platforms out of TF-A would mean we're forced to remove them from coreboot as well, which would be unfortunate.) Let me know what you think! Julius

5 years, 10 months

3
4
0 0

Re: [TF-A] On supporting unmaintained platforms and downstream projects

by Joanna Farley

Hi Julius, It’s a valid issue you have raised. In general we rely on the platform maintainer to work with us to keep their platform port fresh and in this case we proposed some changes and was looking for feedback from the maintainer. We try in our internal standups at least once a week to look for patch reviews that have had no work on them for 21 days and if we do identify any we start chasing to progress these. Eventually if after several attempts we cannot get the patch to progress we would generally look to abandon if it’s the patch originator we cannot contact. In this case it was the platform maintainer who we needed a review from and you managed to get Varun to notice the patches. If we had not managed to contact them then we would have had to make a call on if to submit the changes or not to at least get the build working even though we would not be able to test them. I would like to think in the case of a broken build we would take that option rather than abandon. I think this issue is made a little worse in that the CI results are not yet open so not obvious to everybody although hopefully that will be eventually addressed with the proposed Open CI system on trustedfirmware.org where build results will be available. On top of that if partners want to engage in providing a board available that could be integrated into the LAVA farm that’s part of the CI system and would also be tested. Joanna On 03/08/2019, 01:10, "TF-A on behalf of Julius Werner via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: > Thanks for the email, Julius. To be clear, we very well intend to be part of the TF-A project. Having said that, I was not aware of the two commits you mentioned in the email and di not know that Tegra builds are broken in the master branch. Thanks. You were CCed on the patch so I assumed you would've seen it. If not, maybe your email address isn't set correctly in your Gerrit account or something? I've already pushed an update to https://review.trustedfirmware.org/1192 which I think should fix the issue for Tegra, but I need someone to test it. Nevertheless, I think it's a good idea to answer these questions in a general case (e.g. whether we can make sure that we won't break the build on master even if there are temporary issues with certain platforms), because it's probably going to become relevant again sooner or later even if the Tegra issue gets fixed now. 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, 10 months

1
0
0 0

Advisory TFV 5 to CVE-2017-15031 only saves/stores the PMCR_EL0 across world switching

by Marek Bykowski

Hi David/ATF Support, An excerpt from the commit message to CVE-2017-15031 is "Additionally, PMCR_EL0 is added to the list of registers that are saved and restored during a world switch." My question is why it is only being saved/restored across the world switch and not during a "normal" SMC call? When I do modify the PMCR_EL0 in EL2 or NonSecure-EL1 and run the smc call the PMCCNTR counter counts during the smc call and does expose secure world timing information to NonSecure in that matter. Thanks, Marek

5 years, 10 months

1
0
0 0

Raspberry Pi 4 ATF port

by Andre Przywara

Hi, (BCC:ing Antonio as well) not sure if someone gets notified, but I pushed a patch set to add Raspberry Pi 4 support to Trusted Firmware: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1629 This port is quite a departure from the existing RPi3 port, that's why I wanted to start a discussion about it here. I originally started by copying files. But for the sake of simplicity, also to get away without a BL33 loader, it turned into just a BL31-only port (for now?). This ties more into the existing RPi Foundation boot style, as the resulting bl31.bin is a drop-in replacement for the existing armstub8.bin. So you put your AArch64 kernel into kernel8.img and copy bl31.bin to armstub8.bin (or use the respective config.txt options to point to any other filename), and it should work (TM). The code will pick up the actual kernel and DTB load address from the GPU firmware, patch the DT to use PSCI instead of spin tables, then will drop into EL2 at the kernel load address. There could (should?) be U-Boot or EDK-II there as well, or any other kernel, for that matter. The only thing Linux specific we do is to put the DTB address into x0. I guess this doesn't hurt, even if the BL33 payload does not use this information. I would be grateful to hear some opinions about this approach. Does that sound sensible? Is the split of the platform directory (plat/rpi3 -> plat/rpi/rpi[34]) reasonable? Shall we add this design as a build option to RPi3 as well? Shall we add the "full featured" RPi3 design to RPi4 also? Looking forward to any feedback! Cheers, Andre.

5 years, 10 months

3
2
0 0

Re: [TF-A] Defects detected by Coverity Scan Online

by Sandrine Bailleux

Hi, On 7/3/19 11:15 AM, Sandrine Bailleux via TF-A wrote: > We would need help from the TF-A community for analyzing and fixing > them, especially those in platform ports and drivers. Note that there > might be false positives, in which case we would just triage them as > such in the tool's database. > > Hopefully everyone should be able to view the defects, according to the > tool's settings. You might need to create an account on > https://scan.coverity.com for that. We've received a couple of requests from users to get access to the TF-A defects database in the Coverity Scan Online service. I think it's worth clarifying the different levels of access the tool offers and how we envisage the defects triaging. In Coverity Scan Online, users can have any of the following 4 roles (in ascending order of permissions): - Observer/User: Only sees defects summary. - Defect Viewer. - Contributor/Member: Can also triage defects. - Maintainer/Owner: Also has some admin powers, like managing users and submitting builds to be analyzed. Right now, all users should be able to see the project summary and view the defects in read-only mode so this is equivalent to the "Defect viewer" role. I suspect people still need to create an account in Coverity Scan Online and be logged in to see the data. We would expect subsystems and platforms maintainers (i.e. people listed in docs/maintainers.rst [1]) to manage the defects in the part of the codebase they own, as they know best how to assess the severity of these defects and how to fix or triage them. As such, they need to have the "contributor/member" role in the tool. If you are such a maintainer, please feel free to create an account and request this role. If you would like to delegate part/all of the triaging process to a peer, that is also possible. In this case, could you please send me an email to indicate who you have chosen for this task? This is just to make sure that whoever requests the "contributor/member" role has done so with the relevant maintainer's approval. Please be aware that those with "contributor/member" role will be able to triage any defects in any part of the codebase, and not just in the subsystem/platform they maintain. "Maintainer/Owner" role will be reserved to the main maintainers (i.e. people listed at the top of docs/maintainers.rst) for now. Best regards, Sandrine [1] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/docs/maint…

5 years, 11 months

1
0
0 0

Re: [TF-A] How can I check detail error of CI failure?

by Sandrine Bailleux

Hi Jun, On 7/16/19 11:30 AM, John Tsichritzis via TF-A wrote: > Thank you for your email. Unfortunately detailed information is not available in Gerrit since CI is hosted internally. The maintainers post detailed information of the errors in case there is something that needs fixing. In this case I will post the error details in the Gerrit review itself. > > When a patch stack is submitted, usually we launch the tests on the topmost patch on the stack. In this case the entire branch gets tested, not a single commit. In other words, the testing doesn't do any "cherry-picking" on the patches, so even if there are dependencies between the patches this doesn't affect the test. That's why we usually launch the tests on the topmost patch. To add on top of what John said, I would like to mention that we are working with Linaro to have the CI loop opened up to all contributors in the future. When this day comes, you will be able to check the error log by yourself. In the meantime, I'm afraid you'll have to rely on Arm maintainers to give you the details, as John said. If they forget, please feel free to ping them in Gerrit (like you've already done for this patch). Best regards, Sandrine

5 years, 11 months

1
0
0 0

Re: [TF-A] How can I check detail error of CI failure?

by John Tsichritzis

Dear Jun, Thank you for your email. Unfortunately detailed information is not available in Gerrit since CI is hosted internally. The maintainers post detailed information of the errors in case there is something that needs fixing. In this case I will post the error details in the Gerrit review itself. When a patch stack is submitted, usually we launch the tests on the topmost patch on the stack. In this case the entire branch gets tested, not a single commit. In other words, the testing doesn't do any "cherry-picking" on the patches, so even if there are dependencies between the patches this doesn't affect the test. That's why we usually launch the tests on the topmost patch. Kind regards, John -- John Tsichritzis | Graduate Software Engineer Email: john.tsichritzis(a)arm.com<mailto:john.tsichritzis@arm.com> 110 Fulbourn Road, Cambridge, CB1 9NJ, United Kingdom https://www.arm.com/ On 16/07/2019 09.24, Jun Nie via TF-A wrote: Hi, I see below failure in this link: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1367 How can I check the error log? I am not sure it is due to lack of earlier patch in patch set or something. Because local build is OK. Patch Set 4: Verified-1 Build Failed https://jenkins.oss.arm.com/job/tf-gerrit-tforg-l1/221/ : FAILURE Jun

5 years, 11 months

1
0
0 0

How can I check detail error of CI failure?

by Jun Nie

Hi, I see below failure in this link: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1367 How can I check the error log? I am not sure it is due to lack of earlier patch in patch set or something. Because local build is OK. Patch Set 4: Verified-1 Build Failed https://jenkins.oss.arm.com/job/tf-gerrit-tforg-l1/221/ : FAILURE Jun

5 years, 11 months

1
0
0 0

Header file re-org

by Soby Mathew

Hi Everyone, This is regarding the header file re-organization patch that was submitted by Julius https://review.trustedfirmware.org/#/c/TF-A/trusted-firmware-a/+/1207/. It is necessary for the headers which form the ABI/handover interface for BL31 to be able to copied separately and included in other projects. The current approach taken in the patch is to define a "raw" version of such headers and have the original header include them. This certainly is the easiest way to solve the problem. But if it possible to have a more refined solution, that would be preferable. For that I have the following questions : 1. Should the project recognize these special headers and have them organized together in a folder ? It is important to recognize that the ABI can be extended by the platform. I would expect even if these "common" headers are organized into a folder, the platform specific ones need not go together with them. 2. Should the header be restricted from including standard C library headers ? 3. Should these ABI headers be allowed to include each other ? Forward declaration might be able to solve some of the issues, but good to have a policy on this. The current patch as such can be treated as step towards the ideal solution, if that solution needs more work/churn in the code base. Comments welcome. Best Regards Soby Mathew

5 years, 11 months

3
8
0 0

Re: [TF-A] [RFC] isolate the memory into different pagetable for TF-A

by feng chen

Hi Soby Mathew, Thanks for your reply. IMHO, the isolate pagetable is much more heavy. It looks like a big idea. And if we have a dynamic mapping function, which map the service's needed memory in the service's call can also mitigate this. But this can be more slower. For accessing limited resource, what's your idea? -Feng On 2019/7/9 4:27 下午, Soby Mathew wrote: > Hi Feng, > Thanks for your email. This is an interesting topic and this is an active area of work for us but in a slightly different manner. Could you please send this message to the mailing list tf-a(a)lists.trustedfirmware.org , so we can continue conversation on the list ? > > The mailing list info can be found here : > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > > Thanks & Regards > Soby Mathew > >> -----Original Message----- >> From: feng chen <puck.chen(a)foxmail.com> >> Sent: 08 July 2019 16:24 >> To: Dan Handley <Dan.Handley(a)arm.com>; Soby Mathew >> <Soby.Mathew(a)arm.com>; Sandrine Bailleux <Sandrine.Bailleux(a)arm.com>; >> Alexei Fedorov <Alexei.Fedorov(a)arm.com>; Paul Beesley >> <Paul.Beesley(a)arm.com>; John Tsichritzis <John.Tsichritzis(a)arm.com> >> Subject: [RFC] isolate the memory into different pagetable for TF-A >> >> Hello maintainers, >> >> Is it possible for mapping the memory into different page-tables for TF-A? >> >> Since the ATF is running in EL3 mode, which is the highest level of ARM SoCs. >> >> And for security reason, once one service provided in TF has some >> vulnerabilities, It can access all the memory TF mapped. And it could be more >> acceptable. >> >> Thinking about the userland goto kernelland, the process use isolated page >> tables. >> >> So I want to implement this for TF-A, different memory-mapping for different >> service, and it can also use a shared mem-mapping space which all the service >> need to use. >> >> >> I want to know how do you think about this? Does this make sense to you? >> >> >> Cherrs, >> >> Feng >> > > 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, 11 months

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-A