December 2021 - TF-M - lists.trustedfirmware.org

Re: [TF-M] Supporting encryption with ITS

by Sherry Zhang

Hi George, The ITS without encryption is not a compromised RoT. In the PSA Secure Storage API spec, the PSA Internal Trust Storage aims at providing a place for devices to store their most intimate secrets. Also “””””””””””””””””””” 1. The storage underlying the PSA Internal Trusted Storage Service MUST be protected from read and modification by attackers with physical access to the device. 2. The storage underlying the PSA Internal Trusted Storage Service MUST be protected from direct read or write access from software partitions outside of the PSA Root of Trust (PRoT). “””””””””””””””””””” So, for internal trusted storage service, it requires the underlying storage itself should provide being read or write protection. The storage area should be a “trusted” area. Does the storage area on your device meet this requirement? Is the memory physically isolated? If not, I wonder why not uses the Protected Storage service instead? For the design of adding encryption in ITS, in the PS partition, the `iv` and the encrypted object data are stored with the object file while the tag of each object is stored with the object table file. So, if encrypt the PS object in the ITS file system, how the PS partition get the `tag` of each object? After a rough thought, I think probably a standalone encryption for ITS is more reasonable. As this is a relatively “big topic”, would you like to hold a discussion on the TF-M Tech forum if it is not limited by confidential information? The next Tech forum will be hold on this Thursday 3:00 PM UTC time. Regards, Sherry Zhang From: Vasilakis, Georgios <georgios.vasilakis(a)nordicsemi.no<mailto:georgios.vasilakis@nordicsemi.no>> Sent: Friday, September 24, 2021 8:52 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: [TF-M] Supporting encryption with ITS Hello Sherry, Thank you for your input! 1. Our threat model is more concerned about attacks which can happen very early in the boot process, I think. A completely compromised RoT is not in our threat model. 2. I see that, ITS is supposed to store small objects. The storage overhead of adding encryption will be probably bigger than 20 bytes I think but the intention is to have this only as a configuration, not as the default option. 3. Agreed, a HAL API should be used for this. Do you have any opinion on the design of it? Do you think that it adds value to do try to use a common design for the object handling of both PS and ITS or is it better to have it as a standalone thing for the ITS. Regards, George ________________________________ From: Sherry Zhang <Sherry.Zhang2(a)arm.com<mailto:Sherry.Zhang2@arm.com>> Sent: Friday, September 24, 2021 11:58 AM To: Vasilakis, Georgios <georgios.vasilakis(a)nordicsemi.no<mailto:georgios.vasilakis@nordicsemi.no>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <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] Supporting encryption with ITS Hi George, Some comments from my side: 1. Internal trusted storage is part of the Root of Trust domain. If ITS storage device is attacked, then the code flash where the PSA Rot SP locates may also be attacked. Does the thread model of your system require the encryption in ITS? 2. The ITS service is intended to be used to interface to a small piece of storage. Encryption would increase the context for each ITS file. For example, similarly to PS object context, the `IV` which is used in encryption as well as the generated `tag` should be added into each file context. They total together can be about more than 20 bytes. 3. If the encryption is mandatory/ necessary required by the thread model of your system, as discussed, the PSA crypto service should not be called to avoid the circular. I think a HAL API for encryption may be created in ITS for platform implementation defined encryption/decryption. Regards, Sherry Zhang From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Vasilakis, Georgios via TF-M Sent: Thursday, September 23, 2021 10:47 PM To: Gyorgy Szing <Gyorgy.Szing(a)arm.com<mailto:Gyorgy.Szing@arm.com>>; Fabian Schmidt <fabian.schmidt(a)nxp.com<mailto:fabian.schmidt@nxp.com>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] Supporting encryption with ITS Hey Gyorgy, These are very valuable comments! I am aware of the circular dependency issue because the PSA apis are using the ITS as a storage backend. This, as you said, can be circumvented by using a software crypto library or an implementation specific API. So, for the encryption a flexible API can be used which can allow externals to use their own function calls. Regarding the key storage, this is what I had in mind as well, using derived keys from the HUK. So that we don't need to store anything but the crypto metadata. Adding another layer of storage will raise more issues, I think. ________________________________ From: Gyorgy Szing <Gyorgy.Szing(a)arm.com<mailto:Gyorgy.Szing@arm.com>> Sent: Thursday, September 23, 2021 4:30 PM To: Fabian Schmidt <fabian.schmidt(a)nxp.com<mailto:fabian.schmidt@nxp.com>>; Vasilakis, Georgios <georgios.vasilakis(a)nordicsemi.no<mailto:georgios.vasilakis@nordicsemi.no>> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>; nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: [TF-M] Supporting encryption with ITS Hi, AFAIK the main reason for ITS not using encryption is the problem of circular dependency. ITS is used by crypto SP for key storage, so how will crypto fetch the key from ITS to decrypt ITS? You could use a software crypto implementation (another mbed-tls instance) in ITS, but where would you safely store the keys? If you have a two layer ITS, one for only storing the keys for the second instance, and a second, encrypted one, then you end up with something like ITS and PS. You may not need a full blown on-chip FLASH device for ITS. If you have a HUK available, you can derive the same SP specific keys from that at each boot, and store these in RAM backed ITS. You won’t be able to store other keys in ITS in a persistent way of course, but for that you can use PS. Well, something along these lines. Perhaps the TF-M team could help better if you could share some details on why your customer would need encrypted ITS. (A PSA for Cortex-A (TS) maintainer chiming in to a “not his business” discussion here 😉 ) /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Fabian Schmidt via TF-M Sent: September 23, 2021 15:51 To: Vasilakis, Georgios <georgios.vasilakis(a)nordicsemi.no<mailto:georgios.vasilakis@nordicsemi.no>> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] Supporting encryption with ITS Hi George, I’m wondering if that would add value. To my understanding, ITS was never designed to be encrypted because of the way it’s supposed to be set up. (It’s Internal Trusted Storage.) I believe best practice is to place it in a “trusted” location, one that is ideally only accessible from Secure world, and also ideally on-die. If you then restrict outside access to the internal flash (JTAG, flash programmer ports,…), you’re pretty golden, in that no unauthorized party should be able to read from or write to the ITS.* Let me know if I misunderstand anything about ITS or TrustZone, but that’s my view. Maybe I’m painting an idealized picture. Greetings, Fabian Schmidt * at least short of a sophisticated physical attack or finding some loophole in TrustZone… From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Vasilakis, Georgios via TF-M Sent: Donnerstag, 23. September 2021 15:28 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [EXT] [TF-M] Supporting encryption with ITS Caution: EXT Email Hey all, Lately the requirement for an encrypted ITS solution is being asked from our customers and I would like to have a discussion here on how we can design this in a reasonable way. The first thought that came to my mind was to add the functionality to the ITS flash-fs layer. This layer contains file metadata in the its_file_meta_t structure and it should be possible to expand this to include additional crypto metadata (conditionally). This seems to be the less invasive change to me, even though it will introduce some increased memory usage since supporting encryption will mean that we cannot read the data in chunks anymore, we will have to use static buffers. At the same time, I looked at the PS partition since I knew that it has support for encryption. I believe that some core concepts of both solutions have similarities even though the code is quite different. For example, a file in ITS is similar to an object in PS and the (linear) list of file metadata in ITS is similar to the concept of the object table in PS. So, I think that it should be possible to design some generic-enough APIs that we can use for both the ITS and PS. Even though this will require some major refactoring in both partitions, it will decrease the code of these services which will probably decrease maintenance later. What are your thoughts on this? Regards, George

