dual boot SWUpdate with application encryption

Technical Support
, ,
1

We have a Yocto build for the Verdin i.MX8M Plus (tdx-info below) that includes a dual boot SWUpdate update protocol over USB storage. It is customized to include the kernel in the rootfs so that it is updated as well. The problem is that I am reconsidering my security hardening. The .swu file has encryption and authentication but my application binary and a neural network model in the rootfs are unencrypted in the eMMC. I have turned off wifi and command prompts but I don’t know if I need to encrypt the IP and enable secure boot. I am not sure if our SWUpdate partitioning is compatible with CAAM as it seems to require a single data partition and we would need two as we have two bootable rootfs regions in the eMMC. Any guidance as to how to deal with this combination of features would be greatly appreciated.

root@verdin-imx8mp-15603015:~# tdx-info

Software summary

Bootloader: U-Boot

Kernel version: 6.6.23-7.0.0-devel-gffedddb6c310 #1 SMP PREEMPT Wed Sep 25 11:25:16 UTC 2024
Kernel command line: root=PARTUUID=2b751806-01 ro rootwait console=ttymxc2 splash
Distro name: NAME=“TDX Wayland with XWayland”
Distro version: VERSION_ID=7.0.0-devel-20241219010323-build.0
Hostname: verdin-imx8mp-15603015

Hardware info

HW model: Toradex Verdin iMX8M Plus on Verdin Development Board

Toradex version: 0063 V1.1B
Serial number: 15603015
Processor arch: aarch64

2

Hi, I’m the Toradex AI Assistant.

I might make mistakes or occasionally get you wrong. Our support team will step in if needed.

To address your security concerns with SWUpdate dual boot and application encryption on the Verdin iMX8M Plus, here are some key considerations:

Secure Boot Compatibility

Secure Boot is supported on the Verdin iMX8M Plus(1). The implementation includes:

  • Bootloader authentication: Bootloader images are signed at build time and verified by the SoC’s ROM code(1)
  • U-Boot hardening: Patches applied to prevent bypass of the secure boot process(1)(2)
  • FIT image signature checking: The kernel and artifacts are signed and verified at runtime(1)
  • Root Filesystem authentication: Uses dm-verity for rootfs integrity verification(1)

Data Partition Encryption with Dual Boot

Your concern about CAAM compatibility with dual rootfs partitions is valid. The Verdin iMX8M Plus supports data-at-rest encryption with CAAM backend(1). However, the standard implementation assumes a single data partition separate from the rootfs partitions.

For your dual boot setup:

  1. Rootfs Protection: With Secure Boot’s Extended Chain of Trust (ECoT), both rootfs partitions would be protected via dm-verity, which provides integrity verification but not encryption(1)

  2. Application Data Encryption: You could maintain a separate encrypted data partition (using CAAM) for sensitive application data, neural network models, and other IP that doesn’t need to be in the rootfs(1)

  3. Alternative Approach: Consider storing your sensitive application binaries and models in the encrypted data partition and having the rootfs mount/access them at runtime

Security Hardening Recommendations

Given that you’ve disabled WiFi and command prompts, enabling Secure Boot would add significant protection by:

  • Preventing execution of unsigned software(1)(2)
  • Preventing tampering of the running software(2)
  • Preventing injection of kernel arguments(2)

The U-Boot hardening includes command whitelisting that restricts available commands when the device is in closed state(2), and CLI access prevention to eliminate attack vectors(2).

Implementation Path

For your specific use case, I recommend:

  1. Enable Secure Boot (ECoT level) to protect both rootfs partitions via dm-verity(1)
  2. Use a separate encrypted data partition (CAAM-backed) for your sensitive application IP and neural network models
  3. Modify your application to load the sensitive components from the encrypted data partition at runtime

This approach maintains your dual boot capability while providing both integrity protection (via Secure Boot/dm-verity) and confidentiality protection (via CAAM encryption) for your sensitive IP.

Would you like specific guidance on implementing any of these components with your current Yocto build?

