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.
Sorry, correction to date in the title.
-----Original Message----- From: Dan Handley via TSC tsc@lists.trustedfirmware.org Sent: Tuesday, June 20, 2023 5:50 PM To: tsc@lists.trustedfirmware.org Cc: Joanna Farley Joanna.Farley@arm.com Subject: [TF-TSC] TSC minutes 2023-06-23
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.
-
Dan Handley