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.
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
Hi All,
Please find the meeting minutes from the Jan 19th meeting attached.
Also find the presentations and supporting content from Julianus (OP-TEE
updates) and Kevin Oerton(EU Cyber Resilience Act & ENISA Good
Practices...) attached.
Thanks and best regards
Don - Sent on behalf of the TF TSC co-chairs
Hi all
The agenda so far for Thursday's TSC is:
* OP-TEE roadmap (Ilias, cc'd)
* EU Cyber Resilience Act analysis (KevinO).
Let me know if you have any other topics.
Regards
Dan.
Hi all,
Please see the announcement below regarding the first public release of the RMM implementation for the Arm CCA architecture.
The Trusted Firmware.org website will be updated soon, together with an accompanying blogpost!
Thanks
Matteo
From: Soby Mathew via TF-A <tf-a(a)lists.trustedfirmware.org>
Sent: 09 November 2022 13:32
To: tf-rmm(a)lists.trustedfirmware.org; tf-a(a)lists.trustedfirmware.org
Subject: [TF-A] Announcing TF-RMM v0.1.0
Hi Everyone
The TF-RMM team is pleased to announce the first public release of RMM implementation aligned to RMM Beta0 Specification [1] . The RMM is a software component that runs at Realm EL2 and forms part of a system which implements the Arm Confidential Compute Architecture (Arm CCA). The implementation can create Realm VMs in the Realm PAS and the Realm contents can be attested as specified in the RMM specification.
The official trustedfirmware.org git repo can be found at : https://git.trustedfirmware.org/TF-RMM/tf-rmm.git/. There is also a github read-only mirror and can be found at https://github.com/TF-RMM/tf-rmm . Contributions will be accepted via TF-RMM gerrit at trustedfirmware.org : https://review.trustedfirmware.org/q/project:TF-RMM%252Ftf-rmm
Please see the readme [2] and the getting started guide [3] to get started with RMM. We expect patches for supporting Realm Management Extension (RME) in linux kernel and related kvm-unit-tests to be available in the coming months. The patch to exercise Realm creation and execution via TF-A-Tests is in review at the moment [4] and the OOB instructions for the same can be found in TF-A RME documentation [5]. We expect these patches to be part of the upcoming TF-A v2.8 release.
The mailing list for the project is tf-rmm(a)lists.trustedfirmware.org<mailto:tf-rmm@lists.trustedfirmware.org>. Looking forward to fruitful community engagement and successful deployment Arm CCA systems in future.
Best Regards
Soby Mathew
PS : We hope to setup readthedocs documentation in the coming days, but till then , please bear with the github rendering of the rst documentation.
[1] https://developer.arm.com/documentation/den0137/1-0bet0/?lang=en
[2] https://github.com/TF-RMM/tf-rmm/blob/main/docs/readme.rst
[3] https://github.com/TF-RMM/tf-rmm/blob/main/docs/getting_started/getting-sta…
[4] https://review.trustedfirmware.org/c/TF-A/tf-a-tests/+/17221
[5] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/17610
Hi All,
Please find the November 17th meeting minutes attached.
Also please find attached both presentations referenced during the call.
Best regards,
Don Harbin
TrustedFirmware Community Manager
don.harbin(a)linaro.org
Hi all,
Hi all,
Please find below the minute of the meeting for the TSC held on 20/10/2022, plus find attached the slide decks presented by Shebu and Anton.
Best regards,
Antonio
Attendance:
Eric Finco (STM)
Antonio De Angelis (Arm)
Anton Komlev (Arm)
David Brown (Linaro)
Dan Handley (Arm)
Shebu Varghese Kuriakose (Arm)
Kevin Townsend (Linaro)
Lionel Debeve (STM)
Kevin Oerton (NXM)
Julius Werner (Google)
Andrej Butok (NXP)
Matteo Carlini (Arm)
Thomas Sanderson (Infineon)
Presentation from Eric about STM usage and general direction of the projects on TF.org . Slide deck and meeting minute details available to TSC members only.
Next presentation about TF-M roadmap from Shebu
KevinO: Is the PSA Crypto Driver item a reference/open source implementation?
* Provides standard driver model API that implements PSA Crypto Client API. Driver API is what interfaces to HW
* Silicon Labs did one for their own driver in their SDK, but the one in TF-M for CryptoCell acts as an upstream reference
Memory usage and performance: first batch in April release, remaining optimisations to be released in TF-M v1.7
Default config to be switched to Base: SPM + platform (minimal skeleton TF-M) instead of having the full features in default build. But still three profiles (S/M/L)
Library mode to be deprecated and removed
KevinT: Something missing is the KConfig based approach, which is going to be really useful
* Yes, this is part of the "simplify configuration" bullet (on slide 4).
* Anton to discuss this later
ArotLess L2 Profile for customers request
* Which particular chip is going through the process with this Profile?
* Not specific, but very constrained platforms that support TF-M, SFN L1 isolation (small chips).
* The certificate will explicitly say that it will not support ARoT partitions.
* KevinT: Are there significant memory savings by just separating S and NS?
* Yes, mainly due to absence of IPC model, just SFN.
* Also no config for MPU and only TrustZone based. Memory/performance benchmarks should improve.
* KevinT: Will it still support main TF-M services?
* Yes. Profile medium for crypto i.e. symm and asym. is the base of this
Anton updated about KConfig support.
* Already presented in TF-M tech forum
* Addresses difficulty of TF-M configuration space (hundreds of options).
* There are build options and config options. Build options stay in cmake.
* Put anything not related to build in header files. Then move these options to KConfig system
* KConfig checks consistency, dependencies and set of options to generate the config headers
* Orange options are high level ones that OEM might tweak. Black is more TF-M internal stuff
KevinO: Are there implications of all this variability in terms of certification (i.e. re-usability)?
KevinO: i.e. what PSA certification assurance to customers get if they change config options?
* Shebu: PSA talks about required functionality; things like isolation levels. But doesn't mandate specific config options. This is implementation defined.
KevinO: Thinking about C-SIP certification. How reusable is the certification if they then change? Presumably the items in black wouldn't affect this?
* Shebu: Would need to talk about this on a case by case basis.
KevinO: Trend now is to do both C-SIP and PSA. With CSIP, it's composable. If you integrate any one of these modules with C-SIP cert, then how re-usable is C-SIP cert in product side, if we change this options?
* Shebu: Don't have a good answer for that. OEMs might not appreciate all these options and distinctions. Perhaps only allow control ones that matter most to an integrator rather than fine-grained config
* Anton: For a quite some time we don't have up to date CMSIS-pack. Part of this was due to the number of build options
* Anton: Reducing build options might help with feasibility of CMSIS pack.
Only thing missing in 2022 work is some of PSA ADAC support
* Eric: On CMSIS Pack. Will there be version of packgen in TF-M repo?
* Shebu: Packgen is missing some features, so want to enhance this in next months. Would include this in TF-M
* Might not be fully automated, though.
Eric: Are you thinking about a low power TF-M mode?
* Shebu: Not been looking at this. Would appreciate more details on that.
* Eric: Will get Lionel to send something here
* Anton: Are you concerned about power management or power reduction?
* Eric: Not sure of difference. Want to put TF-M in low power mode
Next item from roadmap rota should be: Mbed TLS in November meeting.
Hi all
The October TF TSC is tomorrow. The agenda topics we have so far are:
* ST use of Trusted Firmware and direction of travel (Eric)
* TF-M roadmap (Shebu)
Please let me know if you have any other topics.
Regards
Dan.
Hi All,
As TF is moving forward with a TF-A LTS per the proposals that have been
presented, I've created a new mail list for this purpose.
Please feel free to subscribe.
https://lists.trustedfirmware.org/mailman3/lists/tfa-lts.lists.trustedfirmw…
Thanks,
Don Harbin
TrustedFirmware Community Manager
don.harbin(a)linaro.org
Hi All,
Please see Joakim's notes from his recent OSFC attendance below. Thanks
for attending and sharing the notes Joakim. :)
Best,
Don
---------- Forwarded message ---------
From: Joakim Bech via Board <board(a)lists.trustedfirmware.org>
Date: Mon, 3 Oct 2022 at 01:20
Subject: [Board] OSFC 2022
To: <board(a)lists.trustedfirmware.org>, Okash Khawaja <okash(a)google.com>
Hi,
From Linaro, Ilias and I were attending the Open Source Firmware Conference
(https://www.osfc.io) in Gothenburg in September. As you remember
TrustedFirmware decided to sponsor the event again, so I was actually
attending on behalf of TrustedFirmware. I think it was a great event, one
of the best I've been at I think.
A common theme seemed to be "less is more", i.e., my impression after
listening to the talks and after having discussions with people, it feels
like people believe that various projects have had a bit too much feature
creep (BMC's and EDK2 was brought up a couple of times as an example).
Another issue is the slow response time on getting things fixed in BMCs,
Management Engines etc. On average it took 18 months to get reported
(security) issues fixed. Related was the complexity of having a lot of
other code running outside the main OS (again ME's, BMC's, dedicated
security blocks etc). General impression was that people would like to get
back into more controlled environments.
DICE [1] (RIoT) from TCG/Microsoft seems to be getting more attention and
it's starting to find its way into more devices. Recently we've heard this
being mentioned by a few independent companies as a possible and simple
lightweight solution to devices in need for some device identity and to be
able to do some measure boot without having to rely on a TPM device. We
(Ilias) presented DICE to the Linaro LEDGE group half a year ago as a
potential area of interest. We'll bring this up again to a greater audience
at Linaro and eventually we'll propose something that will affect TF-A .
The DICE engine could run in BL1 and the DICE core could live in BL2. If
that discussion matures, we'll have to bring it up to the TF TSC as well.
[1]
https://www.microsoft.com/en-us/research/project/dice-device-identifier-com…
There still seems to be a misconception about UEFI, that UEFI == EKD2. To
some extent I believe that we were able to communicate that U-Boot contains
tiny subset of UEFI, making it possible to boot EFI and that our end goal
with ongoing Linaro work is to make it possible to boot any Linux distro
(and possible also Windows) without having to make devices/platform
specific changes to the OS side. On this matter, we've also synced up with
Simon Glass at Google. As you know Simon is proposing an alternative
implementation called VBE, which has a different approach. In some sense
it's a cleaner and more simple solution, but we believe it will be hard to
reach the goal of running any distro without relying on device specific
customizations when using VBE.
Google (Thordur Bjornsson), mentioned challenges with attesting hardware on
the upcoming v9 (CCA). He claimed that Intel did that part right, although
the security solution around it later on was broken. I think we should
introduce him to Charles Garcia Tobin.
I briefly had a chat with Christian Walter (9element) who is one of the
OSFC organizers. He was grateful that TrustedFirmware sponsored the event
again and that we seemed to like their event.
Mullvad (Swedish VPN provider and also sponsor) released a new USB key
called tilitiskey [2]. They gave a demo where they authenticated a user for
a SSH session. Their solution is kind of built using DICE as well (they mix
in additional user provided data as well into the hash). We all got
engineering samples, it should be fun to see how that project turns out.
[2] https://www.tillitis.se
@Okash, perhaps you have something to share as well?
--
Regards,
Joakim Bech
| Distinguished Engineer | Technology and Product Management | Linaro |
| Mobile: +46 73 697 37 14 | Address: Scheelevägen 17, 223 63 Lund, Sweden |
--
Board mailing list -- board(a)lists.trustedfirmware.org
To unsubscribe send an email to board-leave(a)lists.trustedfirmware.org
Hi,
This is in context of earlier discussion about socialising TF-A more
widely, e.g. on LinkedIn and Twitter. I noticed that stackoverflow.com
didn't have a "tf-a" tag even though there are questions referring to
it. I have created it now.
Adding more questions and answers under this tag will also help in
socialising TF-A.
Best regards,
Okash
TL;DR: Attached is the TF-A LTS proposal doc. Please review and share
your thoughts.
Hello everyone,
Long term support for TF-A has a long history. As a community we have
flirted with it for a while, and like any flirtation, it started with
gossip -- in our case, over mailing list [1] -- more than two years
ago. Then Varun Wadekar did a wonderful tech forum presentation [2]
which demonstrated interest in the topic and raised interesting
questions about LTS.
After some time, the affair lost headline status, only to be revived
again [3], earlier this year. This time however, there is a formal
proposal (no pun intended). After the mailing list discussion and
feedback from TF-A tech forum [4], we have put together a draft which
attempts to give a concrete idea about what the TF-A LTS will look
like.
Please spare some time to read through it and share your feedback. The
plan is to put LTS into action this November.
Cheers!
Okash
[1] https://lists.trustedfirmware.org/archives/search?mlist=tf-a%40lists.truste…
[2] https://www.trustedfirmware.org/docs/TF-A-LTS.pdf
[3] https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.…
[4] https://www.trustedfirmware.org/docs/TForg_LTS_proposal.pdf
Hi All,
Please find the minutes to the Sept 15 TSC.
Best regards,
Don - sent on behalf of the TSC co-chairs
======================================
Attnedees: David Brown (Linaro), Thomas Sanderson (Infineon), Kevin
Townsend (Linaro), Lionel D (ST), Eric Finco (ST), Andrej Butok (NXP), Dan
H (Arm), Antonio (Arm), Bill Peckham (Google), Kevin Oerton (NXM.Labs),
Julius Werner (Google), Okash (Google), Matteo (Arm)
Agenda items:
* LTS
* RMM
* FW handoff spec
Recurring:
* OpenCI update won't be held as Glen/Don are not available today. See
backup in the redacted board slides sent out by Don for Open CI monthly
update.
LTS sum-up from board meeting
* until we start, it's hard to gain momentum and hard to estimate costs in
advance.
* TF.org to evaluate direct funding but only from the next financial year
* Proposal: share the burden for 1 LTS release to be maintained for at
least one year. To evaluate the effort, gather data, see how it goes,
evaluate the engagement, and then have data to propose to the board for
long term funding. Share the burden between companies interested.
* Question: which platforms are tested and supported? The baseline is the
one tested by the official TF-A releases, with those platforms available in
the OpenCI
* Board requests to carefully iron out the messaging to be shared with the
community around the announce of the LTS so that expectations are clear in
the community
* Tech-wise, the proposal does not seem to have any objection so this is
mostly around funding/maintainership topics at the moment
* Companies interested are now to meet and agree next steps
TF-RMM component
* Upstreaming expected November 2022. Plans on integrating TF-RMM in the
OpenCI in the longer term as well.
Is the code already visible? It's still private. Arm Architecture group
has some private prototype that was shared with some partners under NDA.
But different significantly from what we're planning to upstream.
* Is it completely separate or depends on other TF.org projects? It's
coupled with TF-A in the same way as Hafnium is. It implements RMM
specification, so Linux and KVM and other clients they need to support the
same version of the spec of RMM to be compatible
Is the KVM counterpart of RMM going to be upstreamed? Yes, but Arm not
the maintainer so actual upstreaming will take longer as Arm does not
maintain those projects. But there will be public branches with these
changes in the meantime
* KVM, EDK2, etc altogether available in November, they will follow their
own destiny in each project.
Is there a plan-B if upstream does not accept them? There is the risk but
hopefully we will try to minimize and does not come to upstream maintainers
as a surprise (discussions under NDA for years already with non-Arm
maintainers). It does not mean it will be quick and easy but confident that
it will happen. For example one particular concern is the major work going
on in Android pKVM. Might risk some conflicts that slow down upstreaming
FW Handoff spec
* Several discussions around this happened so far. A number of interested
parties (e.g. uboot). Quite difficult to accommodate all requirements from
different parties. This is a tentative to summarise and centralise the
discussion so far to foster further collaboration and evolution of the
spec. We start on TF.org then we will re-assess if this the best place (or
needs to be moved to GitHub or other places).
* Contribution model: similar to other projects but with indepedent
maintainers, no strong links to other projects
* Creative commons license as it's more user friendly.
* Unless a big objection this is what is going to happen in the next weeks
* Is the format not pinned to devicetree? The spec just talks about
container format, the actual data can have different practical formats. It
tends to accommodate different implementation details. It's more focused on
the information itself rather than formats to organize this information
(i.e. registers to use, etc). It's quite a simple spec
* The spec will allow to specify different formats for the practical
structures that hold the information
Are there plans to add also tftf-tests for RMM? Yes there are some
additional tests that will be upstreamed.
* There are some changes in TF-A for example that are already happening
upstream in preparation for November 2022
Agenda items finished, no further objections.
Discussion about what will happen in subsequent meetings.
1. Roadmap sharing: Start again with TF-M (action item: inform Shebu and
invite for October (last presentation was in February)
2. Members inform about their usage (e.g. Kevin from NXM did very good
presentation last round) of TF.org projects, we believe it can be
beneficial for the community. Call to major partners in the call if there
is something you might be considering.
TSC interested especially in hearing about any particular challenge that
you need to overcome to use the projects commercially, any
suggestions/lesson learnt that can benefit the different projects in terms
of technical direction. Not necessarily to public TSC, can be a members
only TSC (and share public/open info only)
Feel free to reach out (directly to us in private if not comfortable)
STM: We can do that for some of the projects of TF.org (what we use).
Some direction, what we think it's difficult, what can be changed in terms
of direction.
Is there anything else members would like to have in future TSC?
No particular feedback.
Last clarification about the structure of mailing lists. TSC-Private is the
members only invited to the meeting.
TSC is for public attendance (no filter). Don has re-organized recently so
hopefully minutes of meetings will have been correctly archived in the list
manager now.
No particular other business, meeting close.
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or copy the
information in any medium. Thank you.
Hi All,
As I was doing some updates, I realized that the TF TSC maillists were out
of date. We also haven't been sending minutes to the list for archival
purposes. To that end, please see below:
- There are 2 maillists for the TSC.
- *tsc-private*: For the official TSC reps
- *tsc*: Includes the folks in *tsc-private* plus additional
developers interested in tracking the TSC activities.
- We've been sending TSC minutes to individuals in the TSC calendar
invite. I plan to change this so that the minutes are sent to TSC list to
be correctly archived.
- I've just updated both lists to represent what I believe is
correct. If you see anyone I've missed or other errors, please send me a
note and I'll correct. If a communication is for TSC Member Reps only,
please use TSC-private.
- Moving forward, we will send TSC Meeting minutes to the TSC maillist
to include the wider distribution..
- I plan to keep the invite to the meeting as-is with invites going out
to individuals.
Please review the snapshots of each list below and let me know if I've
missed anyone on your teams.
Thanks for your support/feedback in cleaning up,
Don
[image: TSC-private.png]
[image: TSC maillist.png]
Hi all
Please let me know if you have any topics for the TSC on Thursday. I won't be present at the meeting so Antonio will chair. I have the following topics so far:
* LTS discussion (see mailing list thread<https://lists.trustedfirmware.org/archives/list/tsc@lists.trustedfirmware.o…>) - Okash
* Hosting the firmware hand-off spec at tf.org (see TF-A mailing list thread<https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.…>). If no-one is comfortable leading this, I can do it next month.
Given it's holiday/vacation season, It would be helpful if you can let Don/Antonio know if you will be attending.
Regards
Dan.
Hi all,
Next TSC meeting is scheduled for Thursday 2022-07-21 9 AM PST. The only (tentative) item we have so far in agenda is:
1. Introduction to PSA FW handoff spec on TF.org (15 minutes)
This is the same discussion which happened in the last board meeting, and we could replicate it for TSC in case there are any TSC attendees who missed the board meeting.
To avoid replicating the presentation un-necessarily though, I would kindly ask you to confirm if you are interested in having this item discussed on the next TSC by replying to this email or directly to me in private by Wednesday 20th .
If I don't receive any reply for this (or for any other business you might want to discuss), I will cancel the upcoming TSC meeting.
Thanks,
Antonio
Hi All,
FYI, the Call For Participation(CFP) deadline for this year's OSFC in
Sweden is very near. If you or others on your team are interested,
the proposal
submission page is here <https://talks.osfc.io/osfc2022/cfp>.
The in-person conference is scheduled for mid-September.
Best regards,
Don Harbin
TrustedFirmware Community Manager
don.harbin(a)linaro.org
Hi All,
The CFP deadline for Arm Dev summit is in a couple days- Thursday 23 June.
I realize this is last minute, but still wanted to make sure you were all
aware in case you had a topic to present.
Here is the link to submit
<https://devsummit.arm.com/flow/arm/devsummit22/cfpinfo/page/details>,
Best regards,
Don
Attendees:
Glen Valante (Linaro)
Antonio de Angelis (Arm)
Matteo Carlini (Arm)
Kangkang Shen (FutureWei)
Andrej Butok (NXP)
Dan Handley (Arm)
Julius Werner (Google)
Bill Peckham (Google)
Kevin Oerton (NXM LABS)
Brandon Hussey (Renesas)
Eric Finco (STMicroelectronics)
Meeting start, Dan introduces.
- [Matteo] First we'll talk about CCA - same presentation already given to the board.
- Don't share roadmap slides normally, but we are not going to talk about anything confidential information anyway. We'll cover where we are and where we're going with the CCA architecture.
- Realm Management Extension (RME) in v9 - realm world is distrustful wrt NS and S, EL3 becomes the Root World. This is the Arm way of doing confidential compute, a well-known practice in the industry.
- Changes relating to RMI interfaces already happening in TF-A latest release. There will be changes in Linux kernel, in EDKII as the reference implementation of UEFI; focus on infrastructure systems first.
- TF-RMM will be our implementation of Realm Management Monitor software component: it will be a new project part of the TF.org family; already introduced to the board
- Outside of the application processor: RSS (runtime security subsystem) firmware will be upstreamed to TF-M project
- RSS is the HW root of trust that implements the HES (Hardware Enforced Security) requirements of the Arm CCA Security Model.
- RSS is going to appear on mobile client platform first (it will be enabled on its own without the rest of HES/CCA)
- [Kangkang]: We looked at CCA, 100% full implementation might be taking a long time. Stages and status of different software components?
- [Matteo] I will describe the various components and how we will start to demonstrate some of the components on a fast model platform soon.
- RME EL3 implementation first appeared in TF-Av2.6
- Specification will be public and published around end of June on developer.arm.com - if delay, beginning July
- [Dan]: This means the RMM spec for SW (the architecture specs are already out)
- [Matteo] All components and interfaces must be aligned towards the same interface version - currently non-public alpha, so that when beta goes public realigned work is needed
- (4-5 upstream components aligned against the public beta released spec)
- The timeline is roughly H2 2022 (CY22Q4 for upstreaming to start) kernel/kvm, edk2, rmm in tf-org]
- Quality level still not finalised (0.1, or better)
- Hafnium/TF-A EL3/TF-RMM will need to be aligned to be able to communicate
- Spec will be EAC end 22 beginning 23 - will need to realign components against EAC then
- In H2 2023 advanced 1.x features of the spec will start to be implemented
- [Kangkang]: Remember our experience in TrustZone, implementing Secure World (EL3), Trusted OS and secure applications one at a time.
- Why do you focus on the complete set of components instead of just picking a single use case / component and expand gradually on this?
- CCA looks like all components are planned and need to work together and be aligned and implemented. Why not just start with simple use case (CCA application) and then expand?
- [Matteo]: It's the architecture itself that has such extensive requirements. It's already an MVP. Very basic use case. You can't go simpler than this.
- [Matteo] You need to have several components in place otherwise it won't work, but we're just giving basic building blocks without trying to overstretch.
- [Dan]: Agree, it's a lot of components, but they are all needed for the key initial use-case: Boot guest VM from encrypted disk into a realm protected from host access.
- [Kangkang]: it's important to demonstrate how to use as soon as possible. Showing the full picture but implemented gradually
- [Matteo]: RME extension is available on latest publicly accessible architectural model (Base FVP) - allows you to play with these features.
- Qemu work ongoing (towards the end of the year). Emulation functionality is being assessed by virtualisation team of Linaro.
- Arm will provide publicly available solution FVPs, containing all System IP (CPU, GIC, interconnect, GPU for mobile for example)
- Infrastructure FVP will contain all IPs needed to demonstrate CCA.
- [Glen]: OpenCI status update; this has been moved from board to TSC to reduce technical details shared in board meeting.
- Boards going into lava lab. Rack still being built to add more boards; ST boards going in next week or two.
- After that it's Renesas, although still waiting on Renesas on the availability of the SW.
- Board meeting required to discuss other boards that need to be made available.
- [Eric]: as we discussed: additional candidate board coming from ST but no pressure. Any timing?
- [Glen] From a Sw point of view we're almost ready; but need to check latest readiness internally. Glen on standby for updated timeline to plan accordingly.
- Mbed TLS in openCI:. Some stability issues with Windows, need to upgrade the CI platform - will allow stability and performance increase
- PSA ACK tests enabled, but still have failures. Working with Arm to fix them.
- Code coverage: going through docs and code coverage reports to have source links (got completed last week)
- Will do MISRA enablement after code coverage and PSA ACK tests. Starting with TF-A. Create a series of milestones and estimates. Published plan and resourcing.
- Having biweekly meetings -> maybe going to weekly to keep up the pace.
- Getting licensing in place now. Discussions and emails ongoing for licensing infrastructure. Several weeks work for that before prototyping can start in staging.
- Then onto production. Several issues closed/fixed.
- [Dan]: Is the resource/plan public? I did not see numbers.
- [Glen]: Updated the plan two days ago with resource, check again. TFC-10 contains actual work tasks and first two milestones.
- [Dan] Is this waiting for review and approval?
- [Glen] Already reviewed from Arm and Linaro.
- [Dan]: What's the status of the ticket for read only mirrors on GitHub?
- [Glen]: need to check offline.
- [Dan]: The plan going forward is for OpenCI details to be in TSC and feedback from TSC back to board. Is there any feedback for the board yet? Anything offline is fine as well.
- [Dan]: Next time would be good to focus on what are the big things in the backlog, what are the next important things planned, etc (i.e. 6 months medium term roadmap).
- [Glen]: we presented that detail to the board meeting. will move from the board meeting to the TSC meeting next time.
- Any questions / AOB?
- None. Meeting end.
Hi all
We have these topics so far for the TSC meeting tomorrow. Please let me know if you have any more.
* Arm CCA roadmap update
* Open CI update
(Note, there is a plan to discuss the LTS topic in the TF-A and TF-M tech forums so I didn't put this as an agenda item here, but we can discuss this needed).
Regards
Dan.
Hi all
We have these topics so far for the TSC meeting tomorrow. Please let me know if you have any more.
* Combined OP-TEE and Trusted Services roadmaps (Julianus and Shebu)
* Open CI Update
* Discussion on whether this should be a recurring topic
* Discussion on what board info should be shared with TSC
Regards
Dan.
Hi,
Please find Apr 21 minutes below:
Thanks - Sent on behalf of the TSC co-chairs
Don
Attendees: Kevin Oerton(NXM), David Brown(Linaro), Kangkang
Shen(Futurewei), Julius Werner(Google), Andrej Butok(NXP), Dan
Handley(Arm), Okash(Google)
Minutes:
-
TF-A Roadmap update: Matteo
-
Walked thru roadmap page
-
https://developer.trustedfirmware.org/w/tf_a/roadmap/
-
Don: Can be found from the https://www.trustedfirmware.org/faq/
page as well.
-
Plan to keep this page up-to-date
-
Note the in-development section that shares active engineering
activities.
-
Okash: Heard there was a push to make Hafnium compulsory. Is the EL3
SPMC a stop gap?
-
Matteo: Depends on use cases for TZ enablement. Google not
mandating FF-A to the best of my knowledge. From Arm POV, if
you want to
isolate the normal world from malicious TAs/TEEs, Arm recommends using
Hafnium Secure-EL2 reference.
-
Okash: S-EL2 adds code/architecture complexity. Need an IOMMU that
supports S-EL2. Must look at tradeoffs. If OEMs want other
secure VMs, I
can see the advantage. Would all vendors want this? Is there
an option not
to use this (secure EL2) solution?
-
Matteo: Yes, TF-A doesn’t impose mandatory Hafnium usage. Can
still use other SPM configs. From an upstream POV, there’s a
limit to the
long-term support for all the different configs. We can’t
promise that EL3
SPMC will still be supported upstream in 2-3 years (though it
can still be
used downstream).
-
DanH: If there’s partner demand for long term support of the EL3
SPMC, we’re open to other non-Arm maintainers helping out.
-
Okash: Deprecating EL3 SPMC would send the message that Arm thinks
partners should move to Hafnium (S-EL2). Not deprecating
implies partners
can choose.
-
Matteo: Some components in TF-A aren’t maintained by Arm.
-
Okash: Any discussions on long-term LTS releases?
-
Matteo: Has been discussed in the past, also in a previous tech
forum. This lost traction, but a recent security issue
(Spectre-BHB) has
brought it back. Arm isn’t in a position to maintain it
ourselves. We can
discuss lighter options, like hotfix releases to most recent tagged
release, as recently added to TF-M. Could do similar in TF-A.
Must consider
the cost of various options..
-
Okash: Can look at the phone ecosystem as an example starting
point for what is required. Could provide a rough gauge for
how many years
an LTS needs to be maintained.
-
Dan: The cost of emulating the phone ecosystem would be high, for
example you’d need to backport bug fixes to 3 year old
releases. As Matteo
says, this would be too much for Arm on its own. Partners
would need to
share those costs.
-
Okash: Google is interested but would also need other partners too.
-
Don: There’s a CI cost as well?
-
Dan: Yes
-
Matteo: Could this be a future TSC topic?
-
Dan: May be a good maillist topic so that non-members can chime
in.
-
Okash: I restart the thread on the TF-A mailing list.
-
Matteo: reviewed ongoing/future tasks
-
MISRA tool integration into OpenCI now planned. Arm will remove
reliance on internal instructure.
-
See tech forum recording on DRTM here:
https://www.trustedfirmware.org/meetings/tf-a-technical-forum/
-
KangKang: How often will the roadmap be updated?
-
Matteo: It’s a live doc. Will try to update every quarter, but at
least every 6 months. These roadmap presentations are roughly every 6
months.
-
Dan: TSC survey feedback: Should Open CI tasks be reviewed in TSC or
Board?
-
Matteo: Not much discussed in the Board meeting. Perhaps high level
strategy in Board and ticket/plans reviewed by TSC?
-
Dan: Should Board minutes be shared w/ TSC?
-
Don: Ask the Board?
-
Planned future TSC topics
-
OP-TEE
-
Action: Next session is an OP-TEE review. Don reach out to Rushika
-
Trusted Services: by Shebu
-
Open CI - a potential backlog/roadmap review in this round robin
review
<end>
Hi all
So far we have the following topics for tomorrow's TSC meeting. Please let me know if you have any others.
* TF-A roadmap update
* TSC survey feedback
* GitHub mirroring update
Regards
Dan
Hi All,
Please find the March 17th TSC minutes below. Dan's slides regarding
Github from the meeting are also attached.
Best regards,
Don
========================================================
Attendees: Don Harbin, David Brown (Linaro), KangKang Shen (Futurewei),
Antonio De Angelis (Arm), Dan Handley (Arm), Shebu Varghese Kuriakose
(Arm), Andrej Butok (NXP), Anton Komlev (Arm), Kevin Oerton (NXMLabs), Dave
Rodgman (Arm), Julius Werner (Google), Kevin Townsend (Linaro), Eric Finco
(ST), Okash Khawaja (Google)
Actions:
-
Anton: Check feasibility of changing PSA Crypto header folder name.
-
Anton: Gauge interest in various GitHub options for TF-M
Minutes:
MBed TLS Roadmap (Shebu): Presented his slides
-
Continuing to look for support from members in the review role since
there’s a large load. Several members have stepped up - could still use
some additional support.
-
Kevin Townsend: Have we made any progress making PSA Crypto headers
work across projects?
-
Anton: No mismatch between MBed TLS v3.1.0 and TF-M
-
Antonio: TF-M’s headers are good now. Public headers are aligned
between TF-M and MBed TLS. Some headers are private to implementation, so
there’s not much we can do there.
-
Andrej: Can we change the folder name for one of the projects, so
that we don’t get conflicts in projects that build both sets of headers?
Could be either Mbed TLS or TF-M, but it’s important for them to be
different. Tfm_psa for example.
-
ACTION Anton: Check feasibility of changing PSA Crypto header folder
name.
-
Dave Rodgman: Getting good engagement/involvement. Agree review
contributions are very helpful
-
Andrej: What is the best place for companies to upstream their own PSA
Crypto drivers?
-
DaveR: Mbed TLS doesn’t plan to host h/w specific drivers.
-
Andrej: Somewhere in TF-M or create own repo?
-
Antonio: There are some PSA Crypto drivers in TF-M platform folder.
Would this make sense?
-
Andrej: What about products that don’t use TF-M?
-
Andrej: Could provide in own SDK or a separate repo on github. We’ll
probably go with the latter. We’re getting customers wanting to use the
upstream.
-
Anton: TF-M allows use of external projects. Github seems the right
place.
-
DanH: In future there may be value in TF.org providing full platform
stacks where stuff like this could live. Part of the problem here is that
TF-M and TF-A already have platform interfaces and host platform
code, but
Mbed TLS is a generic library with no platform interfaces.
-
Shebu: We also need to get MBed TLS tested on real target h/w in Open
CI
-
See the MBed TLS roadmap for more.
-
Don: reminder - new FAQ points to roadmaps page:
https://www.trustedfirmware.org/faq/
Current GitHub Status: Dan Handley
-
Presented status slides
-
Dan: Will be moving MBed TLS repos to a TF-owned org account vs
Arm-owned in the next few weeks.
-
Dan: TSC previously decided that all TF projects should have a GitHub
presence, even if some projects (e.g. TF-A) retain Gerrit for review
-
Andrej: Was this a TSC decision?
-
Dan: Yes. Unfortunately progress got blocked on funding an investigation
into a hybrid Gerrit/GitHub solution. But other solutions are possible.
-
Dan: NXP/Linaro especially keen for TF-M to move to GitHub
-
Andrej: Would like TF-M to fully move to GitHub (not just a read-only or
hybrid solution)
-
Andrej: Agree it will help contributions. We believe this will make TF-M
more popular
-
David Brown: Recently had difficulty creating a simple change for
review. GitHub will remove blockers in pushing changes.
-
Dan: GitHub access from China is more difficult, but solvable with VPN
-
Antonio: Could have a repo mirror in TF.org infrastructure to remove the
VPN dependency?
-
David: Providing a read-only mirror is simple enough
-
Dan: But what about providing a seamless GitHub experience.
-
David: That’s a much harder problem to solve.
-
Andrej: MBed TLS doesn’t have a problem, then it should be OK for TF-M
as well
-
Dan: It’s a problem for all GitHub projects
-
Kangkang: Most big China companies have their own VPN. Mainly a problem
for smaller companies.
-
Dan: Even if we decide that fully migrating to GitHub is the way to go,
this requires a lot of work from Arm to move internal systems to GitHub,
which we can’t do for some months. Could we create a read-only mirror as a
stepping stone and see if this improves engagement?
-
Kevin: We won't be able to measure success from a read-only mirror, but
it’s still a good stepping stone.
-
Antonio: Can at least measure attempted pull requests, even if they
can't be merged.
-
Kevin: It would also be useful to link to GitHub from related projects.
-
Dan: We should also check if fully moving to GitHub eventually is what
TF-M contributors want
-
ACTION Anton: Gauge interest in various GitHub options for TF-M
-
DanH: Secondary issue is our dependency on deprecated Phabricator.
GitHub provides a solution for migrating content out.
-
Agreement: Pursue the read only mirror. Objections?
-
None heard.
Hi all
We have 2 topics so far for the TSC meeting tomorrow. Please let me know if you have any more.
* Mbed TLS roadmap
* Continuation of the "Using GitHub" discussion (especially for TF-M). This got bounced back from the board to the TSC.
Regards
Dan.
Hi,
Please find the minutes to the Feb 17 TSC below.
Best regards,
Don - Sent on behalf of TSC chairs.
=============================
Meeting started 17.05 UK time on 02-17-2022
*Attendance:*
Antonio de Angelis
Anton Komlev
Andrej Butok
David Brown
Julius Werner
Kevin Townsend
1. Brief introduction from Antonio on the survey prepared by the
tf.org community
manager to be circulated with TSC and Board members after the upcoming
Board meeting. General overview of the type of questions in the survey,
possibility to request a 1:1 with TSC leadership in one of the survey
questions, if don’t want to share feedback on the survey itself. Results
will be collected and shared during March’s TSC.
1. Next topic: Anton’s presentation on TF-M roadmap.
- Release cadence updated to two releases per year, April and November.
Next one in April will be TF-M 1.6 (still in discussion when to move to 2.0
numbering, might be November or earlier depending on features that end up
in the release)
- Main focus for the project is on optimisations
- Kevin: code size/RAM requirements don’t look that bad, especially
given the amount of features you get
- Anton: agree, but trying to achieve some smaller footprints like 8
KB of RAM for FF-M
- Mbed TLS 3.1.0 already integrated and will be available in next
released version of TF-M
- Allows to pass full set of compliance tests for PSA (Architecture
Compliance Kit, ACK)
- David: need to further investigate integration with Zephyr OS at
this stage given the new version of mbed TLS 3.1.0 integrated in TF-M
- Efforts to improve documentation
- Kevin: There is a lot of good documentation in the design docs
folder, but unfortunately it gets outdated and does not reflect latest
status of development. Idea proposed to add an expiry date and
an owner to
each document. When the document expires the owner needs to review and
update it accordingly to latest development. It’s extra effort
on owner but
helps keeping documentation updated. Might be an expiry date of once per
year. TF-M to consider the idea.
- ADAC tooling support for host side tools
- PSA FWU
- Kevin: wondering how big is the update expected here . TF-M: We
expect consolidation phase: check with the users and work on
their feedback.
- Any questions:
- Andrej: are there examples of companies already using TF-M in
production? TF-M: Some startups already using TF-M in their
designs but not
sure if already production stage
- Kevin: Confidential AI use case from Linaro is an example of how
TF-M can be used to secure model parameters for inferencing on the edge
node. Confidential AI whitepaper for additional details. Security and
protection of the models, encryption of raw sensor data on S world,
transition to NS world in encrypted form only to establish a TLS
connection
to a cloud server. Decryption happens in the server
- TF-M: Another use case is an algorithm to be protected hence
allowed to run only on the Secure world
- Andrej: moving from Gerrit to GitHub would improve wide spreading
the adoption process of TF-M as a lot of companion projects (e.g. Zephyr,
mbed TLS) in this space are already hosted in GitHub and developers are
used to GitHub flow while Gerrit flow is more complicated. TF-M:
agree move
to GitHub is good for popularity. Discussions ongoing in TSC already for
several months, final decision is with maintainers for Gerrit to GitHub
move.
DavidB: TF-M on GitHub might improve contribution rate from
additional developers more used to GitHub, Gerrit is more complicated /
less common: might result in popularity increase
1. Any other topics for today TSC:
- Attendance: no questions or additional topics raised
- Antonio: need to identify which is next project for March’s meeting
roadmap update. Will discuss and communicate on the mailing list
accordingly in advance.
Meeting close 17:45 UK time.
Hi all,
Can you please let me know if you have any additional topics for tomorrow's TSC meeting? Please find below the agenda so far:
* Update on the trustedfirmware.org survey for Board / TSC members (5 mins)
* Roadmap update for trustedfirmware.org projects: Trusted Firmware - M (by Anton Komlev, TF-M tech lead) (25 mins)
* AOB
Best regards,
Antonio
Hi All,
Please find the minutes from yesterday's meeting below.
Please let me know if any questions
Best regards,
Don - *Sent on behalf to the TSC Chairs*
*==================================*
*Attendees*: Antonio De Angelis(Arm), David Brown(Linaro), Don,
Kangkang(FutureWei), Kevin Oerton(NXMLabs), Anton Komlev(Arm), Dan
Handley(Arm), Julius Werner(Google), Andrej Butok(NXP), Lionel
Debieve(ST), Eric
Finco(ST), Michael T(Renesas)
*Minutes*:
-
Don: Quorum reached
-
Dan: Welcome to Antonio (online) - taking on Abhishek’s role.
-
Dan: Interested in chairing this call since transitioning?
-
If interested, let Don know on the side and we can propose the change.
-
Kevin: For continuity, it seems a good thing to have an Arm rep
chairing. Substitutions if the Arm rep can’t attend would be more
effective.
-
Dan will chair
-
MBed TLS Github location. Currently under Github and currently being
transitioned. Plan is to move to TF.org account. Maintainers are having
2nd thoughts. If repos are put in the organization account, Github is
flat, so sometimes hard to map multiple repos to one project. Access
control is also a concern. So plan to create a separate MBed TLS github
account.
-
David: Is the mbed-tls available?
-
Dan: Yes we have it
-
Dan: Will run by the board
-
Eric: Just MBed TLS or all projects?
-
Dan: Separate accounts provide some healthy autonomy. Some are
blocked by reviews - Hafnium and TF-A use Gerrit for reviews.
Some tooling
helps with this but hasn’t been progressing.
-
No objections from TSC
-
Kevin: Breaking up to individual accounts makes sense, could have
“cross-pointers” to all other accounts in each one. Can use Github for
discussions integrated into Github
-
Dan: Good point, and can use github wiki and other features if not a
“shared” project.
-
Kevin - Lightning talk recorded here:
-
https://linaro-org.zoom.us/rec/share/dN_VrMIH6jjBYEbYf9DYO_oBhAqeHp2BAyCTZA…
-
Passcode: Tid4xb8&
-
Don: Survey to TSC and Board? Thoughts?
-
Consensus wan that both may be valuable.
-
Could help to answer Dan’s question on the direction of the TSC
-
Next month topics:
-
Dan: Restarting roadmap presentations thru each project starting with
TF-M next month.
Hi TSC members
Just forwarding the below info to you too FYI
Dan.
From: Don Harbin via Board <board(a)lists.trustedfirmware.org>
Sent: 13 January 2022 00:11
To: board(a)lists.trustedfirmware.org
Subject: [Board] FYI - Upcoming session at FOSDEM (Feb 5 & 6) and more
Hi,
I hope this note finds you all well.
FOSDEM<https://fosdem.org/2022/>(Free and Open-source Software Developers' European Meeting) is coming up in early February, and we wanted to let you all know that a session will be presented entitled "Arm CCA enablement through the Trusted Firmware community project" by Charles Garcia-Tobin and our own Matteo Carlini. :) Session details can be found here<https://fosdem.org/2022/schedule/event/tee_arm_cca/>.
I'll also mention a couple of other items:
* Linaro is hosting a free 2-hour technical training session entitled "Kernel Debug Stories for Arm" on February 8th and 15th. Three slots are provided to help find a session that's time-zone friendly. Further details and registration can be found here<https://www.linaro.org/events/kernel-debug-stories-for-arm-linaro-connect-t…>. Feel free to share with any devs on your teams that may find it of interest
* A white paper from Linaro many of you may enjoy called "Confidential AI for MCUs" has been garnering lots of interest, so I wanted to share it. It can be downloaded here<https://www.linaro.org/iot-and-embedded> if interested.
If you have any questions, please feel free to reach out to me.
Thanks and best regards,
Don
Hi all
Can you please let me know if you have any topics for tomorrow's TSC meeting? So far I have:
* Change in Arm TSC representation and chair (see separate mail)
* Proposal for migrating Mbed TLS GitHub location
* Perhaps also revisit the wider TF.org GitHub presence
* Lightning talk on NXM usage of TF. Kevin - are you ready to do this?
* Identify any future lightning talks
Regards
Dan.
