 |
|
Dan Handley (Arm)
Ashutosh Singh (Arm)
Eric Finco (ST)
Lionel Debieve (ST)
Kangkang (Futurewei)
Julius Werner (Google)
Joakim Bech (Linaro)
Erik Shreve (TI)
David Brown (Linaro)
Bill Fletcher (Linaro Community Projects)
Andrej Butok (NXP)
Dave Cocca (Renesas)
`
Minutes
Website UX
BF: (see slide).
Have set up a specific branch for the website code on GitHub that generates a preview.
Would like project leads for each project to fill out the schema at the top of each of the project pages with the key project-specific links to code/review/documentation etc and a small amount of descriptive text. If they push that to the new UX branch it will update the preview.
DH: Are approvals needed?
BF: Admins for the website code approve PRs, but this is still just a preview, not the live site.
Landing CHERI/Morello enabled Hafnium
https://developer.arm.com/architectures/cpu-architecture/a-profile/morello
https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/cheri-morello.html
JB: Have an implementation of Hafnium that pre-dates TF. Consortium asking if this is something that TF would be interested in. Have asked Robert from Cambridge Uni if he would be able to give an overview of the project.
EF: Is there a specific usecase or is it just that it’s available?
JB: Nothing to prevent having Morello in any firmware component. This is a proof of concept - not confirmed that it will become a product. Aim is to kill big classes of security issues.
JB: Should we say it’s too early or ask Robert to present?
DH: Are others interested? Maybe it’s a bit early?
JB: Can still ask if Robert is available/interested to discuss.with us.
Ownership of project release strategy/execution, especially for OP-TEE
JB: For OP-TEE after transfer to TF, have been asked who is setting the direction of the project. Still currently mainly Lenaro. Seems wrong that Linaro Jira instance has details of when we are going to make releases. Should we create some kind of tracking internally?
EF: Intent in transfer was to encourage other users of OP-TEE to become more active in the community. Needs minimum infrastructure to show a live forum. Seems a mandatory step to set this up.
DH: Seems a Product Management/Technology Management question. Could ask Arm Technology Managers (Matteo/Shebu) to take on more of a role. Shebu is looking at Arm’s contributions to OP-TEE.
JB: Main contributors are Linaro Members, Arm, non-members. Would be good if could get these 3 groups closer together.
DH: For other projects intersection of collaborators is more complex. Feels like we need a TF.org roadmap that coalesces each individual project contribution.
JB: Would be nice to have some kind of reference implementation with OP-TEE, TF, Mbed-TLS, Hafnium …
DH: That’s a ‘platform solutions’ problem (different team in Arm). Could point to work done by the teams involved in that within Arm. Are we looking for alignment and unified releases. Think projects would want to determine their own cadence.
JB: Yes. But should be possible to find when the releases are happening from tf.org.
DH: You were also talking about the resources to make the releases.
JB: We are rotating between Linaro staff to do the releases. Maybe just showing how/when it will happen on the website project page. also get the question a couple of times on LTS branches.
DH: Don’t think project teams would be able to manage additional LTS costs.
AS: Same for TF-M. No plan yet for TLS.
DH: Think LTS is something special. Primary customers are product vendors.
JB: Will think some more and come up with a proposal
Standard Hardware Requirements
EF: Minimum hardware requirements. Was discussed back in June. Abhishek proposed to come back on it when I was available. When we discuss Level 3 isolation, what is the minimum number of descriptors needed. Was a presentation on this in the Tech Forum. also discussion of different profiles. Could TF-M specify the minimum requirements for HW to support the features?
DH: Minimum number of MPU regions - function of the number of secure services that need to be supported. Does it not follow from that? Does PSA specify?
EF: Didn’t find it in the PSA document
DH: Probably not explicit but maybe it can be inferred.
EF: PSA doesn’t enforce implementation. Could provide SiPs with what the profiles mean.
DH: If it’s missing (from PSA) then needs to be defined somewhere.
AS: Partly defined in PSA but doesn’t go to the granularity for e.g. different profiles. Do see value but separate discussion as to where. Number of descriptors doesn’t scale with number of regions since can re-use. Do need to reserve a few for the core code. MPU is one hardware piece but what about other bus masters?
DH: Seems like a need for some kind of hardware integration guide.
AS: would hope that someone from the user community can come up with a starting point. Could be a topic for the Technical Forum and some initial point for what makes sense for each of the profiles.
Groups.io discussion
DH: Considered a better interface than plain old mailman lists.
DB: Zephyr happy with it. Could use it and not realise it has the web interface.
DH: Conclusion to migrate completely. Take a break or migrate domain support. $1000/y for non-profits. If TSC think it’s ok then can just push this to the Board.
BF: Current cost to the project for Linaro to maintain the mailman servers (plus endless spam work)
DC: Sounds good. In favour.
JB: Agree (vs mailman)
GitHub/GitLab discussion
DH: Started with the reasons that OP-TEE should stay on GitHub (from Joakim). Think Mbed-TLS would agree. Other projects in Arm looking at how to upstream. Issue tracking and wiki is currently not used consistently. Arm looking at GitLab internally. May not be the driving requirement for TF. Point raised by Julius that GitHub code review is not ideal. Either hybrid solution or some kind of plug in (to GitHub)
DB: Are projects that do Gerrit review on GitHub.
DH: There is ‘GerritHub’ but also possible plugins.
DB: Also the issue of ‘community’ in that it’s an expectation that embedded work will happen on GitHub.
EF: Spoke to some of our developers had a very negative view of GitLab (may be ST specific).
DH: Is self-hosting a requirement?
DB: Don’t have DoS issues
DH: Mbed TLS does use private repositories for security advisories.
DB: Can have private repositories on GitHub
JB: (Demonstrates security advisory/private repositories)
DH: Who owns https://github.com/TrustedFirmware ? (Action BF)
Action BF/DH to look at the hybrid solution
DH: MbedTLS will have to move since under an Arm/Mbed account. Bit worried about lumping many projects under one organisation due to potential risks. Like that OP-TEE is in it’s own org account.
|
|