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)