# Qualcomm TEE and TrustZone secure application
Source: [https://docs.qualcomm.com/doc/80-88500-4/topic/77_TrustZone_and_secure_application.html](https://docs.qualcomm.com/doc/80-88500-4/topic/77_TrustZone_and_secure_application.html)
The Qualcomm TEE provides security services such as image loading, authentication,
cache management, crypto, logging, and Qualcomm fuse-programmable read-only memory (QFPROM)) to
the TrustZone secure applications.
The chipset has a 64-bit Armv8-A architecture in which Arm cores have two modes of
execution:
- Non-Secure mode – HLOS executes in this mode of Arm core
- Secure mode – Secure OS (TZ) executes in secure mode of Arm core
The Secure mode of Arm core is the core of TZ technology, which provides a hardware-based
security environment for secure OS and separates secure world from non-secure world.
Figure : Qualcomm TEE v5.0 security framework architecture
The XBL loads the TZ software image during the initial device bootup process.
TZ comprises the following major components:
- Trusted application space
- TZ board support package (TZBSP)
- Secure monitor
- Device configuration
## Trusted application space
Trusted applications are run in this space. The TZ gives freedom to develop and execute a trusted
application in TZ user space for any secure use case.
## TZBSP
The TZBSP provides software support for security. It exposes hardware abstraction layer (HAL)
APIs for the security functions, such as, Crypto, fuse block, pseudo random number generator
(PRNG).
- It initializes system security environment for software and hardware during bootup and wake-up from power collapse.
- It provides memory, other subsystem protection, and services during runtime.
## Device Configuration
There are some platform-dependent customizations, which are configurable via device configuration
(devcfg) files. You can configure the changes and build the devcfg.mbn image with new
customizations.
## TZ functionalities
The major TZ functions are as follows:
- Cold boot:
1. The boot sequence starts from a secure root of trust (application processor PBL), the boot process begins in on-chip ROM (application processor PBL).
2. Signed software images (including XBL and TZ) from flash memory are loaded into DDR and authenticated before execution.
3. Application processor PBL loads and authenticates XBL, XBL loads and authenticates TZ.
4. TZ programs different xPUs in the system to protect different resources.
5. TZ also programs VMIDMT tables and the masters that have access to the tables.
- TZ access control – Sets up access control for the registers of following hardware blocks:
- BAM
- CPU registers
- Qualcomm generic interrupt controller (QGIC)
- Hardware crypto engine
- QFPROM
- TZ can write/blow QFPROM bits in application processor region
- All other subsystems have read access, but no write access
- PRNG
- Warm boot:
- TZ runs within DDR partition allocated for it and application processor CPU starts in Secure mode
- Power collapse terminates in TZ and it programs application processor CPU to start from TZ reset vector
- TZ warm boot – Performs the following initializations during warm boot:
- CPU core system initialization, which configures CPU to a known state
- Initializes CPU security
- If it is a power collapse, initialize L2 cache
- Switches to Nonsecure mode
- Secure peripheral image loader (PIL):
1. TZ Secure PIL authenticates different subsystem images and configures related xPUs to protect the subsystem memory regions
2. During initialization, the PIL authentication service in TZBSP protects the registers responsible for taking the peripheral processors out of reset
3. HLOS loads the ELF file for subsystem image at a 4-byte aligned location in DDR RAM
4. HLOS requests the PIL authentication service in TZBSP to authenticate the images securely
5. HLOS cannot authenticate the images as it can potentially be tampered
6. TZBSP protects the memory areas used by the subsystem images with the MPU
7. TZBSP initializes the registers of a processor and necessary clocks
8. Once an image is validated, the PIL authentication service resets the respective subsystem core so it can boot
- Power collapse:
- Some xPUs are power collapsible and they are mostly related to multimedia functionalities.
- Crypto BAM:
- TZ configures every BAM pipe crypto to prevent HLOS from using the hardware keys.
- Secure debug:
- Disable the JTAG debug functionality using QFPROM; which is re-enabled in TZ using software
OVERRIDE registers
- The hardware keys replace dummy keys when debug is enabled; TZ software then, use the dummy keys when debug is re-enabled
- Watchdog debug
## Major BSP drivers in TZ
- QFPROM:
- QFPROM blowing framework is now part of TZ
- Use the following APIs to read and write QFPROM from their TZ application
- qsee\_fuse\_read()
- qsee\_fuse\_write()
- API prototype is at
\trustzone\_images/ssg/api/securemsm/trustzone/qsee/qsee\_fuse.h
- Crypto engine:
- Two general-purpose crypto engines (one each for modem and TZ)
- Random number generator (RNG):
- Configured by TZ only
- Both TZ and HLOS can access the generated random numbers
- SPI driver:
- Used to interface with external devices
- Configured by TZ and is disabled by default
- To enable the SPI driver, uncomment the definition of BAM\_TZ\_DISABLE\_SPI in the
\core\hwengines\bam\build\builds.scons build file
## Secure watchdog
Only secure watchdog timer (SWDT) can reset the system. All other WDTs generate an interrupt on
bite. HLOS (subsystem restart) handles the subsystem WDT bites. TZ (context dump/reset)
handles the HLOS WDT bite. Secure WDT bites and resets the device to the first stage of
reset.
The longest bark/bite timeout in the system, a maximum of 32 seconds. It is configured and
accessible only by TZ. Enabled in cold boot after TZ enables interrupts. TZ pet secure WDT
on bark.
Debug APIs:
- Disable secure WDT for debug purposes – tzbsp\_wdt\_disable()
- Trigger secure WDT for debug purposes – tzbsp\_wdt\_trigger()
## Secure monitor
Secure monitor executes at the highest privilege level (EL3) of Arm core and facilitates the
transition between the nonsecure world to secure worlds.
## Device configuration
The TZ has multiple platform dependent customizable features such as:
- SFS storage path
- Key derivation features
- Access control configuration
- xPU enable disable configuration
- Hypervisor configuration
- Key re-provisioning configuration and so on
Multiple configuration files are available for controlling different functionalities.
For example, oem\_config.xml
6000 Copy to clipboard
22000 Copy to clipboard
Change the configuration and build new device config (devcfg.mbn) images.
For information on Qualcomm TEE 5.0, see Qualcomm Trusted Execution Environment (TEE)
Version 5.0 User Guide (80-NH537-4).
**Parent Topic:** [Security](https://docs.qualcomm.com/doc/80-88500-4/topic/76_Security.html)
Last Published: Aug 18, 2023
[Previous Topic
Security](https://docs.qualcomm.com/bundle/publicresource/80-88500-4/topics/76_Security.md) [Next Topic
Overview of Qualcomm TEE 5.0](https://docs.qualcomm.com/bundle/publicresource/80-88500-4/topics/78_Qualcomm_TEE_5_0.md)