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