Generating signature for initrd and verifying using cboot

Autonomous Machines Jetson & Embedded Systems Jetson AGX Xavier
,
1

Hi,

I am using L4T 32.4.2 for secure boot on Xavier. I generated the mass flash blob using the steps indicated. I see that the kernel and the kernel dtb are signed. I also need to get the initrd signed. I see that there is a sample l4t_initrd.img provided in the bootloader directory of L4T. How do I go about including the initrd, so that the scripts can pick it up and generate the required signature? I am assuming that cboot will take care of the verification once the signature is generated.

Is there a upper limit on the size of the initrd that cboot can verify?

Thanks and Regards
Rayees

3

hello rayees.shamsuddin,

you may also refer to Boot Flow.
there’re loading and authentication flow for MB1, and copies MB1 into SysRAM.
MB2 also had similar flows for authentication, but MB1 copy it into DRAM. after that, BPMP-FW own the controls.

there’s hardware crypto security engine key slot for storing SBK, KEK, SSK…etc.
it’s flash script to handle sign and encryption; you may enable secureboot and check the flashing messages.
for example,

[   3.1481 ] PKC key in Open SSL format
[   3.1484 ] Key size is 256 bytes
[   3.1485 ] Valid PKC key
[   3.1486 ] Saving pkc public key  in pub_key.key
[   3.2069 ]
[   3.2097 ] tegrahost_v2 --updatesigheader cboot_sigheader.bin.encrypt.signed cboot_sigheader.bin.encrypt.sig oem-rsa --pubkeyhash pub_key.key
[   3.2135 ]
[   3.2170 ] tegrahost_v2 --chip 0x18 --align cboot_sigheader.bin.encrypt
[   3.2192 ]
[   3.2218 ] tegrasign_v2 --key /home/linuxdev/Nvidia/Linux_for_Tegra/rsa_priv.pem --pubkeyhash pub_key.key --list cboot_sigheader.bin.encrypt_list.xml
4

Jerry,

I generated the flash blob and in the xml file(secureflash.xml), I have the following, which contains the signed kernel and the signed dtb. My question is with regards to how do I get the initrd signed by the secure-boot scripts. Do I need to do something to enable this? I would appreciate if you could give me the detailed steps to do so. Let us assume that we have the “l4t_initrd.img” as the initrd - what changes do I have to make to get this initrd image included in the signature?

<partition name="kernel" oem_sign="true" type="data">

            <allocation_policy> sequential </allocation_policy>

            <filesystem_type> basic </filesystem_type>

            <size> 83886080 </size>

            <file_system_attribute> 0 </file_system_attribute>

            <allocation_attribute> 8 </allocation_attribute>

            <percent_reserved> 0 </percent_reserved>

            <filename> boot_sigheader.img.signed </filename>

            <description> **Required.** Slot A; contains the Linux kernel. </description>

        </partition>

        <partition name="kernel_b" oem_sign="true" type="data">

            <allocation_policy> sequential </allocation_policy>

            <filesystem_type> basic </filesystem_type>

            <size> 83886080 </size>

            <file_system_attribute> 0 </file_system_attribute>

            <allocation_attribute> 8 </allocation_attribute>

            <percent_reserved> 0 </percent_reserved>

            <filename> boot_sigheader.img.signed </filename>

            <description> **Required.** Slot B; contains the Linux kernel. </description>

        </partition>

        <partition name="kernel-dtb" oem_sign="true" type="data">

            <allocation_policy> sequential </allocation_policy>

            <filesystem_type> basic </filesystem_type>

            <size> 524288 </size>

            <file_system_attribute> 0 </file_system_attribute>

            <allocation_attribute> 8 </allocation_attribute>

            <percent_reserved> 0 </percent_reserved>

            <filename> tegra194-p2888-0001-p2822-0000_sigheader.dtb.signed </filename>

            <description> **Required.** Slot A; contains kernel device tree blob. </description>

        </partition>

        <partition name="kernel-dtb_b" oem_sign="true" type="data">

            <allocation_policy> sequential </allocation_policy>

            <filesystem_type> basic </filesystem_type>

            <size> 524288 </size>

            <file_system_attribute> 0 </file_system_attribute>

            <allocation_attribute> 8 </allocation_attribute>

            <percent_reserved> 0 </percent_reserved>

            <filename> tegra194-p2888-0001-p2822-0000_sigheader.dtb.signed </filename>

            <description> **Required.** Slot B; contains kernel device tree blob. </description>

        </partition>
5

hello rayees.shamsuddin,

it seems to me that secureboot did not sign initrd, and you don’t need extra step to get the initrd included.
for example, during the flash process…

copying initrd($OUT/Linux_for_Tegra/bootloader/l4t_initrd.img)... done.
    populating kernel to rootfs... done.
    populating initrd to rootfs... done.
    populating extlinux.conf.emmc to rootfs... done.

please also have to modify configuration files entries for customization.
for example,

$OUT/Linux_for_Tegra/bootloader/extlinux.conf
...

LABEL primary
      MENU LABEL primary kernel
      LINUX /boot/Image
      INITRD /boot/my_initrd
      APPEND ${cbootargs}
6

Jerry,

Thanks for your reply. I also see that the initrd is copied to rootfs. I want to understand specifically if the signature that is generated - “boot_sigheader.img.signed” is done over the kernel or the entire system.img (which is the compressed version of the rootfs and which contains the initrd). If the signature is done only over the kernel, then I need to have another mechanism to extend the secure boot chain from the kernel to the rootfs. Could you please confirm this? Also, if the rootfs signature is not verified, is there a way I can extend cboot to do this verification?

Thanks and Regards
Rayees

7

hello rayees.shamsuddin,

please refer to Security chapter.
there’re secureboot for protecting Jetson Linux boot process; and trusty to make a secure environment.

please refer to Trusty, a Trusted Execution Environment chapter for more details of security features to ensure code and data on a device is protected.
thanks