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