Hi,
I saw that PSA_FRAMEWORK_HAS_MM_IOVEC is not permitted for Isolation level 2-3 and transient copies of the input and output data into a 5KB scratch buffer are always made when making a PSA call. This makes sense as FF-Mv1.1 states: “In a system using isolation level 3, a Secure Partitions is not permitted to access another Secure Partition’s Private data. MM-IOVEC can provide a mechanism for one Secure Partition to access the other’s Private data.”
But I think the requirements for isolation level 3 could be fulfilled by: If SP detects a Secure caller, it could make a transient copy of I/O data. If SP detects a Non-Secure caller, it could use MMIOVECs or a similar method to access NS memory directly to avoid overhead and limitations of copying the I/O data.
Is this logical/ correct?
With this approach, an attacker may tamper NS input data while the RoT service is processing those data but rules of isolation level 3 are maintained.
Regards,
Brian Quach SimpleLink MCU Texas Instruments Inc.
Hi Brian,
MM-IOVEC is permitted in isolation 2-3. It just may have some conflicts with the isolation rules. What you’ve quoted is just one of the conflicts. However, “Access to an input or output vector’s buffer for the duration of the call is expected by the client, so this does not itself present a new attack surface”. So MM-IOVEC could be implemented for isolation 2 and 3. But you have to be careful as the “implementation uses to map input and output vectors can be imprecise” because of, for example, the HW limitation of MPU. The MPU has the alignment constraints, for example, 32-byte. And then if you’d like to map a 16-byte vector, you might have to provide 16-byte more data for the RoT Service to access. Whether this imprecise map is acceptable depends on the security requirements.
But it is true that TF-M has not implemented that.
-an attacker may tamper NS input data while the RoT service is processing those data Usually, input data should be accessed by RoT Services with READ-ONLY permission.
-Kevin
From: Quach, Brian via TF-M tf-m@lists.trustedfirmware.org Sent: Tuesday, November 14, 2023 7:37 AM To: tf-m@lists.trustedfirmware.org; Shreve, Erik e-shreve@ti.com Subject: [TF-M] PSA_FRAMEWORK_HAS_MM_IOVEC
Hi,
I saw that PSA_FRAMEWORK_HAS_MM_IOVEC is not permitted for Isolation level 2-3 and transient copies of the input and output data into a 5KB scratch buffer are always made when making a PSA call. This makes sense as FF-Mv1.1 states: “In a system using isolation level 3, a Secure Partitions is not permitted to access another Secure Partition’s Private data. MM-IOVEC can provide a mechanism for one Secure Partition to access the other’s Private data.”
But I think the requirements for isolation level 3 could be fulfilled by: If SP detects a Secure caller, it could make a transient copy of I/O data. If SP detects a Non-Secure caller, it could use MMIOVECs or a similar method to access NS memory directly to avoid overhead and limitations of copying the I/O data.
Is this logical/ correct?
With this approach, an attacker may tamper NS input data while the RoT service is processing those data but rules of isolation level 3 are maintained.
Regards,
Brian Quach SimpleLink MCU Texas Instruments Inc.
Hi Kevin,
Is there any future plan to allow PSA_FRAMEWORK_HAS_MM_IOVEC with Isolation 2-3 in the TF-M build?
Would removing this cmake check be all that is required: tfm_invalid_config(TFM_ISOLATION_LEVEL GREATER 1 AND PSA_FRAMEWORK_HAS_MM_IOVEC)
Regards, Brian
From: Kevin Peng Kevin.Peng@arm.com Sent: Monday, November 13, 2023 9:18 PM To: Quach, Brian brian@ti.com; tf-m@lists.trustedfirmware.org; Shreve, Erik e-shreve@ti.com Subject: [EXTERNAL] RE: PSA_FRAMEWORK_HAS_MM_IOVEC
Hi Brian,
MM-IOVEC is permitted in isolation 2-3. It just may have some conflicts with the isolation rules. What you’ve quoted is just one of the conflicts. However, “Access to an input or output vector’s buffer for the duration of the call is expected by the client, so this does not itself present a new attack surface”. So MM-IOVEC could be implemented for isolation 2 and 3. But you have to be careful as the “implementation uses to map input and output vectors can be imprecise” because of, for example, the HW limitation of MPU. The MPU has the alignment constraints, for example, 32-byte. And then if you’d like to map a 16-byte vector, you might have to provide 16-byte more data for the RoT Service to access. Whether this imprecise map is acceptable depends on the security requirements.
But it is true that TF-M has not implemented that.
-an attacker may tamper NS input data while the RoT service is processing those data Usually, input data should be accessed by RoT Services with READ-ONLY permission.
-Kevin
From: Quach, Brian via TF-M <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Sent: Tuesday, November 14, 2023 7:37 AM To: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org; Shreve, Erik <e-shreve@ti.commailto:e-shreve@ti.com> Subject: [TF-M] PSA_FRAMEWORK_HAS_MM_IOVEC
Hi,
I saw that PSA_FRAMEWORK_HAS_MM_IOVEC is not permitted for Isolation level 2-3 and transient copies of the input and output data into a 5KB scratch buffer are always made when making a PSA call. This makes sense as FF-Mv1.1 states: “In a system using isolation level 3, a Secure Partitions is not permitted to access another Secure Partition’s Private data. MM-IOVEC can provide a mechanism for one Secure Partition to access the other’s Private data.”
But I think the requirements for isolation level 3 could be fulfilled by: If SP detects a Secure caller, it could make a transient copy of I/O data. If SP detects a Non-Secure caller, it could use MMIOVECs or a similar method to access NS memory directly to avoid overhead and limitations of copying the I/O data.
Is this logical/ correct?
With this approach, an attacker may tamper NS input data while the RoT service is processing those data but rules of isolation level 3 are maintained.
Regards,
Brian Quach SimpleLink MCU Texas Instruments Inc.
Hi Brian,
It’s not just about configurations. You need to implement the feature in the SPM. However, as the imprecise map issues mentioned below, it must be designed very carefully. And the implementation may even vary between different use cases. We have no clear plan to support it for the time being.
-Kevin
From: Quach, Brian brian@ti.com Sent: Wednesday, November 15, 2023 8:38 AM To: Kevin Peng Kevin.Peng@arm.com; tf-m@lists.trustedfirmware.org; Shreve, Erik e-shreve@ti.com Subject: RE: PSA_FRAMEWORK_HAS_MM_IOVEC
Hi Kevin,
Is there any future plan to allow PSA_FRAMEWORK_HAS_MM_IOVEC with Isolation 2-3 in the TF-M build?
Would removing this cmake check be all that is required: tfm_invalid_config(TFM_ISOLATION_LEVEL GREATER 1 AND PSA_FRAMEWORK_HAS_MM_IOVEC)
Regards, Brian
From: Kevin Peng <Kevin.Peng@arm.commailto:Kevin.Peng@arm.com> Sent: Monday, November 13, 2023 9:18 PM To: Quach, Brian <brian@ti.commailto:brian@ti.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org; Shreve, Erik <e-shreve@ti.commailto:e-shreve@ti.com> Subject: [EXTERNAL] RE: PSA_FRAMEWORK_HAS_MM_IOVEC
Hi Brian,
MM-IOVEC is permitted in isolation 2-3. It just may have some conflicts with the isolation rules. What you’ve quoted is just one of the conflicts. However, “Access to an input or output vector’s buffer for the duration of the call is expected by the client, so this does not itself present a new attack surface”. So MM-IOVEC could be implemented for isolation 2 and 3. But you have to be careful as the “implementation uses to map input and output vectors can be imprecise” because of, for example, the HW limitation of MPU. The MPU has the alignment constraints, for example, 32-byte. And then if you’d like to map a 16-byte vector, you might have to provide 16-byte more data for the RoT Service to access. Whether this imprecise map is acceptable depends on the security requirements.
But it is true that TF-M has not implemented that.
-an attacker may tamper NS input data while the RoT service is processing those data Usually, input data should be accessed by RoT Services with READ-ONLY permission.
-Kevin
From: Quach, Brian via TF-M <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Sent: Tuesday, November 14, 2023 7:37 AM To: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org; Shreve, Erik <e-shreve@ti.commailto:e-shreve@ti.com> Subject: [TF-M] PSA_FRAMEWORK_HAS_MM_IOVEC
Hi,
I saw that PSA_FRAMEWORK_HAS_MM_IOVEC is not permitted for Isolation level 2-3 and transient copies of the input and output data into a 5KB scratch buffer are always made when making a PSA call. This makes sense as FF-Mv1.1 states: “In a system using isolation level 3, a Secure Partitions is not permitted to access another Secure Partition’s Private data. MM-IOVEC can provide a mechanism for one Secure Partition to access the other’s Private data.”
But I think the requirements for isolation level 3 could be fulfilled by: If SP detects a Secure caller, it could make a transient copy of I/O data. If SP detects a Non-Secure caller, it could use MMIOVECs or a similar method to access NS memory directly to avoid overhead and limitations of copying the I/O data.
Is this logical/ correct?
With this approach, an attacker may tamper NS input data while the RoT service is processing those data but rules of isolation level 3 are maintained.
Regards,
Brian Quach SimpleLink MCU Texas Instruments Inc.
tf-m@lists.trustedfirmware.org
-
Kevin Peng -
Quach, Brian