Hi,
The next Technical Forum is planned on Thursday, October 28, 15:00-16:00 UTC (US time zone).
That session Chris Reed kindly agreed to present "Introduction to pyOCD" - the method to program and debug TF-M and Cortex-M MCUs, in general, using the open-source tool https://pyocd.io/
Recording and slides of previous meetings are here:
https://www.trustedfirmware.org/meetings/tf-m-technical-forum/
Best regards,
Anton
Hi all,
I'd like to introduce a CMAKE library dependency trace tool to you. This python script can
* Search a specific library's dependent libraries and to-be-linked libraries in a list of repo paths.
* Draw a diagram to show the link relationship.
* Give some other information about:
* Include paths
* Source files
* Compile definitions
The main feature of diagram is similar with [CMakeGraphVizOptions]<https://cmake.org/cmake/help/latest/module/CMakeGraphVizOptions.html#cmakeg…>, the differences are:
* The new tool can focus on certain library with specific trace depth like 1, 2 and n.
* The new tool is not runtime, it is a static search and can search all libraries whose runtime build may be silenced.
* The new tool makes the diagram more colourful to be more readable.
With this tool, I hope you can get and check the structure of CMAKE library more quickly when developing the code and libraries.
I have proposed a patch in tf-m-tools repo: [library dependency trace tool]<https://review.trustedfirmware.org/c/TF-M/tf-m-tools/+/12019>.
This tool may not be convenient for everyone of you so here I beg for your feedbacks to make it better. Thanks.
Best Regards
Jianliang Shen
Hi,
To support FFM 1.1 features (SFN mainly), the SPM logic is under significant updating till End of Oct, please:
- If you are doing release-targeted development, please based on the released tags.
- If you are developing with the latest master branch, please report bugs met. Our plan is to collect all bugs and fix them after this update, before the next release.
- Keen to receive your fixes and contributions. It would be very nice if you can do these.
All patches would go as a usual process, hence it should work for most of the configurations, except those not covered by the automation test. The platform related interfaces are not changing, hence no worry for platform owners.
Thanks!
/Ken
Hi Ken,
Thanks for the nice suggestions! I was thinking of using an interrupt from TF-M to NS world as well but that needs some hardware support, which should be fine since I'm still designing the device. Maybe there is a software interrupt solution?
Our application needs to put a biometric service inside TF-M and its enrollment process needs to send out some intermediate events to give the user some feedbacks. This is why I'm asking this question. I think TF-M can use an input buffer from NS world to store the new events and notify the NS world with the interrupt to fetch the new events. Sounds good?
Regards,
Jun
On 10/19/21, 00:23, "TF-M on behalf of tf-m-request(a)lists.trustedfirmware.org" <tf-m-bounces(a)lists.trustedfirmware.org on behalf of tf-m-request(a)lists.trustedfirmware.org> wrote:
Send TF-M mailing list submissions to
tf-m(a)lists.trustedfirmware.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
or, via email, send a message with subject or body 'help' to
tf-m-request(a)lists.trustedfirmware.org
You can reach the person managing the list at
tf-m-owner(a)lists.trustedfirmware.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of TF-M digest..."
Today's Topics:
1. Re: Sending events from TF-M to non-secure world? (Ken Liu)
2. Inline asm syntax unified and symbol reference in IAR
toolchain (Ken Liu)
----------------------------------------------------------------------
Message: 1
Date: Tue, 19 Oct 2021 02:06:35 +0000
From: Ken Liu <Ken.Liu(a)arm.com>
To: "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] Sending events from TF-M to non-secure world?
Message-ID:
<DB9PR08MB67613655A2ACA207C751C791F5BD9(a)DB9PR08MB6761.eurprd08.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"
Hi Jun,
Basically, the service accessing model is a client-service model, hence the service won't call back to the client which makes the client a 'service'. Service can get client info by passed-in parameters and other SPM controlled channels.
Assuming you are using a Trustzone based hardware, the hardware provides the capability that calling back to NSPE, but it is not encouraged inside TF-M because it breaks the simplified model proposed by FF-M and difficulties the secure threat analysis - a simple case is that the secure context is blocked because it is waiting for NS returns.
If you do need to perform such operations, implement an interrupt based asynchronous mechanism is safer than software callbacks.
The most queried requirement we have met is someone querying if the execution can be delivered back to NSPE when secure IDLE is going to happen. Not sure if you are facing the similar, is it okay to share more details?
BR
/Ken
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Li, Jun R via TF-M
Sent: Tuesday, October 19, 2021 12:20 AM
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] Sending events from TF-M to non-secure world?
Hi,
Anyone has idea how a service inside a secure partition can send out some events to the non-secure world? Does callback still work over IPC? It seems non-secure world can connect to a SP but not easy to do the other way.
Appreciate any comments or suggestions!
Jun
Intel Corporation @ SC, CA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.trustedfirmware.org/pipermail/tf-m/attachments/20211019/1ff875…>
Hi Sherry,
So I actually checked issue from last mail
‘When building TFM with CRYPTO_HW_ACCELERATOR=ON and BL2=OFF I am getting this error:’
and turns out everything is fine in master branch, that error is only present in my local branch due to changes I have made.
I am glad we have one bug less 😊
Sorry for wrong report.
Best regards,
Bohdan Hunko
Cypress Semiconductor Ukraine
Engineer
CSUKR CSS ICW SW FW
Mobile: +38099 50 19 714
Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>
From: Hunko Bohdan (CSUKR CSS ICW SW FW)
Sent: 01 October 2021 12:49
To: Hunko Bohdan (CSUKR CSS ICW SW FW) <Bohdan.Hunko(a)infineon.com>; Sherry.Zhang2(a)arm.com; Brand Chris (CSCA CSS ICW SW PSW 1) <Chris.Brand(a)infineon.com>; Kytsun Hennadiy (CSUKR CSS ICW SW FW) <Hennadiy.Kytsun(a)infineon.com>; Mazurak Roman (CSUKR CSS ICW SW FW) <Roman.Mazurak(a)infineon.com>; Tkachov Kostiantyn (CSUKR CSS ICW SW FW) <Kostiantyn.Tkachov(a)infineon.com>
Cc: nd(a)arm.com
Subject: RE: Enablement of external bl2 builds
Hi all,
One more thing on this topic.
There is one more issue with building TFM without BL2.
When building TFM with CRYPTO_HW_ACCELERATOR=ON and BL2=OFF I am getting this error:
CMake Error at platform/ext/accelerator/CMakeLists.txt:11 (add_library):
No SOURCES given to target: bl2_crypto_hw
So I think this is one more thing that needs to be fixed.
Best regards,
Bohdan Hunko
Cypress Semiconductor Ukraine
Engineer
CSUKR CSS ICW SW FW
Mobile: +38099 50 19 714
Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Bohdan Hunko via TF-M
Sent: 30 September 2021 17:34
To: Sherry.Zhang2(a)arm.com<mailto:Sherry.Zhang2@arm.com>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; Brand Chris (CSCA CSS ICW SW PSW 1) <Chris.Brand(a)infineon.com<mailto:Chris.Brand@infineon.com>>; Kytsun Hennadiy (CSUKR CSS ICW SW FW) <Hennadiy.Kytsun(a)infineon.com<mailto:Hennadiy.Kytsun@infineon.com>>; Mazurak Roman (CSUKR CSS ICW SW FW) <Roman.Mazurak(a)infineon.com<mailto:Roman.Mazurak@infineon.com>>; Tkachov Kostiantyn (CSUKR CSS ICW SW FW) <Kostiantyn.Tkachov(a)infineon.com<mailto:Kostiantyn.Tkachov@infineon.com>>
Cc: nd(a)arm.com<mailto:nd@arm.com>
Subject: Re: [TF-M] Enablement of external bl2 builds
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 Sherry,
Thanks for patching MCUBOOT_IMAGE_NUMBER issue. It was one of the issues we faced with.
I also agree that mcuboot_config.h should be taken from our BL2 repo. So no changes needed there.
About porting files (tfm/bl2 folder). We are planning to use existing porting files. But as you said currently they are not included into the build because BL2=0. So this needs to be fixed to include these porting files when TFM_PARTITION_FIRMWARE_UPDATE is ON.
One minor issue we have is BOOT_DATA_AVAILABLE currently it is only defined if BL2=1 and MCUBOOT_MEASURED_BOOT=1. See this line of code<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/secure_fw/…>.
I think we can either change that line of code or we can defile BOOT_DATA_AVAILABLE in our platform files using add_definitions(-DBOOT_DATA_AVAILABLE). First way is a bit harder but I thinks it fits better into TFM architecture. Second way is easier but it seems more like workaround than like solution. Do you have any suggestions about this problem?
We are not blocked by these issues, so no worries here.
Best regards
Bohdan Hunko
Cypress Semiconductor Ukraine
Engineer
CSUKR CSS ICW SW FW
Mobile: +38099 50 19 714
Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>
From: Sherry Zhang <Sherry.Zhang2(a)arm.com<mailto:Sherry.Zhang2@arm.com>>
Sent: 30 September 2021 11:38
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; Tkachov Kostiantyn (CSUKR CSS ICW SW FW) <Kostiantyn.Tkachov(a)infineon.com<mailto:Kostiantyn.Tkachov@infineon.com>>; Mazurak Roman (CSUKR CSS ICW SW FW) <Roman.Mazurak(a)infineon.com<mailto:Roman.Mazurak@infineon.com>>; Kytsun Hennadiy (CSUKR CSS ICW SW FW) <Hennadiy.Kytsun(a)infineon.com<mailto:Hennadiy.Kytsun@infineon.com>>; Hunko Bohdan (CSUKR CSS ICW SW FW) <Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: RE: Enablement of external bl2 builds
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 Bohdan,
I tried to build TF-M with FWU service without BL2 with the following command(FWU enabled with shared data while no BL2):
cmake -S . -B cmake_build -DTFM_PLATFORM=arm/musca_b1/sse_200 -DCRYPTO_HW_ACCELERATOR=OFF -DPLATFORM_DUMMY_NV_SEED=ON -DBL2=0 -DMCUBOOT_PATH=../mcuboot
The following issues I met:
1. Build time error by that ` MCUBOOT_IMAGE_NUMBER ` is passed as an empty macro into the flash_layout.h
I have created a patch to fix it. https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11729
1. Build error in ` bootutil_public.c `. The mcuboot_config.h which is generated automatically when the BL2=ON is not found. Also the files( in tf-m/bl2 folder) about porting MCUboot into TF-M is not found by the build system as BL2=0. For the config file, I think, it should be imported from your specific MCUboot repo as it is generated when BL2 image is built. For the MCUboot porting files, are you using the files under tf-m/bl2 folder or using your specific porting files? The FWU service needs the porting source files. See code at https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/secure_fw/….
Are your blocked by these two issues? Can you share the detailed issue you met if there is more?
Regards,
Sherry
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Bohdan Hunko via TF-M
Sent: Tuesday, September 28, 2021 6:44 PM
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: Kostiantyn.Tkachov(a)infineon.com<mailto:Kostiantyn.Tkachov@infineon.com>; Roman.Mazurak(a)infineon.com<mailto:Roman.Mazurak@infineon.com>; Hennadiy.Kytsun(a)infineon.com<mailto:Hennadiy.Kytsun@infineon.com>
Subject: [TF-M] Enablement of external bl2 builds
Hi everyone,
When adding support for new platform we ran into an issue with BL2 variable.
In our architecture we have Bootloader based on MCUboot (aka BL2) but we are not planning to build it with TF-M.
Bootloader would be separate repo and be built separately.
So we need the way to build TF-M with FWU service and shared data definitions when BL2=OFF.
I was trying to add support for this but was not able to do this because build structure is quite complicated.
Does anyone have ideas or suggestions about the way we can implement this feature?
Best regards,
Bohdan Hunko
Cypress Semiconductor Ukraine
Engineer
CSUKR CSS ICW SW FW
Mobile: +38099 50 19 714
Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>
Hi Everyone,
I would like to propose the deprecation of arm/mps2/fvp_sse300 platform because the main platform for Corstone-300 is MPS3, available in arm/mps3/an547 and we would like to reduce the number of the platforms to maintain.
Following the deprecation process, https://tf-m-user-guide.trustedfirmware.org/platform/ext/platform_deprecati… this proposal is open for discussion at least for 4 weeks before the platform will be marked as deprecated and removed from TF-M unless any objection received.
Thanks and Best regards,
Anton Komlev
Hello,
>From now on, documentation has no interference with the main build and runs as an independent CMake project. This reduces CMake configuration phase and not requires doc tools for the normal development anymore.
There are no changes for building the binaries, but documentation build shall start in the docs folder
cmake -S docs -B build_docs
cmake --build build_docs
More details are here:
https://tf-m-user-guide.trustedfirmware.org/docs/technical_references/instr…
Thanks,
Anton
Hi,
Anyone has idea how a service inside a secure partition can send out some events to the non-secure world? Does callback still work over IPC? It seems non-secure world can connect to a SP but not easy to do the other way.
Appreciate any comments or suggestions!
Jun
Intel Corporation @ SC, CA
Hi,
We're seeing a failure in the PSA Arch attestation test, specifically:
TEST: 601 | DESCRIPTION: Testing attestation initial attestation APIs | UT: psa_initial_attestation
[Info] Executing tests from non-secure
[Check 1] Test psa_initial_attestation_get_token with Challenge 32
[Check 2] Test psa_initial_attestation_get_token with Challenge 48
Failed at Checkpoint: 1
Actual: -138
Expected: 0
TEST RESULT: FAILED (Error Code=0x1)
The failure is seen on PSoC, but only the gcc Release build (armclang and the other three gcc builds are all fine. Haven't tested IAR), which makes it tricky to debug. PSoC uses the common attest HAL code, though, so I imagine the issue may also be present on other platforms.
Bisecting the problem leads to commit 09d71ffd40368b978d428744ad7ba0d3963f8d1d ("Platform: Use OTP as backing for attestation data").
-138 is PSA_ERROR_BUFFER_TOO_SMALL.
I'm running gcc-arm-none-eabi-7-2018-q2-update, in case that matters.
Chris Brand
Cypress Semiconductor (Canada), Inc.
Sr Prin Software Engr
CSCA CSS ICW SW PSW 1
Office: +1 778 234 0515
Chris.Brand(a)infineon.com<mailto:Chris.Brand@infineon.com>
