Hi,

TF-M version information is carried by manifest data, which is appended to the image in a post build step (at image signing):

* Image header: Contains image actual version: 1.0.0 * Image TLV (footer): Can contains a dependency TLV entry which refers to the dependent image by an ID and its minimum version.

Dependency verification:

* At boot time the bootloader checks whether the dependency would be satisfies after a software upgrade. If not then it deny the update. * https://git.trustedfirmware.org/trusted-firmware-m.git/tree/docs/user_guides...

At runtime there is no API to get the image version or its capability.

Did I answer your question?

Tamas

From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of Reinhard Keil via TF-M Sent: 09 March 2020 09:45 To: tf-m@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: [TF-M] Product Lifecycle Management: TF-M + Non-Secure Application

Hi,

How does TF-M consider Product Lifecycle Management (PLM)?

Assuming the following scenario where TF-M and Non-Secure Application are independently developed/updated in a deployed system:

* TF-M is delivered i.e. by a silicon vendor in a pre-configured variant and Non-Secure Application starts to use this configuration. * During PLM there is a decision to update/upgrade/downgrade TF-M. The new image is pushed to deployed devices independent of Non_Secure application.

Questions that I have:

* Is there a way for the Non-Secure application to identify the functionality available in TF-M? * How is it ensured that new TF-M versions are compatible with previous versions?

Reinhard