Hi Suresh,
I think still there is some misunderstanding here about the role of MCUboot in the update process.
I try to clarify it:
* MCUboot is the *bootloader* in the system, it does not care how the new images are getting installed on the device.
* MCUboot defines a static allocation of the flash. There are the primary slot where the active runtime images are stored and executed from there (if upgrade startegy is XIP) and there are the secondary slot where the candidate image is written by the update client, which his part of the runtime firmware.
* MCUboot is not involved at all in the process when new image is downloaded from the remote server and written to the flash (to secondary slot).
* MCUboot jobs to recognize that there is a new image (magic value is set at the end of secondary slot), validates it (hash + signature) and move it (if valid) to the primary slot to make it executable (because image is XIP and linked to the address space of the primary slot)
* When moving is done just jumps to the reset handler of the new image.
TF-M expose a standard FWU API, which can be used by any cloud client:
* FWU partition in the secure side is responsible to write the new image to the flash
* Because TF-M relies on MCUBoot as a bootloader therefore the image must be placed to the right place in the flash (secondary slot) and some MCUboot specific flags must be set (magic value to indicate new image existence). Therefore in the FWU secure partition there is a MCUboot shim layer to handle these bootloader specific task
* However, MCUBoot can replaced by any bootloader if one wants and then the shim layer also can be replaced to do other bootloader specific things.
* In this architecture update client is responsible to download the image from the remote server and the FWU partition is responsible to write it to the right location.
An implementer can choose:
* Implement the FWU API on the non-secure side
* Do not use FWU API, just writes the image to the right flash location and set certain flags in the flash that allows MCUboot to find the image
* Replace MCUboot with custom bootloader if he wants
I hope this helps!
The call path in the previous mail was incorrect. The correct call path is:
Update client application
|
| Function call
V
FWU API
|
| TF-M psa_call() etc.
V
FWU Partition
|
| Function call
V
MCUBoot Shim Layer
|
| Function call
V
MCUBoot user API
========================== RESTART ======================
MCUboot engine parse flash, validate new image, if there is any, and move it around to the primary slot
|
|
V Function call, never returns
Reset_Handler of new image
BR,
Tamas
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Suresh Marisetty via TF-M
Sent: 2021. május 25., kedd 16:16
To: Andrew Thoelke <Andrew.Thoelke(a)arm.com>; tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] Firmware update API - MCUboot update
Hi Andrew,
I am thinking of two paths for the update client application: one through MCUBoot and another direct to the FWU interface. MCUBoot path is for legacy application compatibility purpose. Longer term, I am wondering if MCUBoot is needed.
In embedded there is always a challenge to optimize the code size as space in storage is limited and any optimization to remove redundancies will help.
Update client application
|
| Function call
V V
MCUBoot user API |
Shim layer |
| |
| Function call |
V |
FWU API <------------|
|
| TF-M psa_call() etc.
V
FWU Partition
|
| Function call
V
MCUBoot user API
MCUBoot engine
MCUBoot image size is around 60K and
thanks
Suresh Marisetty
Infineon Semiconductor Corporation
From: Andrew Thoelke <Andrew.Thoelke(a)arm.com<mailto:Andrew.Thoelke@arm.com>>
Sent: Tuesday, May 25, 2021 1:39 AM
To: Marisetty Suresh (CYSC CSS ICW SW SSE) <Suresh.Marisetty(a)infineon.com<mailto:Suresh.Marisetty@infineon.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: RE: Firmware update API - MCUboot update
Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe<https://goto.infineon.com/SocialEngineering>.
Hi Suresh,
> I am of the belief that MCUboot will be a very thin shim layer over the FWU API to provide the compatibility interface to legacy software and most of the work that was done earlier in MCUboot is pushed down into the FWU partition.
Are you suggesting that the software stack might look like this:
Update client application
|
| Function call
V
MCUBoot user API
Shim layer
|
| Function call
V
FWU API
|
| TF-M psa_call() etc.
V
FWU Partition
|
| Function call
V
MCUBoot user API
MCUBoot engine
This looks like it has one more layer than it needs, as either:
1. The Update client application could Talk directly to the FWU API, or
2. The first MCUBoot user API could interact with an MCUBoot update partition (RoT Service), without having to tunnel the MCUBoot API over the FWU API. The latter might not be straightforward - I am not sure that anyone has reviewed the two APIs for this purpose.
Are you only considering this software stack for a system where touching the update client application source code is not possible (needed for option #1 above)? - and you also cannot introduce a custom MCUBoot RoT Service partition (option #2 above) so you want to reuse TF-M's existing FWU API and partition?
Regards,
Andrew
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Suresh Marisetty via TF-M
Sent: 25 May 2021 02:37
To: Sherry Zhang <Sherry.Zhang2(a)arm.com<mailto:Sherry.Zhang2@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: Re: [TF-M] Firmware update API - MCUboot update
Hi Sherry,
Thanks for the info. Wondering if there is some documentation or powerpoint explaining how the MCUBoot is changed to accommodate the FWU API.
Details that would help:
1. How the MCUboot works without the FWU API - natively
2. How the MCUBoot needs to be modified to leverage from FWU API
3. What components are retained in MCUBoot ex: image format, signing, metadata, tools
I am of the belief that MCUboot will be a very thin shim layer over the FWU API to provide the compatibility interface to legacy software and most of the work that was done earlier in MCUboot is pushed down into the FWU partition.
The other way to look at it is: If somebody wants to replace MCUboot with a simple BL to integrate it tightly into TFM, what would that look like?
thanks
Suresh Marisetty
Infineon Semiconductor Corporation
From: Sherry Zhang <Sherry.Zhang2(a)arm.com<mailto:Sherry.Zhang2@arm.com>>
Sent: Thursday, May 13, 2021 7:51 PM
To: Marisetty Suresh (CYSC CSS ICW SW SSE) <Suresh.Marisetty(a)infineon.com<mailto:Suresh.Marisetty@infineon.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: RE: Firmware update API - MCUboot update
Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe<https://goto.infineon.com/SocialEngineering>.
Hi Suresh,
The MCUboot update functionality is about validating the existing images on the device which is different from that of the firmware update service which follows mostly with the PSA Firmware Update API spec<https://developer.arm.com/documentation/ihi0093/latest/>.
We designed a shim layer between the firmware update partition and bootloader. A specific bootloader can be ported into the firmware update partition via that shim layer. Please refer to the firmware update service document<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/techn…>. In the MCUboot based shim layer implementation, it calls some user/public APIs provided by MCUboot to achieve its functionality. For example, the Firmware Update API spec describes that psa_fwu_install() API should validate the image or defer the validation to a system reboot. In the MCUboot shim layer implementation, it calls the boot_write_magic() API to mark the image as a candidate image for MCUboot and defers the image validation to a system reboot. Please refer to this link<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/secure_fw/…>.
Can you please provide more specific suggestion or questions?
Regards,
Sherry Zhang
From: Suresh.Marisetty(a)infineon.com<mailto:Suresh.Marisetty@infineon.com> <Suresh.Marisetty(a)infineon.com<mailto:Suresh.Marisetty@infineon.com>>
Sent: Thursday, May 13, 2021 11:40 PM
To: Sherry Zhang <Sherry.Zhang2(a)arm.com<mailto:Sherry.Zhang2@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: RE: Firmware update API - MCUboot update
Hi Sherry,
Please take a closer look at the MCUboot and TFM might want to have a clear position/distinction between these two and how to transition from MCUboot update to this mechanism or it could be that they complement each other.
thanks
Suresh Marisetty
Infineon Semiconductor Corporation
From: Sherry Zhang <Sherry.Zhang2(a)arm.com<mailto:Sherry.Zhang2@arm.com>>
Sent: Wednesday, May 12, 2021 8:55 PM
To: Marisetty Suresh (CYSC CSS ICW SW SSE) <Suresh.Marisetty(a)infineon.com<mailto:Suresh.Marisetty@infineon.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: RE: Firmware update API - MCUboot update
Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe<https://goto.infineon.com/SocialEngineering>.
Hi Suresh,
The firmware update service APIs are for updating the firmware. The functionalities of these APIs includes loading the image into its target device(flash), verifying the image and installing it and so on.
The user can call the these APIs to achieve update images. For example, in the integration of TF-M and the FreeRTOS OTA<https://github.com/Linaro/amazon-freertos/blob/tfm-fwu/libraries/abstractio…>, the OTA agent calls the firmware update service APIs to achieve an image update remotely.
I guess that the "MCUboot update services" you mentioned refers to the functionality of MCUboot which acts as a bootloader. As a bootloader, it can verify the image which already exists on the device and chose the right image to start up. But it cannot, for example, load the image into device or control the image update process.
The firmware update partition calls some user APIs provided by MCUboot to cooperate with it. You can refer to https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/techn….
Regards,
Sherry Zhang
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Suresh Marisetty via TF-M
Sent: Thursday, May 13, 2021 11:09 AM
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: [TF-M] Firmware update API - MCUboot update
Hi,
I would like to see if there is any guidance/documentation on how to coordinate between the firmware update services API with that of MCUboot.
Does the use of this API make the MCUboot update services redundant?
thanks
Suresh Marisetty
Infineon Semiconductor Corporation
Lead Member of Technical Staff
CYSC CSS ICW SW SSE
Mobile: +5103863997
Suresh.Marisetty(a)infineon.com<mailto:Suresh.Marisetty@infineon.com>
Hi Jamie,
10-2020-q4-major is the latest release version. I have no idea on when the defect can be fixed in the future GCC 10 release. I think you can query that information in the tools community
https://community.arm.com/developer/tools-software/tools?_ga=2.153861944.16….
Regards,
Sherry Zhang
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Jamie Mccrae via TF-M
Sent: Tuesday, July 27, 2021 5:50 PM
To: David Hu <David.Hu(a)arm.com>; Anton Komlev <Anton.Komlev(a)arm.com>; tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] TF-M v1.4.0 release started
Hi David,
The ARM GCC 10 build from https://developer.arm.com/tools-and-software/open-source-software/developer… does indeed seem to be the cause of the issue, tests are now all passing. Do you know on any timeframe for when an updated version of GCC 10 will be available from ARM which fixes this issue?
Thanks,
Jamie
From: David Hu <David.Hu(a)arm.com<mailto:David.Hu@arm.com>>
Sent: 27 July 2021 10:09
To: David Hu <David.Hu(a)arm.com<mailto:David.Hu@arm.com>>; Jamie Mccrae <Jamie.Mccrae(a)lairdconnect.com<mailto:Jamie.Mccrae@lairdconnect.com>>; Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: RE: TF-M v1.4.0 release started
Hi Jamie,
Can I ask about your toolchain in use?
GNUARM 10-2020-q4-major will cause a similar issue. TF-M suggests to avoid using this version: https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/getti….
Best regards,
Hu Ziji
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of David Hu via TF-M
Sent: Tuesday, July 27, 2021 4:48 PM
To: Jamie Mccrae <Jamie.Mccrae(a)lairdconnect.com<mailto:Jamie.Mccrae@lairdconnect.com>>; Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: [TF-M] FW: TF-M v1.4.0 release started
Hi Jamie,
Sorry for the trouble.
According to your description, the violation error is caused by non-secure test cases. is it correct?
The error message is dumped by tfm_secure_api_error_handler(). It is called multiple times in Library model routine.
Can you please help narrow the step in which tfm_secure_api_error_handler() is called?
Besides, do you mind trying if IPC model can work on your board?
Best regards,
Hu Ziji
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Jamie Mccrae via TF-M
Sent: Tuesday, July 27, 2021 3:43 PM
To: Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: Re: [TF-M] TF-M v1.4.0 release started
Hi,
I have tried the RC1 and RC2 on our platform, the BL5340 (nRF5340-based), which I am testing by building with the following:
cmake -DTFM_PLATFORM=lairdconnectivity/bl5340_dvk_cpuapp -GNinja -DTFM_TOOLCHAIN_FILE=../toolchain_GNUARM.cmake -DTEST_S=on -DTEST_NS=on -DCMAKE_BUILD_TYPE=debug -DPS_TEST_NV_COUNTERS=on ..
And upon starting the non-secure tests, a security violation occurs which reboots the module. Output from secure core:
Test suite 'Crypto secure interface tests (TFM_S_CRYPTO_TEST_1XXX)' has PASSED
Test suite 'Initial Attestation Service secure interface tests(TFM_S_ATTEST_TEST_1XXX)' has PASSED
Test suite 'Platform Service Secure interface tests(TFM_S_PLATFORM_TEST_1XXX)' has PASSED
Test suite 'Audit Logging secure interface test (TFM_S_AUDIT_TEST_1XXX)' has PASSED
*** End of Secure test suites ***
Security violation when calling secure API
[INF] Starting bootloader
[INF] Primary image: magic=good, swap_type=0x1, copy_done=0x3, image_ok=0x3
[INF] Scratch: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[INF] Boot source: primary slot
Output from non-secure core:
Non-Secure system starting...
#### Execute test suites for the Non-secure area ####
Running Test Suite PSA protected storage NS interface tests (TFM_NS_PS_TEST_1XXX)...
> Executing 'TFM_NS_PS_TEST_1001'
Description: 'Set interface'
Non-Secure system starting...
So something that has changed from 1.3 to 1.4 seems to have broken our platform.
Thanks,
Jamie
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Anton Komlev via TF-M
Sent: 26 July 2021 09:50
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: Re: [TF-M] TF-M v1.4.0 release started
EXTERNAL EMAIL: Be careful with attachments and links.
Hi,
All TF-M repositories are updated with TF-Mv1.4.0-RC2 tag.
The changes are minimal and shall not invalidate the tests, already done.
Please use this tag for new tests and report any issues found by the end of July 30.
Thanks and good luck,
Anton
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Anton Komlev via TF-M
Sent: Wednesday, July 21, 2021 11:25 AM
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: [TF-M] TF-M v1.4.0 release started
Hi,
All TF-M repositories are tagged with TF-Mv1.4.0-RC1 tag.
Code is frozen now for the release candidate testing. Note that changes to other repositories are still possible during that time.
Please use this tag for your tests and report any issues found by the end of July 30.
Thanks and good luck,
Anton
THIS MESSAGE, ANY ATTACHMENT(S), AND THE INFORMATION CONTAINED HEREIN MAY BE PROPRIETARY TO LAIRD CONNECTIVITY, INC. AND/OR ANOTHER PARTY, AND MAY FURTHER BE INTENDED TO BE KEPT CONFIDENTIAL. IF YOU ARE NOT THE INTENDED RECIPIENT, PLEASE DELETE THE EMAIL AND ANY ATTACHMENTS, AND IMMEDIATELY NOTIFY THE SENDER BY RETURN EMAIL. THIS MESSAGE AND ITS CONTENTS ARE THE PROPERTY OF LAIRD CONNECTIVITY, INC. AND MAY NOT BE REPRODUCED OR USED WITHOUT THE EXPRESS WRITTEN CONSENT OF LAIRD CONNECTIVITY, INC.
Hi experts,
I want to know how to define the init sequence of secure partitions in
tf-m. For example, PS partition may have dependency on crypto service, if
PS_ENCRYPTION defined ,ps_init() needs calling crypto services, so I think
crypto_init()should be done before ps_init().
Best Regards,
Poppy Wu
Macronix Microelectronics (Suzhou) Co.,Ltd
http://www.mxic.com.cn
============================================================================
CONFIDENTIALITY NOTE:
This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as its attachment(s) from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation.
Macronix International Co., Ltd.
=====================================================================
Hi Chris,
Yes, the following crypto tests are failed as known issue.
Tests related with psa_mac_xxx are failed because of a mbedtls issue:https://github.com/ARMmbed/mbedtls/issues/4755
psa_hash_suspend() and psa_hash_resume() have not supported in TF-M and Mbed TLS currently, so test 262 and 263 will fail.
We will publish PSA Arch Crypto Test Failure Analysis In TF-M V1.4 Release note.
It's welcome to feedback any special or strange failure test case to us if you met.
Best Regards,
Summer
________________________________
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of chris.brand--- via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: Tuesday, July 27, 2021 11:18 PM
To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org>
Subject: Re: [TF-M] TF-M v1.4.0 release started
We ran the regression test suite on PSoC64.
We did see some failures in the PSA Arch crypto tests:
TEST: 226 | DESCRIPTION: Testing crypto MAC APIs | UT: psa_mac_sign_setup
TEST: 227 | DESCRIPTION: Testing crypto MAC APIs | UT: psa_mac_update
TEST: 228 | DESCRIPTION: Testing crypto MAC APIs | UT: psa_mac_sign_finish
TEST: 229 | DESCRIPTION: Testing crypto MAC APIs | UT: psa_mac_verify_setup
TEST: 230 | DESCRIPTION: Testing crypto MAC APIs | UT: psa_mac_verify_finish
TEST: 262 | DESCRIPTION: Testing crypto hash functions APIs | UT: psa_hash_suspend
TEST: 263 | DESCRIPTION: Testing crypto hash functions APIs | UT: psa_hash_resume
This is consistent between Debug/Release and gcc/armclang.
Do we know whether the PSA Arch Crypto tests are passing on other platforms?
Chris
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M
Sent: Monday, July 26, 2021 1:50 AM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] TF-M v1.4.0 release started
Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe<https://intranet-content.infineon.com/explore/aboutinfineon/rules/informati…>.
Hi,
All TF-M repositories are updated with TF-Mv1.4.0-RC2 tag.
The changes are minimal and shall not invalidate the tests, already done.
Please use this tag for new tests and report any issues found by the end of July 30.
Thanks and good luck,
Anton
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Anton Komlev via TF-M
Sent: Wednesday, July 21, 2021 11:25 AM
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: [TF-M] TF-M v1.4.0 release started
Hi,
All TF-M repositories are tagged with TF-Mv1.4.0-RC1 tag.
Code is frozen now for the release candidate testing. Note that changes to other repositories are still possible during that time.
Please use this tag for your tests and report any issues found by the end of July 30.
Thanks and good luck,
Anton
Hi Kevin,
Thank you for your reply. It turned out to be the configuration problems
of this peripheral.
Best Regards,
Poppy Wu
Kevin Peng via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent by: "TF-M" <tf-m-bounces(a)lists.trustedfirmware.org>
2021/07/28 13:58
Please respond to
Kevin Peng <Kevin.Peng(a)arm.com>
To
Edward Yang <EdwardYang(a)mxic.com.cn>
cc
"tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org>
Subject
Re: [TF-M] spi peripheral doesn't work in secure world
Hi Poppy,
Mmio_regions is required for Secure Partitions to access peripherals, even
though in some cases it would work without mmio_regions declaration.
Could you please provide more information such as what’s your build
configuration and what’s the type of your Secure Partition?
Have you put the driver codes into the Secure Partition’s library in the
TF-M build system? Are you seeing any exceptions or errors?
Best Regards,
Kevin
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edward
Yang via TF-M
Sent: Wednesday, July 28, 2021 11:23 AM
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] spi peripheral doesn't work in secure world
Hi experts,
We are running Arm TF-M on stm32l562e_dk board, and we add a new secure
partition based on TF-M architecture according to our specific
application.In this new secure partition ,spi peripheral is used to
communicate with a external spi nor flash.
If we just test the spi driver in non-secure world(without tf-m),it works
well.
Then we put this driver in secure world,it's a plarform driver used by
this new secure partition,and we have configured the spi peripheral as
secure peripheral in gtzc_init_cfg() inside tfm_core_init().
We used a logic analyzer to debug, and found there was no spi
communication waveform, it seems that this peripheral doesn't work in
secure world,. We didn't declare this new partition's dependency on spi
peripheral in its manifest files with mmio_regions. And I am not sure
whether this is why the spi peripheral doesn't work. Is there anything
else that we should pay attention to?
Best Regards,
Poppy Wu
Macronix Microelectronics (Suzhou) Co.,Ltd
http://www.mxic.com.cn
CONFIDENTIALITY NOTE:
This e-mail and any attachments may contain confidential information
and/or personal data, which is protected by applicable laws. Please be
reminded that duplication, disclosure, distribution, or use of this e-mail
(and/or its attachments) or any part thereof is prohibited. If you receive
this e-mail in error, please notify us immediately and delete this mail as
well as its attachment(s) from your system. In addition, please be
informed that collection, processing, and/or use of personal data is
prohibited unless expressly permitted by personal data protection laws.
Thank you for your attention and cooperation.
Macronix International Co., Ltd.
=====================================================================--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
============================================================================
CONFIDENTIALITY NOTE:
This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as its attachment(s) from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation.
Macronix International Co., Ltd.
=====================================================================
Hi Chris,
Please check the PSA Arch Crypto test failure analysis<https://developer.trustedfirmware.org/w/tf_m/release/psa_arch_crypto_test_f…> for TF-M 1.4 release. The data comes from an521 and musca_b1/sse_200 platforms.
Please feel free to contact us if you have any questions : )
Best Regards,
Summer
________________________________
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Anton Komlev via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: Wednesday, July 28, 2021 4:34 PM
To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] TF-M v1.4.0 release started
Hi,
All TF-M repositories are updated with TF-Mv1.4.0-RC3 tag.
There were no code change so assume all completed tests are still valid.
Please use this tag for new tests and report any issues found by the end of July 30.
Thanks,
Anton
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Summer Qin via TF-M
Sent: Wednesday, July 28, 2021 8:22 AM
To: tf-m(a)lists.trustedfirmware.org; Chris.Brand(a)infineon.com
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] TF-M v1.4.0 release started
Hi Chris,
Yes, the following crypto tests are failed as known issue.
Tests related with psa_mac_xxx are failed because of a mbedtls issue:https://github.com/ARMmbed/mbedtls/issues/4755
psa_hash_suspend() and psa_hash_resume() have not supported in TF-M and Mbed TLS currently, so test 262 and 263 will fail.
We will publish PSA Arch Crypto Test Failure Analysis In TF-M V1.4 Release note.
It's welcome to feedback any special or strange failure test case to us if you met.
Best Regards,
Summer
________________________________
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of chris.brand--- via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>
Sent: Tuesday, July 27, 2021 11:18 PM
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>
Subject: Re: [TF-M] TF-M v1.4.0 release started
We ran the regression test suite on PSoC64.
We did see some failures in the PSA Arch crypto tests:
TEST: 226 | DESCRIPTION: Testing crypto MAC APIs | UT: psa_mac_sign_setup
TEST: 227 | DESCRIPTION: Testing crypto MAC APIs | UT: psa_mac_update
TEST: 228 | DESCRIPTION: Testing crypto MAC APIs | UT: psa_mac_sign_finish
TEST: 229 | DESCRIPTION: Testing crypto MAC APIs | UT: psa_mac_verify_setup
TEST: 230 | DESCRIPTION: Testing crypto MAC APIs | UT: psa_mac_verify_finish
TEST: 262 | DESCRIPTION: Testing crypto hash functions APIs | UT: psa_hash_suspend
TEST: 263 | DESCRIPTION: Testing crypto hash functions APIs | UT: psa_hash_resume
This is consistent between Debug/Release and gcc/armclang.
Do we know whether the PSA Arch Crypto tests are passing on other platforms?
Chris
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Anton Komlev via TF-M
Sent: Monday, July 26, 2021 1:50 AM
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: Re: [TF-M] TF-M v1.4.0 release started
Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe<https://intranet-content.infineon.com/explore/aboutinfineon/rules/informati…>.
Hi,
All TF-M repositories are updated with TF-Mv1.4.0-RC2 tag.
The changes are minimal and shall not invalidate the tests, already done.
Please use this tag for new tests and report any issues found by the end of July 30.
Thanks and good luck,
Anton
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Anton Komlev via TF-M
Sent: Wednesday, July 21, 2021 11:25 AM
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: [TF-M] TF-M v1.4.0 release started
Hi,
All TF-M repositories are tagged with TF-Mv1.4.0-RC1 tag.
Code is frozen now for the release candidate testing. Note that changes to other repositories are still possible during that time.
Please use this tag for your tests and report any issues found by the end of July 30.
Thanks and good luck,
Anton
Hi,
Is it possible/allowed to call a function in NSPE from a secure
partition using the GCC Cortex M Security Extensions (CMSE)? If NSPE
and SPE are on different cores then it is definitely not working but
in my case they are on the same M33 core.
If it is possible then I would like to call a semaphore P operation in
the RTOS that might block. Will that work?
Regards,
Jan.
Hi,
The next Technical Forum is planned on Thursday, August 5, 15:00-16:00 UTC (US time zone).
Please reply on this email with your proposals for agenda topics.
Recording and slides of previous meetings are here:
https://www.trustedfirmware.org/meetings/tf-m-technical-forum/
Best regards,
Anton
Hi,
All TF-M repositories are updated with TF-Mv1.4.0-RC3 tag.
There were no code change so assume all completed tests are still valid.
Please use this tag for new tests and report any issues found by the end of July 30.
Thanks,
Anton
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Summer Qin via TF-M
Sent: Wednesday, July 28, 2021 8:22 AM
To: tf-m(a)lists.trustedfirmware.org; Chris.Brand(a)infineon.com
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] TF-M v1.4.0 release started
Hi Chris,
Yes, the following crypto tests are failed as known issue.
Tests related with psa_mac_xxx are failed because of a mbedtls issue:https://github.com/ARMmbed/mbedtls/issues/4755
psa_hash_suspend() and psa_hash_resume() have not supported in TF-M and Mbed TLS currently, so test 262 and 263 will fail.
We will publish PSA Arch Crypto Test Failure Analysis In TF-M V1.4 Release note.
It's welcome to feedback any special or strange failure test case to us if you met.
Best Regards,
Summer
________________________________
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of chris.brand--- via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>
Sent: Tuesday, July 27, 2021 11:18 PM
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>
Subject: Re: [TF-M] TF-M v1.4.0 release started
We ran the regression test suite on PSoC64.
We did see some failures in the PSA Arch crypto tests:
TEST: 226 | DESCRIPTION: Testing crypto MAC APIs | UT: psa_mac_sign_setup
TEST: 227 | DESCRIPTION: Testing crypto MAC APIs | UT: psa_mac_update
TEST: 228 | DESCRIPTION: Testing crypto MAC APIs | UT: psa_mac_sign_finish
TEST: 229 | DESCRIPTION: Testing crypto MAC APIs | UT: psa_mac_verify_setup
TEST: 230 | DESCRIPTION: Testing crypto MAC APIs | UT: psa_mac_verify_finish
TEST: 262 | DESCRIPTION: Testing crypto hash functions APIs | UT: psa_hash_suspend
TEST: 263 | DESCRIPTION: Testing crypto hash functions APIs | UT: psa_hash_resume
This is consistent between Debug/Release and gcc/armclang.
Do we know whether the PSA Arch Crypto tests are passing on other platforms?
Chris
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Anton Komlev via TF-M
Sent: Monday, July 26, 2021 1:50 AM
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: Re: [TF-M] TF-M v1.4.0 release started
Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe<https://intranet-content.infineon.com/explore/aboutinfineon/rules/informati…>.
Hi,
All TF-M repositories are updated with TF-Mv1.4.0-RC2 tag.
The changes are minimal and shall not invalidate the tests, already done.
Please use this tag for new tests and report any issues found by the end of July 30.
Thanks and good luck,
Anton
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Anton Komlev via TF-M
Sent: Wednesday, July 21, 2021 11:25 AM
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: [TF-M] TF-M v1.4.0 release started
Hi,
All TF-M repositories are tagged with TF-Mv1.4.0-RC1 tag.
Code is frozen now for the release candidate testing. Note that changes to other repositories are still possible during that time.
Please use this tag for your tests and report any issues found by the end of July 30.
Thanks and good luck,
Anton
Hi Poppy,
Mmio_regions is required for Secure Partitions to access peripherals, even though in some cases it would work without mmio_regions declaration.
Could you please provide more information such as what's your build configuration and what's the type of your Secure Partition?
Have you put the driver codes into the Secure Partition's library in the TF-M build system? Are you seeing any exceptions or errors?
Best Regards,
Kevin
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edward Yang via TF-M
Sent: Wednesday, July 28, 2021 11:23 AM
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] spi peripheral doesn't work in secure world
Hi experts,
We are running Arm TF-M on stm32l562e_dk board, and we add a new secure partition based on TF-M architecture according to our specific application.In this new secure partition ,spi peripheral is used to communicate with a external spi nor flash.
[cid:image001.gif@01D783B8.24FD4C40]
If we just test the spi driver in non-secure world(without tf-m),it works well.
Then we put this driver in secure world,it's a plarform driver used by this new secure partition,and we have configured the spi peripheral as secure peripheral in gtzc_init_cfg() inside tfm_core_init().
We used a logic analyzer to debug, and found there was no spi communication waveform, it seems that this peripheral doesn't work in secure world,. We didn't declare this new partition's dependency on spi peripheral in its manifest files with mmio_regions. And I am not sure whether this is why the spi peripheral doesn't work. Is there anything else that we should pay attention to?
Best Regards,
Poppy Wu
Macronix Microelectronics (Suzhou) Co.,Ltd
http://www.mxic.com.cn<http://www.mxic.com.cn/>
CONFIDENTIALITY NOTE:
This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as its attachment(s) from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation.
Macronix International Co., Ltd.
=====================================================================
