Add UC config for disabling storage hash validation #92

ccli8 · 2021-08-19T09:39:59Z

[x] I confirm this contribution is my own and I agree to license it with Apache 2.0.
[x] I confirm the moderators may change the PR before merging it in.
[x] I understand the release model prohibits detailed Git history and my contribution will be recorded to the list at the bottom of CONTRIBUTING.md.

Summary of changes

This PR tries to add one Update Client configuration option to disable the flow of storage hash validation for PAL using like PSA FWU API which doesn't support storage read of firmware candidate (no psa_fwu_read()).

@marcuschangarm

marcuschangarm · 2021-08-19T20:31:32Z

@ccli8 Thank you! I'll take a look!

ccli8 · 2021-08-20T09:38:53Z

@marcuschangarm I merge the suggestion and original #91 into this PR.

marcuschangarm · 2021-08-21T04:32:54Z

@ccli8 good catch with disabling ARM_UC_FEATURE_DELTA_PAAL!

I've sent you an email with an alternative solution to disabling hash calculations, since that would have a negative impact on our security story.

ccli8 · 2021-08-23T03:28:23Z

I've sent you an email with an alternative solution to disabling hash calculations, since that would have a negative impact on our security story.

@marcuschangarm I merge the in-transmit hash validation alternative into this PR. It's fine per my test.

ccli8 · 2021-08-24T06:28:03Z

@marcuschangarm Added PSA implementation update-client-hub/modules/pal-psa. It follows update-client-hub/modules/pal-flashiap-mcuboot for firmware metadata management assuming secure bootloader is TF-M integrated MCUboot, and invokes PSA FWU API to install firmware candidate.

Currently, only non-secure firmware update is supported. To support secure or combined secure/non-secure firmware update, it is necessary to read header (and TLV) of active located in SPE, which is prohibited by TF-M.

marcuschangarm · 2021-08-24T18:29:57Z

update-client-hub/modules/pal-psa/source/arm_uc_pal_psa_implementation.c

