Issue while using the meta-toradex-security layer for secureboot

Hi Team,

I have been working on a project which uses the Toradex Colibri IMX6ULL SOM. I have flashed a custom Linux distro to the SOM which was built using Yocto.
Now for enabling SecureBoot feature in the SOM, I am trying to use and integrate the meta-toradex-security layer (GitHub - toradex/meta-toradex-security).

After adding the layer to the build, I provided the ‘TDX_IMX_HAB_CST_DIR’, ‘TDX_IMX_HAB_CST_CERTS_DIR’ values and also added
‘INHERIT += " tdx-signed "’ in the local.conf file.
Also I have added these 2 layers → ‘meta-openembedded/meta-perl’ and ‘meta-security’ as they were shown as dependencies.
After all this changes, on building I am getting the following error.

DEBUG: Executing shell function do_compile
NOTE: nothing to compile
grep: boot.cmd: No such file or directory
ERROR: Amendments to bootscript must be reviewed: line setting the ‘setupargs’ variable has not been found.
WARNING: exit code 1 from a shell command.

Kindly check and comment on the possible cause for this issue?

Hi, I’m the Toradex AI Assistant.

I might make mistakes. Our support team will step in if needed. If I answered your question, please tick the “Solution” checkbox. For follow-up questions to me, please use @ToradexAI in your post.

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


Hello! Thank you for reaching out with your question regarding Secure Boot integration on the Colibri iMX6ULL SOM with your custom Yocto-based Linux distribution.

The error message you encountered:

ERROR: Amendments to bootscript must be reviewed: line setting the ‘setupargs’ variable has not been found.

is related to the U-Boot hardening feature in the meta-toradex-security layer. This feature expects your boot.cmd script to follow the format used by Toradex BSP reference images, especially looking for the setupargs variable which configures kernel command-line parameters.

Since you are using a custom Linux distribution, your boot.cmd script likely does not contain this exact variable or may follow a different structure. The script amendment for Secure Boot compatibility works only if the expected patterns are present.

To resolve this issue, you have two options:

1. Disable Boot Script Amendment

You can prevent the system from trying to amend your custom boot script by adding the following line to your local.conf:

TDX_AMEND_BOOT_SCRIPT = "0"

This will skip the check and modification for setupargs in the script and allow the build to proceed with your existing boot script.

2. Make Your boot.cmd Script Compatible

Alternatively, you can modify your boot.cmd so that it includes a line defining the setupargs variable, similar to what is present in the standard Toradex boot scripts. For example:

setenv setupargs 'console=ttymxc0,115200 ...'

Ensure it matches the format expected by the scripts in the meta-toradex-security layer.


Additional notes:

  • Secure Boot on the Colibri iMX6ULL is supported specifically on the 1GB eMMC variant.
  • With tdx-signed, you’ll get bootloader and FIT image signing, but rootfs signing (e.g., with dm-verity) is not included.
  • The U-Boot hardening feature will enforce command whitelisting and prevent execution of unsigned software, among other security measures.

You can find further resources and guidance here:

Please let me know if you need more details or further assistance!

Best regards,
Toradex AI Assistant.

Hi,
Thanks for the reply.
After Disabling Boot Script Amendment, on building the image, I am getting the following error log.



  ./tools/mkimage -n u-boot.cfgout -T imximage -e 0x87800000 -d u-boot.bin u-boot.imx >u-boot.imx.log  && cat u-boot.imx.log
| Image Type:   Freescale IMX Boot Image
| Image Ver:    2 (i.MX53/6/7 compatible)
| Mode:         DCD
| Data Size:    716896 Bytes = 700.09 KiB = 0.68 MiB
| Load Address: 877ff420
| Entry Point:  87800000
| HAB Blocks:   0x877ff400 0x00000000 0x000acc00
| DCD Blocks:   0x00910000 0x0000002c 0x000001d8
| /home/user/projects/Project/build/tmp/work/my_machine-tdx-linux-gnueabi/u-boot-toradex/1_2022.07-r0/imx6_imx7_create_csf.sh -m IMX6ULL
| Verified TDX_IMX_HAB_CST_SRK=/home/user/projects/repo_clone/hab+cst_2/release/crts/SRK_1_2_3_4_table.bin
| Verified TDX_IMX_HAB_CST_CSF_CERT=/home/user/projects/repo_clone/hab+cst_2/release/crts/CSF1_1_sha256_2048_65537_v3_usr_crt.pem
| Verified TDX_IMX_HAB_CST_IMG_CERT=/home/user/projects/repo_clone/hab+cst_2/release/crts/IMG1_1_sha256_2048_65537_v3_usr_crt.pem
| Verified TDX_IMX_HAB_CST_BIN=/home/user/projects/repo_clone/hab+cst_2/release/linux64/bin/cst
| Verified IMXBOOT=/home/user/projects/Project/build/tmp/work/my_machine-tdx-linux-gnueabi/u-boot-toradex/1_2022.07-r0/build/u-boot-nand.imx
| Verified HAB_LOG=/home/user/projects/Project/build/tmp/work/my_machine-tdx-linux-gnueabi/u-boot-toradex/1_2022.07-r0/build/u-boot.imx.log
| WARNING: exit code 126 from a shell command.
ERROR: Task (/home/user/projects/Project/build/../layers/meta-toradex-bsp-common/recipes-bsp/u-boot/u-boot-toradex_2022.07.bb:do_deploy) failed with exit code '1'

