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.