+        uint32_t total_size = 0;
+
+        result = 
+            arm_uc_pal_psa_get_hash_from_header(arm_uc_flashiap_active_read,


I was expecting the hash to be read using the PSA call psa_fwu_query and not directly from memory: https://github.com/ARMmbed/mbed-os/blob/master/platform/FEATURE_EXPERIMENTAL_API/FEATURE_PSA/TARGET_TFM/TARGET_TFM_LATEST/include/psa/update.h#L178-L193

Originally, I also expect psa_fwu_query() can do the hash calculation, but situation isn't so smooth: TF-M's psa_fwu_query() doesn't return hash of active firmware for security concern
https://github.com/OpenNuvoton/trusted-firmware-m/blob/149271c63a448b0d690b41ae62dfbf3f36abcf72/secure_fw/partitions/firmware_update/bootloader/mcuboot/tfm_mcuboot_fwu.c#L529-L533

I see. That doesn't seem right, but it is what it is.

I would suggest using the firmware version (x.y.z) as the key instead of the hash then. That would make the solution generic without depending on where the image is stored and whether the client has read permissions. The tradeoff is that new firmware must increment the version number for the client to detect any errors during installation.

Using PSA firmware version (x.y.z) (actually, it is MCUboot firmware version) to identify firmware is one approach, but it is not workable in practice. Currently, in Mbed, all M2354 and Musca hardcode MCUboot firmware version to 1.3.0, that is, TF-M version. It is not a requirement to advance MCUboot firmware version number each build.

That doesn't sound right. You should be able to set the firmware version when signing the image: https://mcu-tools.github.io/mcuboot/imgtool.html#signing-images

Yes, mcuboot firmware version is specified on signing. But currently, Mbed integrated build system doesn't open this. I suggest adding one Update Client configuration so that secure or combined firmware update can be supported for such build system supporting the expected firmware versioning.

https://github.com/ARMmbed/mbed-os/blob/f6e165febec105c042137a4d1bf663a58968aac8/platform/FEATURE_EXPERIMENTAL_API/FEATURE_PSA/TARGET_TFM/TARGET_TFM_LATEST/scripts/generate_mbed_image.py#L52-L56

That sounds like a PR to Mbed OS would fix that problem? From the Update client's and PSA's point of view there are three options:

Full image update, updating both Secure and Non-Secure partition.

Secure image update.

Non-secure image update.

Using the concatenated version for both secure and non-secure as the key to KCM would make the update work as intended as long as the version is correctly incremented.

I raise one PR to Mbed so that image version (Major.Minor.Revision+Build) via psa_fwu_query() is unique. For this PR, I update for above discussion, plus removing unnecessary code.

Sounds good, I'll take another look and get back to you!

marcuschangarm · 2021-08-24T18:39:55Z

update-client-hub/modules/pal-psa/source/arm_uc_pal_psa_implementation.c

+        if (result.error != ERR_NONE) {
+
+            /* calculate hash from active image */
+            result = arm_uc_pal_psa_calculate_hash(arm_uc_flashiap_active_read,


I added this to the MCUBoot version to handle the corner case where one wanted to do a delta update as the very first update. In that scenario, the KCM would be empty and the update client would not be able to verify that the delta image matches the image it is supposed to be applied to.

For the PSA implementation, I would expect the secure side, e.g., TFM, to do the delta update since reading from memory is not guaranteed with PSA.

Not clear about delta update. It seems Update Client needs to read active firmware plus delta update patch to generate intended new firmware for update. For non-secure firmware update, it is possible because non-secure active firmware can read. But for secure or combined firmware update, read is prohibited as pointed out.

marcuschangarm · 2021-08-24T18:44:54Z

update-client-hub/modules/pal-psa/source/arm_uc_pal_psa_implementation.c

+        /* TODO: Currently, only non-secure firmware update is supported. To support
+         *       secure/combined firmware update, it is necessary to read
+         *       header (and TLV) of active located in SPE, which is prohibited by
+         *       TF-M. */


It shouldn't be necessary to calculate the hash in this file when using psa_fwu_set_manifest and psa_fwu_query. Depending on how the system is configured, it should be possible to do a full system update, updating secure and non-secure at the same time. In the new FOTA client it would also be possible to use component update to update each side individually.

As above, TF-M's psa_fwu_query() doesn't return hash of active firmware. Besides, its psa_fwu_set_manifest() doesn't support. So I need to parse mcuboot and calculate hash of active firmware manually. But the solution can apply only on non-secure firmware and cannot on secure or combined one.

https://github.com/ARMmbed/mbed-os/blob/f6e165febec105c042137a4d1bf663a58968aac8/platform/FEATURE_EXPERIMENTAL_API/FEATURE_PSA/TARGET_TFM/TARGET_TFM_LATEST/src/tfm_firmware_update_ipc_api.c#L183-L190

1. Add configuration UPDATE_CLIENT_STORAGE_PSA for PSA PAL 2. Fix compile errors for PSA PAL having no ARM_UC_FEATURE_PAL_FLASHIAP support 3. Support in-transit hash validation for like PSA PAL having no read permission and unable to do read-back hash validation from storage 4. Add PSA PAL implementation

ccli8 force-pushed the nuvoton_uc_dis_stor_hash_valid branch from b07b2e3 to 1ef3df2 Compare August 20, 2021 09:31

ccli8 mentioned this pull request Aug 20, 2021

Fix compile error for Mbed TF-M V8M target (2) #91

Closed

ccli8 force-pushed the nuvoton_uc_dis_stor_hash_valid branch 2 times, most recently from 4bda366 to 8e27558 Compare August 23, 2021 03:23

ccli8 force-pushed the nuvoton_uc_dis_stor_hash_valid branch from 8e27558 to 25fabfe Compare August 24, 2021 06:14

marcuschangarm reviewed Aug 24, 2021

View reviewed changes

ccli8 mentioned this pull request Aug 27, 2021

M2354: Generate unique MCUboot image version ARMmbed/mbed-os#15027

Merged

ccli8 force-pushed the nuvoton_uc_dis_stor_hash_valid branch from 25fabfe to 8ee7cc3 Compare August 27, 2021 09:19

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add UC config for disabling storage hash validation #92

Add UC config for disabling storage hash validation #92

ccli8 commented Aug 19, 2021

marcuschangarm commented Aug 19, 2021

ccli8 commented Aug 20, 2021

marcuschangarm commented Aug 21, 2021

ccli8 commented Aug 23, 2021

ccli8 commented Aug 24, 2021

marcuschangarm Aug 24, 2021

ccli8 Aug 25, 2021

marcuschangarm Aug 26, 2021

ccli8 Aug 26, 2021

marcuschangarm Aug 26, 2021

ccli8 Aug 26, 2021

marcuschangarm Aug 27, 2021 •

edited

Loading

ccli8 Aug 27, 2021

marcuschangarm Sep 1, 2021

marcuschangarm Aug 24, 2021

ccli8 Aug 25, 2021

marcuschangarm Aug 24, 2021

ccli8 Aug 25, 2021

Add UC config for disabling storage hash validation #92

Are you sure you want to change the base?

Add UC config for disabling storage hash validation #92

Conversation

ccli8 commented Aug 19, 2021

Summary of changes

marcuschangarm commented Aug 19, 2021

ccli8 commented Aug 20, 2021

marcuschangarm commented Aug 21, 2021

ccli8 commented Aug 23, 2021

ccli8 commented Aug 24, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

marcuschangarm Aug 27, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

marcuschangarm Aug 27, 2021 •

edited

Loading