- TF-A - lists.trustedfirmware.org

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

by Sandrine Bailleux

Hi Joakim, On 4/2/20 10:18 AM, Joakim Bech via TF-A wrote: > Hi Sandrine, > > On Wed, Apr 01, 2020 at 11:46:20AM +0200, Sandrine Bailleux wrote: >> Hi Joakim, >> >> On 4/1/20 10:08 AM, Joakim Bech via TSC wrote: >>> 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! >> > The "Tested-by" part for OP-TEE releases has been working pretty good, > not sure how scalable it is the long run though. To give some more > info regarding the "last known version", we even at one point had some > stop-light for that. I.e. if a maintainer missed testing a release once, > then it became "orange". If missed twice, then it became "red" and we > showed last know supported version. But we dropped that idea a short > while after introducing it. May I know why you dropped the idea? Was it too much maintenance? If that's the reason I guess again this could be addressed with some automation work (generating the stop-light status from the commit message info). >>> 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. >> > Indeed it could, it's just a matter of doing some scripting if one > doesn't want to do it manually. I already have Python scripts pulling > all tags from GitHub pull requests. But there are of course several > other ways how one could pull that kind of information. Regards, Sandrine

5 years, 11 months

2
1
0 0

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

by Sandrine Bailleux

Hi Erik, On 4/1/20 9:24 PM, Shreve, Erik via TF-A wrote: > Sandrine, > > To clarify on functionality vs. support. I listed out a support life cycle consisting of the following states: > Fully Supported > Orphan > Out of Date > Deprecated > These states are intended to have nothing to do with functionality, but only the support offered for the functionality that currently exists for a platform. > > I think I may have confused things when I listed "Functional Support" as the heading to represent "Functionality." > I'm proposing that the supported "Functionality" should be documented in a standard way (within a project) for every platform. > > I do agree this could be burdensome to keep up with. But that is why I suggested that the project's feature list be versioned. The platform's supported feature list document would reference the version of the project feature list used. Platform maintainers then don' t have to continuously update the document. But it will be clear how long it has been since they did update and thus what information may be missing. Versioning the feature list document is also why I mentioned that the project version number may want to adopt a version number scheme where feature changes are represented by a certain part of the version number. For example Semantic Versioning 2.0.0: https://semver.org/. Hope that clarifies the intent? For implementation of this I'm imagining each project could create a supported_feature_list.rst file and each platform would copy that file into their platform doc folder and fill it in. I'm not saying that approach would be required at tf.org level, just sharing to further illustrate. > > That said, perhaps the implementation details for a project would not warrant such a document per platform? My primary concern around this is misuse/misconfiguration. If a platform doesn't support a feature or configuration it may not be obvious to a user unless an error is generated at build or run-time. OK, I think I get the idea now, thanks for the explanations. This looks reasonable to me. The idea of keeping a project's feature list being mirrored and filled in per platform sounds like something we would want to enforce at the tf.org level IMO. At the same time, this could also be handled at the build system level as you pointed out, or more precisely by the configuration manager. I am thinking about the Linux kernel, where support for a particular feature is handled (and documented) through the KConfig system. This might be a more scalable approach. And it doesn't prevent us from also auto-generating some feature list out of the Kconfig files for making this information more accessible to users. > My secondary concern is being able to consistently track tickets/bugs with features. Thus, I'm recommending that the features on that list be used with the ticket/issue system by feature name. This would allow users to find all bugs for Feature X on Platform Y in Project Z. > Related to that, when I mentioned "tags." I wasn't thinking of Git tags, but "labels" in the ticket/issue tracking system(s). Different systems work differently for labeling/categorizing issues, but the goal is to provide a consistent way (per project) to find issues related to a feature on a platform. > > If requiring a feature list it is too much at the tf.org level then I'll be satisfied to push for that kind of documentation in the projects or platforms I'm involved in if/as appropriate. Yes, good point, I think it would be desirable to be able to tie tickets to some specific platform/feature/version. And I think it makes sense to unify this across tf.org projects. > Regarding the other conversational tidbits: > > Thanks for pointing out that the original proposal does say "builds all configurations supported by this platform" under "Fully Supported." I can see the intention here now. Substituting "features" for "configurations" would broaden the meaning a bit. OK, I will change the wording, thanks for the suggestion. > You said: "I am starting to think that we need a list of items to be defined per project." > Yes, this sounds like a great idea. > > My original mention of wanting a "stronger standard put forth for platform documentation" was a response to seeing "Limited Support" in the original proposal allowing documentation to fall out of date. > > > Hope that clarifies some of my thoughts. If not, I'm happy to continue the discussion. Thanks again for taking feedback! > > Erik Shreve, PSEM > Software Security Engineer & Architect (CMCU Platform Development) > > -----Original Message----- > From: Sandrine Bailleux [mailto:sandrine.bailleux@arm.com] > Sent: Wednesday, April 01, 2020 4:18 AM > To: Shreve, Erik; tf-a; tf-m(a)lists.trustedfirmware.org; tsc(a)lists.trustedfirmware.org; op-tee(a)linaro.org > Cc: nd(a)arm.com > Subject: Re: [EXTERNAL] [TF-M] Project Maintenance Proposal for tf.org Projects > > Hello Erik, > > Thanks for the feedback. > > On 3/26/20 3:37 PM, Shreve, Erik wrote: >> 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. > > Yes, you are the second person to mention that and I agree with you > both. Unless someone disagrees, I intend to update the proposal and > separate these 2 concepts in the next version of the document. > >> 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. > > I completely agree. It would not make sense to support all features on > all platforms just for the sake of completeness. Each platform ought to > implement what is relevant in its case. > > That's what the current proposal tried to convey: a fully supported > platform must "build all configurations *supported by this platform*" > and "All *supported* configurations are tested in the CI". The key word > here is supported and that would be defined by the platform itself. But > I can see that maybe this wasn't clear enough. Your proposal below makes > that a lot clearer. > >> 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. > > Fair point. > > But is it something we should include in this proposal or should we push > it to a separate document setting expectations for the project's > documentation, which the current general proposal could refer to (as in, > "the platform should provide quality documentation up to the project's > criteria defined in document XXX')? > > This is definitely an important topic but I am wary of keeping the > tf.org proposal concise and focused at this point. I am worried that if > we put too much stuff in it discussions will diverge too much and we > might never reach an agreement. > > The same applies to testing standards for example, we could detail that > in the proposal or simply leave it to projects to define it separately. > >> 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. > > Regarding the last item, this would require all platform maintainers to > update their documentation every time a new feature is added to the > project's global list of features. This seems too much of a constraint > and unnecessary maintenance burden to me. > > I think a better, more lightweight alternative might be to let platform > maintainers list what's supported and if some feature is not listed, it > implies that it is not supported. This does not prevent platform > maintainers from indicating their future plans of supporting a feature > if they want to. > >> 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. > > I can see that Joakim Bech proposed something similar, with more details > about how this was implemented for OP-TEE. > >> Note: projects will need to adopt (if they have not already) a version scheme that distinguishes between feature updates and bug fixes. > > Sorry I didn't get this, could you please elaborate? > >> 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). > > If there's no appropriate tag in some cases, I guess we could always use > a git SHA1 of a specific commit. > >> 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. > > Yes, good point, that is currently undefined in the proposal but I agree > that it needs defining per project. I will add an item in the last > section of the document. > > I am starting to think that we need a list of items to be defined per > project. This list would complement the general tf.org proposal. Things > like code owners/maintainers activity, code review timelines, and so on. > >> >> 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" > > I am confused, you said earlier that you would like to see the concepts > of support and functionality split out, but here you're listing 'orphan' > as one of the possible states... Did I miss your point? > >> 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)

