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>
Hi all,
Thanks for Chris Brand's enhancement suggestion about platform-specific tests.
I'm enabling out-of-tree build mode of platform specific test suites with tf-m-tests.
Currently I have proposed the following changes:
* [TF-M patch<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11296>]
* [tf-m-tests patch<https://review.trustedfirmware.org/c/TF-M/tf-m-tests/+/11297>]
My proposal supplies a flexible interface for partners to out-of-tree build local tests. With this new feature,
* Partners can perform local test quickly during development to improve test efficiency
* Partners can maintain local test code outside tf-m-tests repo in case of confidential information or IP issues.
I also put an out-of-tree example test source code into tf-m-extras repo and a document in TF-M repo:
* [tf-m-extras patch<https://review.trustedfirmware.org/c/TF-M/tf-m-extras/+/11323>]
* [TF-M patch doc<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11336>]
This example indicates that platform-specific tests can be integrated with tf-m-tests, without following tf-m-tests structure or definitions.
The document introduces the usage and coding guide of this new feature.
PS: If partners would like to upstream platform specific test code, we will be glad to create a specific folder under tf-m-tests repo as Chris Brand suggested.
I'd be grateful if you can take a look at the patch sets above. Any suggestion or comment is welcome.
Best Regards
Jianliang Shen
Hi Fabian,
Yes, our team is thinking about adding feature to the Crypto service API, which are not cryptographic in nature. This is one of the possible solution in our design to avoid additional data processing layer between cryptographic clients and crypto accelerator.
Our crypto accelerator also provides additional features which will be used by other secure partitions in TF-M but it doesn’t support handling of crypto and non-crypto requests at the same time.
It’s not a problem for CC312 which is used for crypto services and OTP in the latest commit. As far as I understand CC312 allows to use crypto operations and OTP related functions at the same time without additional synchronization. So, the reference design is not very helpful in our situation.
So, implementation of additional service is not the best solution. It will extend processing time for each cryptographic requests.
The other option is to implement synchronization by using mutex. I think mutex is preferable approach, but this feature is also not support by TF-M yet 😊
There is the discussion which I started for mutex : https://lists.trustedfirmware.org/pipermail/tf-m/2021-October/001914.html
Thanks,
Roman.
From: Fabian Schmidt <fabian.schmidt(a)nxp.com>
Sent: Tuesday, October 12, 2021 13:47
To: Shebu.VargheseKuriakose(a)arm.com; David.Hu(a)arm.com; Mazurak Roman (CSUKR CSS ICW SW FW) <Roman.Mazurak(a)infineon.com>; mbed-tls(a)lists.trustedfirmware.org
Cc: nd(a)arm.com
Subject: RE: [TF-M] Adding platform specific functions to Crypto Service.
Hi Roman,
My understanding is that you would like to add features to the Crypto service API, but the features which you would like to add are not cryptographic in nature.
Have you considered creating your own service for those features, instead of modifying the Crypto service? Or is there anything makes this not a viable option?
If you are thinking about adding hardware acceleration for some Crypto features, that’s indeed covered in Shebu’s link.
Greetings,
Fabian Schmidt
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Shebu Varghese Kuriakose via TF-M
Sent: Dienstag, 12. Oktober 2021 11:46
To: David Hu <David.Hu(a)arm.com<mailto:David.Hu@arm.com>>; Roman.Mazurak(a)infineon.com<mailto:Roman.Mazurak@infineon.com>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; mbed-tls(a)lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: [EXT] Re: [TF-M] Adding platform specific functions to Crypto Service.
Caution: EXT Email
Hi Roman,
I also might not have understood the question completely.
As you mention crypto HAL API, here is the specification which defines a standardized mechanism for PSA Crypto implementations to interface with Secure elements and crypto accelerators - https://github.com/ARMmbed/mbedtls/blob/development/docs/proposed/psa-drive…<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…>
Also adding mbed-tls mailing list as the thread is crypto related..
Regards,
Shebu
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, October 12, 2021 4:18 AM
To: Roman.Mazurak(a)infineon.com<mailto:Roman.Mazurak@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: [TF-M] Adding platform specific functions to Crypto Service.
Hi Roman,
Are you asking about adding platform specific HAL API to implement PSA Crypto API function?
Please correct me if I misunderstand your question.
Best regards,
Hu Ziji
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Roman Mazurak via TF-M
Sent: Monday, October 11, 2021 9:45 PM
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: [TF-M] Adding platform specific functions to Crypto Service.
Hi all,
We would like to add a number of platform specific functions to Crypto Service API. Is it ok if such functions will not be related to cryptographic service, but such approach allows us to optimize platform design? Is there any initiative to create a Crypto Service HAL API to extend Crypto with custom functions?
Best regards,
Roman.
Hello,
Following the Tech Forum today I am duplicating the proposal of TF-M cadence change from 4 to 6 months here. This will generate 2 releases a year, planed for the end or March and the end of October starting from v1.6.0. The upcoming release v1.5.0 will stay on planned date.
Please share your comments and concerns on the topic.
Thanks,
Anton
Commit 42e77b561fcfe19819ff1e63cb7c0b672ee8ba41 ("Crypto: Remove TF-M Crypto service key handle array") seems to break PSA Arch Crypto test 218 (on PSoC64, with gcc, at least). After this commit, the test reports
Failed at Checkpoint: 7
Actual: -137
Expected: -136
(so actual is PSA_ERROR_BAD_STATE and expected is PSA_ERROR_INVALID_HANDLE).
That same test passes with the previous commit.
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>
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(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>