- TSC - lists.trustedfirmware.org

TSC Agenda 16 Apr 2020

by Abhishek Pandit

Hi All, Any agenda items for this week's meeting? Thanks, Abhishek

5 years, 6 months

1
0
0 0

Re: [TF-TSC] [TF-A] TF-A Tech Forum @ Thu 9 Apr 2020 17:00 - 18:00 (GMT) - Special session on Project Maintenance Proposal for tf.org

by Joanna Farley

I realise non TF-A people may not have access to session conference details. These can be found here: https://lists.trustedfirmware.org/pipermail/tf-a/2020-March/000330.html From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Joanna Farley via TF-A <tf-a(a)lists.trustedfirmware.org> Reply to: Joanna Farley <Joanna.Farley(a)arm.com> Date: Tuesday, 7 April 2020 at 18:10 To: tf-a <tf-a(a)lists.trustedfirmware.org> Cc: "tsc(a)lists.trustedfirmware.org" <tsc(a)lists.trustedfirmware.org>, "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org>, "op-tee(a)linaro.org" <op-tee(a)linaro.org> Subject: [TF-A] TF-A Tech Forum @ Thu 9 Apr 2020 17:00 - 18:00 (GMT) - Special session on Project Maintenance Proposal for tf.org Hi All, The third TF-A Tech Forum is scheduled for Thu 9th Apr 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. For this special session I have also copied the TF-M, TSC and OPTEE mailing lists as the subject may interest the people subscribed to those lists as there is a cross mailing list discussion currently ongoing. Agenda: * Overview of the Project Maintenance Proposal for tf.org Projects by Sandrine Bailleux * 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. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

5 years, 6 months

1
0
0 0

TF-A Tech Forum @ Thu 9 Apr 2020 17:00 - 18:00 (GMT) - Special session on Project Maintenance Proposal for tf.org

by Joanna Farley

Hi All, The third TF-A Tech Forum is scheduled for Thu 9th Apr 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. For this special session I have also copied the TF-M, TSC and OPTEE mailing lists as the subject may interest the people subscribed to those lists as there is a cross mailing list discussion currently ongoing. Agenda: * Overview of the Project Maintenance Proposal for tf.org Projects by Sandrine Bailleux * 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, 6 months

1
1
0 0