2 years, 3 months

6
16
0 0

Remove use of ER_INITIAL_PSP

by Mingyang Sun

Hi, ER_INITIAL_PSP section was used as the Trustzone NS Agent partition stack in IPC model. Since Trustzone NS Agent partition has changed to use private variables as its stack, ER_INITIAL_PSP related definitions and references can be removed. Change: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/13186 This change involves all the platforms for IPC model, it removes: * Definition of ER_INITIAL_PSP section in the linker script * Reference of ER_INITIAL_PSP for isolation configuration in platform HALs This can simplify the linker script a bit. This patch is going to be put there for a while as there are holidays, but please do review it when you see this mail. Plan to merge it before end of Jan, as soon as all concerns get addressed (if there are). Regards, Mingyang

2 years, 11 months

2
2
0 0

Technical Forum call - Jan 6

by Anton Komlev

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

2 years, 11 months

1
1
0 0

nucleo_l552ze_q platform does not build since TF-M 1.5

by Michel JAOUEN

Hello, This platform is tested for profile medium and low (-DTFM_PROFILE=profile_small or -DTFM_PROFILE=profile_medium). I just checked on master with medium profile and GNUARM. The default config takes a crypto config with its associated crypto tests that leads to overlap in flash area. (This device has 512Kbytes Flash) Best Regards ST Restricted From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Bøe, Sebastian via TF-M Sent: mercredi 22 décembre 2021 13:40 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] nucleo_l552ze_q platform does not build since TF-M 1.5 Hi, I am observing that the nucleo_l552ze_q platform is producing hex files that overlap since the 1.5 release. Tested on master and 1.5. Is there an STM maintainer that could look into this? Steps to reproduce: rm -rf cmake_build && cmake -S . -B cmake_build -DTFM_PLATFORM=stm/nucleo_l552ze_q -DTFM_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=MinSizeRel -DTEST_S=ON -DTEST_NS=ON && make -C cmake_build install && /usr/bin/python3.8 /home/sebo/ncs/zephyr/scripts/mergehex.py -o merged.hex $(find cmake_build -name "*.hex") "/usr/bin/python3.8 /home/sebo/ncs/zephyr/scripts/mergehex.py" must be replaced with the preferred hex file merging tool. output: Traceback (most recent call last): File "/home/sebo/ncs/zephyr/scripts/mergehex.py", line 28, in merge_hex_files ih.merge(to_merge, overlap=overlap) File "/home/sebo/.local/lib/python3.8/site-packages/intelhex/__init__.py", line 875, in merge raise AddressOverlapError( intelhex.AddressOverlapError: Data overlapped at address 0xC014400 During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/home/sebo/ncs/zephyr/scripts/mergehex.py", line 56, in <module> main() File "/home/sebo/ncs/zephyr/scripts/mergehex.py", line 52, in main merge_hex_files(args.output, args.input_files, args.overlap) File "/home/sebo/ncs/zephyr/scripts/mergehex.py", line 30, in merge_hex_files raise AddressOverlapError("{} has merge issues".format(hex_file_path)) intelhex.AddressOverlapError: cmake_build/install/outputs/STM/NUCLEO_L552ZE_Q/tfm_s.hex has merge issues PS: Depending on the revision tested, it might be necessary to also apply this patch: modified platform/ext/target/stm/common/stm32l5xx/CMakeLists.txt @@ -90,7 +90,7 @@ target_sources(platform_s ${CMAKE_CURRENT_SOURCE_DIR}/hal/Src/stm32l5xx_hal_gtzc.c ${CMAKE_SOURCE_DIR}/platform/ext/common/tfm_hal_isolation_mpu_v8m.c ${CMAKE_SOURCE_DIR}/platform/ext/common/tfm_hal_nvic.c - $<$<BOOL:${TFM_PARTITION_PLATFORM}>:${CMAKE_CURRENT_SOURCE_DIR}/secure/tfm_platform_system> + $<$<BOOL:${TFM_PARTITION_PLATFORM}>:${CMAKE_CURRENT_SOURCE_DIR}/secure/tfm_platform_system.c> ${CMAKE_CURRENT_SOURCE_DIR}/hal/Src/stm32l5xx_hal_rng.c ${CMAKE_CURRENT_SOURCE_DIR}/hal/Src/stm32l5xx_hal_rng_ex.c PUBLIC

2 years, 12 months

2
1
0 0

nucleo_l552ze_q platform does not build since TF-M 1.5

by Bøe, Sebastian

Hi, I am observing that the nucleo_l552ze_q platform is producing hex files that overlap since the 1.5 release. Tested on master and 1.5. Is there an STM maintainer that could look into this? Steps to reproduce: rm -rf cmake_build && cmake -S . -B cmake_build -DTFM_PLATFORM=stm/nucleo_l552ze_q -DTFM_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=MinSizeRel -DTEST_S=ON -DTEST_NS=ON && make -C cmake_build install && /usr/bin/python3.8 /home/sebo/ncs/zephyr/scripts/mergehex.py -o merged.hex $(find cmake_build -name "*.hex") "/usr/bin/python3.8 /home/sebo/ncs/zephyr/scripts/mergehex.py" must be replaced with the preferred hex file merging tool. output: Traceback (most recent call last): File "/home/sebo/ncs/zephyr/scripts/mergehex.py", line 28, in merge_hex_files ih.merge(to_merge, overlap=overlap) File "/home/sebo/.local/lib/python3.8/site-packages/intelhex/__init__.py", line 875, in merge raise AddressOverlapError( intelhex.AddressOverlapError: Data overlapped at address 0xC014400 During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/home/sebo/ncs/zephyr/scripts/mergehex.py", line 56, in <module> main() File "/home/sebo/ncs/zephyr/scripts/mergehex.py", line 52, in main merge_hex_files(args.output, args.input_files, args.overlap) File "/home/sebo/ncs/zephyr/scripts/mergehex.py", line 30, in merge_hex_files raise AddressOverlapError("{} has merge issues".format(hex_file_path)) intelhex.AddressOverlapError: cmake_build/install/outputs/STM/NUCLEO_L552ZE_Q/tfm_s.hex has merge issues PS: Depending on the revision tested, it might be necessary to also apply this patch: modified platform/ext/target/stm/common/stm32l5xx/CMakeLists.txt @@ -90,7 +90,7 @@ target_sources(platform_s ${CMAKE_CURRENT_SOURCE_DIR}/hal/Src/stm32l5xx_hal_gtzc.c ${CMAKE_SOURCE_DIR}/platform/ext/common/tfm_hal_isolation_mpu_v8m.c ${CMAKE_SOURCE_DIR}/platform/ext/common/tfm_hal_nvic.c - $<$<BOOL:${TFM_PARTITION_PLATFORM}>:${CMAKE_CURRENT_SOURCE_DIR}/secure/tfm_platform_system> + $<$<BOOL:${TFM_PARTITION_PLATFORM}>:${CMAKE_CURRENT_SOURCE_DIR}/secure/tfm_platform_system.c> ${CMAKE_CURRENT_SOURCE_DIR}/hal/Src/stm32l5xx_hal_rng.c ${CMAKE_CURRENT_SOURCE_DIR}/hal/Src/stm32l5xx_hal_rng_ex.c PUBLIC

2 years, 12 months

1
0
0 0

Eliminate unnecessary space in tfm_s.bin

by Sherry Zhang

Hi, Currently, in the compiler link script, the CMSE VENEER section is placed at a fixed address which is at the end of tfm code. See code for armclang<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/platform/e…> and gnu arm<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/platform/e…>. Placing the veneers at the fixed address has the benefit that the when the secure image updates, the veneer symbols remain unchanged. So, the nonsecure image does not have to be updated together. The problem is that the size of tfm_s.bin is always the same in different TF-M build configurations(debug mode, release mode, profile small, profile large and so on). So, there can be large empty space between the end of tfm code and the veneer section. As we discussed on today's tech forum meeting, I propose to move the LR_VENEER from the end of tfm code to right after the secure vector table. In this way, the space between the tfm code and the veneers section is eliminated. Also, the supported number of interrupts for each platform is fixed. So, the size of the vector table is fixed for each platform. So, the start address of veneer section is still fixed for each platform. The size of tfm_s.bin is reduced significantly after this change. Take the AN521 platform for example, the size of tfm_s.bin has a 70 percent reduction. The link script change for armclang<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/12620/6/plat…> and gnu arm<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/12620/6/plat…> in this patch<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/12620/> can help me demonstrating my proposal. I am not hurry asking for review and merge this patch. As it impacts all the platforms, I want to get confirmed that all platforms which are using the common link script are happy with this proposal. Any comments or especially concerns on this proposal? Thanks, Regards, Sherry Zhang

3 years

3
5
0 0

Power management and TFM

by Suresh.Marisetty＠infineon.com

Hi, Wondering if anybody can throw some light on any ongoing efforts on power management on a system with TFM (deep sleep, etc). thanks Suresh Marisetty Infineon Semiconductor Corporation CYSC CSS ICW SW SSE Mobile: +5103863997 Suresh.Marisetty(a)infineon.com<mailto:Suresh.Marisetty@infineon.com>

3 years

3
2
0 0

Re: [TF-M] Change in ...trusted-firmware-m[master]: Platform: Refine image flash layout

by Thomas Törnblom

I'm working on the IAR part of this and I'm having a problem with the following test in isolation level 3: --- Running Test Suite TFM IRQ Test (TFM_IRQ_TEST_1xxx)... > Executing 'TFM_NS_IRQ_TEST_SLIH_1001' Description: 'SLIH HANDLING Case 1' --- If I run the test at full speed, it will run into a MemManage fault while if I single step through the entire test it will pass. Is there a race condition somewhere in there? If I disable the SLIH tests it succeeds. The exception happens when dereferencing "dev" in this function: bool timer_cmsdk_is_initialized(const struct timer_cmsdk_dev_t* dev) { return dev->data->is_initialized; } dev is 0x30002440 at the time. I've been trying to figure out what part of the memory protection system it is that is causing the exception. DACCVIOL is set and MMFAR shows the faulting address. Ideas? The build line: cmake -GNinja -S .. -B . -DTFM_PLATFORM=arm/musca_b1/sse_200 "-DTFM_TOOLCHAIN_FILE=..\toolchain_IARARM.cmake" -DTEST_NS=ON -DTEST_S=ON -DCMAKE_BUILD_TYPE=Debug -DBL2=ON -DTFM_ISOLATION_LEVEL=3 -DTEST_NS_SLIH_IRQ=ON -DTEST_NS_QCBOR=OFF Notice that this build runs into a linker bug in the IAR toolchain and I have a non-released fixed version I'm using, in case anyone is attempting to replicate the issue. Cheers, Thomas Den 2021-12-17 kl. 11:30, skrev TrustedFirmware Code Review (Code Review): > > Attention is currently required from: Kevin Peng, Ken Liu, David Hu, > Chris Brand, Anton Komlev, Thomas Törnblom. > > "Build Successful > > http://ci.trustedfirmware.org/job/tf-m-static/3226/display/redirect : > SUCCESS" > > Patch set 16:Verified +1 > > View Change > <https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/12620> > > To view, visit change 12620 > <https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/12620>. > To unsubscribe, or for help writing mail filters, visit settings > <https://review.trustedfirmware.org/settings>. > > Gerrit-Project: TF-M/trusted-firmware-m > Gerrit-Branch: master > Gerrit-Change-Id: I0084aef576d90af45513c7eaae58ba6c6dbbddab > Gerrit-Change-Number: 12620 > Gerrit-PatchSet: 16 > Gerrit-Owner: sherryzhang <sherry.zhang2(a)arm.com> > Gerrit-Reviewer: Anton Komlev <Anton.Komlev(a)arm.com> > Gerrit-Reviewer: David Hu <david.hu(a)arm.com> > Gerrit-Reviewer: Ken Liu <ken.liu(a)arm.com> > Gerrit-Reviewer: Sebastian Bøe <Sebastian.boe(a)nordicsemi.no> > Gerrit-Reviewer: Thomas Törnblom <thomas.tornblom(a)iar.com> > Gerrit-Reviewer: TrustedFirmware Code Review > Gerrit-Reviewer: sherryzhang <sherry.zhang2(a)arm.com> > Gerrit-CC: Andrej Butok <andrey.butok(a)nxp.com> > Gerrit-CC: Chris Brand <chris.brand(a)cypress.com> > Gerrit-CC: Gabor Abonyi <gabor.abonyi(a)arm.com> > Gerrit-CC: Kevin Peng <kevin.peng(a)arm.com> > Gerrit-CC: Michel Jaouen > Gerrit-CC: Márk Horváth <mark.horvath(a)arm.com> > Gerrit-CC: Satish Kumar <satish.kumar01(a)arm.com> > Gerrit-CC: jamie.mccrae(a)lairdconnect.com > Gerrit-Attention: Kevin Peng <kevin.peng(a)arm.com> > Gerrit-Attention: Ken Liu <ken.liu(a)arm.com> > Gerrit-Attention: David Hu <david.hu(a)arm.com> > Gerrit-Attention: Chris Brand <chris.brand(a)cypress.com> > Gerrit-Attention: Anton Komlev <Anton.Komlev(a)arm.com> > Gerrit-Attention: Thomas Törnblom <thomas.tornblom(a)iar.com> > Gerrit-Comment-Date: Fri, 17 Dec 2021 10:30:20 +0000 > Gerrit-HasComments: No > Gerrit-Has-Labels: Yes > Gerrit-MessageType: comment -- *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>

3 years

2
2
0 0

Any existing efforts on enabling X.509 certificate support inside TF-M

by Li, Jun R

Hi everyone, I’m wondering if there is any existing effort on enabling X.509 CSR generation and certificate verification inside TF-M? Our project has some custom secure partitions which need to generate the CSR and verify the issued certificates by themselves. The current TF-M implementation hasn’t added X.509’s support. So, I’m wondering if any open source project already does that which we can leverage? Regards, Jun Li Intel Corporation, CA

3 years

3
3
0 0

Technical Forum call - Dec 23 CANCELLED

by Anton Komlev

Hello, In the light of the end of the year celebrations expecting not many joiners on Dec 23, specially for US time zone, hence let's cancel the forum at the next week. Thanks and wish you the great holidays, Anton

3 years

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

TF-M December 2021