To be most clear, this issue only arrises if QCBORDecode_SetMemPool() is called by the user of the CBOR decoder to configure the internal string allocator.

Fix link issue, to not drop out symbols from archive:
https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/636/

This task is addressed by the following commits:
https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/632/
https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/633/
https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/634/

Porting COSE library to psa_crypto:
https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/630/

COSE library integartion with TF-M build systems:
https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/629/

Related change:
https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/603/

Thanks Alex.
That's a quick fix for removing the blocker. After T244 is solved this patch maybe not relevant, the purpose is no affecting API user behaviour (no workarounds) even the connection handle allocation mechanism is changed. Since mechanism changing may not happen soon, let's apply this one first.

I can verify that https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/627/ works on our code.

the changes will solve current issue, but it is only a partial solution. Full solution depends on https://developer.trustedfirmware.org/T244
It seems the way connection handle is allocated needs to be reworked, thus the changes proposed in https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/627/ will no longer be relevant.

We will verify it on our Musca_a1 mbed-os porting work and update the results.

The patch link to support this function is here: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/627/

The issue is fixed in change https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/611/

The issue is fixed in change https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/612/

In the case of integration with mbedOS in the NS side, I would expect the NS binary to provide its own implementation of the functionalities described in interface/include/tfm_ns_lock.h, instead of reusing the implementation that is available in interface/src/tfm_ns_lock_rtx.c, which is aimed specifically to CMSIS.

From what we've seen mbed-os disables the "Automatic Dynamic Allocation"

fixed by :
https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/601/
https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/602/

As a workaround try to make the path shorter. I refer to the directory where the tf-m, the mbedtls and the CMSIS5 working copy is as "work root" hereafter.
For this on windows:

• you can use the subst command map the work root to a drive letter.
• use the mklink command to link (hard link or junction point) the work root into c:\

The current implementation is based on the mechanism provided by the CMSIS-RTOS2 layer as default, which is the "Automatic Dynamic Allocation"

A workaround for us which fixed this issue was setting the descriptor struct volatile:

volatile struct tfm_sfn_req_s desc;
struct tfm_sfn_req_s *desc_ptr = &desc;

The change which fixes this issue is available here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/593

Patch for this task: https://review.trustedfirmware.org/c/trusted-firmware-m/+/591

Note: cmake release CMake 3.9.0-rc1 has an important bugfix for response file handling. Fixing this issue shall be done after build-system is updated to support latest cmake version. See T228.

The change related to this task is available here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/588

I think we found temporary workaround on our side.
It is no longer a blocker for us, but still HP.
tnx

If a section is empty, and '.' is aligned in the section, the gcc linker returns a warning.

Thanks for submitting. We will investigate it and try to find out a plan.

Patch for this task https://review.trustedfirmware.org/c/trusted-firmware-m/+/574

QCBOR implementation:
https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/454/

COSE implementation:
https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/456/

Related changes:
https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/562/
https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/534/
https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/533/

Handling of "No software component" case:
https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/563/

Miklos,
As always you are 100% right. I just wanted to provide simplistic example. Perhaps i've oversimplified :).
While you assumption is true for single core systems, it breaks on asymmetrical multi-core system where SPM is running on one core and NSPE on other.
TF-M is not supporting such a targets right now, but we are now working on a port for such a target.
I suggest to take this in to consideration while implementing new functionality.

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.

the spec specifies that caller passes a pointer array of psa_invec. The array is allocated in caller memory, thus is modifiable by a caller at any time.
SPM must first copy each individual psa_invec to SPM own memory, and only then verify accessibility of each individual range.

Hi Alex,
This line is for extracting NSPE invec/outvec from invec due to parameters number limitation. The anti-TOCTOU is added in line: 177 now working for secure partitions.

from what i see invecs are not copied. Perhaps i'm looking at outdated sources? https://review.trustedfirmware.org/c/trusted-firmware-m/+/468/1/secure_fw/core/ipc/tfm_svcalls.c#131

in_vec = (psa_invec *)((psa_invec *)args[1])->base;
in_num = ((psa_invec *)args[1])->len;
out_vec = ((psa_outvec *)args[2])->base;
out_num = ((psa_outvec *)args[2])->len;

Please note that newer version of PSA FF spec introduced a change to psa_get API especially to address this issue. psa_get now return an error code (it had void return value before and was not allowed to fail).
PSA_ERR_NOMSG is a special error code that can be returned from psa_get if you encounter resource allocation issue.
SP should then ignore current signal and retry later on.

Thanks, Alexander, currently we copy into a local buffer and then moved to the message instead of moving to message directly due to message buffer allocation limitation (https://developer.trustedfirmware.org/T195)

isolation level 3 assumes mutual distrust between secure partitions.
we need to save connection "owner" client ID and not only secure domain origin.

Patch for this task https://review.trustedfirmware.org/c/trusted-firmware-m/+/544