- TF-M - lists.trustedfirmware.org

Re: [TF-M] Adding platform specific functions to Crypto Service.

by Roman.Mazurak＠infineon.com

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.

5 years

2
2
0 0

TF-M Cadence change proposal

by Anton Komlev

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

5 years

1
0
0 0

PSA API crypto test breakage

by Chris.Brand＠infineon.com

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>

5 years

2
2
0 0

FWU mark TFM image as accepted

by Bohdan.Hunko＠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>

5 years

4
3
0 0

Technical Forum call - Oct 14

by Anton Komlev

Hi, The next Technical Forum is planned on Thursday, Oct 14, 7:00-8:00 UTC (Asia 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

5 years

1
1
0 0

Mutex in SPE

by Roman.Mazurak＠infineon.com

Hi all, We need a mutex to protect access to a shared resource within Platform RoT Services. Is there any plan to add implementation of mutex in TF-M? Maybe it should be a platform specific implementation? Thanks, Roman.

5 years

2
1
0 0

TF Open CI FYI

by Don Harbin

Hi all, In a discussion with Anton, it was realized that all contributors may not be aware of some of the information available regarding Open CI. If interested in digging deeper and understanding here are some helpful links. - The Open CI "mini-website" can be found here <https://www.trustedfirmware.org/projects/open-ci/>. - Note in the intro paragraph a hotlink to the *Open CI Lava farm* showing the hardware platforms in the lab, recent test results, etc. Note it requires a login to see all the information - Also of value is a detailed *users guide* that provides an overview of Open CI. You can click on the "docs" icon or just go here <https://tf-ci-users-guide.readthedocs.io/en/latest/>. It's a living document and contributions are encouraged. :) - This page also shares how to get further involved and the location of the code. Best regards, Don

5 years

1
0
0 0

Adding platform specific functions to Crypto Service.

by Roman.Mazurak＠infineon.com

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.

5 years

3
2
0 0

Enable a peripheral interrupt to an App RoT

by Cristiano Rodrigues

Hi everyone, I am developing an App RoT for STM32L552 and testing the recent integrated FLIH interrupt feature, but I am missing something in the step of "Initializing the Interrupts" and "Integrating the Interrupt Handling Function". As is described in Secure Interrupt Integration Guide <https://tf-m-user-guide.trustedfirmware.org/docs/integration_guide/tfm_secu…>, to enable an interrupt it is needed: 1. Binding the interrupt to a Secure Partition. 2. Granting the Secure Partition access permissions to the device of the interrupt. 3. Initializing the interrupt. 4. Integrating the interrupt handling function Step *1 *and *2, * think that is "checked": - by adding this code to the partition manifest file. "mmio_regions": [ { "name": "TFM_PERIPHERAL_TIMER7", "permission": "READ-WRITE" } ], "irqs": [ { "source": "TFM_TIMER7_IRQ", "name": "TFM_TIMER7_IRQ", "handling": "FLIH", } - By defining the macro with platform peripheral structure in *patform/ext/target/stm/common/stm32l5xx/boards/tfm_peripherals_def.h* extern struct platform_data_t timer7 #define TFM_PERIPHERAL_TIMER7 &timer7 - *By assign the peripheral address in platform\ext\target\stm\common\stm32l5xx\secure\target_cfg.c* struct platform_data_t timer7 = { __TIMER7_BASE, __TIMER7_BASE + 0x3FF, -1, -1 }; - By adding the peripheral name to “partition_named_mmio_list[]” in the file *patform/ext/target/stm/common/stm32l5xx/boards/mmio_defs.h* const uintptr_t partition_named_mmio_list[] = { (uintptr_t)TFM_PERIPHERAL_TIMER0, (uintptr_t)TFM_PERIPHERAL_STD_UART, (uintptr_t) TFM_PERIPHERAL_TIMER7, }; - And add to my partition code, the irq function, and the function to configure the timer psa_flih_result_t tfm_timer7_irq_flih(void) { .... } static void flih_test_case_1(psa_msg_t *msg) { psa_irq_enable(TFM_TIMER7_IRQ_SIGNAL); timer_start(); ....... timer_stop(); psa_irq_disable(TFM_TIMER7_IRQ_SIGNAL); psa_reply(msg->handle, PSA_SUCCESS); } My problem, I think, is with the other two steps, *3 *and *4. *The TF-M documentation is not clear in these two steps. In step *3, *as is said in the documentation it is needed: i) to configure the interrupt priority; ii) to ensure that the interrupt targets the Secure State. iii) and save the interrupt information. So I suppose it goes something like this: struct irq_t { void *p_pt; struct irq_load_info_t *p_ildi; } save_tfm_timer7_irq_info; enum tfm_hal_status_t tfm_timer7_irq_init(void *p_pt, struct irq_load_info_t *p_ildi) { //targetting the interrupt to S state NVIC_ClearTargetState(TIM7_IRQn); NVIC_SetPriority(TIM7_IRQn, 1); NVIC_EnableIRQ(TIM7_IRQn); //Saving the Interrupt Information save_tfm_timer7_irq_info.p_pt = p_pt; save_tfm_timer7_irq_info.p_ildi = p_ildi; return TFM_HAL_SUCCESS; } *But in which file should I put this function? And where should I call this function??* And in step *4, *I also do not understand how can I meet this requirement -> "Platforms should call this entry function in the interrupt handlers defined in Vector Table with the saved information for each interrupt." Being the function in question -> *void spm_handle_interrupt(void *p_pt, struct irq_load_info_t *p_ildi).* *Which file can I do this in? And how should I do this step?* Cheers, Cristiano Rodrigues

5 years, 1 month

2
1
0 0

Boot shared data TLV length

by Bohdan.Hunko＠infineon.com

Hi everyone, IAS docs have this<https://tf-m-user-guide.trustedfirmware.org/docs/integration_guide/services…> note that says: There is a size field tlv_len which has different definitions in the upstream MCUboot repository and in its TF-M forked version: * Upstream MCUboot: Covers only the length of data but not the header size. * TF-M MCUboot: Covers the size of the entry header and the data together. This difference is handled by TF-M code based on which bootloader is used along with TF-M runtime. I was wondering where in code is this difference handled? When calculating next TLV entry address attest_core.c line 213<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/secure_fw/…> takes into account SHARED_DATA_ENTRY_HEADER_SIZE: tlv_curr = (*tlv_ptr) + SHARED_DATA_ENTRY_HEADER_SIZE + tlv_entry.tlv_len; So tlv_entry.tlv_len then must cover only length of entry (without header). This way corresponds to: "Upstream MCUboot: Covers only the length of data but not the header size" I was not able to find anything related to "TF-M MCUboot: Covers the size of the entry header and the data together". Is this difference handled in TF-M fork of MCUboot or is it just outdated IAS doc? 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>

5 years, 1 month

2
1
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M