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.