- TSC - lists.trustedfirmware.org

Fwd: Trusted Firmware website redesign - proposed way forward

by Bill Fletcher

Hi all, At the previous TF TSC we had an action to work on the TF.org website. Here is a mock up of a new website front page, and also a possible graphics template for an example per-project "mini-site" in the attached PDF. It could be useful to stimulate some discussion. The other piece of the puzzle is a schema representing all the data/links per project so we can have consistent links to content across the mini-sites. A mock up of this schema looks like this: Projects Schema: Project Title Project Description Project Documentation Project Code Project Mailing List Project Call to Actions Project Code Review Project Useful Links Any comments ahead of the meeting are welcome. 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, 9 months

1
0
0 0

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

by Sandrine Bailleux

Hi all, On 5/5/20 9:04 AM, Sandrine Bailleux via TF-A wrote: > I've received very little feedback on version 2 of the proposal, which > hints that we are reaching an agreement. Thus, I plan to finalize the > proposal this week. This can then become part of our development flow > for all trustedfirmware.org projects. > > Thanks again for all the inputs! The project maintenance process is now live. The document has been moved here (with a few minor edits to turn it from a proposal to an effective process): https://developer.trustedfirmware.org/w/collaboration/project-maintenance-p… Thanks! Regards, Sandrine

5 years, 9 months

1
0
0 0

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

by Sandrine Bailleux

Hi all, I've received very little feedback on version 2 of the proposal, which hints that we are reaching an agreement. Thus, I plan to finalize the proposal this week. This can then become part of our development flow for all trustedfirmware.org projects. Thanks again for all the inputs! Regards, Sandrine Bailleux

5 years, 9 months

1
0
0 0

Trusted Firmware TSC 16th April - Minutes

by Bill Fletcher

