Android app call TA through CA lib : permission denied

[DamienLieupart]

I vchong,

I work on Hikey 620 with AOSP 8.1. I try to call TA hello world from android application but i have permission denied.

I have created hello_world library (.so) with JNI overlay and method implemented same code as helloworld CA.
In my android app I include JNI library and call this method.

I try to put libopee_hello_world.so generated : in android application, in system/lib64 near libteec.so and also in /data.

I have checked previous link you mentioned OP-TEE/optee_os#903.
I try to set selinux to permissive but same problem.

Could you please give me better way to call TA from android application and which rights, rules i have to changed in android.
I work on demonstrator, so modified root privilege or other is not important.

Thanks.

[vchong]

Have not tried this myself (hopefully soon in the future) so not sure how much help I can be. Can you maybe provide some logs including the commands you run and error messages?

[DamienLieupart]

Hi vchong,

I have tried to add my hello_world.so in my apk (/data/app/mypackage/lib/arm64. But I have java.lang.UnsatisfiedLinkError on libteec.so.

After more investigation i have found this link which say since Android 7 Android application can't uses private librairies anymore : https://developer.android.com/about/versions/nougat/android-7.0-changes.html#afw. To fix the issue i see :

If your app uses private platform libraries, you should update it to include its own copy of those libraries or use the public NDK APIs.

I try to add also libteec.so in my app. So i have libteec.so and libhello_world.so in /data/app/mypackage/lib/arm64.

There is no link error but method "TEEC_InitializeContext" return "TEEC_ERROR_ITEM_NOT_FOUND" (0xFFFF0008).
I don't see any error in logcat and kmsg log is empty. I have tried to compile libteec with debuglevel set to 4 but i have nothing.
How i can see more log ?

Quote above say also to use public NDK APIs. Maybe we can add libteec in it. I don't check this point.

Thanks

[vchong]

I think by copying libteec.so and libhello_world.so to /data/app/mypackage/lib/arm64, you 'gave' your app its own copy of those libraries, so that removed the link error. The 'item not found' error still sounds like the permission again. Have you made sure to test with root or selinux disabled? Maybe try sudo dmesg | tail after you (fail to) run your app to see more logs.

[DamienLieupart]

Hi vchong,

The 'item not found' error is thrown on opening of /dev/tee0 in libteec.

It is okay now with 3 operations :

• libteec.so and libhello_world.so in /data/app/mypackage/lib/arm64
• selinux set to permissive
• full rights for /dev/tee0

I think there is better integration to be done in AOSP. But I do not know all the security features of AOSP.

Thanks again :)

[vchong]

You're welcome. Glad you got it to work. Yes, there's indeed room for improvement and hopefully we can get to them soon. It would be very helpful to that cause if you can contribute back and share your code too!

[DamienLieupart]

I would be happy but what kind of contribution do you want from me ?
libhello_world.so, libteec.so and jni library are include in aar files to be include in android application.
My changes for selinux and /dev/tee0 are manually (setenforce 0 and chmod).

[vchong]

Right, so we don't have a github repository for this atm. Do you have one that you can perhaps share? Basically, it would contain the source code and makefiles for both .so libraries, the Java (and any other apk related) code, and perhaps a README to list the steps required to integrate them into an existing aosp source tree, build and run. If no repository, we'd be willing to accept a post/comment here as well, and we can formally move it to a new repository later once everything is tested and verified.

[DamienLieupart]

Hi vchong,
It's okay know without manual changes, I have modified in build :