5 years, 11 months

1
0
0 0

Re: [TF-A] fconf: Validating config data

by Louis Mayencourt

Hi Raghu, I do agree with you: case 2 and 3 are similar (wrongly formed DTB) and should lead to the same behavior. A mandatory property miss or a hit with a structurally incorrect node means that the DTB doesn't follow the provided binding document. Such a DTB shouldn't be considered as valid and should trigger a build failure and/or a code panic. With the current implementation, case 2 and 3 are similar. The property_getter() functions expect a specific format of the node. If a node is not found or structurally incorrect, the function will return an error code, which will lead to a panic(). regards, Louis ________________________________ 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: 06 April 2020 19:51 To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: Re: [TF-A] fconf: Validating config data Thanks Louis. This new terminology helps. Let me spell this out again just to make sure we're on the same page. The following are the cases: 1) Mandatory Property hit, nodes are structurally correct - Works normally. 2) Mandatory Property hit, nodes are structurally *incorrect* - Asserts should catch structural issues during development because system integrator expected to not make mistakes with number of nodes etc. 3) Mandatory Property miss - Panic(). Why is this case causing a panic, but not case 2? You are allowing for some one to make the mistake of not having a mandatory property, but assume that if a mandatory property is present, it is always structurally sound. This is the part i have a problem with. In my view case 2 and case 3 should panic and code should not just assert on mandatory properties and must ALWAYS check for structural soundness of an FDT property. Similarly there are 3 cases for optional properties. My question: Why does case 3 panic, but not case 2 ? It sounds like your assumption is that case 2 cannot happen. If case 2 cannot happen, i claim that case 3 cannot happen either. Let me know what you think! Thanks Raghu On 4/6/20 3:57 AM, Louis Mayencourt via TF-A wrote: > Hi Raghu, > > Let me try to clarify/reword my idea: > > We complete the fconf documentation with a binding document, which > defines the nodes that should be present in the config DTB to consider > it as valid/well-formed. The document contains two kinds of node: > > * mandatory (critical): the firmware can't proceed without this > information (example: load address, image UUID, ...). If this node > is not present in the DTS, the build fails and/or the code panic. > > * optional (no-critical): the firmware can assume or assign a default > value and proceed (example: uart config, enable authentication flag, > ...). Such a property is used to influence the default behavior of > the firmware. > > />> This is non-deterministic failure./ > The miss of a mandatory (critical) node will always lead to a build > failure / code panic. > The miss of an optional (no-critical) node should not influence the > default behavior of the firmware. > > />> Is it not confusing to make the assumption that a DTB is "well > formed",i.e expect the build process/integrator to not mess up the >>> structure or number of nodes but allow the same integrator to miss a critical property in the DTB?/ > A DTB with a missing mandatory (critical) property should not be > considered well formed. > > />> If there is a missing critical property, is that not a badly formed > DTB?/ > With the above definition, it is. > > />> And if so, why not check for badly formed DTB's uniformly in code > and why only check for missing "critical" properties?/ > With the rewording of "critical" / "no-critical" to "mandatory" / > "optional", I think the situation is clearer: A DTB with a missing > "optional" node/property is is still considered well-formed. > > I hope I answered your questions and clarify the idea behind the design. > > regards, > Louis > > ------------------------------------------------------------------------ > *From:* Raghu Krishnamurthy <raghu.ncstate(a)icloud.com> > *Sent:* 05 April 2020 00:06 > *To:* Louis Mayencourt <Louis.Mayencourt(a)arm.com> > *Subject:* Re: [TF-A] fconf: Validating config data > Thanks Louis. > >>you can imagine a well-formed DTB which contain a > >>critical set of properties and can contain some optional properties. > > This makes things even more confusing. The assumption we are asking code > to make is that the DTB is always "well formed", ie don't check for > structural issues such as extra nodes etc, but we are still making the > distinctions between critical and non-critical properties, that may or > may not exist in the DTB, which may or may not cause a panic. This is > non-deterministic failure. > Is it not confusing to make the assumption that a DTB is "well > formed",i.e expect the build process/integrator to not mess up the > structure or number of nodes but allow the same integrator to miss a > critical property in the DTB? If there is a missing critical property, > is that not a badly formed DTB ? And if so, why not check for badly > formed DTB's uniformly in code and why only check for missing "critical" > properties? > > -Raghu > > On 4/3/20 3:16 AM, Louis Mayencourt wrote: >> Hi Raghu, >> >> I do agree that we need something similar to a binding document for >> fconf properties. (similar to >> https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3694/2/docs/…). > >> At least for the common properties. >> >> The main idea behind the return code of the populator function was to >> allow the code to handle no-critical property misses or to handle >> critical failure by calling a platform hook. >> With this in mind, you can imagine a well-formed DTB which contain a >> critical set of properties and can contain some optional properties. The >> return code and the populator "name" / "config" can be used to handle >> this two cases. >> >> I tried to keep the design of fconf really simple, to leave room for >> improvement according to feedbacks. Thanks for helping improving it! >> >> Regards, >> Louis >> ------------------------------------------------------------------------ >> *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:* 03 April 2020 10:15 >> *To:* tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> >> *Subject:* Re: [TF-A] fconf: Validating config data >> A further point is that the fconf populators return an error code and >> panics on error today. But if we are making the assumption that the >> DTB's are well formed, do we really need to fail or even return an error >> code? >> >> -Raghu >> >> On 4/3/20 1:51 AM, Raghu Krishnamurthy via TF-A wrote: >>> Hi All, (Sorry for the long email) >>> >>> The review >>> https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3845 >>> attempts to fix bounds check in the fconf populator code for the >>> topology and SP's. During review, Sandrine thoughtfully pointed out that >>> there were discussions around bounds check along the same lines in the >>> review >>> https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3492 and >>> it was deemed sufficient to have assertions in code and it was safe to >>> make the assumption that the DTB is always well formed and contains >>> valid values. I think this email mostly echoes Sandrine's concern from >>> review 3492. >>> >>> While i agree with the assumptions, I am generally of the opinion that >>> we should validate/range-check any data, even if it is signed. Being >>> signed does not necessarily mean the data is well formed/valid. If there >>> is a mistake in the build process and it is validly signed, it is >>> possible that we silently corrupt state/data that could later be used to >>> exploit firmware and/or make debugging hard. This is probably far >>> fetched, but the cost of adding the check is trivial to avoid this >>> possibility. >>> >>> I imagine the case where you have secure partitions signed by different >>> entity other than the silicon provider(dual root-of-trust). A silicon >>> provider provides a dev system for the SP provider to test and validate >>> the SP's on silicon. The silicon has production firmware(and hence no >>> assertions), but loads signed data from the SP provider which has some >>> invalid values. There could be silent corruption without any indication >>> whatsoever about what went wrong and it may be hard to debug if/when >>> there are issues. >>> Also, testing does not necessarily catch all invalid values since you >>> will likely not get 100% coverage, given the number of config options >>> available. Moreover, the code today, is not consistent in asserting on >>> every property for valid values and the failure mode is not >>> consistent/deterministic. It seems like every config option should have >>> a list of valid values or a range of acceptable values that must be at a >>> minimum asserted on. >>> I also wouldn't discount platforms such as RPI, where TRUSTED_BOARD_BOOT >>> is likely to be turned off since it really does not provide any >>> security, so assuming we always have signed data might not be valid. >>> >>> Anyway, is this decision worth revisiting? Too paranoid perhaps? :P >>> >>> >>> Thanks >>> Raghu >> -- >> 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. > -- 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, 11 months

