OP-TEE versus Android 11

[ArtIPC]

Dear OP-TEE maintainers,

We are starting a new Android-based project that uses a TEE, and have been investigating different solutions in this area. Very impressed by your work and the maturity of OP-TEE. Our project targets Android 11 and the necessary bricks seem to be present in your code:

• Keymaster (it is v.3.0, but v.4.0/1 are not mandatory currently)
• Gatekeeper 1.0
• AVB

But we may be missing something important. Could you confirm that OP-TEE is "Android 11-compatible"?

Thank you, Best Regards, Ilya

[vchong]

Hi @ArtIPC,

The last time we tried OP-TEE on the latest AOSP (master branch, post v11), there were some regressions in xtest and VtsHalKeymasterV3_0TargetTest. All regressions were fixed for the latest 3.12.0 OP-TE release, but this was tested on an old/stable AOSP v9. We haven't been able to try on v11 and beyond yet.

Keymaster (it is v.3.0, but v.4.0/1 are not mandatory currently)

Yes. Are you aware of any deprecation schedule for v3? Going from 3 to 4.0/1 is an incremental change and not a full (re)implementation, but we've not been able to gather enough interest to sponsor work for an upgrade. Patches/contributions from the community are always welcome.

Gatekeeper 1.0

No change on this as far as we know. There are ongoing discussions upstream (AOSP) that might introduce relatively significant changes later. Not sure what the timeline is though.

AVB

Not sure about this. @igoropaniuk Have you tried AVB on AOSP?

Other things to consider:

1. What is version of linux kernel you expect to use?
2. If you need to enable FBE, see https://connect.linaro.org/resources/san19/san19-226 for details.

[ArtIPC]

Hi @vchong ,

Thank you very much for your quick and detailed answer.

The last time we tried OP-TEE on the latest AOSP (master branch, post v11), there were some regressions in xtest and VtsHalKeymasterV3_0TargetTest. All regressions were fixed for the latest 3.12.0 OP-TE release, but this was tested on an old/stable AOSP v9. We haven't been able to try on v11 and beyond yet.

Just to avoid misunderstanding - you mention "master branch, post v11" and then "but this was tested on an old/stable AOSP v9". Is it a typo or you do mean two different AOSP branches - e.g. for the Android image and to build VTS? Also, are you referring following support thread: https://github.com/linaro-swg/kmgk/issues/22 ?

Are you aware of any deprecation schedule for v3?

No, sorry, I'm not. Reading CDD 11 I could not find any indication for the imperative KM4 use - everything needed seems to be provided by KM3. But on the other hand KM 4.0 is here since Android 9. Google have recently introduced 4.1. At some point they may mandate KM 4.X, for new devices e.g.

Other things to consider: What is version of linux kernel you expect to use?

In the current Android 11 BSP we've got it is Linux 5.4.47 kernel by default. Is there any OP-TEE limitation concerning the Linux version?

If you need to enable FBE, see https://connect.linaro.org/resources/san19/san19-226 for details.

Thank you for the link!

Best Regards, Ilya

[igoropaniuk]

@igoropaniuk Have you tried AVB on AOSP?

AVB 2.0 implementation in the mainline U-Boot should work smoothly with AOSP 10 since this update 4d579a4394("libavb: Update libavb to current AOSP master"), which added support for Android dynamic partitions. Unfortunately I didn't track the changes in AOSP 11, additional work might be needed (at least update libavb to newer version).

@vchong do you still support old Hikey flavor (620) for AOSP builds?

[vchong]

Thank you very much for your quick and detailed answer.

np

Just to avoid misunderstanding - you mention "master branch, post v11" and then "but this was tested on an old/stable AOSP v9". Is it a typo or you do mean two different AOSP branches - e.g. for the Android image and to build VTS? Also, are you referring following support thread: linaro-swg/kmgk#22 ?

