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
Is 11.2-2022.02 the recommended compiler version?
I saw TF-M v1.8 states:
" GNU Arm compiler version *10-2020-q4-major* has an issue in CMSE
support. The bug is reported in `here <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99157>`__.
Select other GNU Arm compiler versions instead.
GNU Arm compiler version greater and equal than *11.3.Rel1* has a linker issue in syscall.
Select other GNU Arm compiler versions instead.
"
Regards,
Brian Quach
SimpleLink MCU
Texas Instruments Inc.
Hi,
When is it appropriate to use "__tz_c_veneer" vs. "__tfm_nspm_secure_gateway_attributes__"? The only difference appears to be placing it in "SFN" section.
Regards,
Brian Quach
SimpleLink MCU
Texas Instruments Inc.
Hello,
I am trying to build TF-M v1.8 with a custom tfm_mbedcrypto_config_profile_medium.h . I mainly do not want to use a platform specific calloc /free calls, instead use standard free() and calloc(). If I disable MBEDTLS_PLATFORM_MEMORY and MBEDTLS_PLATFORM_C in tfm_mbedcrypto_config_profile_medium.h and attempt to build TF-M, I get the following error:
/arm-none-eabi/lib/thumb/v8-m.main+fp/hard/libnosys.a(sbrk.o): in function `_sbrk':
/data/jenkins/workspace/GNU-toolchain/arm-11/src/newlib-cygwin/libgloss/libnosys/sbrk.c:21: undefined reference to `end'
I'm able to build mbedtls package with both MBEDTLS_PLATFORM_MEMORY and MBEDTLS_PLATFORM_C disabled without any errors, the undefined reference error is only seen when building TF-M.
Any thoughts on how to resolve this?
Regards,
Archanaa
Hi all,
Seems like dependency on generated files is broken.
Steps to reproduce:
1. Build any platform at any mode
2. Change any .template file
3.
Expected result:
1. New file is generated from the updated .template file
Actual result:
1. Generated files step is skipped.
My best guess will be that 1ce59292a47b1316e5d8b4d28bcaf9d8e2bdc0a5 broke it.
Could this be fixed?
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,
Some time ago we planned to rename our master branch to main in all 6 repositories. There are multiple ways of doing that and I want to discuss with the community the best way suitable for all.
I can see the following options:
1. rename master->main and use the main from one day.
2. Create the main for contribution with main->master sync. Make master R/O and delete it in 3 months.
3. Keep contributing to the master but syncing master->main.
4. Other way?
I suggest option 2 but looking for better alternatives if any.
Thanks,
Anton
Hi everyone,
The mailbox ns agent update document has the latest update to solidarize the API, here is the link for your review:
Docs: Mailbox non-secure vectors processing (Ie4ec599c) * Gerrit Code Review (trustedfirmware.org)<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/22282>
The agent-specific API should be good enough for now to handle different mailbox implementation cases, such as memory-based or non-memory-based.
* Non-secure provided vectors can be referenced directly to avoid extra copy.
* For non-memory-based schemes, the vectors have to be collected locally in NS Agent.
We are also updating the code to validate the new API, may touch those platforms that are mailbox-related, please take care of the patches as well.
SPM: Update the agent API to follow the design (I38e67578) * Gerrit Code Review (trustedfirmware.org)<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/22608/2>
BR
/Ken