Re: [TF-TSC] [TF-A] [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, 7 months

2
1
0 0

Re: [TF-TSC] [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, 7 months

1
0
0 0

Re: [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, 7 months

2
1
0 0

Re: [TF-TSC] [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, 7 months

2
2
0 0

Re: [TF-TSC] [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, 7 months

2
2
0 0

Re: [TF-TSC] [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, 7 months

3
2
0 0

Trusted Firmware TSC 19th March - minutes

by Dan Handley

(Somewhat belatedly...) Attendees ---------- David Brown (Linaro) Mark Grosen (TI) Bill Mills (TI) Julius Werner (Google) Kevin Townsend (Linaro) Abhishek Pandit (Arm) Dan Handley (Arm) Sandrine Bailleux (Arm) Joakim Bech (Linaro) Eric Finco (ST) Lionel Debieve (ST) KangKang Shen (FutureWei) Agenda ------ * Maintenance proposal * Security process * Misc Maintenance proposal -------------------- * SB presented slides (attached). * JW: Main concern is maintainer bottleneck. Should there be a concept of platform maintainer that can only merge platform patches? * SB: Idea is to increase the number of maintainers to reduce bottleneck. * DH: Can layer concept of platform maintainers on top of this without defining specific role. E.g. can set the expectation that new platform maintainers should be available to review any platform changes instead of existing maintainers. * JW: But if code has been approved by code owner then what value is maintainer adding? * DH: Need someone to review high level aspects like licensing, IP concerns, if it fits in scope of project, etc... * JW: Want to see if this works in practice. * KKS: Need guidelines on how to review, e.g. to ensure important comments are addressed and not focus on small problems. * JW: On the lifecycle, what's the point of keeping it in the tree if it doesn't build? Also what if you add generic API change - are you responsible for updating all platforms? * SB: "Limited support" status would expect some features to still work. * DH: Don't want to rip platforms out of the tree as soon as they stop working. * JW: Shouldn't conflate the issues of "does CI work" and "code owner not responding". * SB: Fair enough. On the generic API change thing, author can try to update all platforms but if changes are more involved then it's better for platform owner to do it. * AB: Purpose of this meeting is to highlight the issues not do detailed review. Can save further comments for offline feedback. * Discussion around how to review. Should we use Gerrit, Phabricator or email. Will start with email review to all the lists. Can revert to Gerrit if it gets out of control. Issue with Gerrit is would need to create new repo or choose temp place in existing repo. [SB has now sought feedback on the lists: https://developer.trustedfirmware.org/w/collaboration/project-maintenance-p…] Security Process --------------------- * EF: No concern on process itself. It's more a question of scope of security issues. * EF: In particular, there's a grey area around what hardware/side-channel attacks we mitigate. * DH: Yes, although hardware attacks were out of scope in the original design of e.g. TF-A, we have added piecemeal mitigations for certain issues (e.g. Spectre). Can give the false impression that the codebase is secure against all attacks in that class when it isn't necessarily. * DH: Arm has internal threat models for TF-A and TF-M that we intend to publish when we can. This is really important in order to publicly communicate the classes of threats we think we've mitigated (and what we should continue to mitigate as changes are added). Also intend to publicise a threat model for upcoming Mbed TLS project. * JB: OP-TEE currently doesn't have a threat model. It's been on the todo list for a long time. * MB: PSA defines a number of threat models [for M Class] and has a potentially useful template that can be used. Can they be freely reused? * Action: DH: Arm to find out. * DH: Status on the process is I'm still making minor updates to cater for Mbed TLS. Main task now is to prototype how to execute process using Phabricator (or other tf.org tools) so we can activate it. Misc ------ * JB: Is tf.org interested in being part of device tree consolidation work? * DH: Yes, TF-A only added DTs to the repo for platforms that the kernel didn't want to host (e.g. models). If and when there's a new place for these, we should remove the ones from TF-A. * General agreement * JB: Should we have some kind of Change Log for TF-A? * SB: We have one! https://trustedfirmware-a.readthedocs.io/en/latest/change-log.html * DH: Would have liked to talk about tf.org tooling (e.g. Gerrit, Phabricator, cgit) but no time. * AB: Could easily turn into a big discussion. * DH: Agreed, maybe I can make a proposal and seek feedback from the project lists first before coming back to the TSC.

5 years, 7 months

1
0
0 0

Re: [TF-TSC] [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, 7 months

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

1
0
0 0

Re: [TF-TSC] TSC Agenda 19 Mar 2020

by Dan Handley

Hi I'd like to discuss the tooling at TrustedFirmware.org (i.e. Cgit, Gerrit, Phabricator) to understand the rationale for the current toolset, what alternatives were considered/discounted and what future tools/enhancements could potentially help us. I expect any proposed changes will require much deeper analysis/discussion but it would be good to have an initial baseline discussion. Regards Dan. From: TSC <tsc-bounces(a)lists.trustedfirmware.org> On Behalf Of Abhishek Pandit via TSC Sent: 18 March 2020 17:13 To: tsc(a)lists.trustedfirmware.org Subject: [TF-TSC] TSC Agenda 19 Mar 2020 Hi All, Any agenda items for the TSC meeting this week? TF-A & TF-M team have been working on defining a clear maintenance process. The initial draft has been uploaded for review - https://developer.trustedfirmware.org/w/collaboration/project-maintenance-p… We can have a quick overview in the meeting. Thanks, Abhishek IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

5 years, 7 months

1
0
0 0

Re: [TF-TSC] TSC Agenda 19 Mar 2020

by Eric FINCO

Hi Abhishek, I also propose we come back on the emails exchanged on the TSC mailing list concerning the on the Security incident handling process Regards, Eric Finco [Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: logo_big5] Eric FINCO | Tel: +33 (0)2 4402 7154 MDG | Technical Specialist From: TSC <tsc-bounces(a)lists.trustedfirmware.org> On Behalf Of Abhishek Pandit via TSC Sent: mercredi 18 mars 2020 18:13 To: tsc(a)lists.trustedfirmware.org Subject: [TF-TSC] TSC Agenda 19 Mar 2020 Hi All, Any agenda items for the TSC meeting this week? TF-A & TF-M team have been working on defining a clear maintenance process. The initial draft has been uploaded for review - https://developer.trustedfirmware.org/w/collaboration/project-maintenance-p… We can have a quick overview in the meeting. Thanks, Abhishek

5 years, 7 months

1
0
0 0

TSC Agenda 19 Mar 2020

by Abhishek Pandit

Hi All, Any agenda items for the TSC meeting this week? TF-A & TF-M team have been working on defining a clear maintenance process. The initial draft has been uploaded for review - https://developer.trustedfirmware.org/w/collaboration/project-maintenance-p… We can have a quick overview in the meeting. Thanks, Abhishek

5 years, 7 months

1
0
0 0

Re: [TF-TSC] Proposed tf.org security incident handling process (v0.5)

by Joakim Bech

Hi Dan, all, I've read the updated version(s), I'm happy with them as they are written here in the 0.5 version (that implies that Linaro is happy with them). External process: - It'd be nice at some point to complement the text with a graphical timeline showing the boundaries at each step. Internal process: - CVSSv3 or something else to identify the severity? I know OP-TEE isn't using CVSSv3. I'd be happy to change OP-TEE to align with other TF projects. - Regarding people on op-tee-security(a)trustedfirmware.org, for now I think it's sufficient to have Jens + the global address ( security(a)trustedfirmware.org). Maniphest: - I have no experience, but that'll probably get the job done as any other tools would have done. Regards, Joakim On Wed, 19 Feb 2020 at 19:00, Dan Handley via TSC < tsc(a)lists.trustedfirmware.org> wrote: > Hi TF TSC > > > > This is a v0.5 update to the proposed tf.org security incident handling > process, which I sent previously. > > > > Changes: > > * Expanded the Trusted Stakeholder embargo request period to 3 working > days (in their timezone). > > * Expanded the ESS definition to include suppliers to ESSes (e.g. distros). > > * Allowed projects to optionally use severity scoring (CVSSv3 preferred > but not mandated). > > * Allowed for flexibility in disclosure plan to accommodate reporter's > disclosure plan. > > * Allowed for the fact that some projects cannot deliver vulnerability > fixes to a restricted audience for export control reasons. > > > > I've also included an internal facing process for the first time, mainly > aimed at members of the security team(s) so they know how to execute the > process. > > > > I propose the next steps are: > > * Discuss the latest changes in the 20th Feb TSC meeting. > > * Set a date for approval of the external process (e.g. mid-March). > > * Identify the right people to be on the security teams. > > * Work with tf.org infra people and each project's security teams to > propose a plan for when this process can be made active. Should we try to > make this active for all projects at the same time or as each project is > ready? > > > > Regards > > > > Dan. > > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > -- > TSC mailing list > TSC(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tsc >

5 years, 7 months

2
1
0 0

Re: [TF-TSC] Proposed tf.org security incident handling process (v0.5)

by Eric FINCO

Hi Dan and all, We have had an ST internal review of the processes (internal and external) I did not hear any significant remarks from my colleagues on the processes themselves but one question related to the implementation of the processes: Obviously, any suspected security flaw can be reported to the TF security team using the dedicated email defined. However, can we have (for information only ) a view on the class of vulnerability the security team will handle ? For instance will they analyze and look for a fix to side channel attack or even hardware attack ? Regards, Eric Finco [Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: logo_big5] Eric FINCO | Tel: +33 (0)2 4402 7154 MDG | Technical Specialist From: TSC <tsc-bounces(a)lists.trustedfirmware.org> On Behalf Of Joakim Bech via TSC Sent: lundi 2 mars 2020 14:52 To: Dan Handley <Dan.Handley(a)arm.com> Cc: tsc(a)lists.trustedfirmware.org Subject: Re: [TF-TSC] Proposed tf.org security incident handling process (v0.5) Hi Dan, all, I've read the updated version(s), I'm happy with them as they are written here in the 0.5 version (that implies that Linaro is happy with them). External process: - It'd be nice at some point to complement the text with a graphical timeline showing the boundaries at each step. Internal process: - CVSSv3 or something else to identify the severity? I know OP-TEE isn't using CVSSv3. I'd be happy to change OP-TEE to align with other TF projects. - Regarding people on op-tee-security(a)trustedfirmware.org<mailto:op-tee-security@trustedfirmware.org>, for now I think it's sufficient to have Jens + the global address (security(a)trustedfirmware.org<mailto:security@trustedfirmware.org>). Maniphest: - I have no experience, but that'll probably get the job done as any other tools would have done. Regards, Joakim On Wed, 19 Feb 2020 at 19:00, Dan Handley via TSC <tsc(a)lists.trustedfirmware.org<mailto:tsc@lists.trustedfirmware.org>> wrote: Hi TF TSC This is a v0.5 update to the proposed tf.org<http://tf.org> security incident handling process, which I sent previously. Changes: * Expanded the Trusted Stakeholder embargo request period to 3 working days (in their timezone). * Expanded the ESS definition to include suppliers to ESSes (e.g. distros). * Allowed projects to optionally use severity scoring (CVSSv3 preferred but not mandated). * Allowed for flexibility in disclosure plan to accommodate reporter's disclosure plan. * Allowed for the fact that some projects cannot deliver vulnerability fixes to a restricted audience for export control reasons. I've also included an internal facing process for the first time, mainly aimed at members of the security team(s) so they know how to execute the process. I propose the next steps are: * Discuss the latest changes in the 20th Feb TSC meeting. * Set a date for approval of the external process (e.g. mid-March). * Identify the right people to be on the security teams. * Work with tf.org<http://tf.org> infra people and each project's security teams to propose a plan for when this process can be made active. Should we try to make this active for all projects at the same time or as each project is ready? Regards Dan. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- TSC mailing list TSC(a)lists.trustedfirmware.org<mailto:TSC@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tsc

5 years, 7 months

2
1
0 0

Trusted Firmware website review

by Bill Fletcher

Hi all, The Trusted Firmware TSC has undertaken to review the TrustedFirmware.org website and propose changes. Some TF website review headings and criteria are listed in a wiki document we've created to capture review comments. Please edit this document to add review inputs. https://developer.trustedfirmware.org/w/collaboration/website/ It would be helpful if you could add your initials to contributions. Version history is also tracked. Best regards Bill -- [image: Linaro] <http://www.linaro.org/> *Bill Fletcher* | *Field Engineering* T: +44 7833 498336 <+44+7833+498336> bill.fletcher(a)linaro.org | Skype: billfletcher2020

5 years, 7 months

1
0
0 0

Trusted Firmware TSC 20th Feb - minutes

by Bill Fletcher

Attendees Abhishek Pandit (Arm) Dan Handley (Arm) Kevin Townsend (Linaro) Joakim Bech (Linaro) Christian Daudt (Cypress) Eric Finco (ST) Mark Grosen (TI) Bill Mills (TI) Bill Fletcher (Linaro Community Projects) Minutes DH: Security handling process. Projects to be incorporated have different ways to handle security … Kernel has an upstream/early approach to get thefix in. In Mbed TLS etc work very closely with crypto researchers to disclose at the same time. Not sure if the latest wording is enough to satisfy them. Flexibility - if the reporter has a different plan. Maybe holding back the fix until you make the disclosure. Skilled researcher could reverse engineer the fix. Also an export control issue. Can’t release fixes to a restricted audience and keep waiver from EAR. Will send an update soon. Try to agree a date for approval - mid March? Then see when we could make it active after approval. Are we trying to make it active for all projects at the same time? AP: Wording looked ok for me e.g. for export restrictions. Currently our TSC list is closed. Think we should open it. Any objection to opening minutes on a public page? EF: If we open it, will allow anyone to review the security document? AP: To be able to point people showing we have an ongoing process. How to track that everyone has agreed? DH: On a project-by-project basis. Expand to everyone on the security team. Give a plan for when it might happen that they adopt it. AP: Create a quick form for everyone to check. DH: Suggest a separate meeting with those people on the details. Proposed some next steps in the email. Will try to drive things forward. AP: Suggest you and Joakim come up with a deadline to review/agree. DH: Could go for a final approval but want to avoid someone vetoing at a late stage. JB: From Linaro point-of-view we’re ok with it. DH: Action: will send a reply to mail to say like to know that approval is acceptable to everyone. Will then ask for final approval on the text of the process. AP: Visibility of TSC Minutes. Should we open the mailing list archives to be public without logging in? CD: In principle OK. Trying to think of instances where we might not want everything public. BF: Mailing list archives are open to all members of the list and the list is open to anyone who wants to subscribe. AP: Action: will send a yes/no vote mail to see if people are ok to open the archive. KT: Provisioning. No feedback responses on certificate chains https://github.com/microbuilder/certificate_chains/blob/master/rfc_tfm.md David has been thinking more about factory provisioning. Early vs late bindings. I replied to thread with Jamie identified some issues for late bindings where need to store in secure storage. Definitely some overlap. Some feedback would be nice. EF: Can’t disconnect from real world product implementation. People have questions about if it is ‘affordable’ on an MCU product. Something that is being targetted for implementation outside of TF-M. KT: A lot of functionality already exists. Not supporting certificate chain today. In order to work with a certificate chain there are some missing pieces. Need to generate cert signing request on TF-M side. Has to happen on secure processing side. Need to expose this functionality in the PSA API. EF: Usecase understood. Initial feedback - purpose understood. Based on this response will ask for a more in-depth opinion. KT: Looks like extra 25-30kbytes of Flash. JB: Did you look into the PSA specification for this? KT: Email from Jamie wasn’t on our radar. JB: Seems Arm is pushing various documents into PSA. Maybe the way to go to get it aligned with PSA. AP: Leave this to next TSC meeting - too early to set a deadline. AP: Coding standards. Divided into which standards we target and also identify a few experienced team members who can make decisions. Would like to put a deadline on this for next TSC and will send out a follow up for ‘enforcers’. MG: Where do we want the codebase to go from a standards point of view? In the automotive space - MISRA - do we care about that? AP: How to take this forward - form a breakaway group for people who are interested? MG: TI definitely interested in having a codebase we could certify to e.g. ISO26262. Need to decide which ones. JB: For all the projects - do we need to specify which projects will follow which conventions. CD: Don’t think can have an overarching one over all projects. AP: TF-M could just do with something set up now to aim for something in a year’s time. Answer doesn’t seem to be coming in this call. Need a breakaway group. CD: Acceptable. Think starting point could be TF-A and OP-TEE as a baseline. Action: Christian will send out an email with a date for a meeting AP: Also platform folders have different coding standards. Think this needs specifying. JB: I was asked about FIPS certification - has anyone had a request? DH: Have never accepted this as a requirement to the project. AP: Platform maintainers and core maintainers. Platform - desire is to make it easier. Core maintainers - are open to adding more. Not pushing, but openness is there. AP: Website review. Had initial discussion last time around. Haven’t seen any response. Action: Will work with Bill to produce a document. Then people can go and add comments. KT: Agree to create a shared document. Need somewhere to post images BF: Could either be Googledoc or on Phabricator wiki. AOB BF: Private workflow on Maniphest raised by Dan? DH: Commenting now. Will follow up on return. -- [image: Linaro] <http://www.linaro.org/> *Bill Fletcher* | *Field Engineering* T: +44 7833 498336 <+44+7833+498336> bill.fletcher(a)linaro.org | Skype: billfletcher2020

5 years, 8 months

1
0
0 0

Proposed tf.org security incident handling process (v0.5)

by Dan Handley

Hi TF TSC This is a v0.5 update to the proposed tf.org security incident handling process, which I sent previously. Changes: * Expanded the Trusted Stakeholder embargo request period to 3 working days (in their timezone). * Expanded the ESS definition to include suppliers to ESSes (e.g. distros). * Allowed projects to optionally use severity scoring (CVSSv3 preferred but not mandated). * Allowed for flexibility in disclosure plan to accommodate reporter's disclosure plan. * Allowed for the fact that some projects cannot deliver vulnerability fixes to a restricted audience for export control reasons. I've also included an internal facing process for the first time, mainly aimed at members of the security team(s) so they know how to execute the process. I propose the next steps are: * Discuss the latest changes in the 20th Feb TSC meeting. * Set a date for approval of the external process (e.g. mid-March). * Identify the right people to be on the security teams. * Work with tf.org infra people and each project's security teams to propose a plan for when this process can be made active. Should we try to make this active for all projects at the same time or as each project is ready? Regards Dan. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

5 years, 8 months

1
0
0 0

TSC Agenda 20 Feb 2020

by Abhishek Pandit

Hi All, Any agenda items for the TSC meeting this week? There are some ongoing discussions from previous meetings which we can cover anyway. Thanks, Abhishek

5 years, 8 months

1
0
0 0

Trusted Firmware website suggestions

by Abhishek Pandit

Hi All, In previous TSC meeting, we discussed the topic of reviewing the trustedfirmware.org website in terms of contents and structure. You can find some of the comments in the TSC meeting minutes. I took an action to kick off an email thread so that we can capture all the inputs in one place. Can you please reply to this thread if you have any improvements suggestions? Thanks, Abhishek

5 years, 9 months

1
0
0 0

Trusted Firmware TSC 16th Jan - minutes

by Bill Fletcher

Attendees Abhishek Pandit (Arm) Dan Handley (Arm) David Brown (Linaro) Kevin Townsend (Linaro) Joakim Bech (Linaro) Eric FInco (ST) Julius Werner (Google) Kangkang (Futurewei) Bill Fletcher (Linaro Community Projects) notes AP: Reduce number of pending items. Coding standard. Decided we could have a couple of experienced SW guys in charge of resolving any conflicts. Looking for a few volunteers who would clarify (for TF-M) the standard. EF: Timescale for closing this? AP: No specific timeline but feel just need a small group who have the judgement. They need prior experience with larger projects. Can send out an email after to close nominations. Also have action to close coding standards for platform (raised by ST). EF: Will discuss with Michel - believe ST can contribute something here. Maintainers AP: Had long discussion last time for both TF-M and TF-A. How would people prefer to close this topic? Otherwise ask one of the TF-A and TF-M engineers from Arm to make a mailing list from a patch. Based on Dan’s comment. Security incident response process DH: Stalling due to my time and discussion about Mbed TLS and Crypto projects moving into the project. Can’t deliver patches to a small audience for export control reasons. Still can have some sort of embargo on reporting issue. Fix has to be available to anyone. Want them to decouple fix from advisory. This is aligned to the link from JB - Google Project Zero. AP: First draft for open review - end of Jan? DH: Have a draft ready now. Should be able to send it next week. AP: Need to inform internal people at the same time. DH: More of a problem at the moment for TF-M that doesn’t have a process. OP-TEE etc should continue to follow their own process. Regional differences for Crypto KK: Example of TPM - TPM 2.0 allowed regional differences. Previous TPM was banned in China. Should have an architecture that allows crypto implementation to plug in. DH: Hope that PSA crypto interface is suitable for anyone, even if the underlying implementations are not. Generally should not have export control issue. May be relying on feedback from Futurewei and other contributors to say what is permissable in China. KK: Suggest to review with Arm China. DH: Need to improve the process before start on any feature improvements. Provisioning KT: Did not meet yet. Can put together an RFC by the end of the month. DB: seeing a conflict between the academic view - X.509 too heavy vs Data I/O saying everyone uses it even in the smallest devices. See what feedback we get. AP: Potentially raise it as a voting point, but have an open RFC discussion first. Trusted Firmware Website AP: Have you browsed through the project website? See if there’s a need for improvement. Main home page doesn’t have much information. A lot of the material is via indirection (links?). TF-M needs more documentation. Also people can’t find things on Phabricator. JB: Always thought the font sizes are too big on all the project websites that Linaro is creating. Have a problem with page layout https://www.op-tee.org/security-advisories/ DB: Feel navigation text is too small and body text is too large. JB: On OP-TEE website we got rid of a lot of information and just pointed to readthedocs. BF: Also have a staging website staging.trustedfirmware.org AP: think first need some people to do some analysis first. DB: Left hand navigation would be easier than dropdowns with 2 or 3 items. KT: Think the documentation for TF-M has improved over the past couple of months. AP: Can find the docs via the dropdown. Discussing with Shebu, feel the experience for getting started can be improved. KT: People just want to know the git clone and CMake commands. DB: There’s navigation of the sections of the doc, and there’s navigation of the website. These are two different things. KT: Have to click on user guide from getting started. DB: Realise have to click on each level of the dropdown - make them just mouse-over. BF: Happy to collate data from a mailing list. AP: Shall we share a document? On Phabricator there is a Q&A page. Anyone object to mailing list? No. Action on Abhishek to kick off the thread Next meeting 20th Feb -- [image: Linaro] <http://www.linaro.org/> *Bill Fletcher* | *Field Engineering* T: +44 7833 498336 <+44+7833+498336> bill.fletcher(a)linaro.org | Skype: billfletcher2020

5 years, 9 months

1
0
0 0

TSC Agenda 16 Jan 2020

by Abhishek Pandit

Hi All, Any agenda items for this week's meeting? I think we can try to close some of the items from the previous meetings. Thanks, Abhishek

5 years, 9 months

1
0
0 0

Re: [TF-TSC] Project Zero disclosure policy updates

by Dan Handley

Thanks for forwarding, Joakim. I'm happy to say this seems aligned with my proposed TF disclosure policy (e.g. encourage a high quality fix ASAP but disclose after 90 days). Regarding the status of the TF disclosure policy, I'm still making changes to this in the light of new information, e.g. * The disclosure timeline is largely controlled by the reporter so we need some acknowledgement of that. * In some cases it may not be possible to release a fix to a restricted audience for export control reasons. Although the incident can be discussed among a restricted audience, the fix may have to be issued publicly. I can elaborate on this at the next TSC if needed. Regards Dan. From: TSC <tsc-bounces(a)lists.trustedfirmware.org> On Behalf Of Joakim Bech via TSC Sent: 07 January 2020 17:44 To: tsc(a)lists.trustedfirmware.org Subject: [TF-TSC] Project Zero disclosure policy updates Hi, I thought this was interesting enough to share it with you guys, especially since we've had this up for discussion a couple of times. https://googleprojectzero.blogspot.com/2020/01/policy-and-disclosure-2020-e… Regards, Joakim 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, 10 months

1
0
0 0

Project Zero disclosure policy updates

by Joakim Bech

Hi, I thought this was interesting enough to share it with you guys, especially since we've had this up for discussion a couple of times. https://googleprojectzero.blogspot.com/2020/01/policy-and-disclosure-2020-e… Regards, Joakim

5 years, 10 months

1
0
0 0

Trusted Firmware TSC 12th December - Minutes

by Bill Fletcher

Hi all, Here are the minutes for yesterday's TSC call. Please could you share any slides or other docs presented during the meeting to the list. Also, I was not able to capture the links posted into the Zoom chat. Please could you add them to the thread. Attendees Abhishek Pandit (Arm) Christian Daudt (Cypress) Dan Handley (Arm) David Brown (Linaro) Kevin Townsend (Linaro) Joakim Bech (Linaro) Mark Grosen (TI) Bill Mills (TI) Eric FInco (ST) Lionel Debieve (ST) Julius Werner (Google) Bill Fletcher (Linaro Community Projects) Notes AP: Let’s start the maintainers topic. (Christian Sharing slides) CD : Dan described what TF-A does and We can just go with TF-A option! CD, DB: There is different format to Kernel and github format DB: No parseability with file names. Should we just fix that? CD: See that people have merged things on TF-A where the maintainers list has not kept up DB: Could gerrit be updated from the maintainers file? DH: Don’t know what happened in the transition to git that adds people to reviews CD: In TF-A gerrit reviews, people who merged the code in are not listed in the maintainers file. DH: That’s not good. CD: No tooling to enforce any of this. DH: Will take an action to fix this.Not clear how to trigger a gerrit change based on this list. CD: Make sure that in TF-M something reads the list of +2ers and compares JW: Do we want to enforce touching every file? Could slow a lot down. Already have a problem with patches sitting around for too long. DB: That’s the difference with the GitHub rules - picks just one. With kernel rules - you get everyone. CD: When 3 people listed as maintainers for a file, means just one of them has to approve it. DB: If touch 5 files, does mean many maintainers involved. DH: Yes but not enforced CD: There are maintainers who oversee the whole tree. JW: Don’t think we need to enforce - force every maintainers to look at everything. CD: But why is that person a maintainer. DH: Maintainers choose when a patch has had enough reviews. Don’t have to do all the reviewing themselves. CD: Makes it hard when someone’s submitting a patch. Who decides to wait on a given maintainers? JW: Do it by time. If maintainer doesn’t respond in a few days and it doesn’t break anyting, put it in. JB: Is this really a big problem? It’s not a big project. Everyone knows everyone. CD: Agree let’s not overdo it. What agreement can we reach? AP: Format seems agreeable to most. Can check with the team what they are doing. Can come back if there’s already a solution in the works. CD: Expect TFM to grow to something like TFA. 30-50 reviewers listed. Let’s set how TFM evolves now. AP: Take an action item to check what’s going on. Coding Guidelnes (Mark G Sharing spreadsheet) AP: Seems we need access to the standards that Mark is talking about. Most should have access to MISRA. DB: It’s $15 MG: Most people should get access to MISRA C. 3 sources: Cert, JPL, MISRA. DB: This is a spreadsheet on Zephyr. Not implemented yet. MG: Variety of tools. TI using Clockwork. DH: We did a years worth of work trying to improve MISRA compliance. MG: If there’s a goal in mid to achieve compliance with an existing standard. A lot of overlap between MISRA and other areas. AP: Suggestion from Reinhard Keil is to stick just to MISRA. Need to nail it down. If do more than MISRA will spend more time. Need to put somerthing in place reasonably soon. DH: TFA treated MISRA as a quality improvement exercise. Big cost to commit to ongoing MISRA compliance. TFA is used in automotive. Have’nt made a statemeent. MG: With MISRA most important is to document what you’re doing. Can write waivers and deviations. DH: Get to where you want to and then maintain it at this point. Quite expensive. Tools are also expensive. MG: Can we add these rules to the Clang sanitizer? Then have an open source tool. Talked to TI team. Don’t understand the legalities about how it would be publishable. DH: TFA spreadsheet is available on public link. JB: Look where do we intend to use this code more than automotive. DH: Probably a never ending set of standards. Should start with all the opensource static analysers we can get. A lot is about undefined C behaviour. EF: Even outside automotiv, MISRA is being used. Agree we should find something where tooling is available. CD: More of a wish list than a hard requirement. Follow path of least resistance. What can we do with open source tools? Then need a specific requirement to go further. AP: This all started with rules about e.g. weak symbols. Dan gave some advice on this. Maybe we define one or two champions of coding standards and if there’s a conflict then they can step in and resolve it. We need a mechanism. CD: OK with that. Don’t want to go down any rabbit holes. AP: Anyone want to volunteer (now or later) Provisioning KT: Discussion in the Provisioning call centred around X.509 certificates. What would it take to get support into TF-M. Have put together some quick thoughts (and scripts) DB: Examples with defaults don’t generate valid certificates KT: Initial attestation service - want it to be a certificate chain. What are some of the missing requirements on TFM To enable that workflow? DB: Met with standards folks at Arm (Hannes, Brendan, +1). Also had a presentation from DataI I/O. Have started some implementation in mcuboot. Guessing it’s a bit heavyweight. Additional work to do. EF: The standard is for attestation tokens DB: RATS Working Group - EAT(S) KT: Several problems in supporting certificates. Have secure storage as an idea but should add some more plumbing for multiple private keys on secure side. DB: Will also need update mechanism. Expiring certificates - CSRs will happen. Not just initial provisioning. Wonder what people are using for the Subject field. Build Environment AP: cmd.exe is installed everywhere, or an alternative is some Zephyr mechanism. MG: Not sure would hold up Zephyr as a good Windows build example. CMake is only part of the problem. DB: There’s a lot of Python code in Zephyr for the build process. BM: Is there an open source project that would be a better model? MG: No good model. AP: Suggest just pick a method that works for a good number of users. TFM guys are going to update the documentation. DB: Amazon FreeRTOS supports the expected IDE for whatever platform you are building it for. Annoying if you want to work on multiple platforms. IDEs DB: Need the flow to be in the right direction. Not having the IDE driving. AP: We agreed we need to create some separate repo (CMSIS PAK etc). Will put on the agenda for January. -- [image: Linaro] <http://www.linaro.org/> *Bill Fletcher* | *Field Engineering* T: +44 7833 498336 <+44+7833+498336> bill.fletcher(a)linaro.org | Skype: billfletcher2020

5 years, 10 months

1
0
0 0

Re: [TF-TSC] adding maintainers to TF-M

by Sandrine Bailleux

Hi Christian, On 12/12/19 4:35 PM, Christian Daudt via TSC wrote: > On a separate topic, I'm looking through the TF-A recent merges, and it > seems that code makes it in 'master' without being merged through gerrit > (e.g. I can only find a merge into 'integration' in gerrit for the > lastest commit in > 'master': https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=ebff… https://review.trustedfirmware.org/q/I46b21573ed25a0ff222eac340e1e1fb93b040…). > Did I miss it or is the flow different than submitting to master in > gerrit for inclusion into TF-A? That's right. In TF-A, once a patch has been reviewed, 1. We first merge it into the integration branch through Gerrit. 2. Then the integration branch goes through some more automated testing overnight. 3. If no major problems are raised, we catch up the master branch with the integration branch. Right now, we do that manually from command line, i.e. not through Gerrit. This process is described here: https://trustedfirmware-a.readthedocs.io/en/latest/process/contributing.htm… I hope that helps. 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, 10 months

1
0
0 0

Re: [TF-TSC] TSC Agenda 12 Dec 2019

by Abhishek Pandit

For the agenda so far: * Adding maintainers and merge rights in TF-M * Coding guidelines * Update from the provisioning discussion Thanks, Abhishek From: TSC <tsc-bounces(a)lists.trustedfirmware.org> On Behalf Of Abhishek Pandit via TSC Sent: 09 December 2019 16:56 To: tsc(a)lists.trustedfirmware.org Subject: [TF-TSC] TSC Agenda 12 Dec 2019 Hi All, Any topics for this week's meeting? Thanks, Abhishek

5 years, 10 months

1
0
0 0

Re: [TF-TSC] adding maintainers to TF-M

by Dan Handley

Hi Christian Sorry I'm coming to this late but I have some feedback on your proposal: * I agree on the need for a TF-M maintainers file and following the Linux style. TF-A already does this and might be worth copying. https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/docs/about… * If the TF-A style doesn't work for TF-M then it would be good to figure out why and align both projects. * The TF-A "Main maintainers" are the ones with +2/merge rights. Other listed maintainers (i.e. sub-maintainers) are there just to show who to chase for code review; they only have +1 rights like everyone else. For TF-M, I'm open to the idea of giving all listed maintainers +2 rights as long as this doesn't give them merge rights! However, I'm sceptical on the value of this since the person merging will still need to check who has given +1/+2 before merging. Also, this could grow to a long list of people if TF-A is anything to go by, which could easily lead to abuse/confusion. * Regarding expanding the list of those with merge (or "Main maintainer") rights, I agree with Kumar that this should be a meritocracy. However, I don't think the TSC need to be involved in the first instance; this can be simply approved by existing "Main maintainers" via the public lists. I think the TSC only needs to get involved if someone wants to be a "Main maintainer" and the existing "Main maintainers" don't approve, or if someone objects to a new "Main maintainer" being added. Escalation to the board should be rare. * I don't think TF members should automatically get "Main maintainer" rights, although some TF members may be ready to be "Main maintainers" now (if approved by the existing TF-M "Main maintainers"). Regards Dan. From: TSC <tsc-bounces(a)lists.trustedfirmware.org> On Behalf Of Christian Daudt via TSC Sent: 19 November 2019 23:32 To: Kumar Gala <kumar.gala(a)linaro.org> Cc: tsc(a)lists.trustedfirmware.org Subject: Re: [TF-TSC] adding maintainers to TF-M > Kumar Gala wrote: > I guess the question is if we separate the review/approval role from the merging role. If that's the intent then I think we should define such roles. > > Maintainer: Reviews/approves code to merge > Merger: Merges code that has been approved, is aware of state of project if it makes sense to review (ie, if in a release window, might not make sense to merge code even if its approved). > > We are actually going through a similar discussion / process in the Zephyr project. Fair point. I'll update the proposal to separate the 2 as reviewer and merger roles. Any pointers to the Zephyr outcome that I can ... borrow ... from ? Thanks, csd 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. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

5 years, 10 months

2
1
0 0

Re: [TF-TSC] TSC Agenda 12 Dec 2019

by Joanna Farley

Hi Lionel, For this MTD framework RFC although there is no progression in Gerrit I see there has been some discussion on the TF-A ML https://lists.trustedfirmware.org/pipermail/tf-a/2019-November/000125.html . Apologies this seems to have stalled our side. We have a little bit of a patch backlog issue and we are working to unblock this will look to continue the discussion in Gerrit and the ML thread. This may well be January now so apologies on that as the patchset is quite significant. On the subject of TF-A feature dashboard I’m not aware of anything beyond the material Matteo shares periodically. We in the Arm TF-A Eng team have been trying to engage more on the TF-A ML by sharing designs for upcoming feature as RFC’s rather than just springing them as patchset reviews but today we don’t have a list of forthcoming RFC’s. I’m afraid as things look to be ready to our end we will share. A dashboard though sounds like a sensible thing as we can all track RFC’s submitted from ourselves and others. I’ll take an AI to set something up on the wiki in the first instance maybe as a table. It may need to wait though until January now. Any suggestions welcome on content and format. Thanks Joanna From: TSC <tsc-bounces(a)lists.trustedfirmware.org> on behalf of Lionel DEBIEVE via TSC <tsc(a)lists.trustedfirmware.org> Reply to: Lionel DEBIEVE <lionel.debieve(a)st.com> Date: Tuesday, 10 December 2019 at 15:24 To: "tsc(a)lists.trustedfirmware.org" <tsc(a)lists.trustedfirmware.org> Subject: Re: [TF-TSC] TSC Agenda 12 Dec 2019 Hi Abhishek, From a TF-A concern, I'm wondering to know if there is any feedback of a MTD framework already under review (till October). https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2284 I'd like also to know if there is a kind of dashboard about the feature development, I've seen that some encryption, key split that have been recently pushed. Is there any sharable dashboard on the feature development on going for TF-A? BR, Lionel On 12/9/19 5:56 PM, Abhishek Pandit via TSC wrote: Hi All, Any topics for this week’s meeting? Thanks, Abhishek IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

5 years, 10 months

2
2
0 0

Re: [TF-TSC] TSC Agenda 12 Dec 2019

by Grosen, Mark

Another possible topic is to review the Zephyr Code Guidelines spreadsheet. I got permission a snapshot of the spreadsheet to distribute to TSC members if I neutered the MISRAC text. I would rather not have it archived in the email list given the authors' concerns (and the banner in the spreadsheet). The sources for the guidelines are MISRA, JPL and CERT. Mark From: TSC [mailto:tsc-bounces@lists.trustedfirmware.org] On Behalf Of Abhishek Pandit via TSC Sent: Monday, December 9, 2019 8:56 AM To: tsc(a)lists.trustedfirmware.org Subject: [EXTERNAL] [TF-TSC] TSC Agenda 12 Dec 2019 Hi All, Any topics for this week's meeting? Thanks, Abhishek

5 years, 10 months

1
0
0 0

Re: [TF-TSC] TSC Agenda 12 Dec 2019

by Lionel DEBIEVE

Hi Abhishek, >From a TF-A concern, I'm wondering to know if there is any feedback of a MTD framework already under review (till October). https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2284 I'd like also to know if there is a kind of dashboard about the feature development, I've seen that some encryption, key split that have been recently pushed. Is there any sharable dashboard on the feature development on going for TF-A? BR, Lionel On 12/9/19 5:56 PM, Abhishek Pandit via TSC wrote: Hi All, Any topics for this week’s meeting? Thanks, Abhishek

5 years, 10 months

1
0
0 0

TSC Agenda 12 Dec 2019

by Abhishek Pandit

Hi All, Any topics for this week's meeting? Thanks, Abhishek

5 years, 10 months

1
0
0 0

Re: [TF-TSC] adding maintainers to TF-M

by Kumar Gala

> On Nov 18, 2019, at 5:36 PM, Christian Daudt via TSC <tsc(a)lists.trustedfirmware.org> wrote: > > Hi TSC, > As discussed in the last TSC meeting, we would like to add Cypress devs as platform maintainers for PSoC6 code in TF-M. Given that (afaik) we are the first non-ARM maintainer, I'd like to formalize the proposal. > --- > Proposal to enhance maintainership of trusted-firmware-m repository to allow additional approvers > > Step 1: Add a MAINTAINERS file to the root of the tf-m repository. This file will follow the same format as the linux kernel MAINTAINERS file, but will only support a subset of options. Exact subset TBD but likely 'M', 'L', 'S', 'F' options will be supported. This MAINTAINERS file will initially be populated with the current designated +2 devs as having maintainer status over the complete tree. It is assume that current devs are already being notified of gerrit reviews so they don't need that step. > > Step 2: All tsc representatives will be granted +2/merge permissions into trusted-firmware-m. Allowable uses of this +2 are as follows: > a) For gerrit reviews that exclusively involve changes to files+directories where the tsc rep's company is listed as maintainer in the MAINTAINERS file > b) For gerrit reviews that involve changes to files+directories where the tsc rep's company is listed as maintainer in the MAINTAINERS file + other changes: only once other maintainers have +1 their portions (i.e. once all maintainers have +1, any of the companies involved in the patch can +2/merge it). > Abuse of this privilege will be escalated to board for resolution. > > Step 3: on any patch that requires a change to maintainers (i.e. a new platform being added): > a) the patch will include an update to the MAINTAINERS file indicating it. > b) the maintainers will add themselves to get notifications from gerrit for appropriate subtrees. > > Responsibility of maintainers: > - Ensure MAINTAINERS file and your gerrit notifications are kept up-to-date > - Provide review in a timely fashion for any reviews that involve your subtree (preferably within a week) > - Notify your tsc rep once a review has sufficient approvals to be +2ed. > > > Let me know of any comments, concerns, issues. If there is agreement on the above, I'll outline the steps with more detail + examples (in phabricator possibly or as a documentation patch to the code itself). > > Thanks, > Christian. STEP 2/3: I don’t think TSC reps should be given this permission by default. I think the TSC should vote/approve any Maintainer. The reason for this is to have things be a meritocracy. The rules for approval w/regards to +1/+2 should be around MAINTAINERs regardless who they work for. I think at this point of the project that hopefully the TSC would approve a MAINTAINER proposed by a Silicon Vendor for the Silicon Vendor’s specific code. - k

5 years, 11 months

2
3
0 0

adding maintainers to TF-M

by Christian Daudt

Hi TSC, As discussed in the last TSC meeting, we would like to add Cypress devs as platform maintainers for PSoC6 code in TF-M. Given that (afaik) we are the first non-ARM maintainer, I'd like to formalize the proposal. --- Proposal to enhance maintainership of trusted-firmware-m repository to allow additional approvers Step 1: Add a MAINTAINERS file to the root of the tf-m repository. This file will follow the same format as the linux kernel MAINTAINERS file, but will only support a subset of options. Exact subset TBD but likely 'M', 'L', 'S', 'F' options will be supported. This MAINTAINERS file will initially be populated with the current designated +2 devs as having maintainer status over the complete tree. It is assume that current devs are already being notified of gerrit reviews so they don't need that step. Step 2: All tsc representatives will be granted +2/merge permissions into trusted-firmware-m. Allowable uses of this +2 are as follows: a) For gerrit reviews that exclusively involve changes to files+directories where the tsc rep's company is listed as maintainer in the MAINTAINERS file b) For gerrit reviews that involve changes to files+directories where the tsc rep's company is listed as maintainer in the MAINTAINERS file + other changes: only once other maintainers have +1 their portions (i.e. once all maintainers have +1, any of the companies involved in the patch can +2/merge it). Abuse of this privilege will be escalated to board for resolution. Step 3: on any patch that requires a change to maintainers (i.e. a new platform being added): a) the patch will include an update to the MAINTAINERS file indicating it. b) the maintainers will add themselves to get notifications from gerrit for appropriate subtrees. Responsibility of maintainers: - Ensure MAINTAINERS file and your gerrit notifications are kept up-to-date - Provide review in a timely fashion for any reviews that involve your subtree (preferably within a week) - Notify your tsc rep once a review has sufficient approvals to be +2ed. Let me know of any comments, concerns, issues. If there is agreement on the above, I'll outline the steps with more detail + examples (in phabricator possibly or as a documentation patch to the code itself). 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

1
0
0 0

Trusted Firmware TSC 14th November - Minutes

by Bill Fletcher

Attendees Abhishek Pandit (Arm) Christian Daudt (Cypress) Dan Handley (Arm) David Brown (Linaro) Kevin Townsend (Linaro) Joakim Bech (Linaro) Mark Grosen (TI) Julius Werner (Google) Bill Fletcher (Linaro Community Projects) Notes Provisioning. This is now running as a separate meeting, hopefully you have received the invite for that. We can have a quick summary of the status. DB: SDO spec is a good option for device provisioning. Having a solution where we can store private keys and signatures - may not work with smallest devices as signatures are big. There is work on a more compact representation. AP: SDO has relationship to multiple domain signing. We could add more specifics on this from Arm. DB: Having a separate meeting is reasonable. AP: Maybe you could send an email to people setting expectations. Could just open the meeting to everyone. DB: Don’t see a problem to be open. CD: Is the aim to come up with a provisioning flow agnostic to TF-M and TF-A DB: Don’t think so - aim is to see the implications for TF-M. At the moment need to build a separate binary for each device. Some approach for provisioning. Then for public key need to load into each device or have it signed so know which device to trust. Need to know what more is needed from TF-M. e.g. key needs to be updatable for ‘device onboarding’ step. CD: Trying to see where requirements coming from and what activity is trying satisfy and what activity is creating requirements. DB: Don’t see is influencing SDO. How much insight do you get on provisioning from people who buy devices? CD: A lot. Have our own private flows. Understanding what we’re trying to standardise would be useful - whether it fits with our models. (discussion handed off to specific meeting) TF-M coding standard. Following up from the mailing list thread about weak symbols. AP: Had an email discussion - Chris saying there’s an on-the-fly coding standard discussion on his patch. Dan was on the discussion - using weak symbols. Caused retrospective pain if going for MISRA compliance. Maybe it’s time we look at industry standards we want to meet. DB: Is the concern with MISRA - extensions? DH: Yes. Some weak symbols fail when run through checkers. Mandatory/required etc rules. MG: We’ve been going through MISRA. Customers - if you justify deviations and waivers they don’t have an issue if consistent. Document why. How do we want to set our coding standards - CERT, JPL …? Don’t do on an ad hoc basis. AP: How do we enforce it. Depoy in CI. MG: First step to document expectations. Tools will do better but do it right first time. DB: Have existing body of code - tools would be informative. MG: Start and say mandatory and required. Not look at 10,000s of ‘advisories’. Use Clockwork internally. AP: Who would do the initial proposal. Volunteer engineer? MG: Do we have any overall standards-based goals we want to be aiming for. Formal requirements, traceability? AP: Safety and security. How to take it forward? CD: Ad hoc at this point. Don’t have a grand plan. If someone wants to propose a specific standard with a reason. Can have a vote on it. Don’t want to spend weeks and months. Let’s go case by case. MG: Would always start from existing place - Zephyr going through it for safety. There is a first draft. AP: Post something on TSC mailing list? MG: Propose look at what Zephyr’s doing https://docs.zephyrproject.org/latest/contribute/index.html#coding-style MG: There’s a new spec that isn’t public. Can take the action to look at how to get that. CD: Been caught for weeks now with reviews. Nobody +2 code reviews. DH: Made rule you’re only allowed 1 definition of a week symbol. Enabling IDE support for TF-M. This topic was raised in the workshop in Lyon. I would like to summarize and discuss possible options, next steps etc. AP: Raised in Lyon. Tool needs to be accessible to everyone. Arm’s CMSIS team attended. DB: CMSIS packs proposed as definition. Other people proposed CMake file that generated CMSIS packs. AP: Need someone to take this discussion forward. Let someone take it forward DB: Is CMSIS pack format public. AP: Yes public MG: Prefer open tools so CMake, Devicetree. If you want to generate CMSIS Zone can do that. Generating manifests etc - not sure how that’s going to work with IDEs. Want to keep it general. Not a fan of specific tools. CD: Second that. DB: So summarize - support CMSIS Pack and Zone by generating from e.g. Devicetree or CMake as a source of truth. AP: Someone would need to maintain the generation. DB: Suggest CMake files are checked in. AP: Should we allow a separate git to be created for CMSIS Pack and CMSIS zone? MG: Developers are all Linux people, even if the users are mainly Windows players. Like the idea of a separate utilities repo. Adding +2 reviewers for subtrees in TF-M. CD: The requirement is be clear how we’re going to add new approvers. How to add a couple of approvers. AP: Take the contribution of the platform - how to ensure platforms all move along. How to manage non compatible changes. Platform owners - companies nominate. CD: Two separate topics. TF-A has a process. Send a patch where you add yourself to the file for the maintainer list. If that patch is accepted, then you’re a maintainer for the subsystem. What do we want the process to be? CD: Then can tell people to look at the maintainer list. Can send an email stating the process. How does the +2 rights get added? AP: With core maintainers who are currently Arm only. CD: Fine for me to put the onus on the Arm maintainers as long as there isn’t a time lag. AP: Option can have TSC approve it. Reminder for TF-M Tech forum open call (5th December) -- [image: Linaro] <http://www.linaro.org/> *Bill Fletcher* | *Field Engineering* T: +44 7833 498336 <+44+7833+498336> bill.fletcher(a)linaro.org | Skype: billfletcher2020

5 years, 11 months

1
0
0 0

TF-M build system & tools discussion

by Abhishek Pandit

All, We had a specific topic in TF-M workshop on build system and tooling. The attached slides were presented to guide the discussion. This was an open discussion lasting about an hour and many attendees provided inputs and feedback on the topics. I plan to follow up in the TSC meetings and have added IDE topic to this week's meeting agenda. Just circulating the slides to help the discussion. Thanks Abhishek

5 years, 11 months

1
0
0 0

TSC Agenda 14 Nov 2019

by Abhishek Pandit

Hi All, Any agenda items for this week? I have following on my list * Provisioning. This is now running as a separate meeting, hopefully you have received invite for that. We can have a quick summary of the status. * TF-M coding standard. Following up from the mailing list thread about weak symbols. * Enabling IDE support for TF-M. This topic was raised in the workshop in Lyon. I would like to summarize and discuss possible options, next steps etc. Thanks, Abhishek

5 years, 11 months

1
1
0 0

Trusted Firmware TSC 10th October - Minutes

by Bill Fletcher

Attendees Abhishek Pandit (Arm) Christian Daudt (Cypress) Dan Handley (Arm) David Brown (Linaro) Kevin Townsend (Linaro) Joakim Bech (Linaro) Eric Finco (ST) Mark Grosen (TI) Bill Mills (TI) Bill Fletcher (Linaro Community Projects) Agenda CNA training Provisioning ELC TF-M workshop in Lyon Git process flow OP-TEE git update Notes DB: CNA training? CVE Numbering Authorities. Able to assign CVEs in blocks of 10 without going through a minder. No charge. Same amount of time as we should be spending on CVEs anyway. JB/DH: Think it’s a good idea. DH: Would like to establish who is on the security mailing lists. JB: Have had bad experience working through Mitre. CD: To clarify this the scope is TF-A, TF-M, OP-TEE DB: Yes. CD: Not much purpose to get CVEs if we don’t have anyone to do anything on them. DB: CF Zephyr … DH: Will send email to allow people to formally sign off on this DB: I would like to have a discussion about provisioning. Right now, it seems that the only way we specify a device identifying itself is by giving its public key, which would require that every device to be provisioned be entered into some kind of database before it could be known. Instead I'd like to propose that we have a way of storing and retrieving an X.509 certificate, which would have that public key in it, along with a signature chain that could be used to indicate that this device is trusted. This is commonly done in deployed devices, and we might as well add this functionality now. AP: Had proposed a provisioning-specific slot, but no one registered interest. Will still schedule this. DB: Have defined attestation token signed with a private key internal to device. There is also a public key. If only this, it has to be known by the entity on the other side to know a valid device. Preferred approach is a certificate - that public key signed by an authority. https://github.com/microbuilder/zephyr/blob/tfm-psa-level-1/samples/tfm_int… Need to “get a certificate” … is this a trusted device? DB: Different to e.g. MQTT using a TLS certificate. Need to be flexible allowing a public key registration. KT: How to know if a device should be joining the network with just public key. DB: Unless a channel from the factory with a list of trusted devices. DB: May also need a mechanism to update these keys BM: Overlap with Intel? JB: Yes. Pelion was the collaboration between Intel and Arm BM: Think the base concept was simpler. JB: Talk to Reed Hinkel about the LEDGE presentation session on this. EF: Got it through the mailing list of LEDGE. AP: Would like to do this as a provisioning subgroup and then ask the TSC if they want to proceed. Happy for David or Kevin to lead the discussion. CD: Shall we see if can have a similar discussion to the one we had at Connect JB: Can ask Francois or Reed to see if they can help us. AP: If you know someone who is interested, we should extend to wider than TSC. Will schedule the meeting. MG: https://www.intel.com/content/dam/www/public/us/en/documents/idz/iot/briefs… AP: TF-M workshop in Lyon after ELC. Will discuss the outcomes at next TSC. MG: Git flow. How to know when it’s a good time to integrate with the TF-M workflow. Aren’t many tags etc. Have tried with some issues. Are there engineering builds, alpha builds? AP: Can take guidance as TF-A which is more mature. Need to decide if 6 monthly test cycle as TF-A. Need solid branches to base work on. Dual core work ongoing on a branch. Posted requests for review but there were no reviews. Has been no drive to fix the methodology yet. AP: CI running but it’s problematic with MPS2 at the moment. CD: But no formal cycles yet AP: Arm stretched to support the feature requests at the moment. Will talk to Shebu to structure the roadmap in order to have something stable. JB: Forked OP-TEE gits are now at git.trustedfirmware.org -- [image: Linaro] <http://www.linaro.org/> *Bill Fletcher* | *Field Engineering* T: +44 7833 498336 <+44+7833+498336> bill.fletcher(a)linaro.org | Skype: billfletcher2020

6 years

1
0
0 0

Re: [TF-TSC] TSC Agenda 10 Oct 2019

by David Brown

I would like to have a discussion about provisioning. Right now, it seems that the only way we specify a device identifying itself is by giving its public key, which would require that every device to be provisioned be entered into some kind of database before it could be known. Instead I'd like to propose that we have a way of storing and retrieving an X.509 certificate, which would have that public key in it, along with a signature chain that could be used to indicate that this device is trusted. This is commonly done in deployed devices, and we might as well add this functionality now. David On Tue, Oct 8, 2019 at 5:00 PM Abhishek Pandit via TSC < tsc(a)lists.trustedfirmware.org> wrote: > Hi All, > > > > Any agenda items for the meeting this week? > > > > Thanks, > > Abhishek > -- > TSC mailing list > TSC(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tsc >

6 years

2
1
0 0

TSC Agenda 10 Oct 2019

by Abhishek Pandit

Hi All, Any agenda items for the meeting this week? Thanks, Abhishek

6 years

1
0
0 0

Trusted Firmware TSC 12th September - Minutes

by Bill Fletcher

Attendees Abhishek Pandit (Arm) Chris (Cypress) Ray Ngun (Cypress) Christian Daudt (Cypress) Dan Handley (Arm) David Brown (Linaro) Joakim Bech (Linaro) Julius Werner (Google) Lionel Debieve (ST) Rajeev Gulati (Data I/O) Bill Fletcher (Linaro Community Projects) Notes Ray: Cypress TF M enablement on PSoC6 dual core (slides circulated separately) Chris: PSoC as SMPUs based on v6/v7 ones. Has alignment/size constraints. Difficult to arrange 1M flash to manage protection regions. Much easier with the v8. Build system work complicated. AP: Getting feedback on build system elsewhere. Not sure if it is CMake. What’s your view? Chris: CMake isn’t particularly intuitive. Building secure side veneers - had to figure out to separate those out. AP: V8m crashes are hard to debug. Maybe worth having a focus group on build system. CD: Implicit assumptin that secure and non-secure are the same ilk and not the case for PSoC6. Does not have the same facilities/options. AP: Assumed secured binary comes from one entity and non-secure from another. That’s how it evolved. Secure people give config and API. Agreed it’s very v8m centric. CD: Patches should fix that AP: Will follow up on why the patches are still pending. Rajeev: Data I/O Security provisioning (slides circulated separately) AP: Need to have a follow up task on this. This is just a prelude to what the TF teams need to do in this area. Rajeev: We can talk about the provisioning usecases next time. Joakim: OP-TEE Pending actions for creating branches for TF gerrit. Not done but have a clear idea after talking to Dan Linking TF.org to OP-TEE.org done one way. Plan to fix the other way with a sit down with Web Admin at Connect. Security sessions at Connect http://bit.ly/san19swg They will be added to the public schedule (WIP) Linaro has PoR (Plan of Record) process to say what work is done. Too early to say what this will mean but things that are expected to continue: - Keymaster work. Will look at new features in keymaster4. - Prototyping work on Armv8 virtualisation. - PKCS11. - Widevine work DH: Expecting that a lot of work will be followed up at Connect. AP: When will incident handling be finalised? DH: Not received any comments for a while. Also need steps to make it active. Which projects will use it? Can spend some time to nail it down at Connect. Then look to make it active. -- [image: Linaro] <http://www.linaro.org/> *Bill Fletcher* | *Field Engineering* T: +44 7833 498336 <+44+7833+498336> bill.fletcher(a)linaro.org | Skype: billfletcher2020

6 years, 1 month

1
0
0 0

TSC Agenda 12 Sep 2019

by Abhishek Pandit

Hi All, Any agenda items? We have following at present: * Update on Twin CPU enablement work in TF-M (Chris Brand, Cypress) * Secure provisioning discussion (Data I/O) Thanks, Abhishek

6 years, 1 month

1
0
0 0

Overview of being a CVE CNA

by David Brown

This screencast goes through the process I used to manage a CVE as part of being the CNA for the Zephyr project. Not all of the links will be accessible, but this should give a rough idea of the kind of work involved in being a CNA. https://www.youtube.com/watch?v=PksNzJXVDDA David

6 years, 2 months

1
0
0 0

Trusted Firmware TSC 8th August Minutes

by Bill Fletcher

Attendees AbhishekP - Arm DanH - Arm DavidB - Linaro MarkG - TI JoakimB - Linaro OP-TEE ChristianD - Cypress JuliusW - Google KumarG - Linaro LITE KevinT - Linaro LITE BillF - Linaro Community Projects Agenda OP-TEE How to add more maintainers AOB Notes: OP-TEE (Joakim’s slides) BF: OP-TEE now visible via trustedfirmware.org DH: No links to code etc BF: Yes, just a first step that we can reference in any press release/blog post. It links back to the main material at op-tee.org JB: Have cleaned up op-tee.org content and not a big job to move it to trustedfirmware.org JB: Certifications. Should now revisit. However - there are many - need to figure out what to spend the money on. CD: Don’t certify in a vacuum JB: Yes - video, payment ... DH: … common criteria, safety. Generally need to certify a product, but helps if know what you’re aiming for. JB: Previously aimed at GC test suite that benefits everyone. DB: FIPS certification AP: At Arm have often focussed on ‘certifiable’ rather than certified. JB: Sounds sane AP: A lot of certifications have some common stuff - e.g. basic MISRA, some threat model, lifecycle. JB: If you clone the git repo you’ll get a test suite - xtest. You will not get anything from GlobalPlatform. You can include it but you have to be a member or buy it. It’s $6000 and includes support for 2 years. In Linaro we have relied on member’s access to use the test suite. DH: Code audits are good but take a hit - need to have all requirements in place first like incident handling and lifecycle. They are expensive. DH: For vulnerability reporting, have discussed increasing embargo period & especially sensitive stakeholders. DB: Zephyr is now a CNA. Organisation has to be a CNA but in the scope of particular project(s). We’re receiving CVEs for the Zephyr project. It might make sense for TF to become one. DH: Process supposed to use for OSS doesn’t seem to work at all. DB: End up going to the CNA of last resort. Much more responsive to CNAs than random projects. JB: tf.org/security should go to the various security centres and this policy that we’re trying to approve. Action DH to give BF an outline of what should be on the security front page JB: Any interest on TF TSC that I present the plan for the coming cycle? Action: JB to check with Mark Orvek if ok to share the OP-TEE information from the project heathcheck. CD: Generally take same approach as TF-A and TF-M. Share the information but TF TSC not to be a bottleneck and have to ‘approve’. If there’s a specific issue can discuss it at TSC. DH: For the fork, we’d be trying to keep up with op-tee master and submit back through the op-tee process. Don’t want to run on a branch for the long term. DH: Encrypted TEEs. Has always been a provision for encrypted TA’s. Architecture allows for it but have had no strong pull for implementing it. JB: Tricky part is key management DH: May be a requirement on TF-A to help here. JB: Haven’t really planned on this but seeing requirements. No requirements from PSA? DH: no - the requirements are on authentication, not encryption. DH: (Next steps) Expand the list of acceptable licenses. AP: (Documenting answers and decisions) Both TF projects are using Phabricator. Action: JB to contact Ben and try out the Phabricator sandbox. DH: Anything holding back to setup an op-tee project in gerrit? JB: Have an action to talk to Ben about setting that up Maintainers AP: Looking at ways to expand maintainers list since have gaps during vacation period JB: Where is the list? AP: Keep the maintainer list in gerrit AP: Ask other members to talk about non-confidential items. If there are external companies - maintainers should be able to invite them to attend. Action: BF to add link to review.trustedfirmware.org to Nav bar DB: If I go to developer.trustedfirmware.org and click on https://developer.trustedfirmware.org/project/ only see TF-A. CD: Seems that project takes the first query https://developer.trustedfirmware.org/project/query/edit/. Can an administrator change the order of the queries? Action: Move the usability discussion to the mailing list since there are people actively working on Phabricator. Attendance: DH: (In response to KT) anyone should be able to join as long as we know who they are from a member company. When it comes to voting that’s specific to reps. AP: If someone additional invited announce it at the start of the meeting. Date for the next meeting? AP: 12th Sept. -- [image: Linaro] <http://www.linaro.org/> *Bill Fletcher* | *Field Engineering* T: +44 7833 498336 <+44+7833+498336> bill.fletcher(a)linaro.org | Skype: billfletcher2020

6 years, 2 months

1
0
0 0

TSC Agenda 08 Aug 2019

by Abhishek Pandit

Hi All, We already have one topic: * OP-TEE update (Joakim) Any other agenda items? Thanks, Abhishek

6 years, 2 months

1
0
0 0

Re: [TF-TSC] tf.org security incident handling process (v0.3)

by Dan Handley

Hi Joakim Thanks for reviewing. Some further comments below. > From: Joakim Bech <joakim.bech(a)linaro.org> > Sent: 11 July 2019 13:11 > To: Dan Handley <Dan.Handley(a)arm.com> > Cc: tsc(a)lists.trustedfirmware.org > Subject: Re: [TF-TSC] tf.org security incident handling process (v0.3) > > Hi Dan and TF reps, > > Thanks for putting this together Dan. I like it and it's pretty short and > concise. Nothing big from me, but please find a few comments from me inline > below. > >> On Wed, 10 Jul 2019 at 18:35, Dan Handley via TSC >> <mailto:tsc@lists.trustedfirmware.org> wrote: >> Hi TF TSC >> >> This is a v0.3 update to the proposed http://tf.org security incident >> handling process, which I sent previously, incorporating the comments I've >> had since then. >> <snip> >> >> If you would like replies to be encrypted, please provide your public key. >> Please note the Trusted Firmware security team cannot guarantee that >> encrypted information will remain encrypted when shared with trusted third >> parties. >> >> [DH: Is this acceptable? It allows reporters to use encryption without adding >> too much admin burden on the security team. The alternative is to force >> everyone receiving embargoed information to provide an encryption key and >> decrypt/re-encrypt as information is passed around. I think this adds too >> much overhead without significant security benefit.] > [JB: I do think this is the right level of dealing with this. The > communication with the one reporting the issue can (optionally) be encrypted, > but for sharing between members of the security team I think it's easier to > use things like LDAP protections, Google docs, GitHub private security > advisories (https://help.github.com/en/articles/collaborating-in-a-temporary- > private-fork-to-resolve-a-security-vulnerability) etc.] > I'm glad we're in agreement. I hadn't seen that GitHub security advisory support before - thanks! <snip> >> 3. After the primary embargo period, the fix and relevant vulnerability >> information are shared with registered Trusted Stakeholders (see below >> section). Fix release may be deferred further if a Trusted Stakeholder >> requests it within 1 working day (Monday to Friday) of being notified, > [JB: One day is not much time, there is a chance that people on the receiving > end misses this for both good and bad reasons. However, I don't know how many > days that would be sufficient. In the end these kind of things require some > discipline and extra efforts from both sides.] > I think you're right this is a bit too aggressive. The window for requesting the primary embargo period is extremely short because we expect ESS security teams to operate 24/7 and we want to minimise the delay in proceeding to the next stage when ESSes are unaffected. But Trusted Stakeholders may need more time. We don't want to unnecessarily delay release of fixes but increasing this window a bit is unlikely to cause a problem in practice: If there is no primary embargo period it's likely we'll need at least a few days to prepare a fix anyway; if there is a primary embargo period, it's likely we'll need a secondary embargo period as well. How about making this window 3 working days? <snip> >> [DH: Note, this aggressive release of security fixes is aligned with the >> kernel process. The existing TF-A process allows for early release of fixes, >> which we generally do in practice, but that process doesn't really specify a >> fix embargo period. However it does specify a 4 week embargo on the >> subsequent security advisory. Also note that OP-TEE's fix embargo period is >> 90 days, which is aligned with Google's policy.] > [JB: Right, our initial OP-TEE embargo period was much shorter, but after > getting feedback from our members it was clear that they preferred a longer > embargo, which was the reason we went back to 90 days. Did we end up asking > other people? TF members? Companies that we know are using TF-A/M?] Sorry, I haven't sought any wider feedback. This is purely based on the Google and OP-TEE policies, which I (and I think TF-A partners would) find reasonable. Given that the fixes are made much earlier, I don't see anyone objecting to this longer advisory embargo, except perhaps some reporters. >> 4. After the fix is released, details of the security vulnerability are >> consolidated into a security advisory. This includes a CVE number and the >> security team will request one if not already done by the reporter. It also >> includes credit to the reporter unless they indicate otherwise. Drafts of the >> security advisory are circulated with the reporter, ESSes and Trusted >> Stakeholders as they become available. > [JB: Do we want to have our own numbering schema also? If we believe _all_ > issues will get a CVE number then it's not needed. But if there are issues > that for whatever reasons wouldn't get a CVE, then it's quite useful to have > some internal numbering system. Out of experience, I know that it can become > quite messy if you get a report containing lots of potential security issues. > Having an internal number to use in commits etc has been proven to be quite > useful.] > Yes, I do expect to have our own numbering scheme for the reasons you state. I thought this could be covered by a supplementary internal process, which we could create after this external process is approved. Let me know if you think we should say something here instead. >> 5. 90 days after the vulnerability was reported, the security advisory is >> made public at https://www.trustedfirmware.org/. This 90 day window is the >> public embargo period. >> >> [DH: This public embargo period aligns with Google and OP-TEE processes, >> although this proposal releases fixes earlier.] >> >> In exceptionally rare cases, the above disclosure plan may be extended in >> consultation with the reporter, ESSes and Trusted Stakeholders, for example >> if it is very difficult to develop or deploy a fix, or wider industry >> consultation is needed. >> >> [DH: I'm accommodating for the Spectre/Meltdown case here] >> > [JB: So, is it fair to write the complete timeline as Fast case > | Report given to TF: <X days> | <X days + 1>: first embargo | <+ 1 > | day>: second embargo | <+ 90>: public security advisory | > i.e "X days + 1 + 1 + 90 = X days + 92" > > "Worst" case (mentioned in your attached PDF) > | Report given to TF: <X days> | <X days + 14>: first embargo | <+ 14 > | day>: second embargo | <+ 90>: public security advisory | > i.e "X days + 14 + 14 + 90" = X days + 118 > > Or are the dates running in parallel so to say? Example: public advisory is > always X days + 90?] > The latter! It should always be X days + 90. The above says "90 days after the vulnerability was reported". Let me know if I can make this clearer somehow. <snip> >> Note, the security team reserves the right to deny registration or revoke >> membership to the Trusted Stakeholders list, for example if it has concerns >> about the confidentiality of embargoed information. > [JB: Only stakeholders list? What about ESS list?] > OK, I'll include that too. >> [DH: Note, I've not included severity scoring in this proposal, as I think >> the only value of a score is helping to determine whether a bug is a security >> vulnerability or not, which in the end has a subjective element. I'm open to >> the idea of adding this to the process but I'd prefer it to be optional and >> aligned with CVSSv3 as used by CVE.] > [JB: Agree and regarding the process I'm quite open to have a look at CVSSv3. > The current OP-TEE process is better than the first one, but it's still a bit > rough around the edges. If CVSSv3 works for TF-A/M, then I'll probably also > work for OP-TEE. Also, something that I've been missing when doing work like > this is an internal process also. But that's definitely out of scope for this > discussion.] > OK but the process currently doesn't say anything about scoring. I guess we can look at CVSv3 later if there's a need. I agree we will need internal process documentation as well but that can be worked through later. I can ask the current TF-A security team to help with this. Regards Dan. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

6 years, 3 months

1
0
0 0

Trusted Firmware TSC 11th July Minutes

by Bill Fletcher

Attendees AbhishekP - Arm DanH - Arm DavidB - Linaro MarkG - TI ChristianD - Cypress JuliusW - Google LionelD - ST BillF - Linaro Community Projects Agenda Pending action items Round table Notes Pending actions: Bill to find out about cost of internal Sphinx hosting Gerrit hooks topic was clarified separately BF: Cost of Sphinx hosting will be more than readthedocs ad-free but certainly possible AP: Proposal to go ahead with readthedocs hosting for now and add a link from the website No objections in the call. BF: Will also re-look at Sphinx with TF-A CI ongoing work. CD: Top 2 Engineering topics would be a good input to the agenda - bring it into the forum - ongoing ‘topic du jour’. DH: Is it for knowledge sharing? Not sure TSC is for design review. CD: Bit of both. Information input and where people raise flags/concerns.Might not be discussed here but could be separate meetings. DH: Design reviews should be happening in a public design list. AP: Are only few open design discussions DH: Bigger problem in TF-A than TF-M AP: In TF-M there are some discussions happening on the mailing list AP: Do you think some of the partner engineers would join design review calls? CD: Yes - hence kick off to a separate call from the TSC discussion BF: Topic for next meeting could be OP-TEE since the vote has been passed by the Board. Need to make sure Joakim could make it. DB: Getting close to TF-M bootloader upstreaming JW: Should we pro-actively cancel if we don’t have items BF: Will mail the day before to give the option to cancel in future LD: Open Source Firmware - sponsoring that event. Any plans? DH: Matteo has had a session accepted BF: Also we will have a table and some promotion material AP: Next meeting proposed to be 8th August -- [image: Linaro] <http://www.linaro.org/> *Bill Fletcher* | *Field Engineering* T: +44 7833 498336 <+44+7833+498336> bill.fletcher(a)linaro.org | Skype: billfletcher2020

6 years, 3 months

1
0
0 0

Re: [TF-TSC] tf.org security incident handling process (v0.3)

by Joakim Bech

Hi Dan and TF reps, Thanks for putting this together Dan. I like it and it's pretty short and concise. Nothing big from me, but please find a few comments from me inline below. On Wed, 10 Jul 2019 at 18:35, Dan Handley via TSC < tsc(a)lists.trustedfirmware.org> wrote: > Hi TF TSC > > This is a v0.3 update to the proposed tf.org security incident handling > process, which I sent previously, incorporating the comments I've had since > then. > > Changes: > * Changed ESS 1 day response window to be from date of notification, not > from date of fix availability. > * Restored the 7 days embargo limit with 14 days in exceptional cases, to > align with kernel process. > * Explicitly stated that it is permitted to point others to a public > vulnerability fix during an embargo period, as long as this is not > identified as a vulnerability. > > I propose that the deadline for feedback is the end of next week (19th > July), with a view to approving the process at the August TSC meeting. We > can discuss this more at tomorrow's TSC meeting. > > Regards > > Dan. > > --- > > This security incident handling process proposal is broadly based on the > kernel process [1], with influence from the existing TF-A [2] and OP-TEE > [3] processes. > > [DH: Note the contrast with the kernel process: mailto:security@kernel.org > is exclusively about fixing the vulnerability; disclosure is delegated to > mailto:linux-distros@vs.openwall.org [4]. This proposal combines these > activities.] > > Reporting > ========= > If you think you have found a security vulnerability, then please send an > email to the Trusted Firmware security team at mailto: > security(a)trustedfirmware.org. This is a private team of security officers > who will help verify the security vulnerability, develop and release a fix, > and disclose the vulnerability details responsibly. Please give us time to > implement the disclosure plan described in the next section before going > public. We do our best to respond and fix any issues as soon as possible. > > As with any bug, the more information you provide, the easier it is to > diagnose and fix. If you already have a fix, please include it with your > report, as that can speed up the process considerably. Any exploit code is > very helpful. The security team may bring in extra help from area > maintainers to understand and fix the vulnerability. The security team may > share any information you provide with trusted third parties and eventually > the public unless you request otherwise. > > [DH: Note, mailto:security@kernel.org provides stronger confidentiality > guarantees because it is only interested in fixes, not disclosure. In > practice, I'd expect members of the security team to be sensitive with > confidential information as with any other open source interactions, and to > get explicit approval from the reporter for disclosure of sensitive > information, e.g. identity, organization, product information,...] > > You may use this PGP/GPG key [insert link] for encrypting the > vulnerability information. This key is also available at > http://keyserver.pgp.com and LDAP port 389 of the same server. The > fingerprint for this key is: > > [Insert Fingerprint] > > If you would like replies to be encrypted, please provide your public key. > Please note the Trusted Firmware security team cannot guarantee that > encrypted information will remain encrypted when shared with trusted third > parties. > > [DH: Is this acceptable? It allows reporters to use encryption without > adding too much admin burden on the security team. The alternative is to > force everyone receiving embargoed information to provide an encryption key > and decrypt/re-encrypt as information is passed around. I think this adds > too much overhead without significant security benefit.] > [JB: I do think this is the right level of dealing with this. The communication with the one reporting the issue can (optionally) be encrypted, but for sharing between members of the security team I think it's easier to use things like LDAP protections, Google docs, GitHub private security advisories ( https://help.github.com/en/articles/collaborating-in-a-temporary-private-fo…) etc.] > > If the security team consider the bug not to be a security vulnerability, > you will be informed and the bug directed to the standard bug fixing > process. > > > Disclosure > ========== > The general security vulnerability disclosure plan is as follows: > > 1. For confirmed security vulnerabilities, develop a robust fix as soon as > possible. During this time, information is only shared with the reporter, > those needed to develop the fix and Especially Sensitive Stakeholders > (ESSes). See the "ESS and Trusted Stakeholder registration" section below > for more information about ESSes. > > 2. After a robust fix becomes available, our preference is to publicly > release it as soon as possible. This will automatically happen if the > vulnerability is already publicly known. However, release may be deferred > if the reporter or an ESS requests it within 1 calendar day of being > notified, and the security team agree the criticality of the vulnerability > requires more time. The requested deferral period should be as short as > possible, up to 7 calendar days after the fix becomes available, with an > exceptional extension to 14 calendar days. The only valid reason for > release deferral is to accommodate deployment of the fix by ESSes. If it is > immediately clear that ESSes are unaffected by the vulnerability then this > stage is skipped. This 0-14 day deferral is the primary embargo period. > > [DH: Note, this stage is only relevant for TF-A currently.] > > [DH: Note, this assumes that ESS security teams operate 7 days a week.] > > 3. After the primary embargo period, the fix and relevant vulnerability > information are shared with registered Trusted Stakeholders (see below > section). Fix release may be deferred further if a Trusted Stakeholder > requests it within 1 working day (Monday to Friday) of being notified, [JB: One day is not much time, there is a chance that people on the receiving end misses this for both good and bad reasons. However, I don't know how many days that would be sufficient. In the end these kind of things require some discipline and extra efforts from both sides.] > and the security team agree the criticality of the vulnerability requires > more time. The requested deferral period should be as short as possible, up > to 7 calendar days after the Trusted Stakeholder is notified, with an > exceptional extension to 14 days. The only valid reason for further release > deferral is to accommodate deployment of the fix by a Trusted Stakeholder. > This further 1-14 day deferral is the secondary embargo period. > > Note, security fixes contain the minimum information required to fix the > bug. The accompanying vulnerability details are disclosed later. > > [DH: Note, the Trusted Stakeholder required response time is slightly > relaxed compared to the ESS response time; 1 working day as oppose to 1 > calendar day.] > > [DH: Note, this aggressive release of security fixes is aligned with the > kernel process. The existing TF-A process allows for early release of > fixes, which we generally do in practice, but that process doesn't really > specify a fix embargo period. However it does specify a 4 week embargo on > the subsequent security advisory. Also note that OP-TEE's fix embargo > period is 90 days, which is aligned with Google's policy.] > [JB: Right, our initial OP-TEE embargo period was much shorter, but after getting feedback from our members it was clear that they preferred a longer embargo, which was the reason we went back to 90 days. Did we end up asking other people? TF members? Companies that we know are using TF-A/M?] > > 4. After the fix is released, details of the security vulnerability are > consolidated into a security advisory. This includes a CVE number and the > security team will request one if not already done by the reporter. It also > includes credit to the reporter unless they indicate otherwise. Drafts of > the security advisory are circulated with the reporter, ESSes and Trusted > Stakeholders as they become available. > [JB: Do we want to have our own numbering schema also? If we believe _all_ issues will get a CVE number then it's not needed. But if there are issues that for whatever reasons wouldn't get a CVE, then it's quite useful to have some internal numbering system. Out of experience, I know that it can become quite messy if you get a report containing lots of potential security issues. Having an internal number to use in commits etc has been proven to be quite useful.] > > [DH: Note, the existing TF-A process only shares information with Trusted > Stakeholders in the form of security advisories. This proposal is more > aligned with the kernel process and means we can focus on fix development > by sharing raw vulnerability information in the early stages.] > > 5. 90 days after the vulnerability was reported, the security advisory is > made public at https://www.trustedfirmware.org/. This 90 day window is > the public embargo period. > > [DH: This public embargo period aligns with Google and OP-TEE processes, > although this proposal releases fixes earlier.] > > In exceptionally rare cases, the above disclosure plan may be extended in > consultation with the reporter, ESSes and Trusted Stakeholders, for example > if it is very difficult to develop or deploy a fix, or wider industry > consultation is needed. > > [DH: I'm accommodating for the Spectre/Meltdown case here] [JB: So, is it fair to write the complete timeline as Fast case | Report given to TF: <X days> | <X days + 1>: first embargo | <+ 1 day>: second embargo | <+ 90>: public security advisory | i.e "X days + 1 + 1 + 90 = X days + 92" "Worst" case (mentioned in your attached PDF) | Report given to TF: <X days> | <X days + 14>: first embargo | <+ 14 day>: second embargo | <+ 90>: public security advisory | i.e "X days + 14 + 14 + 90" = X days + 118 Or are the dates running in parallel so to say? Example: public advisory is always X days + 90?] > > Handling embargoed information > ============================== > On receipt of embargoed information, you must not disclose any of the > provided information beyond the group of people in your organization that > need to know about it. During the primary and secondary embargo periods, > that group of people should be limited to those entrusted to assess the > impact of the vulnerability on your organization and deploy fixes to your > products. After the secondary embargo period but during the public embargo > period, that group of people may be expanded in order to prepare your > organization's public response. The embargoed information must not be > shared outside your organization during the public embargo period under any > circumstances. It is permitted to point others to a public vulnerability > fix during an embargo period, as long as this is not identified as a > vulnerability. > > If you think another individual/organization requires access to the > embargoed information, then please ask them to register as a Trusted > Stakeholder (see next section). If you believe there has been a leak of > embargoed information then please notify the security team immediately. > > [DH: This section is stronger than the existing TF-A and OP-TEE processes, > but not as strong as the linux distros policy [4]. I hope I've struck the > right balance here.] > > The security team welcomes feedback on embargoed information at any time. > > > ESS and Trusted Stakeholder registration > ======================================== > [DH: This is broadly based on the OP-TEE policy.] > > The security team maintains a vetted list of organizations and individuals > who are considered ESSes and Trusted Stakeholders of Trusted Firmware > security vulnerabilities. Contact <mailto:security@trustedfirmware.org> > if you wish to be added to one of the lists, providing the following > information: > > 1. Which list you want to be on. This will almost always be the Trusted > Stakeholder list. > > 2. A justification of why you should be on the list. That is, why you > should know about security vulnerabilities and have access to security > fixes before they are made public. A valid reason to be on the Trusted > Stakeholder list for example, is that you use Trusted Firmware in a > deployed product. The ESS list is strictly limited to those organizations > with large scale deployments of Trusted Firmware that provide bare-metal > access on multi-tenancy systems. > > 3. An organization email address (not gmail, yahoo or similar addresses). > It is preferable for each organization to provide an email alias that you > can manage yourselves rather than providing a long list of individual > addresses. > > 4. Confirmation that the individuals in your organization will handle > embargoed information responsibly as described in the previous section. > > Note, the security team reserves the right to deny registration or revoke > membership to the Trusted Stakeholders list, for example if it has concerns > about the confidentiality of embargoed information. > [JB: Only stakeholders list? What about ESS list?] > > [DH: Note, becoming a Trusted Stakeholder in the current TF-A process > requires having a valid NDA with Arm and requesting to be added via Arm > account management. I propose that Arm send a mail to all existing > stakeholders to invite them to register for the new process.] > > [DH: Note, I expect each TF project to maintain its own ESS/Trusted > Stakeholder lists.] > [JB: Makes sense!] > > [DH: Note, I've not included severity scoring in this proposal, as I think > the only value of a score is helping to determine whether a bug is a > security vulnerability or not, which in the end has a subjective element. > I'm open to the idea of adding this to the process but I'd prefer it to be > optional and aligned with CVSSv3 as used by CVE.] > [JB: Agree and regarding the process I'm quite open to have a look at CVSSv3. The current OP-TEE process is better than the first one, but it's still a bit rough around the edges. If CVSSv3 works for TF-A/M, then I'll probably also work for OP-TEE. Also, something that I've been missing when doing work like this is an internal process also. But that's definitely out of scope for this discussion.] > > [1] https://www.kernel.org/doc/html/latest/admin-guide/security-bugs.html > [2] > https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/about/docs/secu… > [3] https://optee.readthedocs.io/general/disclosure.html > [4] > https://oss-security.openwall.org/wiki/mailing-lists/distros#how-to-use-the… > > 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. > -- > TSC mailing list > TSC(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tsc Regards, Joakim

6 years, 3 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

TSC