Present:
Dan Handley (Arm)
Antonio De Angelis (Arm)
Akanksha Jain (Arm)
Joanna Farley (Arm)
Olivier Deprez (Arm)
Matteo Carlini (Arm)
Eric Finco (ST)
Lionel Debieve (ST)
Moritz Fischer (Google)
Joakim Andersson (Nordic)
Dominik Ermel (Nordic)
David Brown (Linaro)
Ruchika Gupta (NXP)
Dan: This is the first time Akanksha joins this call
Dan: She a tech manager in Arm taking over from Matteo looking after roadmaps for Trusted Services and TF-A
Dan: No other topics but there will be some AOB later
Akanksha: Introduction (TF-A, Trusted Services and other A-class firmware are bundled now)
Akanksha: Description of deltas since last roadmap presentation that was a few quarters ago
Akanksha: TF v2.9 highlight: TF.org OpenCI, several improvements around Realms, Mbed TLS upgrades, additional platforms, EL3 arch feature enablement, CCA support to BET0 alignment
Akanksha: CCA upstream alignment describes the next steps for the RMM component mainly and Kernel and EDK II components
Dan: The CCA roadmap is a bit out of date. A few items in H1 are still ongoing in H2. Hope soon we can expand on what we're doing in 2024.
Dan: We should get RMM spec EAC5 aligned components into TF-A v2.10 release (backup plan is EAC2 components).
Akanksha: Recent Linaro presentations as additional resources on these topics are available in the slide deck
Akanksha: Trusted Services + OPTEE roadmap is shown as well
Eric: What's behind the requirement for Yocto support (TS roadmap)? Why are there 2 slots for that in roadmap?
Akanksha: Has been deprioritized in favour of platform support. It's going to happen but at a slower pace.
Akanksha: Not sure why it appears twice. We'll take that offline and respond later.
Akanksha: Getting ready for next releases (both normal and LTS) in 2024
Akanksha: Recap on LTS timelines -> requires strong partner support to make sure the branches get the proper support
Matteo: On the LTS side, this was mentioned at board meeting this week.
Matteo: Board says LTS OpenCI work to be in top 3 priority items
Matteo: But maintainers need to be prompt in opening these tickets
Matteo: Board asking for effort estimation on current LTS. Will report to TSC too.
Matteo: Can take figure for Arm make prediction of other companies' effort
Dan: I will ask Ilias (or someone in Linaro) for update on TS integration (e.g. FWU support) next month along with OP-TEE roadmap
Dan: Mbed TLS licensing was mentioned in redacted board slides
Dan: Plan is to re-introduce dual licensing (Apache-2.0 AND GPL-2.0-or-later)
Dan: Fortunately, can do this as we never changed the inbound license
Dan: Plan previously was to drop GPL support but this is needed for U-Boot to integrate Mbed TLS
Dan: Have now given all interested parties an opportunity to comment
Dan: Just awaiting final Arm legal approval then we'll do this
Dan: Migration of Phabricator is ongoing;
Dan: Now GitHub mirrors of all projects are available, can take advantage of tools there (e.g. issue tracking).
Dan: For consistency we want to use readthedocs for wiki content
Dan: Once done we can remove Phabricator
Hi All,
Please find redacted Board Slides from yesterday's meeting for reference.
Best regards,
Don Harbin
TrustedFirmware Community Manager
don.harbin(a)linaro.org
Attendees:
Dan Handley (Arm)
Antonio De Angelis (Arm)
Shebu Varghese Kuriakose (Arm)
Moritz Fisher (Google)
Julius Werner (Google)
Joakim Andersson (Nordic)
KangKang Shen (FutureWei)
Andrej Butok (NXP)
Ruchika Gupta (NXP)
(Linaro not available due to internal offsite meeting)
* Dan: No roadmap updates this month due to unavailability of Linaro and Arm technology manager
* Dan: Expecting combined TF-A + Trusted Services roadmap next month. OP-TEE roadmap is also due.
* Dan: Don wanted to raise again the risk of Phabricator being deprecated (that we use for wiki content)
* Dan: It's not getting security updates and we have had issues with rogue accounts being created
* Dan: Now the task to create GitHub mirrors for all projects (https://linaro.atlassian.net/browse/TFC-247) is mostly complete, we can progress with migrating wiki content there
* Dan: Propose that we ping maintainers to start migrating project information. Can also directly migrate generic content (e.g. community pages).
(No objections)
Action: Dan and Antonio to ping maintainers to start migrating project information. Also directly migrate generic content (e.g. community pages).
Shebu presented attached slides on TF-M LTS proposal.
* AndreJ: TF-M has a dependency on MCUBoot and MBedTLS. Will they have the same LTS policy?
* Shebu: Yes, Mbed TLS has similar LTS schedule that is proposed for TF-M (2 concurrent LTS, each with 3-year lifetime). Slide 6 shows integration plan.
* We thought about doing this for MCUBoot too but as it is a small project, we think we can live with backporting security fixes as required. No plans currently.
* Dan: So, no releases from main branch? Why not?
* Shebu: Such releases wouldn't be usable for PSA certification.
* Shebu: This would save effort, which could be used for LTS maintenance instead
* Shebu: One possible use-case is for RSS releases.
* Shebu: One consequence is that users would have to wait for the next LTS to get latest features in a release (up to 18 months)
* Shebu: Expect that we'll need to backport new platform ports to LTS branches
* Shebu: Platforms can't wait until next LTS release.
* Ruchika: I also think main branch releases would be good as not everyone will be consuming LTS. 18 month wait could be too long.
* Ruchika: Would help platforms that don't need certification but do need new features.
* Shebu: We would need to work out how we could resource main branch releases. Probably wouldn't have the same level of support as LTS releases.
* Shebu: We'll need help from TF-M users using PSA Certified to resource the LTS releases
* Shebu: Going to present this in TF-M Tech forum.
* Shebu: Have already mentioned it to the TF.org board.
* Shebu: This is only tentative until we get approval from certification lab
* Shebu: Need to know from members if this will break their distribution model somehow
* Dan: So the plan is to get feedback from the lab and members, then go to the TF-M tech forum?
* Shebu: Yes.
Hi TSC
Let me know if you have any discussion topics for tomorrow. So far I have:
* TF-M LTS branch (Shebu).
* OP-TEE or Trusted Services roadmap (TBC).
Regards
Dan.
Dear all,
next TSC meeting is scheduled for next Thursday 17/08. Currently, we have an empty agenda, also due to some of the members being not available due to the summer break. If you have any topic you want to discuss on next TSC, please do let me know by the 16th EOB (UK time). If I don't receive any proposal for topics to discuss, I will cancel the upcoming TSC and we will just resume with the September one.
Thanks,
Antonio
Hi All,
I wanted to let you know that next Thursday, July 27th, the TF-A Tech Forum
will be hosting a presentation on OpenCI and MISRA presented by Paul
Sokolovski of Linaro and Roberto Bagnara from Bugseng. MISRA is being
enabled on both TF-A and TF-M in OpenCI, so sending this out to both lists
since users in both domains may be interested in the session.
Meeting time and dial up info can be found in the TF community calendar
located here: https://www.trustedfirmware.org/meetings/
Best Regards,
Don Harbin
TrustedFirmware Community Manager
don.harbin(a)linaro.org
Hi all
Please let me know if you have any topics for this Thursday's TSC. So far I have none. Also, please let me know your availability since we are going into holiday/vacation season.
The next scheduled roadmap presentation is Trusted Services, but we would like to roll that up with the next TF-A roadmap to align with our internal project reporting. The next roadmap after that is OP-TEE. Julianus/Ilias - would you (or someone in the team) be available for that if needed? Sorry for the short notice.
Regards
Dan.
Hi All,
Please find redacted Board Slides from yesterday's meeting for reference.
Best regards,
Don Harbin
TrustedFirmware Community Manager
don.harbin(a)linaro.org
Present:
Dan Handley (Arm)
Joanna Farley (Arm)
David Brown (Linaro)
Eric Finco (ST)
Antonio De Angelis (Arm)
Dominik Ermel (Nordic)
Andrej Butok (NXP)
Joakim Andersson (Nordic)
KangKang Shen (FutureWei)
Kevin Oerton (NXM Labs)
Julus Werner (Google)
Okash Khawaja (Google)
Shebu Varghese Kuriakose (Arm)
Matteo Carlini (Arm)
Agenda:
* Completion of "Use of Rust at tf.org" discussion (Joanna, Dan)
* Use of vector features in A-profile secure world, e.g. FP&SIMD, SVE, SME (Dan)
* MCUBoot overview (David)
Completion of "Use of Rust at tf.org" discussion (slides in last month's minutes)
* Dan: Feedback from last time:
* For mixed Rust/C projects, need to have significant Rust functionality to achieve the full benefits of language, with clear interworking interfaces
* If you want to evolve quickly, you might have additional costs if you don't have the team trained already
* Dan: Other discussion points (slide 5)
* Dan: Long term maintenance vs short term cost. Steep learning curve
* David: It has to be integrated in CI otherwise it will just degrade over time. It applies to every piece of software but with a new language and paradigm you need to be more careful. It has to be integrated in CI.
* Dan: Mixed language projects might be more complex to maintain, more resources to dedicate
* Dan: Cargo + Crates.io: default package manager and repo, double edged sword: A lot of pre-packaged SW, so you can make progress quickly
* David: Very few available for embedded software though
* Dan: Provides a lot of standardization around project layout and tools.
* Dan: But increases dependency and increases risk of supply chain attacks. All components might not be to the required level of quality
* David: Linux kernel does not use cargo. Minimal set of dependencies (copy the crates that they use). Isolated from the rest of the Rust ecosystem
* Dan: Interesting. We might want to adopt the same policy at tf.org. Common for firmware projects to avoid external dependencies generally.
* Dan: Usual licenses not standard for TF.org but highly compatible (outbound = MIT OR Apache 2.0)
* Okash: Longer term do we think Rust is the right direction for the TF-A project? (leave aside the cost).
* Joanna: The final judge for this would be the community. In principle it is, or it could be, but there are a lot practical things to work through
* Okash: TF-A has a special eye on security, so writing it in a memory safe language is very logical. But it depends also on Arm/Linaro thinking on this. TF-A wouldn't survive without these two companies.
* Dan/Joanna: Early stage for anything related to potential company commitments. Can't say at this stage what will happen in 5 years, need to get feedback from ecosystem (community, partners, etc)
* David: Rusted Firmware it would be a great name though :) (Agreed)
* Joanna: Let's keep the discussion ongoing
* Julius: Which part of TF-A are you going to change first? Need an API to work around.
* Joanna: For example, it could be drivers or platform code, which calls into common code written in C.
* Joanna: Both areas very much contribution ready
* Kevin: Need to identify tangible benefits to incentivize move to Rust.
* Kevin: E.g. if it was providing better isolation or would enable better certification then that would be interesting
* David: There are projects that have done the move and have analysed vulnerabilities per line of code before and after to see how it improves. Could look at those.
Use of vector features in A-profile secure world
* Dan: SIMD&FP (aka Neon) has been available on Arm platforms for a long time (pre Armv8).
* Dan: Used by both normal and secure world. EL3 monitor does switching (context save/restore).
* Dan: Armv8.2 added Scalar Vector Extensions (SVE).
* Dan: Armv9 adds SVE2 (e.g. additional crypto instructions) and Scalar Matrix Extensions (SME)? Are there use-cases for these in the Secure world?
* Dan: Full SVE/SVE2/SME use on secure side requires more work
* Dan: Bigger contexts, might needs to be stored in different memory to rest of firmware code/data
* Dan: Depends on the config which component does the switch. Supporting all configs is more work.
* Dan: Might need to do lazy switching to improve performance.
* Dan: Do we have clear use-cases for Trusted Applications / Secure Partions using these extensions?
* e.g. Confidential AI? Enhancements to Crypto? Still very theoretical as we have not been asked yet by partners.
* Dan: Ask is for partners to provide feedback if they have concrete use-cases (can be shared privately).
MCUboot overview after move to the TF.org umbrella (David)
* Focus is on 32 bit
* Secure boot + Secure upgrade
* Started from mynewt (Apache RTOS) as bootutil
* Got ported to Zephyr
* As part of the porting had the mcuboot simulator developed in Rust. Helped find several bugs in the process
* Simulated flash tests most power failure scenarios. A few remaining corner cases.
* More platforms and RTOSes got added
* Uses a lot of GitHub features. Slack for discussions (maybe move to TF.org Discord?)
* Have ~3 corporate contributors. Maybe a few dozen small contributors (need a list of maintainers?)
* Demand based releases (in maintenance mode).
* There is roadmap of features but that is not driving releases. Lack of bandwidth from contributors
* Security holes reporting via email to maintainers or through GitHub interface
* Align to project security as for the others TF.org projects? (i.e. same process)
* Preferred method remains through GitHub reporting system
* Eric: we need to familiarize with the GitHub method ourselves (we have raised one through email recently)
* Dan: Don't have a problem with using GitHub security advisory feature alongside TF.org process.
* Dan: Don't think the GitHub features is scalable to notifying many Trusted Stakeholders. There is value in maintaining the Trusted Stakeholders alias in addition to the tool
* David: Future items:
* IETF-SUIT: Support for it in MCUboot (Software Upgrade for IoT)
* Support for large write devices (more than 4/8/16 bytes, i.e. 128 bytes). Need to have additional algorithms to support such bigger atomic write size
* Code cleanup (increases complexity for contribution and maintenance)
No other business.
