bad mapping of TA secure memref parameters

[etienne-lms]

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.

[jenswi-linaro]

Proposed fix looks good to me, please make a PR.

[etienne-lms]

ok i'll push the PR.

On 30 September 2016 at 01:37, Jens Wiklander notifications@github.com
wrote:

Proposed fix looks good to me, please make a PR.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#1081 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ATEHJhMI7SnX5OKVHRn9z14bznQkqfFwks5qvEu2gaJpZM4KKgdQ
.

[etienne-lms]

fix merged through #1082