Hi Eric,

Please find my comments below. Okay to have a follow up discussion. I plan to present TF-M LTS proposal at the board meeting this month.

Regards,

Shebu

From: Eric FINCO <eric.finco@st.com>
Sent: Tuesday, October 3, 2023 3:48 PM
To: Dan Handley <Dan.Handley@arm.com>; tsc@lists.trustedfirmware.org; Shebu Varghese Kuriakose <Shebu.VargheseKuriakose@arm.com>
Subject: RE: TSC minutes 2023-09-23

Hello All,

I am sorry I was not able to able to join the latest TSC meeting.

I read the slides from Shebu and the minutes concerning the TF-M LTS but I would like to doublecheck a couple of points related to slide 3:

-“ Platform independent TF-M fixes in LTS release evaluated once by Lab. and applicable to all PSA Certified chips based on the LTS release.” Can you share the list of labs that accepted this model ?

>> As mentioned in slide2, the updated PSA certification process that considers the above evaluation using TF-M LTS is under review with PSA Certification body, TrustCB who own the PSA Certification process. They are positive about the approach so far.

Once they formally approve the process, all PSA Labs should support this model.

I presented the slides to all the PSA Labs on the same day as the TSC and didn’t hear any concerns. I can share more info. on the formal approval as I hear about it.

-“ Trustedfirmware.org & Arm will work with Lab and TrustCB to evaluate changes between LTS releases”

-> Do you confirm the concerned  TF-M parts are the TFM Core = IPC, SPM and interrupt handling ?

>>As shown in slide3, this will include everything above the HAL layer in TF-M including the secure services. From a code base perspective, this should be everything outside the platform folder.

-> Does it mean that if a vulnerability is found in these parts TF-org and Arm will have to negotiate with the labs accepting the proposed model on a case by case basis if a  re-certification is needed ?

>> The LTS release update with changes to mitigate against the vulnerability will be submitted to the Lab. for evaluation.  After the lab confirms the vulnerability is fixed and if there are no platform specific changes, then Trust CB would allow chips which upgrades to the latest TF-M LTS to get an updated certificate. If there are platform specific fixes, chip vendor will have to submit the change for evaluation and get confirmation the vulnerability is addressed before an updated certificate is issued.

Arm/TF.org need to have a pre-arranged PSA Lab to do the evaluation of the LTS release updates.

Regards,

Eric Finco

Eric FINCO | Tel: +33 (0)2 4402 7154

MDG | Technical Specialist

ST Restricted

From: Dan Handley via TSC <tsc@lists.trustedfirmware.org>
Sent: Monday, September 25, 2023 1:52 PM
To: tsc@lists.trustedfirmware.org
Subject: [TF-TSC] TSC minutes 2023-09-23

Attendees:

Dan Handley (Arm)

Antonio De Angelis (Arm)

Shebu Varghese Kuriakose (Arm)

Moritz Fisher (Google)

Julius Werner (Google)

Joakim Andersson (Nordic)

KangKang Shen (FutureWei)

Andrej Butok (NXP)

Ruchika Gupta (NXP)

(Linaro not available due to internal offsite meeting)

* Dan: No roadmap updates this month due to unavailability of Linaro and Arm technology manager

* Dan: Expecting combined TF-A + Trusted Services roadmap next month. OP-TEE roadmap is also due.

* Dan: Don wanted to raise again the risk of Phabricator being deprecated (that we use for wiki content)

* Dan: It’s not getting security updates and we have had issues with rogue accounts being created

* Dan: Now the task to create GitHub mirrors for all projects (https://linaro.atlassian.net/browse/TFC-247) is mostly complete, we can progress with migrating wiki content there

* Dan: Propose that we ping maintainers to start migrating project information. Can also directly migrate generic content (e.g. community pages).

(No objections)

Action: Dan and Antonio to ping maintainers to start migrating project information. Also directly migrate generic content (e.g. community pages).

Shebu presented attached slides on TF-M LTS proposal.

* AndreJ: TF-M has a dependency on MCUBoot and MBedTLS. Will they have the same LTS policy?

  * Shebu: Yes, Mbed TLS has similar LTS schedule that is proposed for TF-M (2 concurrent LTS, each with 3-year lifetime). Slide 6 shows integration plan.

  * We thought about doing this for MCUBoot too but as it is a small project, we think we can live with backporting security fixes as required. No plans currently.

* Dan: So, no releases from main branch? Why not?
  * Shebu: Such releases wouldn’t be usable for PSA certification.

  * Shebu: This would save effort, which could be used for LTS maintenance instead

  * Shebu: One possible use-case is for RSS releases.

  * Shebu: One consequence is that users would have to wait for the next LTS to get latest features in a release (up to 18 months)

* Shebu: Expect that we’ll need to backport new platform ports to LTS branches

  * Shebu: Platforms can’t wait until next LTS release.

* Ruchika: I also think main branch releases would be good as not everyone will be consuming LTS. 18 month wait could be too long.

  * Ruchika: Would help platforms that don’t need certification but do need new features.

  * Shebu: We would need to work out how we could resource main branch releases. Probably wouldn’t have the same level of support as LTS releases.

* Shebu: We’ll need help from TF-M users using PSA Certified to resource the LTS releases

* Shebu: Going to present this in TF-M Tech forum.

  * Shebu: Have already mentioned it to the TF.org board.

* Shebu: This is only tentative until we get approval from certification lab

* Shebu: Need to know from members if this will break their distribution model somehow

* Dan: So the plan is to get feedback from the lab and members, then go to the TF-M tech forum?

  * Shebu: Yes.