Hello JerryChang,
Yes, UEFI Secureboot works with the patch applied to release sources.
hello nazaraa,
thanks for sharing test results…
regarding to your questions…
>>Q1
UEFI sources and compilation details for this release are available… Home · NVIDIA/edk2-nvidia Wiki · GitHub.
>>Q2
as you can see in developer guide, Generate Signed UEFI Payloads.
the UEFI payloads have to be signed from the host and then you can download the signed payloads to target.
may I also know the real use-case for signature verification which are located in rootfs. and, let me check this internally.
Hello JerryChang,
Q1:
It is still not clear for me which branch/combo did you use to build uefi_jetson.bin provided in Jetson_Linux_R35.3.1_aarch64.tbz2. I guess it is “main” combo. Correct?
Q2:
As I can see in this developer guide a sentence above:
If the –uefi-keys option is specified during flashing, the UEFI payloads are signed automatically by the flash.sh script.
I see that payloads and their sig files were placed to /boot including extlinux.conf, but they are not used during boot. Kernel, initrd and dtb are taken from emmc partitions.
Use-case: By means of extlinux.conf it is possible to create multiple boot configurations with custom kernel, initrd, FDT and bootags and also can make backup boot configuration when updating kernel and other payloads.
Hi, i’m having the same issue. I’ve burned the fuses by following: Secure Boot — Jetson Linux Developer Guide documentation (nvidia.com)
This is my flash command:
sudo ROOTFS_ENC=1 ./flash.sh --uefi-keys uefi_keys/uefi_keys.conf --user_key $user_key -i "../../../keys/sym2_t194.key" -u $keyfile -v $sbkfile jetson-agx-xavier-devkit mmcblk0p1
it’s r35.3.1.release, this git history, Update release version to 202210.2 look identical with with my local sync.
hello riboyama,
FYI,
we’ve test locally with l4t-r35.3.1, disk encryption works normally, note, we’ve ignore UEFI secureboot at the moment.
could you please check similar topic for reference, Topic 248137.
please also follow-up Topic 248137, comment #40 to double check you’re using identical keys to burned the fuses, EKS creation, and also image flashing.
Hi JerryChang,
Diskencryption seems to be working fine. I’ve fused the board correctly I think (Secureboot enabled).
- Im using the sym2-key file for both
flash.sh -iandgen_ekb -in_sym_key2. - Im using the sym-key for
flash.sh --user-keyandgen_ekb -in_sym_key - Im using
echo "bad66eb4484983684b992fe54a648bb8" > fv_ekb_t194as fv key - The kek2 key is fused to the board, and is used with
gen_ekb - The generated eks_t194.img is copied to the Linux_for_Tegra/bootloader directory
- I’ve generated the uefi_keys according to the docs
- The commit for Secureboot on AGX is cherrypicked
However, during boot I’m getting the following:
OpenAndReadFileToBuffer: boot\extlinux\extlinux.conf failed signature verificati
on: Unsupported
ProcessExtLinuxConfig:sds Failed to Authenticate boot\extlinux\extlinux.conf (Un
supported)
L4TLauncher: Unable to process extlinux config: Unsupported
The Jetson continues to boot and will decrypt the disk and enters Ubuntu succesfully.
How can I fix these warning messages?
it should resolved by applied the patch; may I know the steps you build and update the uefi binary.
Hi Jerry,
Before the patch Secureboot enablement didn’t work, after applying the patch it did.
These are the steps I took to build the UEFI sources:
edkrepo manifest-repos add nvidia https://github.com/NVIDIA/edk2-edkrepo-manifest.git main nvidia
edkrepo clone nvidia-uefi NVIDIA-Jetson r35.3.1
git cherrypick: https://github.com/NVIDIA/edk2-nvidia/commit/dc1bb4fcc83f97f3f0500096d5b4274e43ea8def
.......
cd nvidia-uefi
edk2-nvidia/Platform/NVIDIA/Jetson/build.sh
cp uefi_jetson_release.bin Linux_for_tegra/bootloader/uefi_jetson.bin
cp BOOTAA64_release.efiLinux_for_tegra/bootloader/BOOTAA64.efi
After flashing it resulted in that extlinux.conf failed signature verification, when using the directboot option.
Using kernel boot doesn’t give the error, if I look at the sources this boot option doesn’t verify extlinux.conf.
hello riboyama,
had you generate signed UEFI payloads?
you may sign extlinux.conf using db. (i.e. Signature Database), which contains keys and/or hashes of allowed EFI binaries.
please refer to readme file, for example, $OUT/JetPack_5.1.1_Linux_JETSON_AGX_XAVIER_TARGETS/Linux_for_Tegra/tools/README_uefi_secureboot.txt
Hi Jerry,
I used sudo ./flash.sh --uefi-keys uefi_keys/uefi_keys.conf -i ... -u ... -v...
From the readme:
-) Enable UEFI Secureboot at flashing time:
*) Enable Secureboot through flash.sh during flashing
a). Use option --uefi-keys <keys_conf> to provide signing keys and enable UEFI secure boot
*) Generate signed UEFI payloads
### These steps are performed automatically by flash.sh if enabling Secureboot through flashing.
Secure Boot — Jetson Linux Developer Guide documentation (nvidia.com)
After flashing I can see that extlinux.conf and extlinux.conf.sig exist in /boot/extlinux/.
Using efi-readvar I can see that PK, KEK, and db are there.
@JerryChang I think I’ve found a bug in flash.sh…
When used in combination with ROOTFS_ENC=1, -i, and --uefi-keys. The flash script calls the disk_encryption_helper.func.
This is with disk encryption disabled, the files get signed with the --uefi-keys:
if [ "${__do_sign}" = "True" ]; then
local kernel_fs_basename;
kernel_fs_basename=$(basename "${kernel_fs}");
echo -n -e "\tgenerating signed file of ${kernel_fs_basename} ... ";
uefi_signimage "./boot/${kernel_fs_basename}" "${uefi_db_key}" "${uefi_db_cert}" "nosplit"; chkerr;
echo -n -e "\tgenerating sig file of ${dtbfilename} ... ";
uefi_signimage "./boot/dtb/${dtbfilename}" "${uefi_db_key}" "${uefi_db_cert}" "split"; chkerr;
echo -n -e "\tgenerating sig file of initrd ... ";
uefi_signimage "./boot/initrd" "${uefi_db_key}" "${uefi_db_cert}" "split"; chkerr;
echo -n -e "\tgenerating sig file of extlinux.conf ... ";
# Signing tool will pad extlinux.conf with 0x80 to be 16-byte aligned.
# This pad byte of 0x80 may cause some utilities fail to read the entire
# extlinux.conf.
# So, pad extlinux.conf to 16-byte aligned with linefeed.
pad_file_aligned "./boot/${_extlinux_conf}" 16 "\x0a";
uefi_signimage "./boot/${_extlinux_conf}" "${uefi_db_key}" "${uefi_db_cert}" "split"; chkerr;
fi
If you enable disk encryption in combination with --uefi-keys (so -i … --uefi-keys …), the script will use the following function to sign kernel, extlinux, etc… I think this is leftover code from when cboot was still used?
See: uefi_signimage vs. signimage
if [ "${__do_sign}" = "True" ]; then
local kernel_fs_basename;
kernel_fs_basename=$(basename "${kernel_fs}");
echo -n -e "\tgenerating sig file of ${kernel_fs_basename} ... ";
signimage "./${kernel_fs_basename}" "True" "kernel" "${minratchet_configname}"; chkerr;
echo -n -e "\tgenerating sig file of ${dtbfilename} ... ";
signimage "./dtb/${dtbfilename}" "True" "kernel_dtb" "${minratchet_configname}"; chkerr;
echo -n -e "\tgenerating sig file of initrd ... ";
signimage "./initrd" "True" "data"; chkerr;
echo -n -e "\tgenerating sig file of ${_extlinux_conf} ... ";
# Signing tool will pad extlinux.conf with 0x80 to be 16-byte aligned.
# This pad byte of 0x80 may cause some utilities fail to read the entire
# extlinux.conf.
# So, pad extlinux.conf to 16-byte aligned with linefeed.
pad_file_aligned "${_extlinux_conf}" 16 "\x0a";
signimage "${_extlinux_conf}" "True" "data"; chkerr;
fi
This results in that the UEFI firmware cannot verify the extlinux.conf, because the generated .sig file is in an invalid format.
A workaround is to follow: enabling-uefi-secureboot-through-uefi-utilities-by-running-from-an-ubuntu-promp (nvidia.com).
However, I’m not sure if using an encrypted extlinux.conf (supplying --user-key to flash.sh) interveres with this. I’ll test it at a later date.
I’ve edited the disk_encryption_helper.func script:
if [ "${__do_sign}" = "True" ]; then
local kernel_fs_basename;
kernel_fs_basename=$(basename "${kernel_fs}");
echo -n -e "\tencrypt of ${kernel_fs_basename} ... ";
signimage "./${kernel_fs_basename}" "False" "kernel" "${minratchet_configname}"; chkerr;
echo -n -e "\tgenerating signed file of ${kernel_fs_basename} ... ";
uefi_signimage "./${kernel_fs_basename}" "${uefi_db_key}" "${uefi_db_cert}" "nosplit"; chkerr;
echo -n -e "\tencrypt ${dtbfilename} ... ";
signimage "./dtb/${dtbfilename}" "False" "kernel_dtb" "${minratchet_configname}"; chkerr;
echo -n -e "\tgenerating sig file of ${dtbfilename} ... ";
uefi_signimage "./dtb/${dtbfilename}" "${uefi_db_key}" "${uefi_db_cert}" "split"; chkerr;
echo -n -e "\tencrypt initrd ... ";
signimage "./initrd" "False" "data"; chkerr;
echo -n -e "\tgenerating sig file of initrd ... ";
uefi_signimage "./initrd" "${uefi_db_key}" "${uefi_db_cert}" "split"; chkerr;
echo -n -e "\tencrypt ${_extlinux_conf} ... ";
# Signing tool will pad extlinux.conf with 0x80 to be 16-byte aligned.
# This pad byte of 0x80 may cause some utilities fail to read the entire
# extlinux.conf.
# So, pad extlinux.conf to 16-byte aligned with linefeed.
pad_file_aligned "${_extlinux_conf}" 16 "\x0a";
signimage "${_extlinux_conf}" "False" "data"; chkerr;
echo -n -e "\tgenerating sig file of extlinux.conf ... ";
uefi_signimage "${_extlinux_conf}" "${uefi_db_key}" "${uefi_db_cert}" "split"; chkerr;
fi
Upon further looking at flash.sh:
--user_key <key_file> User provided key file (16-byte) to encrypt user images,
like kernel, kernel-dtb and initrd.
If user_key is specified, SBK key (-v) has to be specified.
**For now, user_key file must contain all 0's.**
It seems that --user_key is unsupported in Jetpack 5… This shouldnt really be an issue except for that kernel, kernel-dtb, initrd and extlinux.conf can’t be encrypted.
Now for setting up rootfs encryption with UEFI Secureboot:
For gen_ekb I’ve done echo "00000000000000000000000000000000" > sym_t194.key
The sym_key should be the --user-key, not supplying the --user-key will set it to zeros in flash.sh
The final command to flash:
sudo ROOTFS_ENC=1 ./flash.sh --uefi-keys uefi_keys/uefi_keys.conf -i $sym2file -u $keyfile -v $sbkfile jetson-agx-xavier-devkit mmcblk0p1
hello riboyama,
just for confirmation,
did you meant given user_key (all zero user_key) into flash commands workaround the issue?
and, you’re able to boot-up the target with… PKC + SBK + DiskEncryption + UEFI secureBoot?
hello riboyama,
it turns out there’s an issue with --user_key.
FYI,
the option --user_key is only supported with JP-4.x to encrypt/decrypt user images, such as kernel/kernel-dtb.
however, this options is no longer supported with JP-5.x, it will be replace by --uefi-enc options, and it’ll be available by the next JP-5 release, i.e. Jetpack-5.1.2 release version.
Hello JerryChang,
Let me try to clarify a bit…
Im now using the following command to flash sudo ROOTFS_ENC=1 ./flash.sh --uefi-keys uefi_keys/uefi_keys.conf -i $sym2file -u $keyfile -v $sbkfile jetson-agx-xavier-devkit mmcblk0p1.
and, you’re able to boot-up the target with… PKC + SBK + DiskEncryption + UEFI secureBoot?
Yes. BUT:
If you use --uefi-keys and -i with flash.sh, there will be an issue signing the UEFI payloads, flash.sh is broken.
How did I fix flash.sh?
Since -i is supplied to flash.sh, the script will use a different function to sign the UEFI payloads (extlinux, initrd, etc) .
signimage is used instead of uefi_signimage, this will sign (and encrypt…) the payloads with the wrong key (it will use tegraflash to encrypt and sign the images, instead of using the db_key).
As shown in my previous reply, by replacing the signimage calls with uefi_signimage, flash.sh will successfully flash the target with PKC + SBK + Disk Encryption + UEFI Secureboot.
I think in Jetpack 5.1.2 with --uefi-enc this will be fixed correctly… However, this manual edit of flash.sh is currently the workaround for Jetpack 5.1.1.
Hello Riboyama,
Thank you so much for your help I try your fix it seems better I have Skipped - USER_MODE but I have always
** WARNING: Test Key is used. ** how to remove that ?
If we have our key It great to remove ** WARNING: test Key is used. ** no ? and EnrollFromDefaultKeysApp: Skipped - User mode too ?
Best regards,
Julien.
Hi Julien,
I also still have the ‘Warning test key used’…
To remove, edit the following files from the uefi sources:
# nvidia-uefi/edk2/MdeModulePkg/Universal/BdsDxe/BdsEntry.c#945
// Print (L"** WARNING: Test Key is used. **\n");
# nvidia-uefi/edk2/SecurityPkg/EnrollFromDefaultKeysApp/EnrollFromDefaultKeysApp.c#51
// AsciiPrint ("EnrollFromDefaultKeysApp: Skipped - USER_MODE\n");
The other messages are from the kernel, you would need to edit efi_stub.c in the kernel sources to remove these
By the way, did you edit the flash script? I don’t get the EFI stub: UEFI Secure Boot is enabled message. If you did, would you mind sharing your edit?
Hi,
Thank you when I have resolved my first issue EKS bad parametter I will try to recompile the UEFI binary to remove some message. Thanks.
I’ve edited only the disk_encryption_helper.func like you explain in your post :
My uefi_keys folder is like that :
Generate the PK, KEK, db RSA keypairs and certificates
To generate the PK, KEK, and db RSA keypairs and certificates, run the following commands:
$ cd to <LDK_DIR>
$ mkdir uefi_keys
$ cd uefi_keys
### Generate PK RSA keypair and certificate
$ openssl req -newkey rsa:2048 -nodes -keyout PK.key -new -x509 -sha256 -days 3650 -subj "/CN=my Platform Key/" -out PK.crt
### Generate KEK RSA keypair and certificate
$ openssl req -newkey rsa:2048 -nodes -keyout KEK.key -new -x509 -sha256 -days 3650 -subj "/CN=my Key Exchange Key/" -out KEK.crt
### Generate db_1 RSA keypair and certificate
$ openssl req -newkey rsa:2048 -nodes -keyout db_1.key -new -x509 -sha256 -days 3650 -subj "/CN=my Signature Database key/" -out db_1.crt
### Generate db_2 RSA keypair and certificate
$ openssl req -newkey rsa:2048 -nodes -keyout db_2.key -new -x509 -sha256 -days 3650 -subj "/CN=my another Signature Database key/" -out db_2.crt
I am on JetPack 5.1.1 and I NOT RECOMPILE the uefi I use the one by default with the release you could try maybe you have and issue with your compilation ?
That help you ?
Best regards,
Julien.