- User Since
- Apr 9 2018, 6:38 AM (190 w, 6 d)
May 7 2020
Marking the issue as closed taking into account the inactivity on this thread.
I suggest opening a new issue/issues - with finer incremental aims if possible - based on the present status of the project if needed.
Apr 29 2020
In line with your latest comment and the closure of the corresponding issue T421 referred to by @tamasban , I am closing this thread.
I suggest to open a new issue and refer back to this thread if there are related comments on the present state of the project.
Since the change referred to in the original issue (https://review.trustedfirmware.org/c/trusted-firmware-m/+/1123) has been abandoned with an alternative added to the comments for that review, I am closing this thread.
I suggest that considering the time elapsed since the last comment to open a new issue and refer back to this if there are related comments on the present state of the project.
The aforementioned fix was merged on 26 July, 2019. Closing this issue.
Sep 9 2019
Various aspects of this task are to be addressed in different broader conceptual changes in the code base.
Jul 29 2019
As I believe the change has been implemented with the new scope, I'm re-assigning the ticket to Mate, the owner of the change.
Jul 25 2019
Revisiting this topic:
Jun 28 2019
TF-M does not need to be aware of any solution applied on the non-secure side to ensure serialization of secure calls. TF-M does not check the status of the NS lock, what it does is detects concurrent calls to the secure domain using a secure lock that is independent of the NS side implementation.
What we have in the repository for the NS lock is a reference implementation for a generic solution, but use of the non-secure lock is not - and cannot - be enforced by SPM. So if the NS OS you are using in your build exposes the functions you mention, your application is free to call them. It does not need support in the TF-M repository.
The only thing to note is that any proprietary implementation should ensure single entry to the secure domain as any concurrent calls would be flagged up as severe security violations. Any NS policy that avoids this scenario is transparent and acceptable.
Jun 19 2019
Jun 6 2019
The NS lock is initialized at a point in time when the scheduler is not yet started, therefore there is a single thread of execution on the NS side.
I agree it is safe to assume that in such a scenario, the only actor on the NS side is privileged and therefore is assumed to be in full control of execution, there are no separate protection domains within NSPE.
Secure lock is already set up so there's no risk of introducing new exploits with this change.
Jun 5 2019
https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/951/ reviewed, approved, upstreamed
Jun 3 2019
Due to increased interest in this feature and no objections to the implementation concept, I'm raising the priority and will rebase my proposal change and do some polishing to make it a good candidate for upstreaming.
The suggested change of naming convention was discussed offline but was deemed unnecessary as there's limited risk of the feature being misunderstood and that is planned to be mitigated by improved documentation, while the design pattern evoked by the current name is hopefully a reasonable point of reference.
May 31 2019
Fix for second issue:
May 30 2019
Thanks, the change is approved.
Could you provide details of the compiler configuration where you received this error?
We may need to update the configurations in CI to capture similar shortcomings.
I will execute some rudimentary tests in the meantime.
May 24 2019
See below review for corresponding change:
May 20 2019
Apr 25 2019
Please see the review below for proposal:
Apr 11 2019
The transition from NS to S using the psa_call veneer has an implementation-defined layer of serialization in addition to what is prescribed in the PSA client API, necessary because of the limitations on parameter passing between security states.
The argument list mentioned above:
psa_status_t tfm_psa_call_veneer(psa_handle_t handle, const psa_invec *in_vecs, const psa_invec *out_vecs);
has those data types by design: both the invec array and outvec array are serialized to one invec each, i.e. two input parameters for the secure veneer, one containing the array of invecs, the other containing the array of outvecs.
From the veneer point of view both are constant input parameters, hence the const psa_invec type.
When extracting the arrays from these vectors in tfm_svcalls.c you can see the deserialization to the PSA-defined data types:
outptr = (psa_outvec *)((psa_invec *)args)->base; out_num = ((psa_invec *)args)->len;
Feb 25 2019
Feb 21 2019
Feb 5 2019
Jan 29 2019
Please note that secure SVC is running on highest priority. Execution of this code cannot be pre-empted by either NSPE or any external secure interrupt. This is essentially a critical section.
Jan 10 2019
Jan 8 2019
Dec 19 2018
Dec 11 2018
Dec 10 2018
Please see https://developer.trustedfirmware.org/w/tf_m/design/uniform_secure_service_signature/ for detailed design proposal
Nov 23 2018
Nov 19 2018
A bugfix is provided for incorrect default behaviour if NS client identification is turned off in the build environment in change:
Nov 14 2018
Nov 13 2018
Nov 12 2018
Oct 20 2018
Oct 19 2018
Oct 1 2018
Design documented at https://developer.trustedfirmware.org/w/tf_m/design/ns_client_management/
Sep 21 2018
Sep 19 2018
Change and related improvements upstreamed
https://review.trustedfirmware.org/#/c/191/ is a proposed resolution for this change.
Sep 17 2018
Based on @gyuri-szing's comment on the review I split the change to two parts:
https://review.trustedfirmware.org/#/c/174/ only fixes the upstream to keep NS exceptions disabled during secure execution by default as is the current assumption for TF-M.
Change https://review.trustedfirmware.org/#/c/183/ introduces the switch. Gyorgy's comment can be debated separately this way without blocking the fix.
Sep 7 2018
In my view we should investigate other options for having the API definitions stand out from the service internal files.
There is an ongoing effort to limit the number of steps that need to be taken in order to integrate a new partition into the system, or to disable/enable one that is already present.
I would therefore suggest to keep service API files in the service folder and not create a new location for them.
Sep 4 2018
Change on review at:
The change has been merged on both branches
Aug 24 2018
Mate is working on the prototype while I'm writing the design document.
Aug 6 2018
Jun 26 2018
https://issues.trustedfirmware.org/T39 to follow up on updates needed for newer version of PSA spec and updates, reduction of proprietary fields
First batch of related changes upstreamed.