1
0
0 0

Re: [TF-A] fconf: Validating config data

by Raghu Krishnamurthy

Thanks Louis. This new terminology helps. Let me spell this out again just to make sure we're on the same page. The following are the cases: 1) Mandatory Property hit, nodes are structurally correct - Works normally. 2) Mandatory Property hit, nodes are structurally *incorrect* - Asserts should catch structural issues during development because system integrator expected to not make mistakes with number of nodes etc. 3) Mandatory Property miss - Panic(). Why is this case causing a panic, but not case 2? You are allowing for some one to make the mistake of not having a mandatory property, but assume that if a mandatory property is present, it is always structurally sound. This is the part i have a problem with. In my view case 2 and case 3 should panic and code should not just assert on mandatory properties and must ALWAYS check for structural soundness of an FDT property. Similarly there are 3 cases for optional properties. My question: Why does case 3 panic, but not case 2 ? It sounds like your assumption is that case 2 cannot happen. If case 2 cannot happen, i claim that case 3 cannot happen either. Let me know what you think! Thanks Raghu On 4/6/20 3:57 AM, Louis Mayencourt via TF-A wrote: > Hi Raghu, > > Let me try to clarify/reword my idea: > > We complete the fconf documentation with a binding document, which > defines the nodes that should be present in the config DTB to consider > it as valid/well-formed. The document contains two kinds of node: > > * mandatory (critical): the firmware can't proceed without this > information (example: load address, image UUID, ...). If this node > is not present in the DTS, the build fails and/or the code panic. > > * optional (no-critical): the firmware can assume or assign a default > value and proceed (example: uart config, enable authentication flag, > ...). Such a property is used to influence the default behavior of > the firmware. > > />> This is non-deterministic failure./ > The miss of a mandatory (critical) node will always lead to a build > failure / code panic. > The miss of an optional (no-critical) node should not influence the > default behavior of the firmware. > > />> Is it not confusing to make the assumption that a DTB is "well > formed",i.e expect the build process/integrator to not mess up the >>> structure or number of nodes but allow the same integrator to miss a critical property in the DTB?/ > A DTB with a missing mandatory (critical) property should not be > considered well formed. > > />> If there is a missing critical property, is that not a badly formed > DTB?/ > With the above definition, it is. > > />> And if so, why not check for badly formed DTB's uniformly in code > and why only check for missing "critical" properties?/ > With the rewording of "critical" / "no-critical" to "mandatory" / > "optional", I think the situation is clearer: A DTB with a missing > "optional" node/property is is still considered well-formed. > > I hope I answered your questions and clarify the idea behind the design. > > regards, > Louis > > ------------------------------------------------------------------------ > *From:* Raghu Krishnamurthy <raghu.ncstate(a)icloud.com> > *Sent:* 05 April 2020 00:06 > *To:* Louis Mayencourt <Louis.Mayencourt(a)arm.com> > *Subject:* Re: [TF-A] fconf: Validating config data > Thanks Louis. > >>you can imagine a well-formed DTB which contain a > >>critical set of properties and can contain some optional properties. > > This makes things even more confusing. The assumption we are asking code > to make is that the DTB is always "well formed", ie don't check for > structural issues such as extra nodes etc, but we are still making the > distinctions between critical and non-critical properties, that may or > may not exist in the DTB, which may or may not cause a panic. This is > non-deterministic failure. > Is it not confusing to make the assumption that a DTB is "well > formed",i.e expect the build process/integrator to not mess up the > structure or number of nodes but allow the same integrator to miss a > critical property in the DTB? If there is a missing critical property, > is that not a badly formed DTB ? And if so, why not check for badly > formed DTB's uniformly in code and why only check for missing "critical" > properties? > > -Raghu > > On 4/3/20 3:16 AM, Louis Mayencourt wrote: >> Hi Raghu, >> >> I do agree that we need something similar to a binding document for >> fconf properties. (similar to >> https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3694/2/docs/…). > >> At least for the common properties. >> >> The main idea behind the return code of the populator function was to >> allow the code to handle no-critical property misses or to handle >> critical failure by calling a platform hook. >> With this in mind, you can imagine a well-formed DTB which contain a >> critical set of properties and can contain some optional properties. The >> return code and the populator "name" / "config" can be used to handle >> this two cases. >> >> I tried to keep the design of fconf really simple, to leave room for >> improvement according to feedbacks. Thanks for helping improving it! >> >> Regards, >> Louis >> ------------------------------------------------------------------------ >> *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:* 03 April 2020 10:15 >> *To:* tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> >> *Subject:* Re: [TF-A] fconf: Validating config data >> A further point is that the fconf populators return an error code and >> panics on error today. But if we are making the assumption that the >> DTB's are well formed, do we really need to fail or even return an error >> code? >> >> -Raghu >> >> On 4/3/20 1:51 AM, Raghu Krishnamurthy via TF-A wrote: >>> Hi All, (Sorry for the long email) >>> >>> The review >>> https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3845 >>> attempts to fix bounds check in the fconf populator code for the >>> topology and SP's. During review, Sandrine thoughtfully pointed out that >>> there were discussions around bounds check along the same lines in the >>> review >>> https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3492 and >>> it was deemed sufficient to have assertions in code and it was safe to >>> make the assumption that the DTB is always well formed and contains >>> valid values. I think this email mostly echoes Sandrine's concern from >>> review 3492. >>> >>> While i agree with the assumptions, I am generally of the opinion that >>> we should validate/range-check any data, even if it is signed. Being >>> signed does not necessarily mean the data is well formed/valid. If there >>> is a mistake in the build process and it is validly signed, it is >>> possible that we silently corrupt state/data that could later be used to >>> exploit firmware and/or make debugging hard. This is probably far >>> fetched, but the cost of adding the check is trivial to avoid this >>> possibility. >>> >>> I imagine the case where you have secure partitions signed by different >>> entity other than the silicon provider(dual root-of-trust). A silicon >>> provider provides a dev system for the SP provider to test and validate >>> the SP's on silicon. The silicon has production firmware(and hence no >>> assertions), but loads signed data from the SP provider which has some >>> invalid values. There could be silent corruption without any indication >>> whatsoever about what went wrong and it may be hard to debug if/when >>> there are issues. >>> Also, testing does not necessarily catch all invalid values since you >>> will likely not get 100% coverage, given the number of config options >>> available. Moreover, the code today, is not consistent in asserting on >>> every property for valid values and the failure mode is not >>> consistent/deterministic. It seems like every config option should have >>> a list of valid values or a range of acceptable values that must be at a >>> minimum asserted on. >>> I also wouldn't discount platforms such as RPI, where TRUSTED_BOARD_BOOT >>> is likely to be turned off since it really does not provide any >>> security, so assuming we always have signed data might not be valid. >>> >>> Anyway, is this decision worth revisiting? Too paranoid perhaps? :P >>> >>> >>> Thanks >>> Raghu >> -- >> 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, 11 months

