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.
Hi all
Please let me know if you have any urgent agenda topics for tomorrow. I have these so far:
* 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)
Regards
Dan.
Since we are having difficulty finding a time everyone can meet, I wanted
to send out this Doodle pool to try to find a better time we can meet. This
will be a regular meeting, either every two weeks, or two weeks each month.
Feel free to reply with any concerns.
https://doodle.com/meeting/participate/id/epkNGmXd
David
Present:
Dave Rodgman (Arm)
Dan Handley (Arm)
Joanna Farley (Arm)
Eric Finco (ST)
Ilias Apalodimas (Linaro)
David Brown (Linaro)
Shebu Varghese Kuriakose
Dominik Ermel (Nordic)
Kevin Townsend (Linaro)
Olivier Deprez (Arm)
AndreJ Butok (NXP)
KangKang Shen (FutureWei)
Kevin Oerton (NXM Labs)
Julius Werner (Google)
Shebu presented Mbed TLS roadmap (attached)
* Mbed TLS in Open CI is a big boost. Contributors can get their PRs tested without asking for help from Arm engineers.
* Creating a read-only interim PSA Crypto repository is a stepping stone to a completely separate PSA Crypto development repo.
* Currently users must carry the memory overhead of the SW crypto implementations even if they're using the backend PSA Crypto driver API. Optimization activities underway.
* Roadmap: Bignum improvements involve a lot of work over multiple quarters (at least until end of year) to improve security (e.g. making algorithms constant time).
* Feedback from TF-M community is memory overhead (due to code size of SW crypto implementations) is too much for MCU use-cases.
* Going slow on TLS 1.3 work due to higher priority items (e.g. mem optimizations and creating PSA Crypto repo).
* Mbed TLS 4.0 is next major version. In early days of planning.
* Could be point of deprecation for legacy Mbed crypto APIs.
* Also related to creation of separate PSA Crypto repo.
* Everything's on the table currently.
* Review bandwidth hasn't allowed us to progress with upstreaming of EdDSA and other algorithm contributions.
* Eric: When you introduce a new algorithm/API, is there always a way to accelerate this in HW?
* DaveR: That's the intent but the driver API support hasn't always come at the same time.
* Shebu: Tends to be 2 phases; SW implementation then driver API support.
* DaveR: If it's just a new cipher, this can fit within existing driver API
* Shebu: E.g. New PAKE, KDF functionality required new driver API support
* Eric: Why are there separate PSA Crypto API 1.1 items?
* Shebu: This is phased to implement high priority features first then remaining features after
* Dave: The 1st item was mainly about correcting some non-compliances rather than adding new features.
* We still have issues integrating community contributions.
* We ask contributors to donate general review time to get review time back for their contributions from core team.
U-Boot integration of Mbed TLS (Ilias)
* We want HTTP boot working in U-Boot. It's lacking TLS code.
* We also have a problem with the lack of a private security vulnerability handling channel in U-Boot project.
* TCP/IP stack was recently added to U-Boot.
* First step was to replace this with known, secure open source library.
* Was looking at backporting crypto lib from kernel but this seems to be old.
* First library we looked at was Mbed TLS as that had all the functionality we needed.
* It's now Apache-2.0 only; it was dual licensed with GPLv2
* U-Boot maintainers not interested in integrating Apache-2.0 code in GPLv2 project (there are varying opinions on compatibility).
* Also have problems with WolfSSL (requires a CLA).
* Shebu: Yes, Mbed TLS was dual licensed previously.
* Shebu: Originally, Mbed TLS was part of Arm's IoT group (strong coupling with Mbed OS) and before that PolarSSL (outside of Arm)
* At that time (5 years back), feedback from some partners was that existing GPLv2 licensing was undesirable (it limited their ability to contribute)
* Agreement was to keep GPLv2 for LTS branches but have Apache-2.0 only on development branch. Would then remove GPLv2 from inbound license when those LTS branches expired.
* Currently still have inbound license of GPLv2 AND Apache-2.0 so it's not impossible to go back on this. But some companies are still allergic to GPLv2.
* Ilias: Would be beneficial for Mbed TLS to support U-Boot, for all the extra testing it would get and possibly extra contributions.
* Shebu: Did get some feedback from a couple of projects that said they wanted GPLv2 support retained too.
* Shebu: They seem be managing to still use Mbed TLS. They have an exception in their documentation and pass on the compatibility issue to their users.
* Ilias: U-Boot firmly don't want to upstream Apache-2.0 code.
* Ilias: They also have a problem with projects that use CLAs like WolfSSL.
* Ilias: Really would like you to investigate this. See if concerns are still valid.
* Shebu: Any comments from other members?
* KevinT: For Zephyr we want Apache-2.0
* Shebu: This is about dual licensing so would not impact current Apache-2.0 users
* KevinT: OK, fine.
* Shebu: Issue originally was people being nervous about contributing drivers that read on their IP
* Dan: I think the general consensus is that Apache-2.0 is compatible with GPLv3 but not earlier versions.
* DavidB: You can get exceptions for GPLv2 but that doesn't help if you're pulling in code from lots of places.
* Dan: Anyway, we don't need to discuss compatibility if U-Boot maintainers already have their own (fixed) opinion
* Ilias: What were the older problems specifically?
* Shebu: I can go back to those old contacts but it might take a while. I'll dig further.
* Shebu: If there are no red flags, then we could put this to a vote at the board.
* Shebu: If there any concerns from members, please let us (Arm) know. This can be private and we'll anonymize any feedback.
* Shebu: So for authenticated variable support, Mbed TLS is not used?
* Ilias: No. We do this manually using code copied from the kernel.
* Ilias: If we can solve this problem, we're basically saving ourselves a year of effort. Plus we get all the benefits of CVE handling, etc...
Rust at TrustedFirmware.org. Joanna showed slides (attached).
* Want to have open a discussion about use of Rust at TF.org
* Most projects are C-based but increasing interest in Rust.
* I'm one of the TF-A maintainers.
* Wanted to gauge feedback from TF.org generally, not just TF-A community. So starting this discussion at the TSC
* DavidB: Contribution projects vary wildly, e.g. kernel has extensive support, Zephyr very limited support.
* Slide 4 is a chart generated daily in our TF-A CI.
* DavidB: Challenge is Rust has an ecosystem behind it.
* Not that useful to just allow Rust to call into C or vice versa.
* Need to introduce interfaces to allow significant part of implementation to be in Rust.
* May be useful for e.g. drivers
* KevinO: Need to consider investment required
* For things that are evolving quickly, there's additional cost to making progress.
* Agree with David that you have to look at how introducing interfaces will produce tangible benefits.
* Would need to come up with criteria for judging this.
* Agree with Joanna that we need to consider the threat of disruptive change
Ran out of time. Discussion to be continued next time.
Hi all
The agenda for this Thursday's rescheduled TSC is as follows:
* Mbed TLS roadmap (Shebu)
* U-Boot use of Mbed TLS and licensing (Ilias)
* Use of Rust at tf.org (open discussion, Joanna to introduce)
* Use of vector features in A-profile secure world, e.g. FP&SIMD, SVE, SME (open discussion, Dan to introduce).
That's the order I'm proposing. We might not get through everything. Let me know if you want to make any changes.
Regards
Dan.
Hi all
Unfortunately, both Antonio and I are unavailable for this Thursday's TSC meeting. Is it possible to reschedule for the same time next week (25th)?
Also, please let me know if you have any topics to discuss. So far I have:
* Mbed TLS roadmap (Shebu)
* Use of Rust at tf.org (open discussion)
* Use of vector features in A-profile secure world, e.g. FP&SIMD, SVE, SME (open discussion).
KevinT - you previously mentioned you could present on "Confidential AI with Zephyr/TF-M", but I see that you already presented this at the TF-M tech forum so I'm assuming a repeat at the TSC is unnecessary?
https://www.trustedfirmware.org/meetings/tf-m-technical-forum/
Regards
Dan
Hi All,
Please find the TSC minutes attached.
Additionally please find the redacted Board Slides for reference.
Best regards,
Don - sent on behalf of TSC co-chairs
Hi all
Please let me know if you have any topics for Thursday. So far we have:
* TF-M roadmap update (Shebu). Carried over from last time.
* PSA-Crypto API / TF-M integration (Antonio).
Regards
Dan.
Hi All,
Please find the minutes from this week's meeting attached.
I've also attached the redacted Board slides from earlier this week.
Best regards,
Don, - sent on behalf of the TSC Co-chairs
