Jetson Orin AGX UEFI secureboot payload manual signature

Hello again,

I’ve been reading the readme file about secure boot on the Jetson, and this is how I understand the process:

In my case, the payload (kernel, rootfs, etc.) is not on the eMMC partition. What I want to do is consider a scenario where we have to change one of the payload files after already flashing, so I won’t be using the --uefi-keys option. The diagram above shows how to sign on the Jetson manually, but as you can see, the files are on the partitions of the eMMC. In my case, they are on the rootfs (specified in the extlinux.conf). So, I have two questions:

Q1: Can we modify the signature of a payload even if secure boot is already activated (efivar returns 01)? In that case, I won’t need to download the keys from the host again because I already have them on my Jetson.

Q2: How can I sign the files that are on the rootfs and not on each partition (for example, tegra243…dtb)?

Thank you!

Hi elhamriothman,

Where are your kernel, rootfs…etc stored in your case?

No, you cannot modify the signature of a payload if Secure Boot is already activated.

Please check for details.

Q1: For our case, we are storing the kernel image in the rootfs after the installation of the package nvidia-l4t-kernel, so the location is in /boot/Image.

Q2: In our scenario, it seems that the payload will undergo frequent changes, such as updates or other modifications. Therefore, the challenge arises when we need to change the signature of the payload. Since we only perform flashing once and won’t be flashing it again, do you have any suggestions or workflows to follow in order to modify the signature of the payload, even when secure boot is already activated?

Q3: Im looking at the signature script there is two one for the low leve secure boot and one for the uefi, does the flash use this script as a helper?

Note: in the readme of uefi secure boot they keep talking about the payload is extlinux.conf and other images, when I search for those payloads I find two paths that I can’t understand the difference between them there is always for each image payload, the /rootfs/boot/image and the /bootloader/image what’s the difference and purpose of each path here?

Where is your rootfs mounted?
You can share the lsblk and df -h result on your board for further check.

Do you mean that image-based OTA with secureboot enabled (by specifying PKC/SBK) not work in your case?

Yes, will be run during flash.

They seem the kernel image.

Q1: it will be mounted on the emmC for now.

Q2: no what I mean is that once we use flash to enbable secure boot with the payload X, one day we will want to modify the payload X with Y without using the flash again.

Q3: I know it’s the kernel image but why have two?

It sounds like the similar use case to use image-based OTA with secureboot enabled for future updates.

They should be the same and copied from <Linux_for_Tegra>/kernel/Image during flash.

Oh ok I see thanks can you send me the link for Q2 use case? that would be much of a help, also Im doing the secure boot without flashing meaning at run time, my question is what makes the value of secureboot in efivar turn from 00 to 01 exactly is it the enrolling of the keys?

I want to clarify with you first.
Do you mean “Secureboot” or “UEFI Secureboot”?
Secureboot is used to protect bootloader.
UEFI secureboot is used to protect UEFI payload(like kernel, initrd…etc)

UEFI Secureboot, I found out that when you update the keys when you do it at runtime via the efivar command efi-updatevar -f /uefi_keys/PK.auth PK , the value of the secureboot goes from 00 to 01 when executing the efivar -n 8be…-SecureBoot. My question now is where does the jetson store the keys when we upload them to the firmware, when we do the command efi-updatevar -f /uefi_keys/PK.auth PK where is the key stored exactly?

Also so I can understand better what is the flow of the verification of the secureboot, who is verified first and how (is it the extlinux.conf then initrd then the boot.img etc…).

For UEFI secureboot, sorry that we don’t support it in image-based OTA currently.
The only way to update is to use flash with all required key.

I see, so I can’t just modify a payload sign it with the openssl and a key for exp and modify it on the botolaoder/image? that won’t work.

Im also still wondering how theflow of verifying the signature is.


You can refer to UEFI Secureboot for details.