1
0
0 0

Re: [TF-A] fconf: Validating config data

by Louis Mayencourt

Hi Raghu, Let me try to clarify/reword my idea: We complete the fconf documentation with a binding document, which defines the nodes that should be present in the config DTB to consider it as valid/well-formed. The document contains two kinds of node: * mandatory (critical): the firmware can't proceed without this information (example: load address, image UUID, ...). If this node is not present in the DTS, the build fails and/or the code panic. * optional (no-critical): the firmware can assume or assign a default value and proceed (example: uart config, enable authentication flag, ...). Such a property is used to influence the default behavior of the firmware. >> This is non-deterministic failure. The miss of a mandatory (critical) node will always lead to a build failure / code panic. The miss of an optional (no-critical) node should not influence the default behavior of the firmware. >> Is it not confusing to make the assumption that a DTB is "well formed",i.e expect the build process/integrator to not mess up the >> structure or number of nodes but allow the same integrator to miss a critical property in the DTB? A DTB with a missing mandatory (critical) property should not be considered well formed. >> If there is a missing critical property, is that not a badly formed DTB? With the above definition, it is. >> And if so, why not check for badly formed DTB's uniformly in code and why only check for missing "critical" properties? With the rewording of "critical" / "no-critical" to "mandatory" / "optional", I think the situation is clearer: A DTB with a missing "optional" node/property is is still considered well-formed. I hope I answered your questions and clarify the idea behind the design. regards, Louis ________________________________ From: Raghu Krishnamurthy <raghu.ncstate(a)icloud.com> Sent: 05 April 2020 00:06 To: Louis Mayencourt <Louis.Mayencourt(a)arm.com> Subject: Re: [TF-A] fconf: Validating config data Thanks Louis. >>you can imagine a well-formed DTB which contain a >>critical set of properties and can contain some optional properties. This makes things even more confusing. The assumption we are asking code to make is that the DTB is always "well formed", ie don't check for structural issues such as extra nodes etc, but we are still making the distinctions between critical and non-critical properties, that may or may not exist in the DTB, which may or may not cause a panic. This is non-deterministic failure. Is it not confusing to make the assumption that a DTB is "well formed",i.e expect the build process/integrator to not mess up the structure or number of nodes but allow the same integrator to miss a critical property in the DTB? If there is a missing critical property, is that not a badly formed DTB ? And if so, why not check for badly formed DTB's uniformly in code and why only check for missing "critical" properties? -Raghu On 4/3/20 3:16 AM, Louis Mayencourt wrote: > Hi Raghu, > > I do agree that we need something similar to a binding document for > fconf properties. (similar to > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3694/2/docs/…). > At least for the common properties. > > The main idea behind the return code of the populator function was to > allow the code to handle no-critical property misses or to handle > critical failure by calling a platform hook. > With this in mind, you can imagine a well-formed DTB which contain a > critical set of properties and can contain some optional properties. The > return code and the populator "name" / "config" can be used to handle > this two cases. > > I tried to keep the design of fconf really simple, to leave room for > improvement according to feedbacks. Thanks for helping improving it! > > Regards, > Louis > ------------------------------------------------------------------------ > *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:* 03 April 2020 10:15 > *To:* tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> > *Subject:* Re: [TF-A] fconf: Validating config data > A further point is that the fconf populators return an error code and > panics on error today. But if we are making the assumption that the > DTB's are well formed, do we really need to fail or even return an error > code? > > -Raghu > > On 4/3/20 1:51 AM, Raghu Krishnamurthy via TF-A wrote: >> Hi All, (Sorry for the long email) >> >> The review >> https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3845 >> attempts to fix bounds check in the fconf populator code for the >> topology and SP's. During review, Sandrine thoughtfully pointed out that >> there were discussions around bounds check along the same lines in the >> review >> https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3492 and >> it was deemed sufficient to have assertions in code and it was safe to >> make the assumption that the DTB is always well formed and contains >> valid values. I think this email mostly echoes Sandrine's concern from >> review 3492. >> >> While i agree with the assumptions, I am generally of the opinion that >> we should validate/range-check any data, even if it is signed. Being >> signed does not necessarily mean the data is well formed/valid. If there >> is a mistake in the build process and it is validly signed, it is >> possible that we silently corrupt state/data that could later be used to >> exploit firmware and/or make debugging hard. This is probably far >> fetched, but the cost of adding the check is trivial to avoid this >> possibility. >> >> I imagine the case where you have secure partitions signed by different >> entity other than the silicon provider(dual root-of-trust). A silicon >> provider provides a dev system for the SP provider to test and validate >> the SP's on silicon. The silicon has production firmware(and hence no >> assertions), but loads signed data from the SP provider which has some >> invalid values. There could be silent corruption without any indication >> whatsoever about what went wrong and it may be hard to debug if/when >> there are issues. >> Also, testing does not necessarily catch all invalid values since you >> will likely not get 100% coverage, given the number of config options >> available. Moreover, the code today, is not consistent in asserting on >> every property for valid values and the failure mode is not >> consistent/deterministic. It seems like every config option should have >> a list of valid values or a range of acceptable values that must be at a >> minimum asserted on. >> I also wouldn't discount platforms such as RPI, where TRUSTED_BOARD_BOOT >> is likely to be turned off since it really does not provide any >> security, so assuming we always have signed data might not be valid. >> >> Anyway, is this decision worth revisiting? Too paranoid perhaps? :P >> >> >> Thanks >> Raghu > -- > 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, 11 months

