# Verify the security configurations of Qualcomm Linux

The security verification process involves checking and validating the [security features](https://docs.qualcomm.com/doc/80-80022-11/topic/features.html#features) of hardware and software components to ensure they operate securely on Qualcomm^®^ Linux^®^. This process ensures that the listed security features meet the necessary requirements to make the system robust and secure.

## Prerequisites

> 
> 
> - [Build and load the software on the device](https://docs.qualcomm.com/bundle/publicresource/topics/80-80022-254/introduction.html).
> - [Enable the secure shell (SSH) in permissive mode to securely access your host device](https://docs.qualcomm.com/bundle/publicresource/topics/80-80022-254/how_to.html#use-ssh).

### Verify TrustZone/device configuration/Hypervisor image loading

By verifying the TrustZone (secure) environment, you ensure that the device’s security architecture is robust and reliable, providing a foundation for secure operations.

The following XBL logs contain information about the TrustZone/Device configuration/Hypervisor image loading.

> 
> 
> For example:
> 
> 
> 
> > 
> > 
> > - Device configuration (DEVCFG)
> > 
> > 
> >     `B - 1206031 - QSEE Dev Config - Image Load, Start`
> > 
> > 
> >     `D - 763 - Auth Metadata`
> > 
> > 
> >     `D - 549 - Segments hash check`
> > 
> > 
> >     `D - 13054 - QSEE Dev Config - Image Loaded, Delta - (53248 Bytes)`
> > - TrustZone
> > 
> > 
> >     `B - 1228113 - QSEE - Image Load, Start`
> > 
> > 
> >     `D - 26382 - Auth Metadata`
> > 
> > 
> >     `D - 22234 - Segments hash check`
> > 
> > 
> >     `D - 88999 - QSEE - Image Loaded, Delta - (4027792 Bytes)`
> > - Hypervisor
> > 
> > 
> >     `B - 1402237 - QHEE - Image Load, Start`
> > 
> > 
> >     `D - 26383 - Auth Metadata`
> > 
> > 
> >     `D - 7045 - Segments hash check`
> > 
> > 
> >     `D - 35258 - QHEE - Image Loaded, Delta - (1491024 Bytes)`
> > - APDP
> > 
> > 
> >     `B - 978348 - APDP - Image Load, Start`
> > 
> > 
> >     `D - 42212 - Auth Metadata`
> > 
> > 
> >     `D - 458 - Segments hash check`
> > 
> > 
> >     `D - 48434 - APDP - Image Loaded, Delta - (17332 Bytes)`

## Verify secure boot and UEFI secure boot

- [Secure boot](https://docs.qualcomm.com/doc/80-80022-11/topic/features.html#section-secure-boot-features) feature is designed to ensure that a device boots using only software that’s trusted by the manufacturer.
- [UEFI secure boot](https://docs.qualcomm.com/doc/80-80022-11/topic/features.html#section-uefi-secure-boot-features) is an extension of secure boot that operates within the unified extensible firmware interface (UEFI) environment.
- Enabling secure boot for the hardware is crucial for achieving hardware security and protecting intellectual property. For instructions, see [Enable secure boot](https://docs.qualcomm.com/doc/80-80022-11/topic/enable-secure-boot.html#enable-secure-boot) and [Enable UEFI secure boot](https://docs.qualcomm.com/doc/80-80022-11/topic/enable-uefi-secure-boot.html#enable-uefi-secure-boot).
- The XBL logs contain the secure boot status of the device. The logs include information about the boot interface, secure boot status, boot configuration, JTAG ID, OEM ID, and serial number.

> 
> 
> S - Format: Log Type - Time(microsec) - Message - Optional Info
>         S - Log Type: B - Since Boot(Power On Reset),  D - Delta,  S - Statistic
>         S - QC_IMAGE_VERSION_STRING=BOOT.MXF.1.0.c1-00037-KODIAKLA-1
>         S - IMAGE_VARIANT_STRING=SocKodiakLAA
>         S - OEM_IMAGE_VERSION_STRING=hu-apasunur-hyd
>         S - Boot Interface: USB **
>         S - Secure Boot: On **
>         S - Boot Config @ 0x00786070 = 0x000000c1
>         S - JTAG ID @ 0x00786130 = 0x001970e1
>         S - OEM ID @ 0x00786138 = 0x00000000
>         S - Serial Number @ 0x00786134 = 0x4172f1dd
>         Copy to clipboard

## Verify SELinux status and customize SELinux policies

Caution

This feature isn’t enabled in the current release.

- [Security-Enhanced Linux (SELinux)](https://docs.qualcomm.com/doc/80-80022-11/topic/features.html#selinux) is a security architecture integrated into the Linux kernel that provides a mechanism for supporting access control security policies.
- Verifying the SELinux status for the device software prevents unauthorized access to critical software modules or drivers. For instructions, see [Enable SELinux](https://docs.qualcomm.com/doc/80-80022-11/topic/enable-selinux.html#enable-selinux).
- [SEPolicy](https://docs.qualcomm.com/doc/80-80022-11/topic/features.html#section-selinux-sepolicy-features) is the SELinux policy that defines rules for process and user interactions with system resources, enforcing mandatory access controls (MAC) in Linux.
- Default SEPolicy may not address all the specific requirements of your applications. By creating custom policies, you can define precise rules that align with your application’s requirements. For instructions, see [Customize SEPolicy](https://docs.qualcomm.com/doc/80-80022-11/topic/customize.html#section-customize-sepolicy-customization-label).
- To verify the SELinux status, do the following:

> 
> 
> 1. Verify the kernel configuration.
> 
> 
> 
> 
> > 
> > 
> > CONFIG_SECURITY_SELINUX=y
> >         Copy to clipboard
> 
> 
>     2. Connect to the device using SSH.
>     3. View the SELinux enable status and other details, by running the `seinfo` commands.
> 
> 
> 
> 
> > 
> > 
> > Statistics for policy file: /sys/fs/selinux/policy
> >         Policy Version:             33 (MLS enabled)
> >         Target Policy:              selinux
> >         Handle unknown classes:     allow
> >         Classes:                    131       Permissions:         423
> >         Sensitivities:              16        Categories:          1024
> >         Types:                      4376      Attributes:          319
> >         Copy to clipboard
> 
> 
>     4. Verify the SELinux enforce status from the console or connect to the device using SSH.
> 
> 
> 
> 
> > 
> > 
> > getenforce
> >         enforcing - if selinux is set to enable
> >         Copy to clipboard

## Verify PIL image loading - Sample logs

The following sample logs show the initialization and status of various remote processors and hardware components, which are part of the boot process managed by the primary image loader (PIL). The PIL is responsible for loading and verifying these components to ensure they’re secure and functioning correctly.

> 
> 
> | WLAN (remoteproc1) | `730, 0x00000000000459B4 | 8.700828: remoteproc remoteproc1: Remote processor 8a00000. Remoteproc is now up` |
> | --- | --- |
> | cDSP (remoteproc3) | `735, 0x00000000000465A3 | 8.794052: remoteproc remoteproc3: Remote processor a300000. Remoteproc is now up` |
> | aDSP (remoteproc2) | `741, 0x00000000000469FC | 8.828033: remoteproc remoteproc2: Remote processor 3000000.remoteproc is now up` |
> | MODEM (remoteproc0) | `1035, 0x000000000006B78B | 13.433955: remoteproc remoteproc0: Remote processor 4080000. Remoteproc is now up` |
> | A660\_zap | `sh-5.1# cat /dev/kgsl-3d0`<br><br><br>`OH HAI GPU` |
> | Video (Vpu20\_1v.mbn) | `sh-5.1# dmesg | grep video`<br><br><br>`[    0.000000] OF: reserved mem: 0x000000008a700000..0x000000008adfffff (7168 KiB) nomap non-reusable video@8a700000`<br><br><br>`[    0.169598] platform aa00000.video-codec: Adding to iommu group 9`<br><br><br>`[   11.385238] videodev: Linux video capture interface: v2.00`<br><br><br>`[   11.476933] qcom-venus aa00000.video-codec: non legacy binding` |

## Verify QCOMTEE driver status

The QCOMTEE driver incorporated into the Linux^®^ TEE subsystem framework enables communication with the Qualcomm^®^ Trusted Execution Environment (Qualcomm TEE) using an Object-IPC based protocol. To verify whether it is enabled, check for the TEE device node.

> 
> 
> ls /dev/tee0
>     Copy to clipboard

## Verify Qualcomm TEE Mink and GlobalPlatform API availability

Linux client applications can communicate with Qualcomm TEE using Mink APIs provided by the Mink adapter library. The adapter library enables Linux applications to manage and load secure applications and to interact with secure peripherals.

Linux applications that require standardized APIs for communicating with the platform TEE (Qualcomm TEE on Qualcomm devices) can use the GlobalPlatform‑compliant APIs implemented by the Mink TEEC library. Using these standard APIs improves interoperability and portability of Linux applications across different TEE‑enabled devices. You can verify the availability of the Mink adapter library and the Mink TEEC library on the device as described below.

Verify the availability of the library on the device.

> 
> 
> cd /usr/lib/
>     ls libminkadaptor*
>     ls libminkteec*
>     Copy to clipboard

## Verify if the Qualcomm TEE supplicant is running

The Qualcomm TEE supplicant daemon provides rich execution environment (Linux) services to the Qualcomm TEE. For example, a secure application running within Qualcomm TEE can request file system services from Linux through the Qualcomm TEE supplicant daemon, which hosts multiple listener services to handle such requests.

> 
> 
> # Get the service status using systemctl
>     systemctl status qteesupplicant.service
>     
>     # The command output must show the service is loaded and running similar to below
>     qteesupplicant.service - QTEE Supplicant Service
>        Loaded: loaded (/usr/bin/qtee_supplicant; enabled; preset: enabled)
>        Active: active (running) since Sun 1980-01-06 00:00:00 UTC; 29min ago
>     Copy to clipboard

## Verify RPMB provisioning status

Caution

The `rpmbClient` feature isn’t enabled in the current release.

The replay protected memory block (RPMB) is a secure partition in storage devices. The RPMB provisioning ensures that the RPMB is correctly provisioned and ready to securely store and retrieve data. To verify the RPMB provisioning status, do the following:

1. Connect to the device using SSH and run the following command.

> 
> 
> sh-5.1# rpmbClient smci -p 1
>         Copy to clipboard

    The following message is displayed.

> 
> 
> SMCINVOKE INTERFACE WARNING!!!
> You are about to provision the RPMB key.
> This is a ONE time operation and CANNOT be reversed.
> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
> 
> 
> 0 -&gt; Provision Production key
> 1 -&gt; Provision Test key
> 2 -&gt; Check RPMB key provision status
> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
2. Select option 2: Check RPMB key provision status. For a non-provisioned device, `RPMB_KEY_NOT_PROVISIONED` output is expected.
3. You may choose option 1: To provision RPMB with test key only if necessary and after reading below caution before proceeding.

> 
> 
> Caution
> 
> 
> Once RPMB is provisioned with test keys on a non-secure device, it becomes irreversible. As a result, secure boot can’t be enabled on such devices. For more information, see [RPMB](https://docs.qualcomm.com/doc/80-80022-11/topic/features.html#section-rpmb-features).

## Verify Qualcomm WES status

- [Qualcomm® wireless edge services (Qualcomm WES)](https://docs.qualcomm.com/doc/80-80022-11/topic/features.html#section-qualcomm-wes-features) helps deploy many edge devices easily and manage them without manual intervention. It includes the following services:

> 
> 
> - Plug‑and‑play setup
>     - On‑demand updates
>     - Emergency and routine upgrades
>     - Third‑party services throughout the device lifecycle.
- If you need to develop applications that offer hardware-based attestation, zero-touch device provisioning, and chipset feature management, see [Develop trusted and client applications](https://docs.qualcomm.com/doc/80-80022-11/topic/develop_lru.html#develop-lru).
- To install or upgrade QCS5430 SoftSKU feature packs, see [Install or upgrade SoftSKU feature packs](https://docs.qualcomm.com/doc/80-80022-11/topic/upgrade-qualcomm-wes-feature-pack.html#upgrade-qualcomm-wes-feature-pack).

Note

This feature is available to licensed users with authorized access to verify the Qualcomm WES status. If you have access, see [Qualcomm Linux Wireless Edge Services Guide](https://docs.qualcomm.com/bundle/resource/topics/80-80022-11B/bring-up-qwes.html).

## Verify trusted and client applications

- Trusted applications function within a trusted execution environment (TEE), offering a secure and isolated environment to keep the integrity and confidentiality of code and data.
- Client applications function within the normal world operating system, communicating with trusted applications using TEE client APIs to perform secure services.
- To execute the security-critical applications in the secure world (TrustZone), you must develop your own trusted applications. You must have access to the Qualcomm TEE software development kit (SDK) to develop corresponding client applications that launch the trusted applications. For more information, see [Develop trusted and client applications](https://docs.qualcomm.com/doc/80-80022-11/topic/develop_lru.html#develop-lru).

Note

This feature is available to licensed users with authorized access to develop and run trusted and client applications. If you have access, see [Qualcomm Linux Security Guide - Addendum](https://docs.qualcomm.com/bundle/resource/topics/80-80022-11A/develop.html).

## Next steps

- To configure Qualcomm TEE for securing devices that handle sensitive data and run trusted applications, see [Configure security services](https://docs.qualcomm.com/doc/80-80022-11/topic/configure.html#configure).
- To customize memory and SEPolicy, see [Customize security services](https://docs.qualcomm.com/doc/80-80022-11/topic/customize.html#customize).

Last Published: May 18, 2026

[Previous Topic
Security tools](https://docs.qualcomm.com/bundle/publicresource/80-80022-11/topics/tools.md) [Next Topic
Configure security services](https://docs.qualcomm.com/bundle/publicresource/80-80022-11/topics/configure.md)