Kindly check this and comment.
Thanks in Advance.

Greetings @Divakaran,

After Disabling Boot Script Amendment, on building the image, I am getting the following error

In most cases you do not need to set the TDX_AMEND_BOOT_SCRIPT yourself. This variable should be automatically set based on other variables. Only if you know what you’re doing should this variable be manually set.

I believe this is just masking the real underlying issue in your build. Based on your logs it looks like you’re on the Kirkstone version of Yocto correct?

If yes, did you make sure to clone the correct Kirkstone branch of meta-toradex-security?

Another thing to check. You said you’re building for the Colibri i.MX6ULL. What exact version of this module are you bulding for?

Do note that meta-toradex-security only has support for the 1GB eMMC variant of the Colibri i.MX6ULL. If you are building for another variant this is not supported and will probably result in issues.

Best Regards,
Jeremias

Hi
Thanks for the fast reply.

In our case, we are using Colibri iMX6ULL 512MB IT (044).
So we had been trying initially without using the ‘meta-toradex-security’ layer but were not able to successfully get the U-Boot signing done. We specifically had issues with the CSF file.
This is the community post link which we raised for those issues(Multiple HAB events found on checking 'hab_status' after signing a yocto generated Linux u-boot image)

Is there any tweak that can make ‘meta-toradex-security’ layer work for our module?
We basically need to get the U-Boot signed, either using the layer or the tool externally. What can be the solution?

In our case, we are using Colibri iMX6ULL 512MB IT (044).

Okay, so you are using another variant other than the 1GB eMMC. Unfortunately then this meta-layer will probably not work for this hardware. The signing process for raw NAND versus eMMC does differ I believe.

Is there any tweak that can make ‘meta-toradex-security’ layer work for our module?

Support would need to be added to the meta-layer, which is something we don’t have planned in the near-future. I’m not sure if it would be a simple tweak or not, it would require further investigation and testing.

We basically need to get the U-Boot signed, either using the layer or the tool externally. What can be the solution?

This thread is probably the most comprehensive discussion regarding HAB on the raw NAND imx6ull: HAB u-boot cannot boot

It’s a bit old, but there hasn’t been much more recent efforts since the raw NAND imx6ull is not often used for such use-cases.

Best Regards,
Jeremias

Thanks for the reply.

In our case, the u-boot files generated as part of build are as below:

 rw-r--r--  1 divakaranom divakaranom  683008 Jul 21 17:46 u-boot.bin
-rw-r--r--  1 divakaranom divakaranom  683008 Jul 21 16:58 u-boot.imx
-rw-r--r--  1 divakaranom divakaranom     288 Jul 21 16:58 u-boot.imx.log
-rw-r--r--  1 divakaranom divakaranom  693248 Jul 21 16:58 u-boot.imx.zero-padded
-rw-r--r--  1 divakaranom divakaranom  694272 Jul 21 16:58 u-boot-nand.imx
-rw-rw-r--  1 divakaranom divakaranom  683008 Jul 21 17:49 u-boot_padded.bin

The u-boot.imx.log is shown below:

Image Type:   Freescale IMX Boot Image
Image Ver:    2 (i.MX53/6/7 compatible)
Mode:         DCD
Data Size:    692320 Bytes = 676.09 KiB = 0.66 MiB
Load Address: 877ff420
Entry Point:  87800000
HAB Blocks:   0x877ff400 0x00000000 0x000a6c00
DCD Blocks:   0x00910000 0x0000002c 0x000001d8

With these information, kindly do:

  1. share a CSF file that works for us
  2. suggest how the files should be padded

Thanks in Advance.

A generic CSF file like so will do (of course substitute your values:

CSF Template
[Header]
    Version = 4.2
    Hash Algorithm = sha256
    Engine = SW
    Engine Configuration = 0
    Certificate Format = X509
    Signature Format = CMS

[Install SRK]
    # Index of the key location in the SRK table to be installed
    File = "@@CST_SRK@@"
    Source index = @@CST_KIDX@@

[Install CSFK]
    # Key used to authenticate the CSF data
    File = "@@CST_CSF_CERT@@"

[Authenticate CSF]

[Install Key]
    # Key slot index used to authenticate the key to be installed
    Verification index = 0
    # Target key slot in HAB key store where key will be installed
    Target index = 2
    # Key to install
    File = "@@CST_IMG_CERT@@"

[Authenticate Data]
    # Key slot index used to authenticate the image data
    Verification index = @@CST_AUTH_KIDX@@
    # Authenticate Start Address, Offset, Length and file
    # Notice that the following line will be replaced.
    Blocks = 0x877ff400 0x00000000 0x000a6c00 "u-boot.imx"

Padding should already be done by the U-Boot build. The u-boot.imx binary is the unpadded binary. Meanwhile u-boot-nand.imx is u-boot.imx with padding, it has 1024 bytes padded at the front and 10k bytes padded at the end.

However, the CSF binary needs to be concatenated in a certain offset in the binary (u-boot-nand.imx), not at the end due to the padding. This other thread goes into detail on how one can calculate the offset needed: Meta-toradex-security with NAND

Best Regards,
Jeremias

Thank you for this reply.
When we tried it taking the initial and final padding into consideration, it worked.
Now we are trying to sign and check the kernel image as well.

Glad I was able to assist.

Best Regards,
Jeremias