ARMv8 AES acceleration needs to be disabled on my Hikey (was Secure Stg blows chunks) #1305
Comments
|
I think you should use TEE_CreatePersistentObject before you invoke TEE_OpenPersistentObject. |
|
Thanks... I'll try it later today and report back. |
gives... ... it can't be a valid solution anyway because it has to support me asking for files that aren't there yet. making |
|
What about ? |
|
I found this https://developer.trustonic.com/blog/secure-storage he has some samples using his own proprietary TEE, but it's the same, presumably GlobalPlatform APIs. He has which is the same as your suggestion with NULL but this "TEE_HANDLE_FLAG_PERSISTENT". He blows a bit more energetically but basically the same This is being built on Linaro 6.2.1 toolchain now... but everything else is working OK. |
|
So what you try is: and get: ? |
|
Yeah. But I just tried xtest as a compiler sanity check... xtest has lots of problems now. Let me back up and try a different toolchain version that xtest is able to like. Strange though because my stuff is working fine in OP-TEE with that toolchain without secure storage. |
|
But I don't think your code is right, IMO it should change to: And about the TEE_HANDLE_FLAG_PERSISTENT, it seems it's not to use here. |
|
Yeah... there is no reason to think that code is correct. I dived into optee_test and dredged out of pieces that looked reasonable to try. And then I looked at someone else's TEE examples for a different TEE. Even so though, the symptom I'm getting is not a legit response to some wrong flags. gives and as I say xtest is broken here atm. So I think it's an "unnatural situation" and my problem is at a deeper than the Secure Storage example. I just downloaded gcc 5.2, let me see what happens there. I can't use 4.9.3 because it breaks BoringSSL ECC code. |
|
Yeah, your problem seems not related much to the Secure Storage example... |
|
I agree, but the whole stack is working if I don't call that API (barring xtest...). Anyway let's see what gcc 5.2 does. |
|
Hum doesn't obviously seem related to gcc version... 4.9, 5.3 and 6.2.1 give the same results.
Most of the tests are OK but then The corrupted last 16 bytes are always the same. another strange failure is ACCESS_CONFLICT seems related to permissions... the permissions down /data are a bit strange |
|
For test 4000/4003, there were some possibly related patches from 3 days ago. Do your repos have them? |
|
Thanks... I updated the optee_os one, but I didn't update the optee_test one because I have seen it work with no errors. I'll try it, but the original issue is we die strangely using the fs api without xtest involved at all. So I don't think the root cause can be related to xtest, it's something else on my system that changed. Since I rolled back optee_os and tee_supplicant to be unpatched upstream, the only other big change is I removed UEFI, a ROMFS with the kernel + dtb + initramfs is now BL33. I patched a-t-f to parse the ROMFS and boot into the kernel directly, and to adapt the DTB at runtime, detect the extra 1GB of memory etc. Linux boots well, my TA functions well in optee... but something broken somewhere it seems. |
|
The fun is still going on with this one... I reverted all my patches-on-top except the elimination of UEFI and rebased it to clean pieces from earlier today. On GCC4.9, or GCC6.2.1, optee_test feels the same way, only these errors The problem is the same, consistent corruption at the end and it's 16 or 32 bytes at the end each time. With no better idea I'll try to study where the corruption occurs in the TA, assuming that's the source. |
|
BTW, I have the same problem.... this is my code When run the "TEE_CreatePersistentObject", TA report the info blew. It's work on op-tee v2.1.0, but v2.3.0 is not. |
|
Wow... thanks for sharing... I was pretty sure this was going to be "just me". Is this on Hikey? How are you booting the normal world? |
|
Yes, it's Android 7.1.1 on Hikey board. I execute "tee-supplicant" first, and execute my ca. Finally, look the error message. |
|
@MannyWang Have you tried xtest recently? |
|
yes, it's bad result. There are a lot of same panic error. |
|
If I leave OP-TEE alone (don't give it my TA) and run xtest, I get the specific 3 errors on xtest I mentioned. If I run my TA (which runs OK), then xtest after blows many more problems. So it feels like something corrupted in OP-TEE side, but no evidence yet. I thought it might be my boot procedure missed something, since I don't use UEFI any more. But if you also find similar problems using the original boot path, I will stop looking at my boot action and go back to looking at the exact corruption in xtest. |
|
Just FYI my xtest repeatably ends like this (when I don't give it any TA before)... the details of the failing cases are listed above on this issue. |
|
@lws-team thank you very much. I will look for the same issues, and figure it out(if I can). |
|
@MannyWang certainly feels better not just in the dark on my own ^^ My failing xtest elements are AES, specifically AES_CBC_NOPAD ... and the secure storage FEK stuff happens to use AES, specifically So maybe these issues are related by one issue in AES. |
|
ええええええええ.... disabling the ARMv8 accelerated AES buys me this: Please try this on optee_os You'll need to delete ./out or maybe |
|
There are two separate issues here mixed together, at least for me.
|
|
@lws-team Thank you for sharing....but it is not work...T_________T |
|
@MannyWang yeah... your problem is caused by something else. In my case I had a function pointer that defaulted to NULL, and I jumped to it. It was not directly caused by the call to CreatePersistentObject but my trying to show the result of the call. I had lots of problems coming before when the different projects (optee_os, optee_client and optee_test) were not all at the same version.... you might want to confirm it and check that the binaries on the rootfs are updated. Another time I had problems because the rootfs already had tee-supplicant and libteec.so.* in different paths, so I was not running what I thought I was. |
lws-team
changed the title
jforissier
added a commit
to jforissier/optee_os
that referenced
this issue
Jan 25, 2017
Ad-hoc fix for regressions introduced by [1]. Tested on HiKey using latest optee_test including GlobalPlatform tests (32/64-bit TEE core, 32/64-bit libutee, with/without ARMv8 CE acceleration). Fixes: b1ecda7 ("libutee: fix off-by-one error in tee_buffer_update()") [1] Fixes: OP-TEE#1305 Signed-off-by: Jerome Forissier <[email protected]>
Merged
|
This is solved by the workaround patch above, so closing. |
jforissier
added a commit
to jforissier/optee_os
that referenced
this issue
Jan 26, 2017
Ad-hoc fix for regressions introduced by [1]. Tested on HiKey using latest optee_test including GlobalPlatform tests (32/64-bit TEE core, 32/64-bit libutee, with/without ARMv8 CE acceleration). Fixes: b1ecda7 ("libutee: fix off-by-one error in tee_buffer_update()") [1] Fixes: OP-TEE#1305 Signed-off-by: Jerome Forissier <[email protected]> Reviewed-by: Jens Wiklander <[email protected]>
jforissier
added a commit
to jforissier/optee_os
that referenced
this issue
Jan 26, 2017
Ad-hoc fix for regressions introduced by [1]. Tested on HiKey using latest optee_test including GlobalPlatform tests (32/64-bit TEE core, 32/64-bit libutee, with/without ARMv8 CE acceleration). Fixes: b1ecda7 ("libutee: fix off-by-one error in tee_buffer_update()") [1] Fixes: OP-TEE#1305 Signed-off-by: Jerome Forissier <[email protected]> Reviewed-by: Jens Wiklander <[email protected]>
takuya-sakata
pushed a commit
to renesas-rcar/optee_os
that referenced
this issue
Dec 22, 2017
Ad-hoc fix for regressions introduced by [1]. Tested on HiKey using latest optee_test including GlobalPlatform tests (32/64-bit TEE core, 32/64-bit libutee, with/without ARMv8 CE acceleration). Fixes: b1ecda7 ("libutee: fix off-by-one error in tee_buffer_update()") [1] Fixes: OP-TEE/optee_os#1305 Signed-off-by: Jerome Forissier <[email protected]> Reviewed-by: Jens Wiklander <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
My TA works nicely. But if I try to start to use Secure Storage APIs, eg just this
We blow chunks
I think the failed "command" is the one that inits my TA and runs the attempted Secure Storage code.
There is some init I missed out? I get the wrong idea about the API?
The text was updated successfully, but these errors were encountered: