Issue Enabling UEFI Secure Boot Using UEFI Utilities on Jetson Orin

Hello,

I’m trying to enable UEFI Secure Boot on a Jetson AGX Orin following the official documentation “Enable UEFI Secure Boot Using UEFI Utilities from an Ubuntu Prompt”, but encounter permission errors:

Environment:

  • Jetson AGX Orin with JetPack 5.1.1
  • Following documentation for enabling UEFI secure boot

Current Status:
I’ve verified that Secure Boot is currently disabled and that the device is in Setup Mode:

# SecureBoot is currently disabled
$ efivar -n 8be4df61-93ca-11d2-aa0d-00e098032b8c-SecureBoot
GUID: 8be4df61-93ca-11d2-aa0d-00e098032b8c
Name: "SecureBoot"
Attributes:
	Boot Service Access
	Runtime Service Access
Value:
00000000  00                                                |.               |

# Device is in Setup Mode
$ efivar -n 8be4df61-93ca-11d2-aa0d-00e098032b8c-SetupMode
GUID: 8be4df61-93ca-11d2-aa0d-00e098032b8c
Name: "SetupMode"
Attributes:
	Boot Service Access
	Runtime Service Access
Value:
00000000  01                                                |.               |

When I try to write the DB, KEK, or PK using efi-updatevar, I get permission errors:

$ efi-updatevar -f /uefi_keys/db.auth db
Cannot write to db, wrong filesystem permissions

# Try to use sudo
$ sudo efi-updatevar -f /uefi_keys/db.auth db
Failed to update db: Invalid argument

Has anyone encountered these issues while setting up UEFI Secure Boot? Are there additional steps or permissions needed that aren’t mentioned in the documentation?

Thanks!

Hi,
If the device cannot be flashed/booted, please refer to the page to get uart log from the device:
Jetson/General debug - eLinux.org
And get logs of host PC and Jetson device for reference. If you are using custom board, you can compare uart log of developer kit and custom board to get more information.
Also please check FAQs:
Jetson AGX Orin FAQ
If possible, we would suggest follow quick start in developer guide to re-flash the system:
Quick Start — NVIDIA Jetson Linux Developer Guide 1 documentation
And see if the issue still persists on a clean-flashed system.
Thanks!

If you are on Jetpack 5.1.1 here is the Developer Guide page that on uefi secure boot.

The Jetpack Developer Guide you link to above is for r36.4 and you are on r35.3.1. I tried looking at the two side by side but can’t tell if the instructions for Orin have changed at all.

Hi carolyuu, thx for your response, but I think there might be a misunderstanding. My problem is not related to device flashing or booting failures. The issue I’m encountering is specifically with enabling UEFI Secure Boot using the UEFI utilities from an Ubuntu prompt as described in the Secure Boot documentation.

The problem occurs when I tried to use the efi-updatevar to write the security keys (db, KEK, PK). The commands failed with invalid argument:

$ efi-updatevar -f /uefi_keys/db.auth db
Cannot write to db, wrong filesystem permissions

$ sudo efi-updatevar -f /uefi_keys/db.auth db
Failed to update db: Invalid argument

You’re right that the link I shared is for r36.4, but I was actually following the JetPack 5.1.1 (r35.3.1) documentation when performing these steps. I’ve double-checked both versions, and the UEFI Secure Boot setup instructions are the same in both.

More detials with strace:

Under Regular User (efi-updatevar -f /uefi_keys/db.auth db)

openat(AT_FDCWD, "/uefi_keys/db.auth", O_RDONLY) = 3  # Successfully reads auth file
fstat(3, {st_mode=S_IFREG|0755, st_size=2401, ...}) = 0
read(3, "\351\7\2\34\16\31\0\0\0\0\0\0\0\0\0\0R\5\0\0\0\2\361\16\235\322\257J\337h\356I"..., 2401) = 2401
close(3) = 0
openat(AT_FDCWD, "/sys/firmware/efi/efivars/db-d719b2cb-3d3a-4596-a3bc-dad00e67656f", O_RDWR|O_CREAT|O_TRUNC, 0644) = -1 EACCES (Permission denied)
write(2, "Cannot write to db, wrong filesy"..., 49) = 49

The regular user can read the auth file but lacks permissions to write to EFI variables, which is expected.

First Sudo Attempt (sudo efi-updatevar -f /uefi_keys/db.auth db)

openat(AT_FDCWD, "/uefi_keys/db.auth", O_RDONLY) = 3  # Successfully reads auth file
fstat(3, {st_mode=S_IFREG|0755, st_size=2401, ...}) = 0
read(3, "\351\7\2\34\16\31\0\0\0\0\0\0\0\0\0\0R\5\0\0\0\2\361\16\235\322\257J"..., 2401) = 2401
close(3) = 0
openat(AT_FDCWD, "/sys/firmware/efi/efivars/db-d719b2cb-3d3a-4596-a3bc-dad00e67656f", O_RDWR|O_CREAT|O_TRUNC, 0644) = 3  # File opened successfully
write(3, "'\0\0\0\351\7\2\34\16\31\0\0\0\0\0\0\0\0\0\0R\5\0\0\0\2\361\16\235\322\257J"..., 2405) = -1 EINVAL (Invalid argument)
write(2, "Failed to update db: ", 21) = 21
write(2, "Invalid argument\n", 17) = 17