1
0
0 0

Re: [TF-A] fconf: Validating config data

by Raghu Krishnamurthy

+tf-a list On 4/4/20 4:06 PM, Raghu Krishnamurthy wrote: > Thanks Louis. > >>you can imagine a well-formed DTB which contain a > >>critical set of properties and can contain some optional properties. > > This makes things even more confusing. The assumption we are asking code > to make is that the DTB is always "well formed", ie don't check for > structural issues such as extra nodes etc, but we are still making the > distinctions between critical and non-critical properties, that may or > may not exist in the DTB, which may or may not cause a panic. This is > non-deterministic failure. > Is it not confusing to make the assumption that a DTB is "well > formed",i.e expect the build process/integrator to not mess up the > structure or number of nodes but allow the same integrator to miss a > critical property in the DTB? If there is a missing critical property, > is that not a badly formed DTB ? And if so, why not check for badly > formed DTB's uniformly in code and why only check for missing "critical" > properties? > > -Raghu > > On 4/3/20 3:16 AM, Louis Mayencourt wrote: >> Hi Raghu, >> >> I do agree that we need something similar to a binding document for >> fconf properties. (similar to >> https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3694/2/docs/…). >> At least for the common properties. >> >> The main idea behind the return code of the populator function was to >> allow the code to handle no-critical property misses or to handle >> critical failure by calling a platform hook. >> With this in mind, you can imagine a well-formed DTB which contain a >> critical set of properties and can contain some optional properties. >> The return code and the populator "name" / "config" can be used to >> handle this two cases. >> >> I tried to keep the design of fconf really simple, to leave room for >> improvement according to feedbacks. Thanks for helping improving it! >> >> Regards, >> Louis >> ------------------------------------------------------------------------ >> *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:* 03 April 2020 10:15 >> *To:* tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> >> *Subject:* Re: [TF-A] fconf: Validating config data >> A further point is that the fconf populators return an error code and >> panics on error today. But if we are making the assumption that the >> DTB's are well formed, do we really need to fail or even return an error >> code? >> >> -Raghu >> >> On 4/3/20 1:51 AM, Raghu Krishnamurthy via TF-A wrote: >>> Hi All, (Sorry for the long email) >>> >>> The review >>> https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3845 >>> attempts to fix bounds check in the fconf populator code for the >>> topology and SP's. During review, Sandrine thoughtfully pointed out >>> that there were discussions around bounds check along the same lines >>> in the review >>> https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3492 and >>> it was deemed sufficient to have assertions in code and it was safe >>> to make the assumption that the DTB is always well formed and >>> contains valid values. I think this email mostly echoes Sandrine's >>> concern from review 3492. >>> >>> While i agree with the assumptions, I am generally of the opinion >>> that we should validate/range-check any data, even if it is signed. >>> Being signed does not necessarily mean the data is well formed/valid. >>> If there is a mistake in the build process and it is validly signed, >>> it is possible that we silently corrupt state/data that could later >>> be used to exploit firmware and/or make debugging hard. This is >>> probably far fetched, but the cost of adding the check is trivial to >>> avoid this possibility. >>> >>> I imagine the case where you have secure partitions signed by >>> different entity other than the silicon provider(dual root-of-trust). >>> A silicon provider provides a dev system for the SP provider to test >>> and validate the SP's on silicon. The silicon has production >>> firmware(and hence no assertions), but loads signed data from the SP >>> provider which has some invalid values. There could be silent >>> corruption without any indication whatsoever about what went wrong >>> and it may be hard to debug if/when there are issues. >>> Also, testing does not necessarily catch all invalid values since you >>> will likely not get 100% coverage, given the number of config options >>> available. Moreover, the code today, is not consistent in asserting >>> on every property for valid values and the failure mode is not >>> consistent/deterministic. It seems like every config option should >>> have a list of valid values or a range of acceptable values that must >>> be at a minimum asserted on. >>> I also wouldn't discount platforms such as RPI, where >>> TRUSTED_BOARD_BOOT is likely to be turned off since it really does >>> not provide any security, so assuming we always have signed data >>> might not be valid. >>> >>> Anyway, is this decision worth revisiting? Too paranoid perhaps? :P >>> >>> >>> Thanks >>> Raghu >> -- >> 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, 11 months

1
0
0 0

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

by Sandrine Bailleux

Hi Raghu, On 4/3/20 1:38 AM, Raghu Krishnamurthy via TF-A wrote: > Thanks Sandrine. Patches look good. Thanks for the review! > 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? I remember some internal discussions around this topic a few weeks ago. If I recall correctly, the current thinking is that down the line, we would like to move image IDs to DTBs but this looks complicated to achieve today because image IDs are used by several components in TF-A to tie things together. More work would be needed to abstract this properly everywhere. I think other folks in the team (Olivier? Manish? Louis?) might be able to comment further on this. 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, 11 months

1
0
0 0

Re: [TF-A] fconf: Validating config data

by Raghu Krishnamurthy

A further point is that the fconf populators return an error code and panics on error today. But if we are making the assumption that the DTB's are well formed, do we really need to fail or even return an error code? -Raghu On 4/3/20 1:51 AM, Raghu Krishnamurthy via TF-A wrote: > Hi All, (Sorry for the long email) > > The review > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3845 > attempts to fix bounds check in the fconf populator code for the > topology and SP's. During review, Sandrine thoughtfully pointed out that > there were discussions around bounds check along the same lines in the > review > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3492 and > it was deemed sufficient to have assertions in code and it was safe to > make the assumption that the DTB is always well formed and contains > valid values. I think this email mostly echoes Sandrine's concern from > review 3492. > > While i agree with the assumptions, I am generally of the opinion that > we should validate/range-check any data, even if it is signed. Being > signed does not necessarily mean the data is well formed/valid. If there > is a mistake in the build process and it is validly signed, it is > possible that we silently corrupt state/data that could later be used to > exploit firmware and/or make debugging hard. This is probably far > fetched, but the cost of adding the check is trivial to avoid this > possibility. > > I imagine the case where you have secure partitions signed by different > entity other than the silicon provider(dual root-of-trust). A silicon > provider provides a dev system for the SP provider to test and validate > the SP's on silicon. The silicon has production firmware(and hence no > assertions), but loads signed data from the SP provider which has some > invalid values. There could be silent corruption without any indication > whatsoever about what went wrong and it may be hard to debug if/when > there are issues. > Also, testing does not necessarily catch all invalid values since you > will likely not get 100% coverage, given the number of config options > available. Moreover, the code today, is not consistent in asserting on > every property for valid values and the failure mode is not > consistent/deterministic. It seems like every config option should have > a list of valid values or a range of acceptable values that must be at a > minimum asserted on. > I also wouldn't discount platforms such as RPI, where TRUSTED_BOARD_BOOT > is likely to be turned off since it really does not provide any > security, so assuming we always have signed data might not be valid. > > Anyway, is this decision worth revisiting? Too paranoid perhaps? :P > > > Thanks > Raghu

