# Enable secure boot on SAIL This section describes how to enable secure boot on the Safety Island (SAIL) domain for Qualcomm Dragonwing^™^ IQ-9100 and Qualcomm Dragonwing^™^ IQ-8300. It covers generating `sec.elf`, signing images, configuring QFPROM fuses, managing debug policies, configuring anti-rollback, and setting up multiple root certificates. Secure boot concepts are the same on main domain and SAIL. For SAIL domain, use SecTools V2 to generate a `sec.elf` image just for SAIL and sign other SAIL images. The images involved in secure boot on SAIL are different from those on main domain. Note There’s no Stage 1 and Stage 2 concept for secure boot on SAIL. ## Prerequisites SecTools v2 is used for the SAIL domain in the same way as for the main domain. The SecTools binary is located at: > > > /common/sectoolsv2/ext/Linux/sectools > Copy to clipboard The security profile XML file is platform-specific: Tab Dragonwing IQ-9100 Tab Dragonwing IQ-8300 Profile name: `lemans_sail_security_profile` /common/sectoolsv2/lemans_sail_security_profile.xml Copy to clipboard Profile name: `monaco_sail_security_profile` /common/sectoolsv2/monaco_sail_security_profile.xml Copy to clipboard ### Generate local (insecure) root key and certificates Follow the same steps as for the main domain. The SAIL domain supports only a two-certificate chain. Skip the steps to generate a CA (intermediate) key pair and certificate, as an intermediate CA certificate isn’t required. For more information, see [Generate keys and certificates](https://docs.qualcomm.com/doc/80-70030-11/topic/generate-keys-and-certificates.html#generate-keys-and-certificate). ### Generate sec.elf to enable secure boot on SAIL Enable secure boot on the SAIL domain by blowing the required fuse bits using the SecTools fuse-blower command. The command is largely the same across platforms; only the security profile path and placeholder values differ. Note Update the signing mode, root certificate path, root key path, chipset, OEM ID, and product ID with appropriate OEM-specific values before running the commands. The following commands are reference examples only. Note `--fuse-anti-rollback-feature-en=0x3`, `--fuse-oem-configuration-write-disable`, and `--fuse-oem-secure-boot-write-disable` can be blown at later stages if you don’t want to blow ARB during development. Note Since there is no CA certificate and key, `--root-key` must be provided for signing. Platform-specific fuse-blower command examples: Tab Dragonwing IQ-9100 Tab Dragonwing IQ-8300 Note Replace `0xAAAA` and `0xBBBB` with HW-ID and Product-ID values. ./sectools fuse-blower --security-profile /common/sectoolsv2/lemans_sail_security_profile.xml --outfile /sail_E2E.elf --fuse-pk-hash-0= --fuse-oem-hw-id=0xAAAA --fuse-oem-product-id=0xBBBB --fuse-oem-secure-boot1-pk-hash-in-fuse --fuse-oem-secure-boot1-auth-en --fuse-oem-secure-boot-fec-enable --fuse-anti-rollback-feature-en=0x3 --fuse-sail-dbgen --fuse-sail-niden --fuse-sail-hiden --fuse-sail-hniden --fuse-sail-c0-dbgen --fuse-sail-c0-niden --fuse-sail-cpu-scan-en --fuse-sail-dcc-scan-en --fuse-sail-c1-dbgen --fuse-sail-c1-niden --fuse-sail-c2-dbgen --fuse-sail-c2-niden --fuse-sail-c3-dbgen --fuse-sail-c3-niden --fuse-oem-secure-boot-write-disable --fuse-public-key-hash-0-write-disable --fuse-oem-configuration-write-disable --fuse-fec-enables-write-disable --fuse-write-permissions-write-disable --fuse-read-permissions-write-disable --fuse-wdog-en --fuse-eku-enforcement-en --fuse-anti-rollback-feature-en=0x3 --generate --sign --signing-mode LOCAL --root-certificate=./OEM-KEYS/qpsa_rootca.cer --root-key=./OEM-KEYS/qpsa-rootca.key Copy to clipboard Note Replace `0xAAAA` and `0xBBBB` with actual OEM values. ./sectools fuse-blower --security-profile /common/sectoolsv2/monaco_sail_security_profile.xml --outfile /sail_E2E.elf --fuse-pk-hash-0= --fuse-oem-hw-id=0xAAAA --fuse-oem-product-id=0xBBBB --fuse-oem-secure-boot1-pk-hash-in-fuse --fuse-oem-secure-boot1-auth-en --fuse-oem-secure-boot-fec-enable --fuse-anti-rollback-feature-en=0x3 --fuse-sail-dbgen --fuse-sail-niden --fuse-sail-hiden --fuse-sail-hniden --fuse-sail-c0-dbgen --fuse-sail-c0-niden --fuse-sail-cpu-scan-en --fuse-sail-dcc-scan-en --fuse-sail-c1-dbgen --fuse-sail-c1-niden --fuse-sail-c2-dbgen --fuse-sail-c2-niden --fuse-sail-c3-dbgen --fuse-sail-c3-niden --fuse-oem-secure-boot-write-disable --fuse-public-key-hash-0-write-disable --fuse-oem-configuration-write-disable --fuse-fec-enables-write-disable --fuse-write-permissions-write-disable --fuse-read-permissions-write-disable --fuse-wdog-en --fuse-eku-enforcement-en --fuse-anti-rollback-feature-en=0x3 --generate --sign --signing-mode LOCAL --root-certificate=./OEM-KEYS/qpsa_rootca.cer --root-key=./OEM-KEYS/qpsa-rootca.key Copy to clipboard ### Sign the images The SAIL domain requires signing fewer images than the main domain. Typical images include: `SAIL_HYP` (hypervisor), `sec.elf`, `SAIL_DP` (debug policy), and `SAIL_SW1`. To sign the images: 1. For detailed instructions, see [SecTools v2 Secure Image User Guide](https://docs.qualcomm.com/doc/80-NM248-12/topic/secure-image-usage.html). 2. Choose one of the following options: > > > Note > > > Update the signing mode, root certificate path, root key path, chipset, OEM ID, and product ID with appropriate OEM-specific values before running the commands. > > - Option A: Sign an individual image > > > > > > > > > The following command is an example. > > > > > > > > > > > > > > > > > > > > > > > > ./sectools secure-image ./sec.elf --security-profile ./lemans_sail_security_profile.xml --sign --signing-mode LOCAL --root-certificate=./OEM-KEYS/qpsa_rootca.cer --root-key=./OEM-KEYS/qpsa_rootca.key --image-id SEC-ELF --oem-id=0x0 --oem-product-id=0x0 --outfile ./secure-image-out/sec.elf --validate > > > > Copy to clipboard > > > > > > > > > > > > For more information, see [SecTools V2: Secure Image User Guide](https://docs.qualcomm.com/doc/80-NM248-12/topic/secure-image-usage.html). > - Option B: Sign all images in the meta build > > > > > > > > > The following command is an example for the SPINOR storage type and the `SAIL_NOR` flavor. > > > > > > > > > > > > > > > ./sectools metabuild-secure-image --image-finder /common/build/app/image_finder.py --sign --signing-mode LOCAL --root-certificate=./OEM-KEYS/qpsa_rootca.cer --root-key=./OEM-KEYS/qpsa_rootca.key --oem-id=0x0 --oem-product-id=0x0 --chipset LEMANS --storage SPINOR --flavor SAIL_NOR --outdir signedMeta --validate > > > Copy to clipboard > > > > > > > > For more information, see [SecTools V2: Metabuild Secure Image User Guide](https://docs.qualcomm.com/bundle/80-NM248-17/resource/80-NM248-17_REV_AB_SecTools_V2__Metabuild_Secure_Image_User_Guide.pdf). - Required OEM signed images > > > The minimum required OEM signed images for successful secure boot enablement can be found by running: > > > > > > > > > ./sectools metabuild-secure-image > > --available-image-ids > > --image-finder /common/build/app/image_finder.py > > Copy to clipboard > > > > This uses the contents.xml file from the meta build, which contains the minimum required OEM signed images and their file paths. ### Flash the images For devices with secure boot enabled, VIP flashing is required. For more information, see [Qualcomm Firehose Validated Image Programming (VIP) User Guide](https://docs.qualcomm.com/bundle/80-P9116-1/resource/80-P9116-1_REV_J_Qualcomm_Firehose_Validated_Image_Programming__VIP__User_Guide.pdf). For devices with secure boot enabled, VIP flashing is required. Flashing SAIL images is similar to flashing main domain images. Select the `SPI_NOR` storage type and the `SAIL_NOR` product flavor. Note The `sec.elf` flashing isn’t supported using fastboot for the SAIL domain. Flash it using PCAT by adding the file name in the rawprogram XML. ## Use debug policy on SAIL The debug policy feature exists on the SAIL side independently of the debug policy on the main domain. SAIL has its own debug policy image that enables debug capabilities such as JTAG, RAM dump, and hypervisor logging on commercial secure devices. For security reasons, the debug policy is tightly controlled using the serial number of the device. On the SAIL side, debug-related terminology differs from that used in the main domain. Instead of secure and non-secure world, the terms hypervisor and non-hypervisor are used. The hypervisor operates at EL2 (similar to the secure world in the main domain), while non-hypervisor components run at EL1. The debug policy feature must be enabled to view logs. For more information, see [SecTools v2: Secure Debug User Guide](https://docs.qualcomm.com/bundle/80-NM248-23/resource/80-NM248-23_REV_AA_SecTools_v2__Secure_Debug_User_Guide.pdf). Tab Dragonwing IQ-9100 Tab Dragonwing IQ-8300 ./sectools secure-debug --security-profile ./lemans_sail_security_profile.xml -h Copy to clipboard ./sectools secure-debug --security-profile ./monaco_sail_security_profile.xml -h Copy to clipboard ### Re-enable JTAG access 1. Sign the `SAIL_HYP` image with the `--jtag-debug` enable option. 2. Specify the device serial number using `--serial-number` to bind the signed images. When enabled, all images are signed with the provided serial number to prevent misuse of debug-enabled images. To disable JTAG re-enablement, sign all images with the `--jtag-debug` disable option. This action causes PBL to write 0x0 to the override registers. Because these registers are one-time writable per power cycle, JTAG access can’t be re-enabled afterward. ### Sign SAIL\_HYP image with JTAG debug option Collect the following information before signing: - Serial number: Upto eight hexadecimal values can be added to enable JTAG debug on up to eight devices using a single `SAIL_HYP` image. Obtain the serial number from the device serial logs or by reading from the QFPROM fuses. - Debug options: List available device restrictions with: > > > ./sectools secure-image --security-profile ./lemans_sail_security_profile.xml --available-device-restrictions > Copy to clipboard Example: Sign `SAIL_HYP` with JTAG debug enabled, bound to two devices by serial number: > > > ./sectools secure-image ./sail_hyp.elf > --security-profile ./lemans_sail_security_profile.xml > --sign > --signing-mode LOCAL > --root-certificate=./OEM-KEYS/qpsa_rootca.cer > --root-key=./OEM-KEYS/qpsa_rootca.key > --image-id SAIL-HYP > --oem-id=0x0 > --oem-product-id=0x0 > --outfile ./secure-image-out/sail_hyp.elf > --validate > --jtag-debug ENABLE > --serial-number 0x68c0f97c 0x68c0f007 > Copy to clipboard Note Update the signing mode, root certificate path, root key path, chipset, OEM ID, and product ID with appropriate OEM-specific values before running the commands. Confirm JTAG Debug is enabled and the correct serial numbers are bound by inspecting the signed image: ./sectools secure-image ./secure-image-out/sail_hyp.elf --inspect Copy to clipboard Check the OEM metadata section of the inspection report to verify the JTAG-debug setting and serial number binding. ### Use debug policy image (dp.mbn) View available SAIL debug options: ./sectools secure-debug --security-profile ./lemans_sail_security_profile.xml -h Copy to clipboard Example: Generate and sign a debug policy image (`saildp.mbn`) for SAIL. The image is signed with a TEST signer and configured to enable SAIL hypervisor logging, JTAG debugging, traces for all execution levels, and SAIL secure (hypervisor) crash dumps. ./sectools secure-debug --generate --outfile /saildp.mbn --security-profile /common/sectoolsv2/lemans_sail_security_profile.xml --sign --signing-mode TEST --serial-number --sail-secure-crash-dumps Copy to clipboard Note Update the signing mode, root certificate path, root key path, chipset, OEM ID, and product ID with appropriate OEM-specific values before running the commands. Sign `saildp.mbn` with the same configurations as other images. Note The command above uses TEST certificates. Select the appropriate signing mode for your environment. If custom certificates were used to enable secure boot, use `--signing-mode LOCAL` with the same certificates as shown in previous commands. ## Sign and validate images on SAIL An image is a packaged format of executable code. Images are validated through signing by Qualcomm, licensees, or trusted vendors. Licensees can use CASS to sign images. SecTools is also available to generate and sign secure images. Alternatively, licensees may use their own code-signing systems. Note CASS isn’t automatically available to the users from Salesforce or CreatePoint accounts. Additional agreements and authorizations may be required. Contact your sales account representative for more information. For more information, see [SecTools V2: Secure Image User Guide](https://docs.qualcomm.com/doc/80-NM248-12/topic/secure-image-usage.html). Trusted vendors perform the following steps: 1. Generate a code signature using their private key. 2. Provide the signed software binary to the device along with the signature. The device uses the corresponding public key to verify the authenticity and integrity of the binary. A signed image includes a code signature and a certificate chain. The certificates contain the public keys required to verify the certificate and image signatures. The image format and signing process on the SAIL side are similar to those used in the main domain. ### Image format - MBN v6 The same MBN v6 image format is used on the SAIL side as on the main domain side. ### Metadata in image header The metadata in the image header for SAIL images is similar to that used in main domain images. The security profile file that defines all supported software IDs on the SAIL side is platform-specific. Tab Dragonwing IQ-9100 Tab Dragonwing IQ-8300 See `lemans_sail_security_profile.xml` for all possible software IDs on the SAIL side. See `monaco_sail_security_profile.xml` for all possible software IDs on the SAIL side. ### Sign hash table segment The signature based on elliptic curve cryptography (ECC) is a new addition. The elliptic curve digital signature algorithm (ECDSA) is the latest modern signature generation scheme and is now used by default. For more information, see the following: - [Elliptic-curve cryptography](https://en.wikipedia.org/wiki/Elliptic-curve_cryptography) - [Elliptic Curve Digital Signature Algorithm](https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm) ### Verify hash table segment signature The generated signature is validated with a public key stored in the certificate, compared with a locally calculated hash digest. If they match, image authentication passes; otherwise it fails. ### Recommended hash signature algorithm ECDSA is the default signature algorithm. SHA-384 is the recommended algorithm for segment hash and signature in the certificate chain. Note For CASS, because the certificate chain is recreated, PBL no longer has the root certificate hash in PBL ROM. The OEM must blow `PK_HASH_IN_USE` or `OEM_PK_HASH` with the new root CA hash. ### Code signing The PBL only allows images signed with software type `SAIL-HYP`. Software versioning is enforced by signing images with the new software version and blowing software version fuses to prevent rollback. ### Double signing Caution Double signing isn’t supported on the SAIL side. ### Multiple image signing and verification Caution Multiple image signing and verification (MISC image) isn’t supported on the SAIL side. ## Use secure boot certificates on SAIL The certificate chain on the SAIL side is similar to that used in the main domain. However, only a two-certificate chain is supported on SAIL, whereas the main domain supports both two- and three-certificate chains. ## Secure boot process on SAIL The secure boot process on the SAIL side is similar to that of the main domain. It’s a multi-stage process in which each image performs a specific function and is verified by the preceding image. The root-of-trust (RoT) initiates the process in SAIL-PBL. Because SAIL-PBL resides in on-chip code, it’s inherently trusted and immutable. Each image is authenticated to ensure it’s authorized before the next image in the boot sequence is executed. Boot chain example: SAIL PBL → SAIL-HYP → SAIL-SWn Copy to clipboard ## Configure QFPROM on SAIL QFPROM is one-time programmable memory. The QFPROM configuration enables the security environment required for secure boot. QFPROM accesses the following: - RAW regions - Intended for fuse blowing and verification. - Read-only corrected address space - Intended for use by software. Caution The QFPROM configuration is irreversible. Exercise extreme caution during the fuse-blowing process. The SAIL side has its own QFPROM regions independent from those of the main domain. Most e-fuses on the SAIL side are similar to those on main domain, but some differ (for example, debug-related e-fuses). To list all e-fuses supported on the SAIL side: Tab Dragonwing IQ-9100 Tab Dragonwing IQ-8300 ./sectools fuse-blower --security-profile ./lemans_sail_security_profile.xml -h Copy to clipboard ./sectools fuse-blower --security-profile ./monaco_sail_security_profile.xml -h Copy to clipboard ### Enable secure boot using QFPROM AUTH\_EN fuse The `AUTH_EN` fuse controls whether secure boot authentication is enabled for all code segments. Blowing the `AUTH_EN` fuse enables secure boot for applications and peripheral images, and enforces authentication for any code that references secure boot configuration. The `AUTH_EN` fuse must be blown to mandate authentication of the associated images. ### Blow secure boot fuses For secure boot enablement fuses, see the platform-specific QFPROM Programming Reference Guide and [SecTools V2: Fuse Blower User Guide](https://docs.qualcomm.com/bundle/80-NM248-9/resource/80-NM248-9_REV_AB_SecTools_V2__Fuse_Blower_User_Guide.pdf). Tab Dragonwing IQ-9100 Tab Dragonwing IQ-8300 [Dragonwing IQ-9100 (SAIL domain) QFPROM Programming Reference Guide](https://docs.qualcomm.com/doc/80-73415-97/80-73415-97_REV_AA_QCS9100_QFPROM_Programming_Reference_Guide.zip) This information will be updated in a future release. ### Blow USE\_SERIAL\_NUM Blow the `USE_SERIAL_NUM` fuse when signing images with the unique chip serial number stored in the `QFPROM_CORR_SERIAL_NUM_LSB` fuse. This enables the authentication logic to use the serial number to verify the image. ### Blow PK\_HASH\_IN\_FUSE Blow the `PK_HASH_IN_FUSE` fuse when using the licensee’s own code signing system. The licensee provisions the hash of their trusted root certificate in the OEM_PK_HASH fuse. The authentication logic uses this hash to validate that the certificate chain originates from the authorized licensee source. Note If the licensee uses Qualcomm CASS with a SHA-384 root certificate, this fuse must also be blown with the hash of the trusted root certificate. ### OEM identifier fuses For more information, see the platform-specific QFPROM Programming Reference Guide and [SecTools V2: Fuse Blower User Guide](https://docs.qualcomm.com/bundle/80-NM248-9/resource/80-NM248-9_REV_AB_SecTools_V2__Fuse_Blower_User_Guide.pdf). Tab Dragonwing IQ-9100 Tab Dragonwing IQ-8300 [Dragonwing IQ-9100 (SAIL domain) QFPROM Programming Reference Guide](https://docs.qualcomm.com/doc/80-73415-97/80-73415-97_REV_AA_QCS9100_QFPROM_Programming_Reference_Guide.zip) This information will be updated in a future release. ### QFPROM programming QFPROM programming has an important role in enabling security features. With an increasing number of security features such as anti-rollback, secure boot, multiple root certificates, secure file system, and JTAG disabling, the fuse bits must be handled with caution. For more information, see the platform-specific QFPROM Programming Reference Guide: Tab Dragonwing IQ-9100 Tab Dragonwing IQ-8300 [Dragonwing IQ-9100 (SAIL domain) QFPROM Programming Reference Guide](https://docs.qualcomm.com/doc/80-73415-97/80-73415-97_REV_AA_QCS9100_QFPROM_Programming_Reference_Guide.zip) This information will be updated in a future release. #### Fuse blowing process The OEM uses SecTools to generate a customized set of fuse values. For more information, see [SecTools V2: Fuse Blower User Guide](https://docs.qualcomm.com/bundle/80-NM248-9/resource/80-NM248-9_REV_AB_SecTools_V2__Fuse_Blower_User_Guide.pdf). The Fuse blower tool generates a `sec.elf` binary file with the following format. | Header | qfuse list header | qfuse entry | qfuse entry | qfuse entry | qfuse entry | Footer | | --- | --- | --- | --- | --- | --- | --- | Note As the `sec.elf` partition is used in RAW format, avoid using the `sec.dat` partition to blow fuses for sensitive data such as OEM private keys. The fuse blowing procedure on the SAIL side is similar to that on the main domain side. OEMs generate sec.elf with the required fuses, flash it to the SAIL side of the device, and it’s authenticated and loaded as part of boot. All configured fuses are blown, then the device resets. ### Disable debug ports When secure boot is enabled, OEMs must blow the debug disable fuses to prevent access to device processors through JTAG ports. This is essential to ensure that secure boot can’t be bypassed. See the platform-specific QFPROM Programming Reference Guide: Tab Dragonwing IQ-9100 Tab Dragonwing IQ-8300 [Dragonwing IQ-9100 (SAIL domain) QFPROM Programming Reference Guide](https://docs.qualcomm.com/doc/80-73415-97/80-73415-97_REV_AA_QCS9100_QFPROM_Programming_Reference_Guide.zip) This information will be updated in a future release. ### Debug overrides One-time writable debug override registers can be used to either keep the debug-disable fuse settings or re-enable JTAG (overriding the debug-disable fuse settings). These override registers can be written only once during each power cycle; subsequent writes don’t take effect. ### Enable SFS Enabling secure file system (SFS) requires hardware key access for the crypto engine. The secondary hardware key (SHK) is generated for the SFS use case from a random hardware seed. The device must be secured in terms of JTAG accessibility. See the platform-specific QFPROM Programming Reference Guide: Tab Dragonwing IQ-9100 Tab Dragonwing IQ-8300 [Dragonwing IQ-9100 (SAIL domain) QFPROM Programming Reference Guide](https://docs.qualcomm.com/doc/80-73415-97/80-73415-97_REV_AA_QCS9100_QFPROM_Programming_Reference_Guide.zip) This information will be updated in a future release. ## Prevent software rollback on SAIL Anti-rollback is used to determine if the current software version is at least greater than the one stored in the fuses. There is no FEC for antirollback fuses. The software only reads the number of bits set in the antirollback fuse. For a 16-bit value, the maximum value is 15, preventing up to a 16-version rollback. The software only reads corrected QFPROMs (read-only). To program QFPROM, program the RAW QFPROMs. ### Enable anti-rollback The rollback feature is independently activated for images based on the following bits of QFPROM: QFPROM_CORR_OEM_CONFIG_ROW2_MSB[33:32] Copy to clipboard For the full ARB fuse list, see the platform-specific QFPROM Programming Reference Guide. Tab Dragonwing IQ-9100 Tab Dragonwing IQ-8300 [Dragonwing IQ-9100 (SAIL domain) QFPROM Programming Reference Guide](https://docs.qualcomm.com/doc/80-73415-97/80-73415-97_REV_AA_QCS9100_QFPROM_Programming_Reference_Guide.zip) This information will be updated in a future release. Anti-rollback control bits: | Bit Position | Name | Subsystem | | --- | --- | --- | | 32 | `SAIL_HYP_ANTI_ROLLBACK_EN` | `SAIL_HYP` | | 33 | `SAIL_SW_ANTI_ROLLBACK_EN` | SAIL SWn components | Maximum secure upgrade versions per image type: | Image Type | Maximum versions of secure upgrade supported | | --- | --- | | `SAIL_HYP` | 60 | | Debug policy | 4 | | `SAIL_SW1` | 60 | The software version is determined from the antirollback version field in the OEM metadata of the MBN. The image type is determined from the `SW_ID` field contents in the common metadata of the MBN. ### Rollback prevention example The `SW_ID` is inserted into the common metadata when the image is signed; persistent memory stores the oldest software version that can be loaded onto the device. When `SAIL_HYP_ANTI_ROLLBACK_EN` is set to 1, the boot loader and `SAIL_HYP` perform a software version rollback check (stored in `SW_ID`) against the oldest software version (stored in persistent memory). The software version is for rollback prevention only. A licensee must increment the version only when a previous version should no longer be loadable (to close a security vulnerability). SecTools V2 options to set SW\_ID and ARB version: --image-id (for SW_ID) --anti-rollback-version (for ARB version) Copy to clipboard Fuse register values (number of bits set = version number): 00000000000000000000 = 0 00000000000000000001 = 1 00000000000000000111 = 3 11111111111111111111 = 20 (maximum in this example) Copy to clipboard ### Rollback prevention use case A device starts at software version 0. To upgrade `SAIL_HYP` software version to 1, sign the `SAIL_HYP` image with the new `SW_ID` and ARB version 1. If the image is signed with a lower version, the device can’t boot. When a newer software version image is loaded, the boot loader blows the fuse with the latest higher software version to prevent further rollback. ### Software version rollback limitation If the software version exceeds the maximum fuse version for a specific image, the image bypasses the version check. Only the maximum allowed bits (20) are blown. For all later bootups, only builds with version >= maximum fuse version (19) are allowed to proceed. Example: - Image signed with ARB version = 0x17 (decimal 23 > max 19): device boots successfully. - Image signed with 0x13 (= 19): device boots. Any version >= 19 can be loaded. - Image signed with 0xF (= 15 < 19): device can’t boot. ## Multiple root certificate The multiple root certificate (MRC) feature allows an OEM to select one from up to four root certificates as the trust anchor for signing and verifying images. The root hash of a concatenation of N root certificates (N = 1 to 4) must be blown to the MRC HASH eFuse. One of the N root certificates is then used to sign images. An OEM can later resign images with a different root certificate if necessary. All root certificates concatenated and used in the root hash calculation must be packaged in the signed image for comparison against the OEM MRC HASH in eFuse. MRC fuses: MRC Hash can contain the hash of up to 4 root certificates. `PK_HASH_IN_FUSE` should be blown. `OEM_ROOT_CERT_ACTIVATION_LIST_*` and `OEM_ROOT_CERT_REVOCATION_LIST_*` enable revocation and activation when more than one root certificate is used. ### SecTools configurations SecTools supports the following options for MRC: [--root-certificate-index {0,1,2,3}] Copy to clipboard Defaults to 0. Specifies the index of the root certificate used to sign the next certificate in the chain. Only applicable when OUTFILE is signed with multiple root certificates. [--transfer-root] Copy to clipboard Defaults to false. Enables revocation and activation of root certificates for devices to which OUTFILE is flashed. Only applicable when OUTFILE is signed with multiple root certificates. Selection of root certificates to revoke and/or activate is achieved using mechanisms such as Devcfg. ### Device configuration Configure root certificate activation and revocation in the `oem_config.xml` file: Path: \trustzone_images\ssg\securemsm\trustzone\qsee\mink\oem\config\\oem_config.xml Copy to clipboard ### MRC on SAIL domain For SAIL, the `ROOT_CERT_ACTIVATION_LIST` and `ROOT_CERT_REVOCATION_LIST` are defined in the sailhyp DTS file, unlike the main domain. See the following platform-specific DTS file name. Tab Dragonwing IQ-9100 Tab Dragonwing IQ-8300 DTS file example: `lemansau-sailhyp.dts` DTS file example: `lemansau-sailhyp.dts` Note The DTS file name is the same as LeMans. Once the updated DTS file is flashed on the SAIL domain, the MRC active and revoked index fuse update must be explicitly triggered by sending the `SAIL_UPD_MSG_UPDATE_MRC` message from main domain. ## Next steps - To enforce strict access controls, see [Enable SELinux](https://docs.qualcomm.com/doc/80-70030-11/topic/enable-selinux.html#enable-selinux). - To ensure that only the verified and trusted applications are loaded during the startup process, see [Enable UEFI secure boot](https://docs.qualcomm.com/doc/80-70030-11/topic/enable-uefi-secure-boot.html#enable-uefi-secure-boot). Last Published: Jun 25, 2026 [Previous Topic Perform VIP flashing](https://docs.qualcomm.com/bundle/publicresource/80-70030-11/topics/vip-flashing.md) [Next Topic Enable SELinux](https://docs.qualcomm.com/bundle/publicresource/80-70030-11/topics/enable-selinux.md)