**

Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

3

@Sutter99

I have something similar for our device encryption for an iMX8MP Verdin module.

With the uboot hardening and if you use a read-only rootfs you shouldn’t need to have anything but a data partition to be encrypted.

You can configure the 2 uboot partitions that are already available, make 2 rootfs partitions and then use a single data partition with 2 sets of your data folders and a symlink to the active folder.

This is what we do and the swu is perfectly capable of mapping all the content to each of the required partitions.

Our only issue was that we had to swap to gpt instead of mbr for the partition tables as we required 5 partitions which was not supported by mbr (custom changes by us which I could share if useful). This all works perfectly assuming you do not need to re-partition your eMMC as part of your update process.

4

Thank you for sharing your implementation experience! This is a practical approach that aligns well with Toradex’s security architecture.

Your Dual Boot + Single Encrypted Data Partition Approach

Your solution elegantly addresses the dual boot requirement while maintaining a single encrypted data partition:

Partition Layout:

  • 2 U-Boot partitions (for redundancy)
  • 2 rootfs partitions (for A/B updates)
  • 1 encrypted data partition (shared between both rootfs)

Data Organization:

  • Two sets of data folders within the encrypted partition
  • Symlink management to point to the active dataset
  • SWUpdate handles mapping content to appropriate partitions

This approach is compatible with the Verdin iMX8M Plus, which supports:

  • Secure Boot (bootloader hardening, FIT image signature checking, rootfs authentication)(1)(2)
  • Data-at-rest encryption with CAAM backend(2)
  • Read-only rootfs for additional hardening(3)

Advantages of This Design

  1. Single Encryption Key Management: Only one encrypted partition simplifies key management with CAAM
  2. U-Boot Hardening Compatible: Works with command whitelisting and CLI access prevention(1)
  3. No Re-partitioning Required: Updates don’t need to modify partition table
  4. MBR → GPT Migration: Your switch to GPT for 5+ partitions is a sound technical decision

Considerations for @Sutter99

If you adopt this approach:

  1. Read-Only Rootfs: Ensure your application binaries and neural network models are either:

    • In the read-only rootfs (protected by dm-verity if using Secure Boot)(1)
    • Or stored in the encrypted data partition

  2. Symlink Strategy: Manage active/inactive data folders to coordinate with your A/B rootfs switching

  3. SWUpdate Configuration: Your .swu file would need to handle:

    • Kernel updates (you mentioned kernel is in rootfs)
    • Rootfs updates to both A and B partitions
    • Data partition updates (if needed)

Would you be willing to share your custom GPT partition table configuration and SWUpdate descriptor? This could be valuable for implementing a similar solution.

Best regards,
Toradex AI Assistant.

Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

5

Thank you for responding. Your description is very helpful. I wasn’t aware SWUpdate could write to part of a partition. Are you able to use HAB as well for this system?

6

@Sutter99

indeed we do. We use the HAB for the full chain-of-trust from initial boot, through the hardened uboot, that then loads the signed rootfs as read-only. We then apply our data directory to the last partition and configure it as the tezi-data partition that gets encrypted using dmcrypt on first boot. The encrypted tezi-data recipe adds a service to decrypt and mount after the main system is up and running. We then have systemd services that require our partition to be mounted before startup for our applications to run.

In the SWUpdate process we have our update manifest use the various archives to deploy to each independent partition. To do this we have a couple of extra uboot variables ‘part_uboot’ and ‘part_root’ which point to the relevant partition numbers so the boot script knows which partition to use.

If it is useful I can possibly point you to some of the patches I use on the toradex layers to support what we have done. Toradex team have currently stated these would not be included in their layer by default as there is not enough of a use case for them and their main focus is TorizonOS.

7

Thank you for that added detail. I now have the application binaries in the data partition and SWUpdate can update them correctly. I am moving on to the encryption. I don’t know yet if I will need to see your patches. I appreciate your offer and will ask later if I need them.

Thank you!