2023-02-14 OP-TEE / S-EL2 discussions - public meeting

Meeting Date: 2023-02-14

Attendance



Name

Leonardo Garcia, Linaro

Jonathan Cameron, Huawei

Yier Jin, Huawei

Ilias Apalodimas, Linaro

Jens Wiklander, Linaro

Joakim Bech, Linaro

Kevin Zhao, Linaro

Olivier Deprez, Arm

Xiangyi Xu, Huawei

Yongzheng Wu, Huawei





Meeting Logistics

When? 2023-02-14

Next meetings will happen in conjunction with the Linaro OP-TEE Contributions (LOC) monthly meeting. The calendar invite for this meeting is available in the Trusted Firmware Public Meetings calendar.

Zoom connection details

 Agenda

  • Kick-off Huawei and Linaro collaboration on OP-TEE and S-EL2.

  • Review list of requirements from Huawei.

Documents

Action Items

Jonathan to find out more details on what is being required on remote attestation.
Jonathan will clarify what is the requirement around OpenSSL.
Jonathan will check what if Huawei has hardware that supports GICv4. Linaro doesn’t have hardware to check the current implementation for GICv4 on OP-TEE. This is needed for testing device assignment whenever we work on this support.
C++ support: Huawei to share what they have worked on already.
Discuss in the mailing list if anyone can be the owner of this task: Are we able to run multiple OP-TEE instance at the same time? Does it require position independent code?
Discuss the attestation flow of S-EL2 in the next meetings.

Minutes

  • Kick-off Huawei and Linaro collaboration on OP-TEE and S-EL2

  • Review list of requirements from Huawei

    • List of requirements:

      • OP-TEE enhancements

        • Position independent

        • Support new languages: C++, Java, Python

        • Support secure side:

          • OpenSSL

          • PCIe

          • SMMU

          • GICv4

          • ACPI

          • POSIX API

        • S-EL2 support

    • S-EL2 support

      • [Leonardo] What is missing in Hafnium today?

      • [Ilias] S-EL2 is different from CCA. CCA is related to the Realms world, while S-EL2 is related to the Secure world.

      • [Jonathan] There is a confusion here because it is possible to do confidential computing in S-EL2 and S-EL1, but some bits of CCA will affect the secure world as well, such as dynamic allocation of memory, which will be available in the secure world when CCA is available.

      • [Leonardo] The objective would be to have different TEEs running on the secure world.

      • [Ilias] S-EL2 isn’t strictly required because OP-TEE can load and dispatch the secure partitions from S-EL1. Probably won’t have the same level of isolation, but would provide some isolation with the current hardware (Arm v8.4).

      • [Jonathan] Yes, that’s correct, but some people want to run different OS, instead of OP-TEE, such as proprietary code on the secure world.

      • [Ilias] The main difference between CCA and the secure world would be the possibility to assign devices to the Realms.

      • [Jonathan] Yes, but CCA version 1 doesn’t have this support yet, and there are products that can use devices specially crafted to work with the secure world. In the end of the day, there are features that are currently exploited in secure world by proprietary code that is still not available in OP-TEE. The objective is to close some of these gaps, but, at the same time, allow both codes to run side by side.

    • Position indepenent

    • Language support in general:

      • [Jonathan] Commercial solutions provide that, including Java support

      • [Yier] We want to add features to OP-TEE because it will take some time until CCA is available.

    • C++

      • [Jonathan] This is a big requirement for some markets.

      • [Ilias] What is missing w.r.t. C++ support? Loader support?

      • [Jens] OP-TEE doesn't have full support in the TA dev kit. There is a very limited C++ support today.

    • Remote attestation

      • [Ilias] What is the gap in OP-TEE? TPM is responsible for that, and it is controlled by the non-secure world. OP-TEE binaries are measured by TF-A.

      • [Jonathan] My guess is that the issue is providing the correct hooks to make sure what is running on the TA is what you were expecting.

      • [Ilias] The measured boot is a chain of measures that start at the TPM. Apart from that, there is an event log that describes how the PCRs ended in the state they are. Today, this is not accounting the TAs.

      • [Jonathan] I will try to find more details on this one.

      • [Ilias] This problem of measuring TAs may be similar to measuring containers. This may require the TAs to be loaded always in the same order. Or we can leverage TPM to handle multiple chained hashes from Hafnium.

      • [Yier] How do we measure the VMs in the case of CCA?

      • [Leonardo] The firmware will need to support that as you don’t trust the host.

      • [Jonathan] And the VM will need to make sure it is running where it was expecting to be running.

    • Hafnium

      • [Jonathan] Where we are with this? Can we have multiple copies of OP-TEE running today?

      • [Jens] Only tested with one OP-TEE, but in theory should be able to run multiple S-EL1 on top of Hafnium today already.

      • [Olivier] Why running multiple instances of OP-TEE?

      • [Jonathan] This is to mix OP-TEE and proprietary S-EL1 code with very specific, stripped out, code.

      • [Ilias] One problem is what you would use as storage. If you use the non-secure world, that is fine. However, if you are using a device that OP-TEE supports, you will run into racing problems as it is not possible to run multiple instances. This would need changes in the hypervisor. OP-TEE with position independent code would be needed for that as well, otherwise you won’t be able to load more than one OP-TEE at the same time.

      • [Olivier] Another objective of having an S-EL2 is to be able to remove drivers from EL3 into lower levels. That would make EL3 smaller, which is ultimately an objective for CCA as well.

    • PCIe

      • [Jonathan] How to do device attestation (TEE Device Interface Secure Protocol (TDISP))? Today this can be done on the Linux kernel, but ultimately we would like to move this to the secure world. But for that to happen, we need to have a way to expose the PCIe devices to the secure world. CCA doesn’t have support for device assignment yet, but there are use cases for this today already.

      • [Ilias] Probably not useful in this case, but there is a patch for attestation and verification of the kernel that continuously check the content of some memory areas of the kernel, as OP-TEE has access to the whole non-secure memory. You can even watch user space application memory content.

    • POSIX API

      • [Ilias] We probably won’t support it as OP-TEE supports the Global Platform API to talk to the secure world.

      • [Jonathan] This is available today in commercial solutions. Don’t spend too much time on this for now.

    • ACPI

      • [Jonathan] Similar to POSIX API. There are commercial solutions that support this. Don’t spend too much time on this for now.