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.
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.
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
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
> 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
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.
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
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
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