Attendees Ruchika Gupta (NXP) Andrej Butok (NXP) Abhishek Pandit (Arm) Kevin Townsend (Linaro) Joakim Bech (Linaro) Christian Daudt (Cypress/Infineon) Eric FInco (ST) Julius Werner (Google) Mark Grosen (TI) Bill Mills (TI) David Brown (Linaro) Bill Fletcher (Linaro Community Projects) Actions AbhishekP: Action to follow up on TF hosting released PSA specification AbhishekP: Action to check with Shebu if the roadmap included 1.0 BillF: Action to storyboard/mock up web page for next TSC BillF: Action to check how to prepare the support of some member’s boards in CI and come back to CD/EF KevinT: Action/semi-volunteering to put some road-signs for helping people moving from gitHub to gerrit AbhishekP: Action to put the gerrit/GitHub issue on the agenda for next time Notes JB: Some practicalities around: - Our mailinglists, Bill have created/enabled some already and I have a discussion with Linux kernel developers regarding mailinglist for TEE kernel discussions. I can give a 2 minute update on this. - OP-TEE transition, I've tried to clean-up and redirect everything from Linaro to TrustedFirmware.org. Yet another 2 minute update. BF: All lists have been created - see TF.org/contact for all (public ones) JB: Suggested there should also be a tee mailing list in the kernel. DB: Vger list? JB: yes JB: also cleaned up OP-TEE.org to use new mailing list and mention trusted firmware where relevant AP: Maybe we need an ‘all’ mailing list for process, otherwise getting 3 mails every time? DB: In the kernel people are good at cross posting. CD: Suggest to wait if there are more of these things and see if we need a top level list DB: May be unintended consequences. AP: Leave it for now JB: Bill also created op-tee-security list. Need to describe membership/use DB: Has been done for Zephyr. JB: Not the same as what was agreed with Dan JB: Sandrine's maintainer / process proposal, do we want to have a follow-up discussion? AP: Was a special TF-A Tech Forum call last week. Has incorporated the suggestions from the list and forum. Would anyone want us not to formalize it? CD: In principle? AP: Sandrine published the updates she got. Suggest she finalises with each contributor rather than continuing to blast it to the list. EF: -Some time ago, you asked for feedback on trustedfirmware.org website and BillF created a wiki document to capture comments = https://developer.trustedfirmware.org/w/collaboration/website/ I have edited it with some comments and proposals. EF: could have per project logos routing people to mini-sites per project AP: Initial project landing pages often have member logos. EF: Dashboard is confusing - not analytics. Also different between TF-A and TF-M. Docs and wiki - not sure people visiting will understand the difference. EF: TF-M Wiki page is good. Could be mini-site entry point. AP: Was looking at Apache since has multiple projects too CD: Agree that the slicing is not good at the moment. People typically coming in for a specific project. First item for each one could be a ‘start here’ like Eric pointed out for TF-M DB: Don’t want drop downs need to be clicked on - should just select by hovering. AB: The PSA Specification is still under Arm. Also requires registration and doesn’t inform you if there’s a new version. Could it be moved to TF.org? AP: Will check with Arm BF: Not sure we can host it CD: It’s a public spec - so could host a copy AP: release versions could be ok but draft versions may be via a closed channel AP: Action to follow up on TF hosting released PSA specification BF: Action to storyboard/mock up web page for next TSC EF: Furthermore, last time Dan proposed to discussed the tools used by the projects (git, gerrit phabricator) and I see a link with the web site improvement topic so if members of the TSC agree we may start discussing this in today TSC AP: Phabricator is becoming an overhead. Would be good if it was more based on Sphinx/git. But some people do like the wiki. RG: Any plans to shift op-tee from github to tf.org. JB: Depends who - for me no. RG: Expect any change? DB: Gerrit seems to do better with long patch chains JB: A lot of new stuff is being added on GitHub. KT: Burden for new people getting a first patch in using Gerrit CD: Standard ramp up for a new tool. DB: But many more people using GitHub KT: Could do a better job in the documentation (semi-volunteering to put some road-signs) AP: Put the gerrit/GitHub issue on the agenda for next time? EF: As now the budget for the next phase to TF OpenCI has been voted, do we have an update on the execution plan and further to it how to prepare the support of some member’s board (Christian and I made raised a question pointing to it while reviewing Linaro proposal) BF: Action: will check this explicit step out and come back to CD/EF AOB: MG: How was the decision made to say TF-M is at 1.0? AP: Think it was related to PSA specification. MG: What’s the criteria for what is a version release? AP: Action: Will check with Shebu since this would be published as the roadmap. He joins the board but not the TSC. Think the roadmap included 1.0. MG: Are we going to have a process for doing a release - quality/features/bugs/benchmarks. Should be documented and reviewed before a release. JB: If nothing else need some kind of checklist so that it’s possible to include new people’s participation in a release. MG: Zephyr project has been looking at this quite a bit. Think we should document a process for getting a release out. As people look at using this in production. AP: Cross-TF? MG: Prefer not to do it 5 times (for each subproject). At least a baseline common across projects. JB: This is what exists for the OP-TEE project, we wanted to make some kind of "checklist" at some point also, to actually check off various items: https://optee.readthedocs.io/en/latest/general/releases.html#release-proced… CD: There is the aspect what is the feature set - shebu has been putting it together but don’t think we have a feature set to discuss/steer. i.e. what is important. This is orthogonal to the release process checklist. Some people sidestep this with a periodic release - either it made the release or it didn’t. EF: Semantic versioning? AP: Was discussed but think we stayed with the TF-A versioning. JB: Op-TEE follows semantic versioning. AB: Difficulty to use Zoom from NXP. Have asked for an exception. Was blocked today. Preference is MS Teams. JB: Issue to find one tool that works for all. MS Teams is only free ‘for now’. BF: Hoping to progress on this in the coming days. Already other ongoing discussions with NXP with respect to other Linaro meetings. -- [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] TSC Agenda 16 Apr 2020

by Eric FINCO

