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>
Hi all,
We've created a change, which is using original CMSIS headers in TF-M. Current patch is only for arm/mps3/an552 platform. Our plan is to create a public review only for this (which will NOT be merged), and after the review, we would like to extend this patch to all of the platforms.
The main changes in the chain:
- copy and zero_table size fix in the GNU linker scripts and initial startup code
- Removed __INITIAL_SP and __STACK_LIMIT patch form gcc and iar cmsis files, NS linker scripts using CMSIS style naming, the secure and bl2 build's linker scripts remains untouched (ARMCLANG style naming, __INITIAL_SP and __STACK_LIMIT patched with cmsis_stack_override interface library)
- NS process stack removed from NS linkers (PSP)
- Common startup file for bl2 and ns builds
- Add original cmsis headers, updated system and startup files
- Stack sealing done twice, once from startup (to resemble CMSIS startup template) and once from TF-M secure main
Feedback is welcome:
https://review.trustedfirmware.org/q/topic:%2522use-original-cmsis-headers%…
David Hazi
Hi everyone,
I have several questions related to L3 isolation in TFM.
First of all, FFM specifies that:
* In L3 PSA RoT partitions does not need to be isolated from SPM (and vice versa)
* PSA RoT partitions does not need to be isolated from each other
* PSA RoT partitions and SPM must be isolated from APP RoT partitions
* APP RoT partitions must be isolated from each other
This picture from TFM docs<https://tf-m-user-guide.trustedfirmware.org/docs/technical_references/desig…> seem to illustrate statements above.
Currently platforms with L3 support (e.g. an521) follow the rules stated above.
They achieve this by executing PSA RoT partitions and SPM in privileged mode, and APP RoT partitions in unprivileged mode. Partition boundaries are only updated when switching to APP RoT partition.
From description of tfm_hal_activate_boundary (see code here<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/secure_fw/…>) and this an521 code<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/platform/e…> seems like platform can determine whether partition will be executed in privileged or unprivileged mode.
So my questions are:
1. For improved isolation in L3 does it make sense to:
* isolate SPM from PSA RoT partitions
* isolate PSA RoT partitions from each other (like APP RoT partitions are isolated)
1. If question 1 make sense then can platform achieve this improved isolation with current code base?
From this an521 code<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/platform/e…> it seems like platform may set all partitions to be executed in unprivileged mode and dynamically switch boundaries between them (between both PSA and APP RoT partitions). SPM will remain in privileged mode.
It seems like this approach is possible with minor changes to SPM. For example this code will need<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/secure_fw/…> to be changed to call tfm_hal_activate_boundary regardless of partition privilege level.
Are there any other changes needed to make this approach work?
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>
Hi everyone,
I have several questions related to partition assets attributes.
FFM specifies 2 types of assets (mmio_regions):
* Named MMIO region
* Numbered MMIO region
FFM does not really specify the use cases for these 2 different types.
I expect that Named region is only used for peripherals and numbered region is only used for memory regions.
Am I right here? If no, then what the use cases for these 2 types are and what is currently supported in TFM?
Also I see that in tools/templates/partition_load_info.template lines 221-224 ASSET_ATTR_NUMBERED_MMIO or ASSET_ATTR_NAMED_MMIO are assigned for assets from manifest files depending on their type, but tools/templates/partition_load_info.template#187<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/tools/temp…> does not assign any of these attributes for "PART_REGION_ADDR(PT_{{manifest.name}}_PRIVATE, _DATA_START$$Base)" at isolation level 3.
Is this some a bug or I am missing some knowledge on this mmio_regions stuff?
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,
Following tech forum today and the presentation on August 18 (to be published asap), I propose to deprecate TF-M library model as an obsolete and replace it with SFN model as a successor.
PSA compliant SFN and IPC, defined in FF_M will then be the 2 supported models in TF-M going forward.
Please share your thoughts and concerns on the proposal.
Having no objections, we will depreciate the Library model after October 1 and it will be removed in TF-M v1.7.0
Thanks, and best regards,
Anton
Hi,
we wish to avoid the pitfalls of "doing your own security", and at the same time not use
dummy/template code that is not meant for production.
May I ask if it is still accurate what the docs say here about the template folder, namely that
nothing in the template folder should be used in production without being ported first?
This directory contains platform-independent dummy implementations of the interfaces in platform/include. These implementations can be built directly for initial testing of a platform port, or used as a basic template for a real implementation for a particular target. They must not be used in production systems.
$ ls platform/ext/common/template/
attest_hal.c flash_otp_nv_counters_backend.c otp_flash.c tfm_initial_attest_pub_key.c
crypto_keys.c flash_otp_nv_counters_backend.h tfm_fih_rng.c tfm_rotpk.c
crypto_nv_seed.c nv_counters.c tfm_initial_attestation_key.pem tfm_symmetric_iak.key