With sudo, the file opens successfully but the write operation fails with EINVAL. Looks like UEFI is rejecting the db.auth. Not sure if this is due to format issues or platform-specific limitations. db.auth is generated strictly following the documentation.

Sudo Again

openat(AT_FDCWD, "/uefi_keys/db.auth", O_RDONLY) = 3  # Successfully reads auth file
fstat(3, {st_mode=S_IFREG|0755, st_size=2401, ...}) = 0
read(3, "\351\7\2\34\16\31\0\0\0\0\0\0\0\0\0\0R\5\0\0\0\2\361\16\235\322\257J\337h\356I"..., 2401) = 2401
close(3) = 0
openat(AT_FDCWD, "/sys/firmware/efi/efivars/db-d719b2cb-3d3a-4596-a3bc-dad00e67656f", O_RDWR|O_CREAT|O_TRUNC, 0644) = -1 EPERM (Operation not permitted)
write(2, "Failed to update db: ", 21) = 21
write(2, "Operation not permitted\n", 24) = 24

The following sudo attempts yield EPERM rather than EINVAL. After reboot this file will be cleared and we will get Invalid argument again.

System Information

The EFI variables mount is correctly configured:

$ mount | grep efi
efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)

The system is in setup mode and secure boot is not enabled:

$ efivar -n 8be4df61-93ca-11d2-aa0d-00e098032b8c-SecureBoot
Value: 00
$ efivar -n 8be4df61-93ca-11d2-aa0d-00e098032b8c-SetupMode
Value: 01

I don’t know if this helps, but if it’s immutable then it might.

example from webpage “efi-updatevar -a -c newkey.crt -k KEK.key db”
NOT to be used on AGX Orin.

Warning: A mistake when using efi-updatevar can be quite damaging. In particular, note the -a option in the preceding example, which causes a key to be added to the list. Omitting that option causes the new key to replace all existing keys.

In practice, this command might not work immediately, even if you have the correct key files and apply them appropriately. Specifically, efi-updatevar may report Failed to update db: Operation not permitted or Cannot write to db, wrong filesystem permissions, even when run as root. The reason is that this command relies on write access to the EFI firmware variables at /sys/firmware/efi/efivars/, and most Linux distributions mount this pseudo-filesystem such that the immutable bit is set on most files, as a precaution against damage. To check the status of this bit, use the following command:

$ lsattr /sys/firmware/efi/efivars/{db,dbx,KEK,PK}*
----i--------------- /sys/firmware/efi/efivars/db-d719b2cb-3d3a-4596-a3bc-dad00e67656f
----i--------------- /sys/firmware/efi/efivars/dbx-d719b2cb-3d3a-4596-a3bc-dad00e67656f
----i--------------- /sys/firmware/efi/efivars/KEK-8be4df61-93ca-11d2-aa0d-00e098032b8c
----i--------------- /sys/firmware/efi/efivars/PK-8be4df61-93ca-11d2-aa0d-00e098032b8c

In this example, the db, dbx, KEK, and PK are all immutable, as revealed by the i character in the fifth position of each line of output. To change this setting, you can use chattr to remove the immutable flag:

chattr -i /sys/firmware/efi/efivars/KEK-8be4df61-93ca-11d2-aa0d-00e098032b8c

Note that, although you can discover the immutable flag status of most Secure Boot files (the dbx being an exception on some distributions) as an ordinary user, you can change it with chattr only as root (or using sudo). Once you’ve removed the immutable flag, it should be possible to use efi-updatevar to update the EFI variables. Once you’ve done so, I recommend re-setting the variable by using chattr with +i rather than -i. (The values will usually end up being reset when you reboot, though, so this precaution is redundant if you reboot immediately to test the changes.)

1 Like

hello ancientmodern4,

would you like to stay-on JetPack 5.1.1/L4T 35.3.1?
there’re some known issue, such as r35.3.1 does not have UEFI variable protection.
so… is it possible for moving forward to JetPack 5.1.3/L4T 35.5.0 or later public release for verification?

Hi whitesscott,

thanks for the detail response :) You are right the “operation not permitted” error is caused by the immutable attribute. After removing it with chattr -i, I can access it again.

$ sudo lsattr /sys/firmware/efi/efivars
----i--------------- /sys/firmware/efi/efivars/db-d719b2cb-3d3a-4596-a3bc-dad00e67656f
$ sudo chattr -i /sys/firmware/efi/efivars/db-d719b2cb-3d3a-4596-a3bc-dad00e67656f
$ sudo lsattr /sys/firmware/efi/efivars
-------------------- /sys/firmware/efi/efivars/db-d719b2cb-3d3a-4596-a3bc-dad00e67656f

Looks like the real issue is still Invalid argument:

$ sudo efi-updatevar -f /uefi_keys/db_1.auth db
Failed to update db: Invalid argument

I will try to regenerate the key/cert/auth files and update to later version of jetpack. thanks a lot for noticing the permission issue

Hi JerryChang, I can give it a try. Sorry for the basic question,does upgrading the JetPack version require reflashing the Jetson Orin?

Here’s a link on Managing EFI Boot Loaders for Linux: Controlling Secure Boot to a bash script that automates the creation of the secureboot keys.

please refer to Updating Jetson Linux with Image-Based Over-the-Air Update. you may upgrading the JetPack version without re-flashing,

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.