- TF-M - lists.trustedfirmware.org

by Anton Komlev

Hi, The next Technical Forum is planned on Thursday, Nov 11, 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

4 years, 2 months

1
1
0 0

lpcxpresso55s69 builds broken

by Thomas Törnblom

More breakage: In file included from ../secure_fw/spm/include/tfm_arch.h:19, from ../secure_fw/spm/cmsis_psa/spm_ipc.h:13, from ../secure_fw/partitions/idle_partition/load_info_idle_sp.c:10: ../secure_fw/spm/include/tfm_arch_v8m.h:58:2: error: #error "VTOR not present, check configurations." 58 | #error "VTOR not present, check configurations." | ^~~~~ ninja: build stopped: subcommand failed. Same issue with IAR. /Thomas -- *Thomas Törnblom*, /Product Engineer/ IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom(a)iar.com Website: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>

4 years, 2 months

3
13
0 0

PSoC64 TF-M - Port to CYB06447BZI-D54

by Cristiano Rodrigues

Hi guys, I am trying to put tf-m running in the PSoC64 board. However, I have a board that is slightly different from the one used by default in the tf-m. (I have *CYB06447BZI-D54* and the default tf-m is prepared to *CYS0644xxZI-S2D44). *For what I saw, the main difference among them is in memory, *CYB06447BZI-D54 *has 1MB of flash and 256kB of RAM and *CYS0644xxZI-S2D44 *has 2MB of Flash and 1MB of RAM. So now I'm trying to make a small port from tf-m to *CYB06447BZI-D54. * I changed the flash size in the flash_layout.h file to meet the *CYB06447BZI-D54 *flash size, however, I am having some difficulties in changing the RAM size. I am trying to change the RAM partitions size in region_defs.h and the smpu definitions of that partitions in smpu_config.h, but without much success. My question are: - Is possible to do the porting? Or does *CYB06447BZI-D54* not have enough memory to run tf-m? - If possible, what is I missing? Are more changes needed than I'm making? Best regards, Cristiano Rodrigues

4 years, 2 months

2
2
0 0

Key derivation from HUK in NS application

by Kevin Townsend

Hi, I need to derive a new key from the HUK using HKDF, but are we able to request key derivation with the HUK from the NS side, or would we need to create a custom ARoT partittion for that? The requirements are identical to what PS does here with HKDF -- no salt and a fixed 'info' value, resulting in a key that is device-bound and can be regenerated at startup with no storage requirements: https://tf-m-user-guide.trustedfirmware.org/docs/technical_references/desig… (that API usage looks to be out of date, BTW, since "psa_open_key" now takes two params). I tried to do something similar from the NS side, modifying this code https://github.com/zephyrproject-rtos/zephyr/blob/main/samples/tfm_integrat… ..., but get an error when trying to open the HUK with "TFM_CRYPTO_KEY_ID_HUK". That isn't surprising, but is there any alternative to generate keys from the HUK without a custom ARoT service? The fact that no storage is required when deriving from the HUK is significant. Best regards, Kevin

4 years, 2 months

1
0
0 0

Using software random generator for FIH library

by Roman.Mazurak＠infineon.com

Hi all, Does anyone know if using software random generator seeded with TRNG to provide random delays for Fault Injection Hardening library is correct from PSA Level 3 certification point of view? The basic idea is to : 1. Use TRNG to provide seed for software random generator on fih_delay_init. 2. Use software random generator to implement fih_delay_random. 3. Periodically reseed software random generator with data from TRNG (optional). Thanks, Roman.

4 years, 2 months

2
1
0 0

Commit b8bc0d2a breaks Musca_S1

by Thomas Törnblom

Appears there are more recent breakage. b8bc0d2a "HAL: Expand the scope of tfm_hal_platform_init API" breaks Musca_S1 /Thomas -- *Thomas Törnblom*, /Product Engineer/ IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom(a)iar.com Website: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>

4 years, 2 months

2
1
0 0

fce78aef breaks psoc64 console output with IARARM and ARMCLANG toolchain

by Thomas Törnblom

The current version breaks console output for the secure partition on psoc64 with IAR or ARMCLANG. Appears to work with GNUARM. It appears that this commit is the culprit: fce78aef Platform: Duplicate the tfm_hal_platform_init The console starts out good, then during tests only garbage is seen. Linker script issues? /Thomas -- *Thomas Törnblom*, /Product Engineer/ IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom(a)iar.com Website: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>

4 years, 2 months

4
4
0 0

BL2 builds, no "PYTHON_EXECUTABLE" defined

by Thomas Törnblom

While attempting to build for the musca_s1, with mcuboot, on Windows, the build failed very late and brought up a Code Writer window on my screen. I nailed it down to no "PYTHON_EXECUTABLE" being defined while processing bl2/ext/mcuboot/CMakeLists.txt, which caused the build line to just attempt to run wrapper.py, with no interpreter, and windows brought up the appropriate tools to write python code. Adding "-DPYTHON_EXECUTABLE=python" to the cmake line fixed that, but it seems that this shouldn't be needed. The build tools should handle this, or? There is a line: #! /usr/bin/env python3 in wrapper.py, and I assume linux will handle this appropriately, but it doesn't seem windows does. Cheers, Thomas -- *Thomas Törnblom*, /Product Engineer/ IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom(a)iar.com Website: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>

4 years, 2 months

2
1
0 0

Flash definitions usage

by Bohdan.Hunko＠infineon.com

Hi everyone, I was trying to understand usage of TOTAL_ROM_SIZE and FLASH_TOTAL_SIZE from musca_b1/sse_200/partitions/flash_layout.h file. I haven't found any usage of these definitions. Does anyone know what is the reason to have them defined? 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>

4 years, 2 months

1
0
0 0

Inline asm syntax unified and symbol reference in IAR toolchain

by Ken Liu

Hi Thomas and all, I noticed there are some #if !defined(__ICCARM__) ".syntax unified \n" #endif In source code, looks like ".syntax unified" is not support in IAR, is that true? If it could not be supported in a short term, we can define some wrapper such as: #ifdef __ICCARM__ #define CLAIM_SYNTAX_UNIFIED "\n" #else #define CLAIM_SYNTAX_UNIFIED ".syntax unified \n" #endif Another question is about the: #if defined(__ICCARM__) #pragma required = do_schedule #endif If we claim do_schedule in the constraints, is the above "#pragma required" still needed? __asm (".... :: "i"(do_schedule)); We can create a patch to test this - using a constraint looks more proper. Thanks. /Ken

4 years, 2 months

2
5
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M