Hi Abhishek, Sorry for the late feedback. -Some time ago, you asked for feedback on trustedfirmware.org website and BillF created a wiki document to capture comments = https://developer.trustedfirmware.org/w/collaboration/website/ I have edited it with some comments and proposals. Futhermore, last time Dan proposed to discussed the tools used by the projects (git, gerrit phabricator) and I see a link with the web site improvement topic so if members of the TSC agree we may start discussing this in today TSC -As now the budget for the next phase to TF OpenCI has been voted, do we have an update on the execution plan and further to it how to prepare the support of some member’s board (Christian and I made raised a question pointing to it while reviewing Linaro proposal) 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: mercredi 15 avril 2020 17:25 To: Abhishek Pandit <Abhishek.Pandit(a)arm.com> Cc: tsc(a)lists.trustedfirmware.org Subject: Re: [TF-TSC] TSC Agenda 16 Apr 2020 Hi Abhishek, Some practicalities around: - Our mailinglists, Bill have created/enabled some already and I have a discussion with Linux kernel developers regarding mailinglist for TEE kernel discussions. I can give a 2 minute update on this. - OP-TEE transition, I've tried to clean-up and redirect everything from Linaro to TrustedFirmware.org. Yet another 2 minute update. Sandrine's maintainer / process proposal, do we want to have a follow-up discussion? Regards, Joakim On Wed, 15 Apr 2020 at 17:04, Abhishek Pandit via TSC <tsc(a)lists.trustedfirmware.org<mailto:tsc@lists.trustedfirmware.org>> wrote: Hi All, Any agenda items for this week’s meeting? Thanks, Abhishek -- TSC mailing list TSC(a)lists.trustedfirmware.org<mailto:TSC@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tsc

5 years, 10 months

1
0
0 0

Re: [TF-TSC] TSC Agenda 16 Apr 2020

by Joakim Bech

Hi Abhishek, Some practicalities around: - Our mailinglists, Bill have created/enabled some already and I have a discussion with Linux kernel developers regarding mailinglist for TEE kernel discussions. I can give a 2 minute update on this. - OP-TEE transition, I've tried to clean-up and redirect everything from Linaro to TrustedFirmware.org. Yet another 2 minute update. Sandrine's maintainer / process proposal, do we want to have a follow-up discussion? Regards, Joakim On Wed, 15 Apr 2020 at 17:04, Abhishek Pandit via TSC < tsc(a)lists.trustedfirmware.org> wrote: > Hi All, > > > > Any agenda items for this week’s meeting? > > > > Thanks, > > Abhishek > -- > TSC mailing list > TSC(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tsc >

5 years, 10 months

1
0
0 0

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

by Sandrine Bailleux

Hi all, Thanks to all who have commented on this proposal so far. I've edited the original document to try and incorporate all feedback gathered so far (through the TSC meeting, this email thread and the TF-A tech call). Please have another look and flag anything I might have missed: https://developer.trustedfirmware.org/w/collaboration/project-maintenance-p… The major changes are: == Removed concept of self-review == This is proving too controversial, several people do not want to allow self-review. Roles of maintainer and code owner are still cumulative but cannot be both exercised for the same patch. The exact method of dealing with review bottleneck is still to be decided. In addition to the current proposal of increasing the maintainers pool, the most popular alternatives mentioned so far are: - Set a minimum wait time for feedback before a patch can be merged without any further delay. - Mandate distinct reviewers for a patch. == Enhanced the section "Patch contribution Guidelines" == Mentioned that patches should be small, on-topic, with comprehensive commit messages. == Added a note about how to deal with disagreement == If reviewers cannot find a common ground, the proposal is to call out a 3rd-party maintainer. == Removed "out-of-date" platform state == Squashed it into "limited support" to reduce the number of states. == Removed "orphan" state from platform support life cycle == This concept is orthogonal to the level of functionality. Added a note in the "Code Owner" section instead. == Per-project guidelines as a complementary document == Added a list of things that it would typically cover. == Added requirement on fully supported platforms to document the features they support == == Added todo mentioning that the proposal might cover branching strategies in the future == The full diff may be seen here: https://developer.trustedfirmware.org/phriction/diff/73/?l=4&r=5 This proposal is still open for discussion at this stage and further feedback is most welcome! Regards, Sandrine

5 years, 10 months

1
0
0 0

TSC Agenda 16 Apr 2020

by Abhishek Pandit

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

5 years, 10 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, 10 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, 10 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, 10 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, 10 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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 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

6 years

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.

6 years

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

6 years

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

6 years

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

6 years, 1 month

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

6 years, 1 month

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.

6 years, 1 month

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

6 years, 1 month

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

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

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

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

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

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

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

6 years, 2 months

1
0
0 0

TSC Agenda 12 Dec 2019

by Abhishek Pandit

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

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

6 years, 3 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.

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

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

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

6 years, 3 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, 4 months

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

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

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

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

TSC