Change Details

This topic records the todo items for alignment with PSA FF. The target FF version is the public released version while updating this topic. The current target version is: "1.0-bet0" |No|Issue|First mentioned place|Priority|Comment| |1|NSPE parameter validation|[[ https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/459/ | 459]] Alexander's comments|Medium|The comment is taking about NS parameter checking but finally links to the panic mechanism in core|

The NSPE parameter checking is missing in current patches: [[ https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/459/ | 459]] And the comments: Consider dual core system like PSoC6 or MPS2 we are currently working on. Would you really want to allow NSPE client to cause panic on secure core that easily? As i see it panic should be triggered on the caller core when possible. There are cases like invalid handle which you cannot assert on the caller side as you need to access to SPM internal state. Or pointers to caller inaccessible memory inside in/out vectors. But this is a simple sanity check i'm suggesting to add. We already have C code which compiled as a part of NSPE application. So it very easy to handle. On the other hand you must not relay on this validations only in secure side as an offending code can call SG directly without going through TF-M veneers.

This topic records the todo items for alignment with PSA FF. The target FF version is the public released version while updating this topic.e NSPE parameter checking is missing in current patches: The current target version is: "1.0-bet0"[[ https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/459/ | 459]] |No|Issue|First mentioned place|Priority|CAnd the comment|s: |1|NSPE parameter validation|[[ https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/459/ | 459]] Alexander's comments|Medium|The comment is taking about NS parameter checking but finally links to the panic mechanism in core|Consider dual core system like PSoC6 or MPS2 we are currently working on. Would you really want to allow NSPE client to cause panic on secure core that easily? As i see it panic should be triggered on the caller core when possible. There are cases like invalid handle which you cannot assert on the caller side as you need to access to SPM internal state. Or pointers to caller inaccessible memory inside in/out vectors. But this is a simple sanity check i'm suggesting to add. We already have C code which compiled as a part of NSPE application. So it very easy to handle. On the other hand you must not relay on this validations only in secure side as an offending code can call SG directly without going through TF-M veneers.