On Mon, Apr 15, 2019 at 02:52:56PM +0000, Tamas Ban via TF-M wrote:
>Actually the design doc propose to use a distinct security counter from image version (ih_ver in header). But in the most simple case this security counter can be derived from the image version, to have the exact same value (ignoring the build number).
>
>The image signature cover these continues blocks in memory:
>- image header
>- image
>- some part of TLV section (currently not covered, but due to multi image support it is planned to introduce a signed TLV section)
>
>Because these are contiguous regions in the memory it is not possible
>to place only the (header + TLV section) to the trusted memory but
>miss out the image itself (at least I cannot see how to solve)
Could the trusted memory contain a version field, and perhaps a hash
of the image?
David
Hi Andrej,
Your interpretation is correct: if NS client identification is disabled, all non-secure threads are assigned the default non-secure client id (-1).
That means that secure services cannot differentiate between various non-secure threads, i.e. they would all be provided the same access policies when requesting secure services.
This is in line with PSA Firmware Framework. As described in chapter 3.3.3 of PSA FF 1.0 beta Release 0, "In implementations where NSPE client_id values are provided by the SPM, the same negative client_id must be used for all connections."
Note that according to that specification each connection and message would still have their own unique handles - see chapter 3.3.4.
Note also that this does not impact the client ID assignments for secure partitions, so any service would be able to identify if it was called by a non-secure entity or a secure one, and if a secure one, then which one.
Let me know if you need further assistance in this matter.
Regards
Miklos
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M
Sent: 25 April 2019 12:47
To: David Hu (Arm Technology China) <David.Hu(a)arm.com>
Cc: TF-M(a)lists.trustedfirmware.org
Subject: Re: [TF-M] [EXT] Re: TFM and FreeRTOS
Hi David,
OK. We may try to limit FreeRTOS to the case when it starts and runs only in non-secure world and its tasks will call secure world only via PSA/TFM API.
In this case, if I understand well, to avoid conflict for non-secure SVC, it is enough to disable TFM_NS_CLIENT_IDENTIFICATION.
It means that all user tasks will be assigned to the default user id = DEFAULT_NS_CLIENT_ID.
What does it mean? How does it limits the functionality? Is it OK from PSA point of view?
Thanks,
Andrej
-----Original Message-----
From: David Hu (Arm Technology China) <David.Hu(a)arm.com>
Sent: Thursday, April 25, 2019 11:26 AM
To: Andrej Butok <andrey.butok(a)nxp.com>; tf-m(a)lists.trustedfirmware.org
Subject: [EXT] Re: [TF-M] TFM and FreeRTOS
Caution: EXT Email
Hi Andrej,
I guess that you may ask about the SVCalls communication between secure world and non-secure world in FreeRTOS. If I misunderstood your question, please ignore the following.
In my very own opinion, FreeRTOS has a different concept of how to manage secure stack/context from TF-M does.
FreeRTOS prefers to allocate and manage a dedicated secure stack/context for each non-secure task requiring secure service. In its implementation, each time when it does context switch, it invokes SVCalls to also switch the secure stack/context for the next non-secure task. FreeRTOS implements several own APIs to accomplish those functionalities.
By contrast, TF-M as a trusted firmware, naturally, manages all the secure resource by its own. Therefore, there is no such dedicated stack in secure world mapping to each non-secure task. Currently, TF-M implements CMSIS RTOS thread context management APIs to execute some management work between non-secure world and secure world, on Armv8-M core.
Hope it can hlep you.
Best regards,
Hu Ziji
On 4/25/2019 3:45 PM, Andrej Butok via TF-M wrote:
> Hello,
>
> Do you know about any existing port of FreeRTOS (instead of RTX) to TFM? Did somebody a feasibility study?
> I have just started to look at it, and immediately detected a conflict, both are using Supervisor Calls (SVC) for own needs.
>
> Thanks,
> Andrej
>
>
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
Hi Andrej,
The idea of the OS wrapper layer is to abstract the underlying OS, so that the test app can use generic wrapper APIs, which are implemented using OS-specific APIs. In os_wrapper_rtx.c, we provide an example implementation that targets the CMSIS-RTOS2 APIs for RTX.
As osThreadJoinable is not supported by FreeRTOS, you can remove that attribute in your port, and implement os_wrapper_join_thread() as a no-op. We use semaphores for synchronisation in the test app anyway, so os_wrapper_join_thread() only needs to be implemented if threads are joinable and so need join() to be called to free up resources associated with the thread.
I do think we could make the OS wrapper layer a bit more generic though. We could replace the only call to os_wrapper_join_thread() that currently exists with a call to a new function os_wrapper_delete_thread(), which is defined to release the resources associated with a thread context. For CMSIS-RTOS2 this can be empty because this happens automatically, but for other RTOS APIs there may be some delete() function that needs to be called. Let me know what you think.
Best wishes,
Jamie
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M
Sent: 02 May 2019 15:04
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] Avoid osThreadJoin()
Hello,
The TFM test applications are using CMSIS-RTOS2 API. And this is good.
But could you delete os_wrapper_join_thread()and avoid using of osThreadJoin().
If I understand well, its support by RTOS tasks is optional (via osThreadJoinable flag).
The problem is that the osThreadJoin() functionality is not supported by FreeRTOS (https://arm-software.github.io/CMSIS-FreeRTOS/General/html/tech_data.html).
It is critical obstacle.
Could you tell what are you going to do with this requirement? To understand, if to continue with a FreeRTOS port.
Thank you
Andrej Butok
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
Hello,
The TFM test applications are using CMSIS-RTOS2 API. And this is good.
But could you delete os_wrapper_join_thread()and avoid using of osThreadJoin().
If I understand well, its support by RTOS tasks is optional (via osThreadJoinable flag).
The problem is that the osThreadJoin() functionality is not supported by FreeRTOS (https://arm-software.github.io/CMSIS-FreeRTOS/General/html/tech_data.html).
It is critical obstacle.
Could you tell what are you going to do with this requirement? To understand, if to continue with a FreeRTOS port.
Thank you
Andrej Butok
Hi Andrej,
TF-M has no requirement on NS thread execution being unprivileged, nor is it mandated by PSA.
It is one of a set of measures that make non-secure thread isolation possible, reduce attack surface and provide a degree of tolerance against programming errors, but its absence does not invalidate the security measures provided by TF-M, so it is a fully valid implementation to make NSPE a single protection domain and all non-secure code execution privileged.
Regards
Miklos
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M
Sent: 02 May 2019 14:19
To: TF-M(a)lists.trustedfirmware.org
Subject: [TF-M] NS application privilege mode
Hello,
May a non-secure TFM user application stay in the privilege mode after start-up? It's needed, as some system registers are accessible only in the privilege mode.
Asking, because the TFM NS Musca start-up code is switching to the unprivileged mode from very beginning:
MRS R0, control ; Get control value
ORR R0, R0, #1 ; Select switch to unprivilage mode
ORR R0, R0, #2 ; Select switch to PSP
MSR control, R0
Hope, it is not mandatory.
Thanks,
Andrej Butok
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
Hello,
May a non-secure TFM user application stay in the privilege mode after start-up? It's needed, as some system registers are accessible only in the privilege mode.
Asking, because the TFM NS Musca start-up code is switching to the unprivileged mode from very beginning:
MRS R0, control ; Get control value
ORR R0, R0, #1 ; Select switch to unprivilage mode
ORR R0, R0, #2 ; Select switch to PSP
MSR control, R0
Hope, it is not mandatory.
Thanks,
Andrej Butok
Hi,
This is a proposal that introduces scheduling rules in TF-M.
Introduction:
On ArmV8-M CPUs, NSPE and SPE share the same physical processing element(PE). A TF-M enabled system need to be able to handle asynchronous events (interrupts) regardless of current security state of the PE; and that may lead to scheduling decisions. This introduces significant complexity into TF-M. To keep the integrity of (NSPE and SPE) schedulers and call paths between NSPE and SPE, following set of rules are imposed on the TF-M scheduler design.
https://developer.trustedfirmware.org/w/tf_m/design/cooperative_scheduling/
Feedback welcome!
Thanks,
Ashu
Hi All,
The parts that refer to the BASEPRI_NS register being set on return from Secure services has been removed from the document (marked with strikethrough), as the attack surfaces introduced by not doing it are mitigated by the veneer stack checking on secure function entry.
Sorry for the inconvenience.
Best regards,
Mate
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Mate Toth-Pal via TF-M
Sent: 29 April 2019 15:21
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: [TF-M] Non-secure interrupt handling design proposal
Hi All,
The design proposal for the Non-secure interrupt handling is available for review at the following link:
https://developer.trustedfirmware.org/w/tf_m/design/ns_interrupt_handling/
Please share your thoughts in this mail thread.
Thank you!
Best regards,
Mate
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
Hi,
There was a cmake response file patch to fix the linker error especially in windows:
https://review.trustedfirmware.org/c/trusted-firmware-m/+/237
In this patch I set proper flags for linkers, but also enable response file as default, which caused some concerns about: is the response file option stable enough, will it break the build?
So I created an updated one, which just set correct response file switch for linkers, and do not enable response file as default. In the case if ARMCLANG response is enabled by cmake automatically, cmake could apply correct response flag for ARMCLANG:
https://review.trustedfirmware.org/c/trusted-firmware-m/+/925
Because they are pushed towards different branches, so a new gerrit item is generated which lost the history...The only difference with previous one is removed below line :
set(CMAKE_${lang}_USE_RESPONSE_FILE_FOR_OBJECTS 1)
The reason I raise this patch is because, this problem happens every time in my PC so I have to cherry-pick this patch before building anything. I had seen someone got the same issue, and want to check how you solve this.
Call for volunteers to help verifying this patch (925) in your side and provide feedback to ensure it will not break the building, is there anyone could help? Just cherry-pick this patch into your environment is OK.
Thanks.
-Ken
