Hi Roman,

 

Thanks for the interest and comments.

Let me rephrase the proposal to explain it better. The improvement targeted to NS application development, not a custom service on S side.

As you mentioned in (3) below: S build creates a package for development NS side to enable NS app development independently from S codebase.

The package contains:

  1. Current set
  2. Additional set

The set 2 is taken (copied) from TF-M S codebase and always in sync with it. In this way NS application developer will deal with much smaller NS codebase,  focusing on application logic. NS app will be linked with PSA_API and platform_ns libraries to generate tfm_ns.bin, out of TF-M S codebase.

 

The 2nd idea of separate binaries for secure services was considered and looks attractive but implementation complexity and risks associated with it blocks us from a progress in that direction. I would be happy to review PoC of such solution.

 

Thanks, and hope that helps,

Anton

 

From: Roman.Mazurak@infineon.com <Roman.Mazurak@infineon.com>
Sent: Tuesday, May 16, 2023 8:42 AM
To: Anton Komlev <Anton.Komlev@arm.com>; tf-m@lists.trustedfirmware.org
Cc: nd <nd@arm.com>; Bohdan.Hunko@infineon.com
Subject: RE: Split build (continue)

 

Hi Anton,

 

It sounds interesting. But I see following questions:

  1. How to align service with API. It seems that for some services like Crypto or ITS it will be a little bit easier, because such API are more or less stable. But it can be a challenge for services that are under heavy development. My first thought is that version field of a service’s manifest is a good start. So, it will be mandatory to update the version field when there is a change in service API.
  2. How to align independent code base of secure and non-secure worlds?
  3. TF-M secure build generates binaries, scripts, configurations, etc. that are important during build process of non-secure part. I suppose such package must be integrated into end-user project using project specific approach. TF-M just need to provide a configuration options to specify location of such assets.

 

We can also think about separating basic services (Crypto, ITS, PS, …) from TF-M core (SPM/platform code). This can be achieved if TF-M provide stable API for services and I think we have it. So, we will have following benefits:

  1. SPM can be updated independently with potentially easier bug fixing of core component and/or service components.
  2. We can also split services into separate subprojects. So, it will give faster bug fixing cycle for each service. For example we create a separate repository with sources for ITS and provide a tag for it “1.x” (ITS API version “1”). Than the latest version of ITS service that should be released with fixes or improves will have two tags. The first one with tag “1.x” (ITS API version) and tag extended with minor version and patch if needed.
  3. It will be a good template for end-user and independent vendors how to create and maintain custom services. And probably less problems with licenses for vendors that would like to provide closed source and/or payed secure partitions – but I’m not sure that this is a real issue now.

 

Regards,

Roman.

 

From: Anton Komlev via TF-M <tf-m@lists.trustedfirmware.org>
Sent: Monday, May 15, 2023 19:44
To: tf-m@lists.trustedfirmware.org
Cc: nd <nd@arm.com>
Subject: [TF-M] Re: Split build (continue)

 

Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe.

 

Hi,

 

Continuing splitting TF-M build process we got alternative idea which make a step further to already proposed.

The key idea is an extension of TF-M installation phase with a copy of NS platform source code and let NS developer focus on that small subset of code only leaving TF-M complexity aside. This approach opens several attractive features like

The drawback or side-effect of this approach is the need to run 2 independent builds: for S and NS sides.

 

I plan to talk about it with details on the next tech forum on May 25 but wish to have a preliminary discussion here with

 

Here is the PoC of the proposal for an521: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/20960

The NS built will not run probably but functional completeness was not the goal of PoC.

 

Thanks, and looking for feedback,

Anton

 

From: David Hu via TF-M <tf-m@lists.trustedfirmware.org>
Sent: Wednesday, May 18, 2022 4:26 AM
To: Bohdan.Hunko@infineon.com; tf-m@lists.trustedfirmware.org
Cc: nd <nd@arm.com>
Subject: [TF-M] Re: Split build

 

Hi Bohdan,

 

It is still a prototype so far.

Some major features underway may impact TF-M structure and build system as well. So the current plan is to resume the build split after those major features are merged.

 

May I know if you have any specific requirement or dependencies on the build split?

Perhaps we can take a look if some optimization can be performed in advance.

 

Best regards,

Hu Ziji

 

From: Bohdan.Hunko--- via TF-M <tf-m@lists.trustedfirmware.org>
Sent: Tuesday, May 17, 2022 11:48 PM
To: tf-m@lists.trustedfirmware.org
Subject: [TF-M] Split build

 

Hi everyone,

 

Some time ago patch for split build of SPE, NSPE, BL2 was announced.

I am interested on when this patch is planned to be merged?

 

Regards,

Bohdan Hunko

 

Cypress Semiconductor Ukraine

Engineer

CSUKR CSS ICW SW FW

Mobile: +38099 50 19 714
Bohdan.Hunko@infineon.com