Setting the image as accepted/confirmed only after a run-once test should be a common use case. So, the application anyway should mark somewhere of the image to tell MCUboot that the image is a good one.
The area is at the image trailer and the psa_fwu_accept API only exposes the “image_id” parameter. The user cannot manipulate other flash area vid the psa_fwu_accept API by setting an invalid “image_id” argument.
It can be accessed by all PSA RoT code which runs with privileged mode. On musca_b1 board, this is achieve by the APBSPPPCEXP0 register in the secure privilege control block.
Regards,
Sherry
From: TF-M <tf-m-bounces@lists.trustedfirmware.org>
On Behalf Of chris.brand--- via TF-M
Sent: Thursday, October 14, 2021 1:18 AM
To: Tamas Ban <Tamas.Ban@arm.com>; Bohdan.Hunko@infineon.com; tf-m@lists.trustedfirmware.org
Cc: Kostiantyn.Tkachov@infineon.com; nd <nd@arm.com>; Hennadiy.Kytsun@infineon.com
Subject: Re: [TF-M] FWU mark TFM image as accepted
The signature only helps after a reboot. Surely it would be more secure if TFM didn’t have permission to modify its own code at all? Anything TF-M can read could be exfiltrated before the next reboot. Is it only the FWU code that has this
permission, or is it any PSA RoT code?
Chris
From: TF-M <tf-m-bounces@lists.trustedfirmware.org>
On Behalf Of Tamas Ban via TF-M
Sent: Wednesday, October 13, 2021 2:09 AM
To: Hunko Bohdan (CSUKR CSS ICW SW FW) <Bohdan.Hunko@infineon.com>;
tf-m@lists.trustedfirmware.org
Cc: Tkachov Kostiantyn (CSUKR CSS ICW SW FW) <Kostiantyn.Tkachov@infineon.com>; nd <nd@arm.com>; Kytsun Hennadiy (CSUKR CSS ICW SW FW) <Hennadiy.Kytsun@infineon.com>
Subject: Re: [TF-M] FWU mark TFM image as accepted
|
Caution: This e-mail originated outside Infineon Technologies. Do not click
on links or open attachments unless you
validate it is safe. |
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