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)?
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?
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?
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?
