Dear TSC members,
Find attached the slides presented by Ahmad for ST regarding TF-M binary hosting during December TSC meeting.
Regards,
Eric Finco
[Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: logo_big5]
Eric FINCO | Tel: +33 (0)2 4402 7500
MDG | Technical Specialist
From: Dan Handley <Dan.Handley(a)arm.com>
Sent: Monday, January 13, 2025 4:29 PM
To: Eric FINCO <eric.finco(a)st.com>; Ahmad EL JOUAID <ahmad.eljouaid(a)st.com>
Subject: RE: TSC minutes 2024-12-19
Hi Eric/Ahmad
I'd be grateful if you could send the (non-confidential version of the) slides you showed regarding binary hosting.
Regards
Dan.
From: Dan Handley via TSC <tsc(a)lists.trustedfirmware.org<mailto:tsc@lists.trustedfirmware.org>>
Sent: 13 January 2025 15:26
To: tsc(a)lists.trustedfirmware.org<mailto:tsc@lists.trustedfirmware.org>
Subject: [TF-TSC] TSC minutes 2024-12-19
Hi
My apologies for the lateness but here are the minutes for December's TSC meeting...
Dan.
Present:
* Ahmad El Jouaid (ST)
* Eric Finco (ST)
* Praneeth Bajjuri (TI)
* Andrew Davis (TI)
* Antonio De Angelis (Arm)
* Anton Komlev (Arm)
* Bharath Subramanian (Arm)
* Matteo Carlini (Arm)
* Frank Kvamtrø (Nordic)
* Dominik Ermel (Nordic)
* Chris Palmer (Google)
* Julius Werner (Google)
* Moritz Fisher (Google)
Agenda:
* TI welcome
* Continue board discussion on impacts of regulation like CRA. Eric
* TF-M binary uploads (Ahmad)
Dan welcomes TI to TF.org TSC
Praneeth:
Andrew and Kamlash will be TI TSC reps
I will be on the board
We were part of TF earlier, 4-5 years back.
Want to be more engaged again.
Especially interested in OpenCI, TF-A and TF-M
We will talk about topics of interest in future calls.
We're also interested in UBoot, e.g. LTS strategy
We're engaged with UBoot maintainers.
Kamlesh working for 3 years at TI: security and power management
Linux crypto driver, TF-A, U-boot, ...
Will be handling any new development here
Dan: FW-handoff could be one other possible topic of interest. We're working with Simon Glass (UBoot maintainer) on this.
(https://github.com/FirmwareHandoff/firmware_handoff)
Continue board discussion on impacts of regulation like CRA
Eric:
There was a 2 day workshop by Linux Foundation in Amsterdam, 10-11 Dec
Impact of regulation
2 sets of rules in CRA specification: 1 for manufacturers, 1 for open source stewards
For manufacturers, it's reasonably clear. Have to comply with all requirements in CRA
For stewards, it's much more fuzzy:
* Specific to open source
* Responsible for maintaining security standards
ST understanding is there will be 3 workgroups setup to dive into this and influence the EU's finalisation of the spec.
There's also discussion under Global Platform (GP) on the same topic. ST is part of this and monitoring/contributing.
Most likely will have an impact on TF.org.
Agreement at board is to have regular conversations about this.
I think this is something we have to do. They're expecting some deployment as early as 2025.
Don: What's our likely investment here?
Eric: Keep contributing to stewards's role. May need more community management.
Eric: May need more CI. Too early to say
Frank: Does the GlobalPlatform work you mention also include and/or focus on SESIP?
Frank: Or is our focus more broad and generic?
Eric: Don't have an answer right now. Can check with our guy working with GP.
Frank: in Zephyr security committee, there's an ongoing requirement to handle requirements like these (also for US, Asian markets).
Frank: Unfortunately likely to be many levels removed from the workshop scope. So anything we learn there will be very valuable.
Frank: Thanks to ST for covering this.
Binary hosting topic (Ahmad):
Presented slides
Eric: We will send declassified version of the slides
Will be using our own boot stage (BL2 equivalent) so will only be publishing TF-M secure/ns apps
Export control problems with hosting own boot binary
Would like TF-M binary to be hosted with TF-M repo for ease of integration
Dan: Would it have a different license?
Eric: No
Dan/Julius: Can't we just use the tf-binaries repo?
(https://git.trustedfirmware.org/plugins/gitiles/tf-binaries/+/refs/heads/ma…)
Eric: Requirements are slightly different.
Would like to keep with platform port in TF-M source code
Dan: How to link precise source code version with the binary?
Eric: Maybe could sign binary with SHA-1.
Could have several versions in the repo.
Antonio: Is this for just new platforms or existing platforms too.
Eric: Just new platforms.
Anton: Concerned about side-effect of repo growth.
Anton: Why not host separately and keep link to TF-M source code?
Eric: Haven't discussed repo growth
Eric: Can we limit to release versions?
Ahmad: Yes, can do that and update with each release
Dan: Repo growth is not a blocker issues on its own. Can use tech like Git LFS (https://git-lfs.com/).
Frank: Could tf-binaries be a staging area for this?
Frank: Agree that releasing binaries is a good use-case
Frank: Could ST look into that?
Anton: I accept the use-case but also would prefer to use tf-binaries.
Eric: Next steps. Should we post something on TF-M forum
Anton: Happy to discuss in TF-M tech forum.
Frank: It might also be useful to store other artefacts to that separate repo.
Frank: We also do not use TF-M BL2. We have our own version. But it's still part of certification scope
AOB:
Call for ideas to use tf.org surplus
TF-M code size:
Frank: Nordic also cater for small devices.
We see some reluctance to use full TF-M distribution
e.g. Maybe will never use the attestation service
e.g. for Mbed TLS developer branch, may need to look into optimisations for small devices
Still want to use TF-M but some of PSA requirements may not be included.
Some vendors are saying TF-M is too big.
e.g. For PSA trusted storage using external storage, need rollback protection. But this is cumbersome for some customers. For our real implementation, we use internal storage.
We hope this kind of suggestion doesn't change governance for generic users of TF-M.
May end up not being fully certified.
Expect this to be internal build details.
Eric: We're seeing more of the same thing
Eric: Would you propose some simplified profile?
Frank: In Zephyr scope, we're already disabling features we don't need.
Frank: Turning off attestation is one basic thing but if we do, it is against PSA certification.
Frank: Seems OK for some devices, e.g. simple Bluetooth devices
(ran out of time)
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
My apologies for the lateness but here are the minutes for December's TSC meeting...
Dan.
Present:
* Ahmad El Jouaid (ST)
* Eric Finco (ST)
* Praneeth Bajjuri (TI)
* Andrew Davis (TI)
* Antonio De Angelis (Arm)
* Anton Komlev (Arm)
* Bharath Subramanian (Arm)
* Matteo Carlini (Arm)
* Frank Kvamtrø (Nordic)
* Dominik Ermel (Nordic)
* Chris Palmer (Google)
* Julius Werner (Google)
* Moritz Fisher (Google)
Agenda:
* TI welcome
* Continue board discussion on impacts of regulation like CRA. Eric
* TF-M binary uploads (Ahmad)
Dan welcomes TI to TF.org TSC
Praneeth:
Andrew and Kamlash will be TI TSC reps
I will be on the board
We were part of TF earlier, 4-5 years back.
Want to be more engaged again.
Especially interested in OpenCI, TF-A and TF-M
We will talk about topics of interest in future calls.
We're also interested in UBoot, e.g. LTS strategy
We're engaged with UBoot maintainers.
Kamlesh working for 3 years at TI: security and power management
Linux crypto driver, TF-A, U-boot, ...
Will be handling any new development here
Dan: FW-handoff could be one other possible topic of interest. We're working with Simon Glass (UBoot maintainer) on this.
(https://github.com/FirmwareHandoff/firmware_handoff)
Continue board discussion on impacts of regulation like CRA
Eric:
There was a 2 day workshop by Linux Foundation in Amsterdam, 10-11 Dec
Impact of regulation
2 sets of rules in CRA specification: 1 for manufacturers, 1 for open source stewards
For manufacturers, it's reasonably clear. Have to comply with all requirements in CRA
For stewards, it's much more fuzzy:
* Specific to open source
* Responsible for maintaining security standards
ST understanding is there will be 3 workgroups setup to dive into this and influence the EU's finalisation of the spec.
There's also discussion under Global Platform (GP) on the same topic. ST is part of this and monitoring/contributing.
Most likely will have an impact on TF.org.
Agreement at board is to have regular conversations about this.
I think this is something we have to do. They're expecting some deployment as early as 2025.
Don: What's our likely investment here?
Eric: Keep contributing to stewards's role. May need more community management.
Eric: May need more CI. Too early to say
Frank: Does the GlobalPlatform work you mention also include and/or focus on SESIP?
Frank: Or is our focus more broad and generic?
Eric: Don't have an answer right now. Can check with our guy working with GP.
Frank: in Zephyr security committee, there's an ongoing requirement to handle requirements like these (also for US, Asian markets).
Frank: Unfortunately likely to be many levels removed from the workshop scope. So anything we learn there will be very valuable.
Frank: Thanks to ST for covering this.
Binary hosting topic (Ahmad):
Presented slides
Eric: We will send declassified version of the slides
Will be using our own boot stage (BL2 equivalent) so will only be publishing TF-M secure/ns apps
Export control problems with hosting own boot binary
Would like TF-M binary to be hosted with TF-M repo for ease of integration
Dan: Would it have a different license?
Eric: No
Dan/Julius: Can't we just use the tf-binaries repo?
(https://git.trustedfirmware.org/plugins/gitiles/tf-binaries/+/refs/heads/ma…)
Eric: Requirements are slightly different.
Would like to keep with platform port in TF-M source code
Dan: How to link precise source code version with the binary?
Eric: Maybe could sign binary with SHA-1.
Could have several versions in the repo.
Antonio: Is this for just new platforms or existing platforms too.
Eric: Just new platforms.
Anton: Concerned about side-effect of repo growth.
Anton: Why not host separately and keep link to TF-M source code?
Eric: Haven't discussed repo growth
Eric: Can we limit to release versions?
Ahmad: Yes, can do that and update with each release
Dan: Repo growth is not a blocker issues on its own. Can use tech like Git LFS (https://git-lfs.com/).
Frank: Could tf-binaries be a staging area for this?
Frank: Agree that releasing binaries is a good use-case
Frank: Could ST look into that?
Anton: I accept the use-case but also would prefer to use tf-binaries.
Eric: Next steps. Should we post something on TF-M forum
Anton: Happy to discuss in TF-M tech forum.
Frank: It might also be useful to store other artefacts to that separate repo.
Frank: We also do not use TF-M BL2. We have our own version. But it's still part of certification scope
AOB:
Call for ideas to use tf.org surplus
TF-M code size:
Frank: Nordic also cater for small devices.
We see some reluctance to use full TF-M distribution
e.g. Maybe will never use the attestation service
e.g. for Mbed TLS developer branch, may need to look into optimisations for small devices
Still want to use TF-M but some of PSA requirements may not be included.
Some vendors are saying TF-M is too big.
e.g. For PSA trusted storage using external storage, need rollback protection. But this is cumbersome for some customers. For our real implementation, we use internal storage.
We hope this kind of suggestion doesn't change governance for generic users of TF-M.
May end up not being fully certified.
Expect this to be internal build details.
Eric: We're seeing more of the same thing
Eric: Would you propose some simplified profile?
Frank: In Zephyr scope, we're already disabling features we don't need.
Frank: Turning off attestation is one basic thing but if we do, it is against PSA certification.
Frank: Seems OK for some devices, e.g. simple Bluetooth devices
(ran out of time)
Hi all
The next TSC meeting is this Thursday (Dec 19). Please let me know if you have any topics you'd like to discuss. Some potential ones are:
* TI welcome
* Continue board discussion on potential TF-funded activities,
* E.g. "Code Development using AI". KangKang - do you want to do this or should we push it to a future meeting?
* Continue board discussion on impacts of regulation like CRA. Eric - do you want to do this?
Also, we're getting close to the holiday season so please let me know if you're available, otherwise I may have to cancel.
Regards
Dan.
Present:
Ilias Apalodimas (Linaro)
Antonio De Angelis (Arm)
Dan Handley (Arm)
Matteo Carlini (Arm)
KangKang Shen (FutureWei)
Frank Audun (Nordic)
LionelD (ST)
Michael Thomas (Renesas)
Julius Werner (Google)
(Ilias speaking unless otherwise stated)
There have been some activities around stability and working with the latest kernel.
Some work to improve secure data path support. How to deal with encrypted buffers in secure world.
Each vendor has its own way of doing this. Want to provide a common way.
Jens picked this up and is working with kernel maintainers to provide the common solution.
It works with both FF-A and direct SMC APIs.
He'll be sending v3 kernel patches next week. This should be merged soon.
fTPM:
Microsoft previously had 2 repos to support OP-TEE TA fTPM; a ref TPM library and an OP-TEE TA.
The latter is no longer available, so Linaro are going to host this alongside the other OP-TEE repos.
OP-TEE secure storage was previously under control of the kernel. It relied on a userspace supplicant to mediate access to RPMB.
That was OK when we needed to access secure storage late in the bootflow.
But there's a problem if you needed this early in the kernel bootflow (before userspace is loaded).
We have moved a big portion of the supplicant code inside the kernel itself.
This works much better than previously.
Lionel: Is it a standalone subsystem that can be used e.g. in UBoot?
Uboot already has direct access to flash.
The problem was early kernel code that needed access before userspace was up
Jens also working on dynamic configuration of OP-TEE for e.g. number of cores, amount of secure memory.
We plan to work on FF-A 1.2. We want this in OP-TEE and Xen.
We think the memory sharing interfaces and other APIs will be useful.
Expect this to land soon.
We're also doing some hardening.
Increasing test coverage, CI improvements , enabling QEMU-sbsa
Secure Partition support:
There's an implicit dependency on thread support, which we're trying to remove
We're thinking about how to launch S-EL0 SPs without an entity in S-EL1 (like Hafnium)
Also support for Logical SPs, which is not supported at the moment
Lionel: Not sure if you're planning to use Device Tree (DT) for the dynamic configuration?
We're trying to base OP-TEE config on DT format
The problem is DT is OP-TEE specific and embedded within the OP-TEE image
Have you thought about adding support for the kernel DT?
Why do we want to pass that to OP-TEE?
Lionel: We already have a number of drivers in OP-TEE. Would be good to be able to discover them.
Lionel: Have already mentioned it to Jens
I haven't discussed this with Jens but it's an interesting idea
Don't think we have a function in OP-TEE to handle DT
Lionel: We have made use of the embedded DT in OP-TEE image but it's not ideal as this is specific to OP-TEE
Could be a security risk.
Lionel: This could use existing support in TF-A
Lionel: Can discuss offline
Suggest using FW handoff protocol, which includes support for DT entries
https://github.com/FirmwareHandoff/firmware_handoff
Would prefer a standard method than every vendor doing their own thing
Dan: Maybe some additional Transfer Entries (TEs) are needed for OP-TEE?
Dan: The preference is to define TEs with specific fields for firmware use rather than generic container formats like DT
Dan: Though using the kernel DT in firmware is fine.
Shebu Varghese Kuriakose (Arm)
Antonio De Angelis (Arm)
Dan Handley (Arm)
Janos Follath (Arm)
Eric Finco (ST)
Lionel Debieve (ST)
P J Bringer (ProvenRun)
Michael Thomas (Renesas)
Julius Werner (Google)
Moritz Fischer (Google)
Dominik Ermel (Nordic)
Mbed TLS roadmap (Shebu)
* Shebu presented roadmap (attached)
* Looking to align TF-M and Mbed TLS LTS releases (every 18 months), 3 year lifetime
* TF-PSACrypto repo expected end of this year or early next year.
* Still features to be added to PSA Crypto to have feature parity with legacy Mbed TLS APIs
* But there's enough now to switch to PSA Crypto as the default
* Original scope of 4.0 release was to remove all legacy interfaces while supporting all features provided by legacy interfaces
* Some rescoping needed to get release out
* Some features provided by legacy interfaces will only be available in subsequent TF-PSACrypto 4.x releases
* 1st half of 2025 is all about MBed TLS 4.0 prep
* We'll look at other features 2nd half of 2025.
* Hopefully TF-M and other consumers will move to TF-PSACrypto 4.x in 2nd half of 2025
7 year TF-A LTS (Dan)
* Request from Chris Palmer (Google Android) to extend TF-A LTS lifetime from 5 years to 7 years
* Currently a community effort from Arm, Google, Nvidia and ST.
* Obviously there's a cost to supporting up to 7 concurrent LTS for longer than before
* Arm's position is that we're willing to increase our own efforts if others are too. Can't do it on our own.
* Not really a cost to TF.org, other than the extra CI cloud cost.
(No concerns raised by others)
Firmware_handoff lib hosting (Dan)
* https://github.com/FirmwareHandoff/
* Originally an Arm spec but became a community effort as it became clear this is about alignment across SW projects rather than a need for central standardization
* Still at v0.9 but expect to be able to make a v1.0 release soon.
* There are already implementations in U-Boot, TF-A and OP-TEE
* There's a common library implementation that we expect to at least be used by the latter 2, maybe U-Boot too eventually
* Needs a hosting location. Stakeholders happy for this to be TF.org.
* Proposing this to be under the \shared namespace in git.trustedfirmware.org.
* For maximum compatibility, we're proposing a dual license of GPLv2 + MIT, or possibly GPLv2 + BSD-2-Clause.
* However, as this is not BSD-3-Clause, it will need board approval (as per the charter).
* Julius/Eric: Sounds OK
(No other concerns raised)
Action: Dan to send a mail to the board to try to get this approved offline
OpenCI hosting (Shebu)
* Effort to move OpenCI from Linaro hosting to Arm
* Has been discussed a lot at the board
* Arm has agreed to fund this directly.
* Board farm and FVP hosting will remain in Linaro
* Jenkins and other CI parts will move to Arm AWS instance.
* TF-A, TF-M and Hafnium will be in staging this quarter, public trials expected in Jan/Feb
* Will have fallback to Linaro CI for some time.
* Will allow us to fund more projects in CI, e.g. TF-RMM
Hi all
The agenda for tomorrow's TSC so far is:
* Mbed TLS roadmap update (Shebu)
* Extending TF-A LTS lifetime to 7 years (Chris Palmer)
Please let me know if you have any other topics.
Regards
Dan.
Hi all,
At Google, we are now promising 7 years of support for Pixel devices
<https://store.google.com/intl/en/ideas/articles/newest-pixel-updates/>. We
therefore wonder what it would take to increase the LTS maintenance
lifetime to 7 years (from, I believe 5): resources, project planning, other
things? Can we put this on the agenda for the next board meeting?
Present:
Shebu Varghese Kuriakose (Arm)
Antonio De Angelis (Arm)
Anton Komlev (Arm)
Joanna Farley (Arm)
Frank Audun Kvamtro (Nordic)
PJ Bringer (ProvenRun)
Julius Werner (Google)
Ruchika Gupta (NXP)
Eric Finco (ST)
Lionel Debieve (ST)
David Brown (Linaro)
Shebu presented TF-M roadmap (attached)
* TF-M v2.1.0 released
* Has been in planning for a while
* Main feature is this is the first LTS release
* RTOS projects can pick up aligned Mbed TLS and TF-M LTS releases
* Have worked with Nordic and others to align PSA Crypto headers with ones used in Mbed TLS
* TF-M v2.1.1 LTS in planning
* Main feature will be PSA L2 security certification (originally intended for previous release)
* Anton: Expecting this to pick up MBed TLS 3.6.1
* Eric: Previous idea was to engage with partner Lab. Is that still the case?
* Aligning with TrustCB primarily as that is recommended by PSA Certified
* Riscure will be doing initial evaluation and then TrustCB will be doing subsequent delta evaluations
* Have been doing significant enhancements to Runtime Security Engine (RSE), an Arm TF-M platform
* Anton working on using open source LLVM
* Anton: Front-end will use GNU compiler but LLVM backend, so should be easy to move over
* Anton: Think we can enable this in the next quarter
* Have had a number of requests for this
* Anton: Latest release has full support for Armv8.1-M architecture features
* Then we will have GCC, IAR and LLVM support
* Currently we use a fork of t_cose in TF-M. Want to use upstream version
* Need to change image encryption functionality to use PSA crypto before moving to Mbed TLS 4.0
* Frank: Sorry on a train, so don't want to speak too much. Just letting you know that we have been having some challenges with TF-M build system and will propose that there is a refactoring of this, which can be done by introducing TF-PSA-Crypto as a self-contained PSA Core.
* Anton: Frank promised to share more details and then we'll take it forward.
* Dan: Might see a temporary code size impact moving to Mbed TLS 4.0
* TF-M won't see that but still might get an improvement later.
(Dan later: Apologies, I got my wires crossed with code size issues in TF-A when moving from legacy crypto API to PSA crypto API on an earlier Mbed TLS version)
Antonio: For ADAC, we will need to add a work item to move API that ADAC uses to PSA Crypto, likely H1 25.
Ruchika: You mentioned Mbed TLS 4.0, do you expect a preview for that. Haven't seen much activity yet.
Shebu: A lot of work going on in the background.
Shebu: Want to make TF-PSA-Crypto a live repo where you can see ongoing development. Plan is before end of year.
Shebu: Will be a precursor to MBed TLS 4.0.
Ruchika: When we integrate PSA Crypto with TF-M we have integration problems. We have to do a lot of manual integration work.
Antonio: Still on our plan to do auto generation script.
Ruchika: It's difficult managing this for several repos.
Antonio: Agree. This hasn't been prioritised yet because it's not broken. But I agree it's not ideal
Dan talked about fTPM enablement:
* Background is that in discussion with partners and Arm's architecture group, we think the importance of firmware TPMs (fTPMs) is increasing.
* Also, the OP-TEE integration code that is hosted by Microsoft along with the reference C implementation seems to be deprecated and may be removed.
* Linaro have agreed to host this integration code along with their other OP-TEE repos (in GitHub).
* There's also some outstanding work to make this work properly, e.g. to leverage the Global Platform crypto library
* This is subject to LEDGE approval but don't expect any issues as it's not a lot of work
* At the same time, Arm will pick up Trusted Services FF-A fTPM implementation (again based on the MS TPM reference code)
* This will work with either Hafnium SPMC or OP-TEE SPMC
* There are some issues regarding what crypto library to use.
* The WolfSSL integration is not suitable for our reference platforms due to the license
* Ideally we'd use PSA Crypto but the simplest integration relies on BigNum interfaces, which are internal to PSA Crypto.
* We also need to intercept work going in OP-TEE and Linux to refactor the supplicant interfaces and use an RPMB driver in Linux
* Once this is all working, Arm reference platforms and OneLab platforms can leverage these implementations
* Shebu: We want to let everyone know what we're doing here
* Shebu: We know people are already using the OP-TEE TA config so want to give a heads up this is moving to TF.org.
* Shebu: It would be good to know if people are interested or want to contribute.
* Shebu: For now this will fully rely on MS reference library.
* There's a potential backlog of other stuff we can do but that is dependent on the above basic enablement and pull from partners
* For example, we could add abstractions for sharing access to secure storage if there are multiple use-cases for access
* Or even replace the MS TPM reference with a lighter library written in a memory safe language, e.g. Rust. But we wouldn't embark on that lightly
* David: FYI Zepyhr approved use of Rust for modules
LTS for MCUboot
* Dan: Now there are LTS for Mbed TLS and TF-M, we might need the same for MCUboot
* David: Agree we might need to define tagging policy and when to backport fixes.
* David: Over lifetime of MCUboot have had maybe 10 patches to backport
* Antonio: This was originally raised by Frank
* Antonio: Makes sense to have LTS version that goes into TF-M
* Antonio: Could have same policy as TF-M
* David: Makes sense to piggy back on something
* David: MCUboot is currently driven by TF-M or Zephyr.
* Antonio: Not sure why but Zephyr release was picking up tip of TF-M
* David: There was something that was considered an internal API but was actually used externally and so we had to coordinate releases of TF-M and MCUboot
* Frank: I do recommend MCUboot defines a process for this
* Frank: MCUboot is actually a toolset for a bootloader, not a boot rom. So it's hard to define the supported APIs.
* Dan: Can we just review the TF-M policy and see if this (or a subset of it) can be used for MCUboot?
https://trustedfirmware-m.readthedocs.io/en/latest/releases/release_process…
* Dan: David, can you read this and we can discuss this next time?
AOB
* Karen Power taking over from Don Harbin as TF.org community manager
* There will be a transition over the next couple of months.
* She's already active in the OpenCI work.
* Need to invite her to this call!
* Some modest budget surplus is projected to be available at the end of year.
* Let us know if there are any ideas for how to use this (e.g. extra testing, external evaluation, tooling, ...)
