I'd like give a proposal on how to manage the version of tf-m-tests repo in auto-download mode of the build system.
Best Regards,
Kevin
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M
Sent: Monday, January 4, 2021 5:33 PM
To: Anton Komlev <Anton.Komlev(a)arm.com>; tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] Technical Forum call - Jan 7
Hi Anton,
I'd like to give a brief introduction to TF-M generic threat model.
Best regards,
Hu Ziji
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Anton Komlev via TF-M
Sent: Monday, January 4, 2021 5:30 PM
To: 'tf-m(a)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: [TF-M] Technical Forum call - Jan 7
Hello,
The next Technical Forum is planned on Thursday, January 7 at 6:00-07: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
I think the link needs to be updated into:
https://review.trustedfirmware.org/q/topic:%22static_linker_scripts%22+(sta…
This would make the components arrangement more simpler than using a templating. But for level 3 we still have to using a templating as now there is no 'foreach' like functionalities supported in the ld/sct/icf.
/Ken
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Raef Coles via TF-M
Sent: Wednesday, January 13, 2021 11:44 PM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: [TF-M] [RFC] Static linker scripts for level 1 and 2 isolation
Hi everyone
I'd like to request comments on an upcoming change to the linker scripts.
Because of some recent changes to the memory layout for level 1 and level 2 isolation, it's now possible to avoid the generation step via tfm_parse_manifest_lists.py for those linker files. This means that the files are static and have been committed into the source tree (as they used to be).
We anticipate this change will make integrating TF-M into non-cmake buildsystems easier, as it will avoid one of the places where files need to be generated at build-time.
The reason this is an RFC is that it is a potentially breaking change, but only for integrators _not_ using the cmake buildsystem.
Currently the linker uses a large variety of pattern matches to organise the partition symbols, with these patterns being defined in the tfm_manifest_list.yaml. After this change, the linker will only look for two patterns:
`*app_rot_partition*` and `*psa_rot_partition*`
With the intention that the secure partitions will be compiled into a static library, where the filename is (for example) `libtfm_psa_rot_partition_crypto.a`. The cmake buildsystem will be updated to generate these filenames, but other integrators will need to adjust their compilation steps else the linking will fail.
Any comments or concerns would be appreciated.
Patches can be found at:
https://review.trustedfirmware.org/q/topic:%23static_linker_scripts%22
Raef
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
Hello,
The next Technical Forum is planned on Thursday, January 21 at 15:00-16:00 UTC (US 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
Hi everyone
I'd like to request comments on an upcoming change to the linker scripts.
Because of some recent changes to the memory layout for level 1 and level 2 isolation, it's now possible to avoid the generation step via tfm_parse_manifest_lists.py for those linker files. This means that the files are static and have been committed into the source tree (as they used to be).
We anticipate this change will make integrating TF-M into non-cmake buildsystems easier, as it will avoid one of the places where files need to be generated at build-time.
The reason this is an RFC is that it is a potentially breaking change, but only for integrators _not_ using the cmake buildsystem.
Currently the linker uses a large variety of pattern matches to organise the partition symbols, with these patterns being defined in the tfm_manifest_list.yaml. After this change, the linker will only look for two patterns:
`*app_rot_partition*` and `*psa_rot_partition*`
With the intention that the secure partitions will be compiled into a static library, where the filename is (for example) `libtfm_psa_rot_partition_crypto.a`. The cmake buildsystem will be updated to generate these filenames, but other integrators will need to adjust their compilation steps else the linking will fail.
Any comments or concerns would be appreciated.
Patches can be found at:
https://review.trustedfirmware.org/q/topic:%23static_linker_scripts%22
Raef
Hi all,
I made a patch<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7817> to refine the variable naming in manifest tooling, specifically the "manifest.manifest" in templates.
I'm changing it to "partition.manifest" which should be more accurate and easy understanding.
Broadcasting here for anyone has out-of-tree templates.
And any comments are welcome.
Best Regards,
Kevin
Hi Antonio,
Thanks a lot for reviewing the threat model and bringing up this topic.
To fully mitigate the threat you mentioned, NSPE shall enforce NS tasks isolation and assign/manage NS identifications. IMHO, It mainly relies on non-secure side implementation.
Therefore that threat can be covered in the scope of another threat model against NS side.
TF-M is trying to figure out how to assist NSPE to manage and transfer NS identifications. Any suggestion or comment is welcome and helpful! 😊
Best regards,
Hu Ziji
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio Ken IANNILLO via TF-M
Sent: Wednesday, December 30, 2020 7:13 PM
To: tf-m(a)lists.trustedfirmware.org
Subject: Re: [TF-M] TF-M generic threat model
Hi Hu,
I read the threat model and I have a question regarding a potential threat.
I’m not sure it should belong to this generic threat model or it is already included in one of those presented.
The scenario is the following: a NS App X uses a RoT Service that store data private to X. Another NS App Y can fool the SPE to impersonate X and retrieve its private data. For example, X save a value in the secure storage and Y retrieves this value. TF-M prevents this using non secure client identification mechanism. This is a classic confused deputy problem.
Can this be considered a threat in this model or should it belong to another model/TOE?
Best,
--
Antonio Ken Iannillo
Research Scientist – SEDAN group
SnT – Interdisciplinary Centre for Security, Reliability and Trust
UNIVERSITÉ DU LUXEMBOURG
CAMPUS KIRCHBERG
29, avenue John F. Kennedy
L-1855 Luxembourg Kirchberg
T +352 46 66 44 9660
https://akiannillo.github.io/
Hi Anton,
I'd like to give a brief introduction to TF-M generic threat model.
Best regards,
Hu Ziji
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M
Sent: Monday, January 4, 2021 5:30 PM
To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com>
Subject: [TF-M] Technical Forum call - Jan 7
Hello,
The next Technical Forum is planned on Thursday, January 7 at 6:00-07: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
Hello,
The next Technical Forum is planned on Thursday, January 7 at 6:00-07: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
Hi,
The existing section 'TFM_UNPRIV_DATA' now holds nothing - it was designed for holding some data belong to the unprivileged code block, while now the unprivileged code is required as read-only and no place for its read-write data.
Remove this section as it is unused; also remove those code objects exists in the unprivileged code section but has read-write data: 'platform_retarget_dev.o' and 'device_definition.o'.
This patch changes some sources inside the platforms, so the platform owner please help to check if that matters:
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7754
Thanks.
/Ken
Hi Hu,
I read the threat model and I have a question regarding a potential threat.
I’m not sure it should belong to this generic threat model or it is already included in one of those presented.
The scenario is the following: a NS App X uses a RoT Service that store data private to X. Another NS App Y can fool the SPE to impersonate X and retrieve its private data. For example, X save a value in the secure storage and Y retrieves this value. TF-M prevents this using non secure client identification mechanism. This is a classic confused deputy problem.
Can this be considered a threat in this model or should it belong to another model/TOE?
Best,
--
Antonio Ken Iannillo
Research Scientist – SEDAN group
SnT – Interdisciplinary Centre for Security, Reliability and Trust
UNIVERSITÉ DU LUXEMBOURG
CAMPUS KIRCHBERG
29, avenue John F. Kennedy
L-1855 Luxembourg Kirchberg
T +352 46 66 44 9660
https://akiannillo.github.io/
