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/tfm_secure_boot.rst#n289

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