• "device/linaro/hikey/ueventd.common.rc", set /dev/teepriv0 and /dev/tee0 from 0660 to 0666
• "device/linaro/hikey/hikey/BoardConfig.mk " add androidboot.selinux=permissive to BOARD_KERNEL_CMDLINE
• "device/linaro/hikey/bootloader/EFI/BOOT/grub.cfg " add androidboot.selinux=permissive (but i don't know if it is necessary)

I don't have github repository. I have standalone build environment, it is not integrated to AOSP build :(
I can share your my code if you want.

[vchong]

@DamienLieupart Yes, for single build or testing you can just do manual changes, but for permanent changes, should change the config or make files. If you use boot.img, change BoardConfig.mk. If you use boot_fat.uefi.img, change grub.cfg. Both boot images can be use, just that the fat one gives you a grub menu.

I have standalone build environment

Assume you're using some sort of IDE like Android Studio?

I can share your my code if you want

Yes please. You can just copy and paste them or attach the source files here, whichever is preferred.

[DamienLieupart]

I'm using eclipse with atd plugin on windows and gradle for compilation.
I make zip file :
OpteeExamples.zip

In "OpteeExamplesLibrary" there is :

• JNI : with native code hello world with method "Java_com_opteeexamples_HelloWorld_helloworld" which make same thing as CA hello world.
• SRC : with android library which make layer between native and Android code. Method "helloworld()" calls previous method.
• optee_client : libteec
• libs : generated "liboptee_example_hello_world.so" and "libteec.so"
  Other folders are android stuff.
  This library uses gradle and target "uploadArchive". This target generates "C:\var\mavenRepo\com\opteeexamples\OpteeExamplesLibrary\0.0.1\OpteeExamplesLibrary-0.0.1.aar" which includes two .so and classes.

"OpteeExamplesApplication" is android application which include "OpteeExamplesLibrary-0.0.1.aar" ->dependencies {
compile group: 'com.opteeexamples', name: 'OpteeExamplesLibrary', version: '0.0.1'
}

It's pretty dirty but it works fine :)

[vchong]

@DamienLieupart Thank you very much for your contribution! We've lots to learn on the app development side of things. Hopefully we can get these published as sample references soon. Will let you know when we do that. Again, thanks!

[dracular1983]

hi victor,
Thank you for sharing the information.

I do not think it is a effective method to deal with the reqirement.

1. we can not allways disable the selinux in the product.
2. Treble will not allow the 3rd app to link the vendor library directly. We can only put the library in vendor/lib64 and set it as a sameprocess-library.
3. It also maybe not a good choice to put libteec.so in each Android app. for example it wil waste some space and have to make sure the app to use the same version of the libteec

BRs

[vchong]

Hi @dracular1983 You're welcome.

I agree there are still room for improvement, but work in this area is currently on hold due to lack of resources and to a certain degree expertise as well, so contributions are always welcome.

With the current development environment provided:

1. We've some reference policies in https://android-git.linaro.org/device/linaro/hikey.git/tree/sepolicy/file_contexts?h=linaro-nougat and https://android-git.linaro.org/device/linaro/hikey.git/tree/sepolicy/tee.te?h=linaro-nougat. Users are expected to reference these and come up with their own as required.

2. Sorry but can you please elaborate? How is 'link the vendor library directly' different than 'put the library in vendor/lib64 and set it as a sameprocess-library'?

3. Right now, libteec.so is in system/lib64 not vendor/lib64, but work has started to move the appropriate HiKey components from system/ to vendor/. In any case, based on previously mentioned comment above and your latest comment, neither location is allowed access anyway. Other than the workarounds suggested in https://developer.android.com/about/versions/nougat/android-7.0-changes.html#afw, we've not started to look at this. I know you suggested the use of hidl previously but again, the client apis are neither platform, hardware nor vendor dependent. This shouldn't be a client api issue only either. What about other private/platform libraries in general? Do you know of any approaches that are used by them to resolve this?

BRs

[ggulgun]

Hello all,

Are there any improvements or news about this situation ?

[vchong]

The only changes since are:

• O build is now obsolete and replaced with P
• All op-tee build artifacts are now located under /vendor, and all affected makefiles and sepolicies have been updated to reflect this change

[ggulgun]

The only changes since are:

* O build is now obsolete and replaced with P

* All op-tee build artifacts are now located under /vendor, and all affected makefiles and sepolicies have been updated to reflect this change

Thank you for answer.

Is there any progress integrating keystore(android) with optee?

[vchong]

You're welcome.

Is there any progress integrating keystore(android) with optee?

You can try/test the initial release here: https://github.com/linaro-swg/optee_android_manifest/tree/3.3.0

[ggulgun]

You're welcome.

Is there any progress integrating keystore(android) with optee?

You can try/test the initial release here: https://github.com/linaro-swg/optee_android_manifest/tree/3.3.0

Sorry for extra questions .

Additionally, I will use keystore for generation of AES and RSA encryption keys. Is it possible to store keys in RPMB or Optee with this release? Next, Can I use Optee for encryption and decryption from keystore?

[vchong]

Is it possible to store keys in RPMB or Optee with this release?

The keystore TA currently uses TEE_STORAGE_PRIVATE, which selects the REE FS when available, otherwise the RPMB FS (in this order), for key storage. I suppose you can try rebuilding optee_os with CFG_RPMB_FS=y defined, and change all occurrences of TEE_STORAGE_PRIVATE in the TA to TEE_STORAGE_PRIVATE_RPMB, but this is not something we've tried or plan to try.

Can I use Optee for encryption and decryption from keystore?

With https://github.com/linaro-swg/optee_android_manifest/tree/3.3.0, all keystore API calls should go through Optee. You can try calling some APIs and check the debug logs to confirm.