Hi Bohdan,

> The first question is: who is responsible for making a call to mark TFM image as accepted ? Is this responsibility of NS application?

It is IMPDEF. Application should define a built in self-test (BIST), which verify the device healthiness.  E.g: It can be the NS app checking the connectivity to the remote server.

> Doesn’t this create a possibility for security violation?

Without knowing the signing key I do not think so. In the case of tampering the image (requires a vulnerability in FWU code) in the primary slot, then at next restart the image will be rejected and device does not boot up.

BR,

Tamas

From: TF-M <tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Bohdan Hunko via TF-M
Sent: 2021. október 13., szerda 10:21
To: tf-m@lists.trustedfirmware.org
Cc: Kostiantyn.Tkachov@infineon.com; Hennadiy.Kytsun@infineon.com
Subject: [TF-M] FWU mark TFM image as accepted

Hi everyone,

When studying FWU service I have noticed that there is a function

psa_status_t psa_fwu_accept(psa_image_id_t image_id)

It is used to mark image as accepted, and it works by writing magic number to image trailer.

This function can be used to mark NS or S application as accepted.

The first question is: who is responsible for making a call to mark TFM image as accepted ? Is this responsibility of NS application?

The second thing I see is write access problem.

TFM can receive a call to mark TFM image as accepted, so this means that TFM must have permission to write in its own  primary slot.

Doesn’t this create a possibility for security violation?

I can imagine that in ideal world TFM would only have Read and Execute mission for its own primary slot. The only thing that should be able to write to TFM primary slot should be bootloader (it need this functionality to swap images). No one else should be able to write into TFM primary slot.

Am I missing something?

Best regards,

Bohdan Hunko

Cypress Semiconductor Ukraine

Engineer

CSUKR CSS ICW SW FW

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