How to sign ostree commits

Technical Support
, , , , ,
1

I would like to build a secure-boot OS that uses secure dm-verity composefs to verify the rootfs. I am following along the instructions for building in yocto. But once I am done I would like to use this OS as an input to a tcbuild.yaml build. Therefore I think it is necessary for me to sign my customized ostree commit after building the OS in tcbuilder. But, I am unclear if this would actually work, and what keys I would be expected to use. I think the keys found in CFS_SIGN_KEYDIR in yocto are probably not the same keys I should use to sign ostree commits? And what about my device tree overlays – do I need to re-sign the kernel or bootloader after adding the overlays?

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.

I can help clarify the secure boot workflow and key management for your use case. Let me address your questions about building a secure-boot OS with composefs and using it with TorizonCore Builder.

Secure Boot Classes and Key Management

For building a secure-boot OS with composefs root filesystem protection, you should use the torizon-signed class in your Yocto build(1). The key configuration variables are:

  • CFS_GENERATE_KEYS = "1" - Enable composefs key pair generation at build time(1)
  • CFS_SIGN_KEYDIR = "${TOPDIR}/keys/ostree" - Directory where the composefs keys are stored(1)
  • CFS_SIGN_KEYNAME = "cfs-dev" - Base name of the key files(1)

The keys in CFS_SIGN_KEYDIR are specifically for composefs signing and are different from other signing keys in the secure boot chain(1).

Root Filesystem Protection with Composefs

When using the torizon-signed class, the root filesystem protection is based on composefs which is integrated into OSTree(1). This provides cryptographic verification of the rootfs contents. The composefs keys are used to sign the OSTree commits that contain your root filesystem(1).

Device Tree Overlays and Secure Boot

Regarding device tree overlays, you can apply them using TorizonCore Builder without needing to re-sign the kernel or bootloader(2). The overlays are applied at boot time and don’t modify the signed kernel image itself. TorizonCore Builder supports applying device tree overlays through the build command using a configuration YAML file(2):

customization:
  device-tree:
    include-dirs:
      - linux/include
    custom: linux/arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts
    overlays:
      add:
        - device-trees/overlays/colibri-imx6_hdmi_overlay.dts

(2)

Using Secure Boot OS with TorizonCore Builder

Your approach of building a secure-boot OS and then using it as input to a tcbuild.yaml should work. The OSTree commits are signed during the Yocto build process using the composefs keys, and TorizonCore Builder can work with these signed commits when you unpack and push them to the platform(3).

For the complete secure boot setup, you’ll need to follow the key generation and setup procedures for your specific hardware platform as described in the secure boot integration guide(1).

Could you specify which hardware platform and Torizon OS version you’re targeting? This will help me provide more specific guidance for your secure boot implementation.

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.

3

Thank you, but I am still wondering if I need to re-sign the bootloader and/or kernel image somehow due to the fact that I have customized the device tree overlays in my tcbuild.yaml

4

Based on the available information sources, I cannot provide a complete answer about re-signing requirements when using secure boot with TorizonCore Builder and device tree overlays.

Current TorizonCore Builder Limitations with Secure Boot

The community forum discussions indicate that TorizonCore Builder was originally designed to work with standard images and does not work well with secure-boot enabled images at the time of writing(1). As one Toradex engineer noted: “Using TorizonCore Builder to modify an image that is secure-boot enabled won’t work well at the time of writing”(1).

Device Tree Overlay Application Process

When using TorizonCore Builder, device tree overlays are applied during the build process and compiled into .dtbo files that get included in the final image(2). The overlays are applied to the device tree during boot time, but the specific signing requirements for secure boot scenarios are not detailed in the available documentation.

Recommended Approach for Secure Boot

For secure boot implementations with custom device trees, the current recommendation is to use the Yocto Project build system instead of TorizonCore Builder(1). This ensures that all components, including custom device trees and overlays, are properly integrated into the signed FIT image that maintains the chain of trust.

Missing Information

The available sources do not provide specific details about:

  • Whether device tree overlays added via TorizonCore Builder require re-signing of the bootloader or kernel
  • The exact signing workflow when combining secure boot with TorizonCore Builder customizations
  • Future plans for TorizonCore Builder support with secure boot images

I’d recommend checking the most current documentation or contacting Toradex support directly for the latest information on secure boot compatibility with TorizonCore Builder, as this appears to be an evolving area of functionality.

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

Greetings @jzylkin2,

Yes you would need to re-sign the OSTree/rootfs after making alterations to it. This is not supported yet by TorizonCore Builder. But we plan to add this functionality soon.

And what about my device tree overlays – do I need to re-sign the kernel or bootloader after adding the overlays?

Yes similarly after modifications that affect the kernel and/or bootloader, these components would need to be re-signed as well. This functionality is present in TorizonCore Builder today: https://github.com/torizon/torizoncore-builder/pull/67

However, these re-signing commands are in a bit of a beta/early-access state. This means that, while they are functional, there is little documentation on these. Also, they are subject to changing while our team continues to improve on the implementation.

Best Regards,
Jeremias