Hi,
Sorry 2nd link was broken. Here is the working version:
https://www.ietf.org/archive/id/draft-tschofenig-rats-psa-token-09.html#tab…
Tamas Ban
From: Andersson, Joakim <Joakim.Andersson(a)nordicsemi.no>
Sent: 2022. május 9., hétfő 12:14
To: Tamas Ban <Tamas.Ban(a)arm.com>
Subject: RE: Attestation token new spec
Is te second link broken? I get a 404 error code.
-Joakim
From: Tamas Ban via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>
Sent: mandag 9. mai 2022 11:31
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: [TF-M] Attestation token new spec
Hi,
the initial attestation token implementation is aligned with this specification:
https://datatracker.ietf.org/doc/html/draft-tschofenig-rats-psa-token-05<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatrack…>
This spec is still evolving and there is a newer version which changes the key values of the claims in the token:
https://www.ietf.org/archive/id/draft-tschofenig-rats-psa-token-09.html#tab…<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.…>
This can cause combability issues between token issuer (device) and token verifier (some remote verification service).
This is an ABI change between token issuer and consumer.
The breaking effect would be manifest in unaccepted IAT tokens by the verifier.
On-device side I see these options to make the transition:
- A build-time option could be introduced which determines which range of key numbers to use. The default value would be the new range. To not let new users pick up the old values accidentally. Existing users can notice the incompatibility issue during the integration test and adjust their build command accordingly. However, the old range would be announced as deprecated in the next TF-M release, then will be removed in the next release after.
- Immediate switch over to the new range, without supporting the old range anymore. On the verification service side, an SW update can handle the transition and might be accepting both ranges for a while. I assume the verification service can be updated more easily than remote devices therefore better to handle the compatibility issue there.
- Keeping the support for both ranges for the long term and letting users choose by build time.
Please share your thoughts on:
- Are you aware that the attestation service is used in deployed devices where this transition can cause incompatibility?
- From the above list which option would you vote to support the transition?
Best regards,
Tamas Ban
Hi everyone,
Some time ago patch for split build<https://review.trustedfirmware.org/q/topic:%2522split-build%2522> of SPE, NSPE, BL2 was announced.
I am interested on when this patch is planned to be merged?
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>
Hello,
The branch release/1.7.x<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/log/?h=release/…> has been created indicating the start of the release process and features freeze.
RC1 tag will follow after successful run of the basic tests.
Let me remind that the code is not frozen, and development can be continued on the main branch.
Thanks,
Anton
Hi,
when I updated from CMake 3.24.0 to the new (two weeks old) CMake 3.25.0 I am no longer
able to build TF-M with -DTEST_PSA_API=CRYPTO.
(Downgrading CMake fixes the issue)
Is there an interoperability issue with the latest CMake release and the TF-M build system?
Reproduced with
TF-Mv1.7.0-RC1
TF-Mv1.6.0
Steps to reproduce:
1. install CMake 3.25.0.
1. cd trusted-firmware-m
1. rm -rf cmake_build && cmake -G Ninja -S . -B cmake_build -DTEST_PSA_API=CRYPTO -DTFM_PLATFORM=nordic_nrf/nrf5340dk_nrf5340_cpuapp -DTFM_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=Debug && ninja -C cmake_build
Only reproduces with TEST_PSA_API and CMake 3.25.0. Builds fine with 3.24.0 or non-PSA API builds.
error:
file INSTALL cannot find
"/home/sebo/ncs/modules/tee/tf-m/trusted-firmware-m/cmake_build/tf-m-tests/app/psa_api_tests/src/psa_generate_database-build/target_database.h":
No such file or directory.
Hello,
I'm trying to build the Trusted Firmware M on Win10 x64 for NXP LPC55S69 using the IAR compiler, but I get the following error:
[ 76%] Building C object secure_fw/CMakeFiles/tfm_s.dir/__/platform/ext/target/nxp/lpcxpresso55s69/Device/Source/startup_lpcxpresso55s69.o
extern uint32_t __INITIAL_SP;
^
"C:\Work\TF-M\trusted-firmware-m\platform\ext\target\nxp\lpcxpresso55s69\Device\Source\startup_lpcxpresso55s69.c",29 Error[Pe007]:
unrecognized token
extern uint32_t __INITIAL_SP;
^
"C:\Work\TF-M\trusted-firmware-m\platform\ext\target\nxp\lpcxpresso55s69\Device\Source\startup_lpcxpresso55s69.c",29 Error[Pe065]:
expected a ";"
extern uint32_t __INITIAL_SP;
^
"C:\Work\TF-M\trusted-firmware-m\platform\ext\target\nxp\lpcxpresso55s69\Device\Source\startup_lpcxpresso55s69.c",29 Error[Pe007]:
unrecognized token
extern uint32_t __STACK_LIMIT;
^
"C:\Work\TF-M\trusted-firmware-m\platform\ext\target\nxp\lpcxpresso55s69\Device\Source\startup_lpcxpresso55s69.c",30 Error[Pe007]:
unrecognized token
extern uint32_t __STACK_LIMIT;
^
"C:\Work\TF-M\trusted-firmware-m\platform\ext\target\nxp\lpcxpresso55s69\Device\Source\startup_lpcxpresso55s69.c",30 Error[Pe065]:
expected a ";"
extern uint32_t __STACK_LIMIT;
^
"C:\Work\TF-M\trusted-firmware-m\platform\ext\target\nxp\lpcxpresso55s69\Device\Source\startup_lpcxpresso55s69.c",30 Error[Pe007]:
unrecognized token
(VECTOR_TABLE_Type)(&__INITIAL_SP), /* Initial Stack Pointer */
In the attachment, you can find the full build log and also the CMake build file generation log.
Some details about my setup:
Win10 Enterprise x64. Version 20H2
IAR ANSI C/C++ Compiler V8.50.9.278/W32 for ARM
GNU Make 3.81
git version 2.36.0.windows.1
CMake 3.24.2
Python 3.10.5
I followed the steps from the Getting started guide here<https://tf-m-user-guide.trustedfirmware.org/getting_started/index.html> than the steps to build the framework for LPC55S69 here<https://tf-m-user-guide.trustedfirmware.org/platform/nxp/lpcxpresso55s69/RE…>.
Do you have any idea what I'm missing?
In case you need any further information let me please know.
Thanks in advance.
Kind regards,
Ildikó Pocsai
Hello,
I see that in coming 1.7.0 the file secure_fw/spm/ns_client_ext/tfm_ns_ctx.h contains a comment
/* Supported maximum context for NS. Only support single context for now. */
#define TFM_NS_CONTEXT_MAX 1
Does it mean that several simultaneous NSC call is not supported ?
Best regards
ST Restricted
Dear developers,
I have a question about interrupt SLIH scheduling in IPC model.
Assume that there are two secure partitions P1 and P2, and P1 has higher priority than P2.
P1 calls psa_call(), so SPM blocks P1 and wakes up P2 to execute P2's service handler.
Now P2 is running. Suddenly P1's interrupt occuerred, and P1's SLIH signal is asserted for more processing.
A shedule request is also triggered.
Since P1 has higher priority than P2, will P2 be preemted by P1 to execute P1's SLIH immediately?
If the answer is yes, the psa_call() chain will be corrupted, right?
Thanks in advance.
Alvin Chang
Hi,
Partition is described through configuration in YAML files (manifests). This configuration includes following properties (see Adding Secure Partition - Add manifest<https://tf-m-user-guide.trustedfirmware.org/integration_guide/services/tfm_…>):
* Name, type, priority, model, ...
* List of services provided by partition
* MMIO regions
* List of IRQs
* Dependencies
Each platform should provide implementation of HAL which is specific to standard partitions like Crypto, ITS, etc. It's mandatory to provide proper isolation of memory/peripheral that are used by platform specific code that provides HAL implementation or add a custom dependency for standard partition.
Currently platform can use following approaches to resolve the problem of extending YAML of standard TF-M partition:
* Create a platform specific copy of partition YAML, see https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/15639 as an example of such approach.
* Modify standard partition by introducing optional fields, see https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/17718.
These both solution are not flexible enough. It requires to modify platform independent code or maintain own copy of partition YAML file with needed changes.
I think it make sense to integrate partition YAML extension tool in TF-M. Platform/application should be able to provide manifest-extension file(s). Such manifest-extension file may provide additional properties which should be joined with properties provided by standard partition manifest files.
For example to solve problem for https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/15639 ARM RSS platform may provide following manifest-extension file with structure like this:
{
"extensions": [
{
"name": "TFM_SP_INITIAL_ATTESTATION",
"dependencies": [
"TFM_MEASURED_BOOT"
]
}
]
}
Tool which parses manifests should add a new dependency on "TFM_MEASURED_BOOT" to list of dependencies for "TFM_SP_INITIAL_ATTESTATION" partition.
Please, share your opinion on this topic.
Best regards,
Roman.
