Skip to main content
The security verification process involves checking and validating the security 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

​
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 feature is designed to ensure that a device boots using only software that’s trusted by the manufacturer.
  • UEFI secure boot 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 and 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

​
Verify SELinux status and customize SELinux policies

This feature isn’t enabled in the current release.
  • Security-Enhanced Linux (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.
  • SEPolicy 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.
  • To verify the SELinux status, do the following:
    1. Verify the kernel configuration.
    CONFIG_SECURITY_SELINUX=y
    1. Connect to the device using SSH.
    2. 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
    1. Verify the SELinux enforce status from the console or connect to the device using SSH.
    getenforce
enforcing - if selinux is set to enable

​
Verify PIL image loading - Sample logs

The following sample logs show the initialization and status of remote processors and hardware components loaded through PIL.
  • 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
OH HAI GPU
  • Video (Vpu20_1v.mbn) 
    sh-5.1# dmesg | grep video
[ 0.000000] OF: reserved mem: 0x000000008a700000..0x000000008adfffff (7168 KiB) nomap non-reusable video@8a700000
[ 0.169598] platform aa00000.video-codec: Adding to iommu group 9
[ 11.385238] videodev: Linux video capture interface: v2.00
[ 11.476933] qcom-venus aa00000.video-codec: non legacy binding

​
Verify QCOMTEE driver status

Check for the TEE device node. 
ls /dev/tee0

​
Verify Qualcomm TEE Mink and GlobalPlatform API availability

Qualcomm® Trusted Execution Environment (Qualcomm TEE) supports Mink and Global Platform based APIs to provide access to secure services implemented within it. Mink is an Object-IPC based protocol implemented by the Mink Adaptor library, whereas the Mink TEEC library implements the Global Platform standardized APIs to allow interoperability of and security across devices. The verification process involves checking that these APIs are correctly implemented and available for use.
  1. Verify the availability of the Mink Adaptor and Mink Teec libraries on the device. 
    cd /usr/lib/
ls libmink*

​
Verify if the Qualcomm TEE supplicant is running

The QTEE supplicant daemon provides Rich Execution Environment (Linux) services to QTEE such as file system and time services.
  1. Verify that the QTEE supplicant daemon is running. 
    # 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

​
Verify RPMB provisioning status

The replay protected memory block (RPMB) is a secure partition defined within the UFS or eMMC storage device. The storage must be provisioned with either a Test or Production key RPMB before it can be used. To verify the RPMB provisioning status, do the following:
  1. Connect to the device using SSH and run the following command. 
    sh-5.1# rpmb_client -p
    The following message is displayed. 
    -------------------------------------------------------
 WARNING!!! You are about to provision the RPMB key.
 You are about to provision the RPMB key.
 This is a ONE time operation and CANNOT be reversed.
 -------------------------------------------------------
  0 -> Provision Production key
  1 -> Provision Test key\n
  2 -> Check RPMB key provision status
 -------------------------------------------------------
  Select an option to proceed:
  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.
    1. 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.

​
Verify Qualcomm WES status

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.

​
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.
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.

​
Next steps