5 years, 11 months

1
0
0 0

fconf: Validating config data

by Raghu Krishnamurthy

Hi All, (Sorry for the long email) The review https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3845 attempts to fix bounds check in the fconf populator code for the topology and SP's. During review, Sandrine thoughtfully pointed out that there were discussions around bounds check along the same lines in the review https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3492 and it was deemed sufficient to have assertions in code and it was safe to make the assumption that the DTB is always well formed and contains valid values. I think this email mostly echoes Sandrine's concern from review 3492. While i agree with the assumptions, I am generally of the opinion that we should validate/range-check any data, even if it is signed. Being signed does not necessarily mean the data is well formed/valid. If there is a mistake in the build process and it is validly signed, it is possible that we silently corrupt state/data that could later be used to exploit firmware and/or make debugging hard. This is probably far fetched, but the cost of adding the check is trivial to avoid this possibility. I imagine the case where you have secure partitions signed by different entity other than the silicon provider(dual root-of-trust). A silicon provider provides a dev system for the SP provider to test and validate the SP's on silicon. The silicon has production firmware(and hence no assertions), but loads signed data from the SP provider which has some invalid values. There could be silent corruption without any indication whatsoever about what went wrong and it may be hard to debug if/when there are issues. Also, testing does not necessarily catch all invalid values since you will likely not get 100% coverage, given the number of config options available. Moreover, the code today, is not consistent in asserting on every property for valid values and the failure mode is not consistent/deterministic. It seems like every config option should have a list of valid values or a range of acceptable values that must be at a minimum asserted on. I also wouldn't discount platforms such as RPI, where TRUSTED_BOARD_BOOT is likely to be turned off since it really does not provide any security, so assuming we always have signed data might not be valid. Anyway, is this decision worth revisiting? Too paranoid perhaps? :P Thanks Raghu

5 years, 11 months

1
0
0 0

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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 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, 12 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, 12 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

6 years

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.

6 years

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

6 years

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.

6 years

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.

6 years

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

6 years

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-A