On our dev platform (hikey960), we have scripts that build the firmware and kernel along with the AOSP user space images. This is for convenience and also serves to hide all the complexities for users who just want to do TA development on AOSP. On the master branch, it is getting more and more difficult to do all the builds together as more and more restrictions are introduced into the AOSP build framework. E.g. removal of GCC, overwriting of PATH to allow only the use of executables checked into the source tree, etc. It has gotten to a point where the workarounds needed to just to overcome those restrictions aren't feasible anymore, so for this OP-TEE release (3.12.0), we reverted to building/testing on the last known stable build that we had - v9. In the future, we'll probably go back to decoupling the firmware and kernel build from the user space images, and then develop and test on master branch again, but this is a moving target and not a high priority atm due to other projects being prioritized. :(

But on the other hand KM 4.0 is here since Android 9. Google have recently introduced 4.1. At some point they may mandate KM 4.X, for new devices e.g.

Yes, I suppose we'll have to cross that bridge when we get there. Where did you see 4.1 being introduced? Lots of work is being done upstream (some still ongoing) for beyond 4.1, but it's not called v5 due to the change in the interface used, from HIDL to AIDL.

In the current Android 11 BSP we've got it is Linux 5.4.47 kernel by default. Is there any OP-TEE limitation concerning the Linux version?

Will your kernel be based on https://android.googlesource.com/kernel/common/+/refs/heads/android11-5.4? Look at https://source.android.com/devices/architecture/kernel/generic-kernel-image, https://source.android.com/devices/architecture/kernel/android-common and https://android.googlesource.com/kernel/build/+/refs/heads/master/abi. android11-5.4 was around the time GKI first got introduced. You can probably just build your kernel the way you did before 5.4, i.e. without GKI support, and it might still work, but if you're releasing a product, it might not be certified. Also, probably all those who use/reference the common kernel 5.4 and above will support GKI anyway, so you'll probably want to do that too. That said, we've not been able to implement GKI support yet in the kernel for the OP-TEE driver (another reason we moved off of building and testing on the master branch for now), so that's something to look out for, but if your kernel engineers have experience implementing GKI support for other kernel drivers you have that's not upstream, then doing the same for the OP-TEE driver shouldn't be difficult at all. Make sure to send in patches if you do. ;)

[vchong]

Hi @igoropaniuk

AVB 2.0 implementation in the mainline U-Boot should work smoothly with AOSP 10 since this update 4d579a4394("libavb: Update libavb to current AOSP master"), which added support for Android dynamic partitions.

Did you test this on the hikey620?

do you still support old Hikey flavor (620) for AOSP builds?

Not recently due to removal of 620 support upstream and EOL of the board. You'll have to try a build from one of the older release tags and try to update from there. The 960 is still supported upstream but it's also impossible to buy a board now. Long term we'll have to find a replacement although there doesn't seem to be any good alternatives atm. :(

[github-actions[bot]]

This issue has been marked as a stale issue because it has been open (more than) 30 days with no activity. Remove the stale label or add a comment, otherwise this issue will automatically be closed in 5 days. Note, that you can always re-open a closed issue at any time.

[angelina-zhao]

I am starting to work on keymaster and gatekeeper based on OPTEE-OS on android 12 recently. I would like to know whether the kmgk project (https://github.com/linaro-swg/kmgk) can be used as a good starting point?

I notice this project has not been updated for nearly 12 months...

what I would like to implement is keymaster 4.1 and gatekeeper 1.0.

Thanks.

[vchong]

@angelina-zhao We stopped working on kmgk for some time now due to lack of resources, but it should still be a good starting point. You probably just need to add support for the missing APIs, and make changes to the existing APIs to fit 4.1 as necessary. Please submit your changes back to the repo if possible.

[angelina-zhao]

vchong，thank you very much for the quick response.

I will submit back the changes in case I can finally make it works on android 12. : )

[vchong]

You're welcome. Good luck and hope to see your patches soon.