(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-pr...]
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.