You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Optee core may badly maps TA buffer parameters (memref parameters) when a memref parameter for a nonsecure buffer has a lower parameter index than the memref parameter for a secure buffer. For example, assuming a TA expects parameter #0 to be a nonsecure buffer reference and parameter #1 refers to a secure buffer. Then those parameters gets a valid virtual address but the effective MMU table gets badly filled in by the core_mmu_lpae.c or core_mmu_v7.c.
This issue is found while experiencing test on the SMAF feature. Yet it can be reproduce in a TA-to-TA invocation setup.
The issue is in the tee_mmu.c implementation where the table listing the mapping for the TA is getting filled with the memref parameter info in the index order of the parameters while the virtual addresses are assigned first for secure memory area (including secure memref parameter) and then the non secure memory areas (obviously non-secure shared memory parameters.
xtest should be enhanced to cover such a setup.
Proposed correction: etienne-lms@ef9d222
This correction simply gets the mapping structure table being filled with secure memref parameters first, then non-secure parameter.
The text was updated successfully, but these errors were encountered:
Optee core may badly maps TA buffer parameters (memref parameters) when a memref parameter for a nonsecure buffer has a lower parameter index than the memref parameter for a secure buffer. For example, assuming a TA expects parameter #0 to be a nonsecure buffer reference and parameter #1 refers to a secure buffer. Then those parameters gets a valid virtual address but the effective MMU table gets badly filled in by the core_mmu_lpae.c or core_mmu_v7.c.
This issue is found while experiencing test on the SMAF feature. Yet it can be reproduce in a TA-to-TA invocation setup.
The issue is in the tee_mmu.c implementation where the table listing the mapping for the TA is getting filled with the memref parameter info in the index order of the parameters while the virtual addresses are assigned first for secure memory area (including secure memref parameter) and then the non secure memory areas (obviously non-secure shared memory parameters.
xtest should be enhanced to cover such a setup.
Proposed correction: etienne-lms@ef9d222
This correction simply gets the mapping structure table being filled with secure memref parameters first, then non-secure parameter.
The text was updated successfully, but these errors were encountered: