OP-TEE device enumeration¶

OP-TEE provides a pseudo Trusted Application: drivers/tee/optee/device.c inorder to support device enumeration. In other words, OP-TEE driver invokes thisapplication to retrieve a list of Trusted Applications which can be registeredas devices on the TEE bus.

OP-TEE notifications¶

There are two kinds of notifications that secure world can use to makenormal world aware of some event.

1. Synchronous notifications delivered withOPTEE_RPC_CMD_NOTIFICATIONusing theOPTEE_RPC_NOTIFICATION_SEND parameter.

2. Asynchronous notifications delivered with a combination of a non-secureedge-triggered interrupt and a fast call from the non-secure interrupthandler.

Synchronous notifications are limited by depending on RPC for delivery,this is only usable when secure world is entered with a yielding call viaOPTEE_SMC_CALL_WITH_ARG. This excludes such notifications from secureworld interrupt handlers.

An asynchronous notification is delivered via a non-secure edge-triggeredinterrupt to an interrupt handler registered in the OP-TEE driver. Theactual notification value are retrieved with the fast callOPTEE_SMC_GET_ASYNC_NOTIF_VALUE. Note that one interrupt can representmultiple notifications.

One notification valueOPTEE_SMC_ASYNC_NOTIF_VALUE_DO_BOTTOM_HALF has aspecial meaning. When this value is received it means that normal world issupposed to make a yielding callOPTEE_MSG_CMD_DO_BOTTOM_HALF. Thiscall is done from the thread assisting the interrupt handler. This is abuilding block for OP-TEE OS in secure world to implement the top half andbottom half style of device drivers.

OPTEE_INSECURE_LOAD_IMAGE Kconfig option¶

The OPTEE_INSECURE_LOAD_IMAGE Kconfig option enables the ability to load theBL32 OP-TEE image from the kernel after the kernel boots, rather than loadingit from the firmware before the kernel boots. This also requires enabling thecorresponding option in Trusted Firmware for Arm. The Trusted Firmware for Armdocumentation [6] explains the security threat associated with enabling this aswell as mitigations at the firmware and platform level.

There are additional attack vectors/mitigations for the kernel that should beaddressed when using this option.

1. Boot chain security.

   • Attack vector: Replace the OP-TEE OS image in the rootfs to gain control ofthe system.

   • Mitigation: There must be boot chain security that verifies the kernel androotfs, otherwise an attacker can modify the loaded OP-TEE binary bymodifying it in the rootfs.

2. Alternate boot modes.

   • Attack vector: Using an alternate boot mode (i.e. recovery mode), theOP-TEE driver isn’t loaded, leaving the SMC hole open.

   • Mitigation: If there are alternate methods of booting the device, such as arecovery mode, it should be ensured that the same mitigations are appliedin that mode.

3. Attacks prior to SMC invocation.

   • Attack vector: Code that is executed prior to issuing the SMC call to loadOP-TEE can be exploited to then load an alternate OS image.

   • Mitigation: The OP-TEE driver must be loaded before any potential attackvectors are opened up. This should include mounting of any modifiablefilesystems, opening of network ports or communicating with externaldevices (e.g. USB).

4. Blocking SMC call to load OP-TEE.

   • Attack vector: Prevent the driver from being probed, so the SMC call toload OP-TEE isn’t executed when desired, leaving it open to being executedlater and loading a modified OS.

   • Mitigation: It is recommended to build the OP-TEE driver as builtin driverrather than as a module to prevent exploits that may cause the module tonot be loaded.