Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bad mapping of TA secure memref parameters #1081

Closed
etienne-lms opened this issue Sep 29, 2016 · 3 comments
Closed

bad mapping of TA secure memref parameters #1081

etienne-lms opened this issue Sep 29, 2016 · 3 comments
Labels

Comments

@etienne-lms
Copy link
Contributor

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
Copy link
Contributor

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

@etienne-lms
Copy link
Contributor Author

ok i'll push the PR.

On 30 September 2016 at 01:37, Jens Wiklander [email protected]
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
Copy link
Contributor Author

fix merged through #1082

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants