Secure Boot
Applies to: Jetson Xavier NX series, original Jetson Nano, Jetson AGX Xavier series, Jetson TX2 series, and Jetson TX1 only
NVIDIA® Jetson™ Linux Driver Package (L4T) provides boot security using the Secure Boot package. Secure Boot prevents execution of unauthorized boot codes through chain of trust. The root-of-trust is on-die BootROM code that authenticates boot codes such as BCT, Bootloader, and warm boot vector using Public Key Cryptography (PKC) keys stored in write-once-read-multiple fuse devices. On Jetson platforms that support Secure Boot Key (SBK), you can use it to encrypt Bootloader images.
Fuses and Security
NVIDIA SoCs contain multiple fuses that control different items for security and boot. Once a fuse bit is set to 1, you cannot change its value back to 0. For example, a fuse value of 1 (0x01) can be changed to 3 (0x03) or 5 (0x05), but not to 4 (0x4) because bit 0 is already programmed to 1.
Once odm_production_mode is fused with a value of 0x1, all further fuse write requests are blocked and the fused values are available through the provided API. However, the odm_reserved and odm_lock fields are still writable until odm_lock bit is programmed by changing the value of the bit from 0 to 1.
Although SoC fuses are writable, you must use the odmfuse.sh script to program these fuses: public_key_hash, pkc_disable (T210 only), secure_boot_key, and odm_production_mode.
The following two tables describe user-programmable fuses related to Secure Boot.
Secure Boot fuses for
Jetson Nano and Jetson TX1 (T210 processor) |
Bit size | Name | Default value set by odmfuse.sh |
1 | odm_production_mode | 0x1 |
256 | public_key_hash | RSA public key hash |
Software and configuration fuses related to Secure Boot for
Jetson Xavier NX series and Jetson AGX Xavier series (T194)
and Jetson TX2 series (T186) |
Bit size | Name | Default value set by odmfuse.sh |
1 | odm_production_mode | 0x1. |
256 | public_key_hash | RSA public key hash. |
128 | secure_boot_key * | Secure Boot Key (SBK): AES encryption key for encrypting bootloader. |
128 | KEK0 * | Four 32‑bit registers named KEK00 through KEK03. |
128 | KEK1 * | Four 32‑bit registers named KEK10 through KEK13. |
256 | KEK256 | Not a distinct fuse; addresses KEK0 and KEK1 as a single 256‑bit fuse. |
128 | KEK2 * | Four 32‑bit registers named KEK20 through KEK23. |
* You may use secure_boot_key or the three Key Encryption Keys with different combinations of width as a key seed to encode keys. For example, KEK2 can be used as a key seed to encrypt and decrypted the Encrypted Key Blob (EKB) when TOS is enabled. |
Fuses that are handled by the user are as follows:
Bit size | Name | Default value set by odmfuse.sh |
1 | jtag_disable | 0x0: JTAG is enabled (the default). 0x1: JTAG is disabled. |
256 | odm_reserved | Programmable fuses at the user’s direction. However, 32 MSB are reserved for NVIDIA use. |
4 | odm_lock | Each bit set disables the write for the corresponding 32-bit ODM fuses. For example: 0x2 locks bits 32−63 of odm_reserved. |
14 | sec_boot_dev_cfg | Depending on sec_boot_dev_sel, each bit has a different meaning. |
8 | sw_reserved | A bit map of configuration options. Bits not described here are reserved. Bits 2-0: sec_boot_dev_sel. Meaningful only if ignore_dev_sel_straps is enabled: 0=eMMC, 1=SPI. Bit 3: ignore_dev_sel_straps. 1=Ignore device selection boot strap. Bit 5: enable_watchdog. Bit 23: 1=disable RCM mode (T194 only). |
For details on hardware fuses and fuse names, consult the following documents:
The following two tables describe the fuse name aliases recognized by tegraflash.
Fuse Name Aliases Recognized by tegraflash for T210 |
|---|
Name | tegraflash Alias & Notes |
|---|
odm_production_mode | SecurityMode |
public_key_hash | PublicKeyHash |
pkc_disable | PkcDisable |
secure_boot_key | SecureBootKey |
device_key | DeviceKey |
jtag_disable | JtagDisable |
odm_reserved | ReservedOdm |
odm_lock | OdmLock |
sec_boot_dev_cfg | SecBootDeviceSelect |
sw_reserved | SwReserved |
Fuse Name Aliases Recognized by tegraflash for T186 and T194 |
|---|
Name | tegraflash Alias & Notes |
|---|
odm_production_mode | SecurityMode |
public_key_hash | PublicKeyHash |
secure_boot_key | SecureBootKey |
Security_info | BootSecurityInfo |
Key_encryption_key_0 | Kek0 |
Key_encryption_key_1 | Kek1 |
Key_encryption_key_256 | Kek256 |
Key_encryption_key_2 | Kek2 |
jtag_disable | JtagDisable |
odm_reserved0, odm_reserved1,… odm_reserved7 | ReservedOdm0, ReservedOdm1,… ReservedOdm7 Customer programmable fuses; remain programmable after FUSE_SECURITY_MODE has been programmed. Default value (when no Reserved ODM fuses have been programmed) is all zeros. One intended application of these fuses is software version revocation. You may use them for other purposes at your discretion. |
odm_reserved8,… odm_reserved11 | ReservedOdm8,… ReservedOdm11 (T194 only) Reserved for use by NVIDIA. Do not use these fuses. Customer programming of these can result in boot failures and unexpected behavior. |
odm_lock | OdmLock Each bit disables further changes to one of the ReservedOdm fuses. Only the first four ReservedOdm fuses can be disabled by this means. • OdmLock[0] disables ReservedOdm0 • OdmLock[1] disables ReservedOdm1 • OdmLock[2] disables ReservedOdm2 • OdmLock[3] disables ReservedOdm3 |
sec_boot_dev_cfg | SecBootDeviceSelect |
sw_reserved | SwReserved |
Overall Fusing and Signing Binaries Flow
The Secure Boot process with PKC (and SBK) requires you to:
• Install the Secure Boot package.
• If necessary, prepare the DK(KEK), SBK, and ODM fuse values.
• Generate the RSA key-pair.
• Prepare the SBK key (if using the flash.sh ‑v option).
• Prepare the user key (if using the flash.sh ‑‑user_key option).
• Burn DK(KEK), ODM fuses, the PKC/SBK, security information, and odm_production_mode fuses.
• Sign the boot image files with PKC (and SBK).
• Flash the signed boot image files.
Note: | The odm_production_mode fuse is burned to protect the SoC device from erroneous ODM production fuse burning. The ODM_RESERVED and ODM_LOCK fuses remain writable until the ODM_LOCK bit is burned. |
Installing the Secure Boot Package
Prerequisites
• X86 host running Ubuntu 16.04 or 18.04 LTS
• libftdi-dev for USB debug port support
• openssh-server package for OpenSSL
• Full installation of the latest L4T release on the host
Download the latest release from the NVIDIA Developer site’s
Jetson Linux page.
• The NVIDIA® Jetson™ platform is connected to the host with a USB cable
• Debug serial port is connected to the host, if necessary
To install Secure Boot
1. Download the version of the Secure Boot package for your platform and release of Jetson Linux from the release page.
The URL of the release page has the form:
https://developer.nvidia.com/embedded/linux-tegra-r<rel>
Where <rel> is the Jetson Linux release number with dots removed. For example the last segment of the URL for Jetson Linux release 32.6.1 is linux-tegra-r3261.
2. Go to the directory that contains the Linux_for_Tegra directory. (This directory is created when the Jetson Board Support Package is installed.)
3. Enter this command to untar the downloaded file:
tar xvjf secureboot_<release_version>.tbz2
This command overlays the contents of the file on the Linux_for_Tegra directory.
Generating the RSA Key Pair
Secure Boot requires an RSA key-pair whose length is 2048 bits (RSA 2K) or 3072‑bits (RSA 3K).
Note: | The 3072-bit RSA key option is supported only on Jetson Xavier NX series and Jetson AGX Xavier series platforms. |
To generate a key-pair
1. Execute one of these commands.
• To generate an RSA 2K key:
$ openssl genrsa -out rsa_priv.pem 2048
• To generate an RSA 3K key:
$ openssl genrsa -out rsa_priv.pem 3072
Upon successful execution, OpenSSL generates the key file named rsa_priv.pem.
2. Rename and save the key file securely and safely.
The key file is used to burn fuses and sign boot files for Jetson devices. The security of your device depends on how securely you keep the key file.
To ensure the security of the key file, restrict access permission to a minimum number of personnel.
Note: | To generate a truly random number key, use the Hardware Security Module (HSM). Consult the Hardware Security Module User Guide for output format and private key conversion to PEM format. |
Preparing the SBK Key
Applies to: Jetson Xavier NX series, Jetson AGX Xavier series, and Jetson TX2 series
If you want to encrypt Bootloader (and TOS), you must prepare the SBK fuse bits.
Note: | You may only use the SBK key with the PKC key. The encryption mode that uses these two keys together is called SBKPKC. |
The SBK key consists of four 32-bit words stored in a file in big-endian hexadecimal format. Here is an example of an SBK key file:
0x12345678 0x9abcdef0 0xfedcba98 0x76543210
The representation in the fusing XML file is:
0x123456789abcdef0fedcba9876543210
Preparing the User Key
Applies to: Jetson Xavier NX series, Jetson AGX Xavier series, and Jetson TX2 series
If you want to encrypt kernel images (the kernel, kernel-dtb, initrd, and extlinux.conf files), you must prepare the user key. You need the user key as well as the SBK key and the PKC key.
The user key is stored in the Encrypted keyblob (EKB) in encrypted form. The Secure Engine (SE) retrieves the user key from the EKB and uses it to decrypt the kernel image files.
For information about how the EKB is generated, see
EKB Generation in the topic
Trusty, a Trusted Execution Environment.
You must use the same user key in flash.sh to encrypt kernel images. That script flashes the EKB to the target along with the encrypted kernel images. The EKB is flashed to the EKS partition.
The user key must be specified in two different formats for different purposes:
• For use in the ‑‑user_key command line option of the flash.sh command, it is a file containing four big-endian 32‑bit words stored as four 8‑digit hexadecimal numbers. (The ‑‑user_key option specifies the pathname of this file.) Here is an example of a user key in this format:
0x12345678 0x9abcdef0 0xffeeddcc 0xbbaa9988
• For use in generating the EKB, it is a file containing 32 hexadecimal digits that represent the same key, interpreted as a single big-endian 128‑bit value. Here is an example:
123456789abcdef0ffeeddccbbaa9988
Preparing the DK(KEK)/ODM Fuses
If you want to use another security application, you must prepare the DK(KEK) and other ODM fuse bits as described in the documentation for the other security application.
Name | Description |
|---|
DK | A 32-bit number stored in a file in big-endian HEX format. Applies to: Jetson Nano and Jetson TX1 Example: 0xddccbbaa |
KEK0 KEK1 KEK2 | A 128-bit number stored in a file in big-endian HEX format. Applies to: Jetson Xavier NX series, Jetson AGX Xavier series, and Jetson TX2 series |
KEK256 | A 256-bit number stored in a file in big-endian HEX format. Applies to: Jetson Xavier NX series, Jetson AGX Xavier series, and Jetson TX2 series |
ODM Fuse Bits | To use applications other than Secure Boot, additional ODM fuse bits may be required. The specific fuse information differs depending on the application being used. Consult the user guide for the application being used. |
Note: | Hexadecimal numbers must be presented in big-endian format. The leading 0x or 0X may be omitted. The Jetson Secure Boot software converts big-endian hexadecimal format to the format that the Jetson device expects. All standard OpenSSL utilities output in big-endian format. |
Burning PKC [DK(KEK), SBK] Fuses
The steps for burning PKC, DK, and SBK fuses using a private key file PEM format are as follows.
To burn PKC fuses
1. Navigate to the directory where you installed L4T.
2. Put the Jetson device into Forced Recovery Mode.
Note: | odmfuse.sh uses OpenSSL to burn PKC fuses. |
odmfuse.sh Options
For fuses other than PKC key and odm_production_mode fuses, odmfuse.sh allows you to program ODM fuses that are completely under your discretion. Skip this topic if you do not plan to modify these fuses.
The odmfuse.sh command line options that blow some ODM fuses are as follows:
Option | Description |
-d 0xXXXX | Sets sec_boot_dev_cfg=<value>&0x3fff. For detail, refer to TRM. |
-disable-jtag | Disables JTAG. Use this option to block use of the JTAG debugger. |
-l 0xX | Sets odm_lock to the specified value. Setting each bit locks (makes read-only) the corresponding 32‑bit word in the odm_reserved field. For example, setting odm_lock to 0x1 locks the first 32‑bit word of odm_reserved. Setting odm_lock to 0x5 locks the first and third 32‑bit words of odm_reserved, and so on. |
-o <value> Applies to: Jetson Nano devices and Jetson TX1 only | Sets odm_reserved to the specified value. The value must be a quoted 256‑bit (64‑digit) hexadecimal number in the form "0xnnnn… nnnn". The last 32 bits (eight digits) must be all zero because these bits are reserved for use by NVIDIA. |
--odm_reserved[0–7] Applies to: Jetson Xavier NX series, Jetson AGX Xavier series, and Jetson TX2 series only | Sets odm_reserved[n] to the specified value. The value must be a quoted 32‑bit (eight-digit) hexadecimal number in the form 0xnnnnnnnn. |
-p | Sets production mode. |
-r 0xXX | Sets sw_reserved=0xXX. The bit definitions are: Bits 7-6: Reserved. Bit 5: Enable_watchdog. Bit 4: Reserved. Bit 3: ignore_dev_sel_straps: Ignore device selection boot strap. Bits 2-0: sec_boot_dev_sel: Boot device: 0=eMMC, 1=SPI. |
-D <DK_file> Applies to: Jetson Nano devices and Jetson TX1 | Sets the Device Key to be used by the high-level security application to generate the application encryption keys. The content of <DK_file> must be a single 32-bit big endian HASH in HEX format. |
-S <SBK_file> | Sets the Secure Boot Key used to encrypt Bootloader and TOS. The content of <SBK_file> must be four 32‑bit big-endian numbers in hexadecimal format. For Jetson Xavier NX series, Jetson AGX Xavier series, and Jetson TX2 series, this key must be used along with PKC key. For Jetson TX1 and Jetson Nano, this key must be used along with PKC key and pkc_disable = 0. This key will not be used to encrypt Bootloaders, it can be used by the high-level application as encryption key. |
--noburn | Prepares the fuse blob to be used repeatedly on the factory floor. This option generates Linux_for_Tegra/fuseblob.tbz2, which can be downloaded and untarred in the Linux_for_Tegra directory of a factory host. After fuseblob.tbz2 is untarred in the Linux_for_Tegra directory, Linux_for_Tegra/bootloader/fusecmd.sh is used to burn fuses repeatedly instead of the standard odmfuse.sh. |
--KEK0 --KEK1 --KEK2 <path> Applies to: Jetson Xavier NX series, Jetson AGX Xavier series, and Jetson TX2 series | Pathname of the Key Encryption Key file that other security applications are to use to encrypt/decrypt keys. The content of the file must be a single 128-bit big-endian number in hexadecimal format. |
--KEK256 <path> Applies to: Jetson Xavier NX series, Jetson AGX Xavier series, Jetson TX2 series | Pathname of the 256-bit Key Encryption Key file that the high-level security application will use to encrypt the application keys. The content of the file must be a single 256-bit big-endian number in hexadecimal format. |
--auth Applies to: Jetson Xavier NX series, Jetson AGX Xavier series, and Jetson TX2 series | Sets the authentication status of the board. Possible values are: NS (Non-Secure), PKC, and SBKPKC. Use this option only when running odmfuse.sh with no boards connected (i.e. in offline mode). To run odmfuse.sh in offline mode: 1. Use --noburn on the command line. 2. Specify the carrier board by setting these environment variables on the command line. You can get the appropriate values from the Jetson module’s EEPROM as described in the topic Jetson Module EEPROM Layout. • BOARDID: Use the value of the “Board number” field. • FAB: Use the value of the “FAB number” field. • BOARDSKU: Use the value of the “SKU number” field. • BOARDREV: Use the values of the “major revision” and “minor revision” fields, separated by a period. For example: sudo FAB=400 BOARDID=2888 BOARDSKU=0006 BOARDREV=B.0 ./odmfuse.sh --noburn -i 0x19 --auth SBKPKC -p -k <pkc> --KEK2 <kek2> -S <sbk> jetson-xavier-8gb |
--test | Prevents the script from actually burning fuses. Pre-burn processing and tests are performed as usual. This option is normally used for fuse burning tests, since fuse values cannot be changed once they are burned. |
Non-Destructive Testing for Fuse Burning Operations
Fuse burning operations are high-risk because they can’t be reversed. NVIDIA strongly recommends that you use the ‑‑test option to verify fuse burning operations before you perform them.
When you add ‑‑test to an odmfuse.sh command, the command performs pre-burn processing and verification, but does not actually burn the fuse. If the command reports the results you want, you can re-enter the command without ‑‑test and burn the fuse with greater confidence that you are doing it correctly.
odmfuse.sh Option Examples
• To burn a secure fuse with PKC only (Jetson Nano devices and Jetson TX1 only):
sudo ./odmfuse.sh -i <chip_id> -c PKC -k <PKC file>
• To fuse PKC HASH from the .pem file with JTAG enabled:
For Jetson Nano devices and Jetson TX1:
$ sudo ./odmfuse.sh -i <chip_id> -c PKC -p -k <key.pem> [-D <DK_file>]
For Jetson Xavier NX series, Jetson AGX Xavier series, and Jetson TX2 series:
$ sudo ./odmfuse.sh -i <chip_id> -p -k <key.pem> --KEK[0-2] <KEK file> -S <SBK_file> > <device_name>
• To fuse PKC HASH from the .pem file with JTAG disabled:
For Jetson Nano devices and Jetson TX1:
$ sudo ./odmfuse.sh -i <chip_id> -c PKC -p -k <key.pem> [-D <DK_file>] --disable-jtag
For Jetson Xavier NX series, Jetson AGX Xavier series, and Jetson TX2 series:
$ sudo ./odmfuse.sh -i <chip_id> -p -k <key.pem> --KEK[0-2] <KEK file> -S <SBK_file> --disable-jtag <device_name>
• To burn a secure fuse with PKC, SBK, and KEK2 (Jetson Xavier NX series, Jetson AGX Xavier series, and Jetson TX2 series only):
sudo ./odmfuse.sh -i <chip_id> -k <PKC file> -S <SBK file> --KEK2 <KEK2 file> <device_name>
• To burn a secure fuse with PKC and KEK2 (Jetson Xavier NX series, Jetson AGX Xavier series, and Jetson TX2 series only):
sudo ./odmfuse.sh -i <chip_id> -k <PKC file> --KEK2 <KEK2 file> <device_name>
• To burn a secure fuse with PKC and encryption service preparation (Jetson Nano devices and Jetson TX1 only):
sudo ./odmfuse.sh -i <chip_id> -c PKC -k <PKC file> -D <DK_file>
• To protect ODM production fuse with JTAG enabled (T210 only):
$ sudo ./odmfuse.sh -i <chip_id> -c NS -p
• To protect ODM production fuse with JTAG disabled (T210 only):
$ sudo ./odmfuse.sh –disable-jtag -i <chip_id> -c NS -p
Where:
• <chip_id> is:
• For Jetson Xavier NX series: 0x19
• For Jetson Nano (production module only): 0x21
• For Jetson Nano (4 GB development module only): 0x21
• For Jetson AGX Xavier series: 0x19
• For Jetson TX2 series: 0x18
• For Jetson TX1: 0x21
• <device_name> is the device name of the Jetson platform you are using, as shown in the
table of device names in the topic
Quick Start. This placeholder is not used for Jetson Nano devices or Jetson TX1.
• For Jetson Xavier NX series: jetson-xavier-nx-devkit-emmc
• For Jetson AGX Xavier series: jetson-agx-xavier-devkit
• For Jetson TX2 series: jetson-tx2-devkit
Signing and Flashing Boot Files
You can use the following procedures to sign and flash boot files:
• In one step, using PKC-key only or zero-key signing (signing with a key file that is all 0’s)
• In one step, using both SBK and PKC key signing
• In separate steps
Note: | When you reflash a previously flashed device, you must determine the type of signing that has been used on the device and reflash with the same type. This is because the type of signing is specified by fuses which can be written only once. For example if a device is first flashed with PKC signing, that type of signing is burned into its fuses, and it cannot later be reflashed with SBKPKC signing. If no key file is specified, the flashing utility uses zero-key signing. The flashing utility uses OpenSSL to sign the boot file. |
You can use this procedure on Jetson Xavier NX series, Jetson AGX Xavier series, and Jetson TX2 series to encrypt bootloader, kernel, kernel-dtb, and initrd. On Jetson Xavier NX series and Jetson AGX Xavier series you can encrypt and sign extlinux.conf.
To encrypt and sign
kernel,
kernel-dtb,
initrd, and
extlinux.conf separately, see the section
Signing and Encrypting Kernel, Kernel-DTB, and Initrd Binary Files.
Placeholders Used in the Procedures
The procedures described in this section use the following placeholders in their commands:
• <pkc_keyfile> is an RSA 2K or 3K key file.
• <sbk_keyfile> is an SBK key file.
• <user_keyfile> is a user key file.
To sign and flash in one step using PKC-key or zero-key signing
1. Navigate to the directory where you installed L4T.
2. Place the Jetson device into Force Recovery mode.
3. Enter one of these commands:
• To flash the Jetson device with PKC signed binaries:
$ sudo ./flash.sh -u <pkc_keyfile> <device_name> mmcblk0p1
• To flash the Jetson device with zero-key signed binaries:
$ sudo ./flash.sh <device_name> mmcblk0p1
To sign and flash in one step using SBK and PKC keys
Applies to: Jetson Xavier NX series, Jetson AGX Xavier series, and Jetson TX2 series
1. Navigate to the directory where you installed L4T.
2. Place the Jetson device into Force Recovery mode.
3. Enter the command:
$ sudo ./flash.sh -u <pkc_keyfile> -v <sbk_keyfile> <device_name> mmcblk0p1
Note: | Neither the PKC key file nor the SBK key file may be placed under the bootloader directory. If you do not specify -–user_key in the command, the flashing utility uses a zero key as the user key. |
To sign and flash in one step using the user, SBK, and PKC keys
Applies to: Jetson Xavier NX series, Jetson AGX Xavier series, and Jetson TX2 series
1. Navigate to the directory where you installed L4T.
2. Place the Jetson device into Force Recovery mode.
3. Enter this command:
$ sudo ./flash.sh -u <pkc_keyfile> -v <sbk_keyfile> --user_key <user_keyfile> <device_name> mmcblk0p1
To sign and flash in separate steps
1. Sign the boot files.
• Using PKC-key or zero-key signing:
1. Navigate to the directory where you installed L4T.
2. Place the Jetson device into Force Recovery mode.
3. Enter one of the commands:
• For PKC-key signing on Jetson Xavier NX seroes, Jetson AGX Xavier series, and Jetson TX2 series only:
$ sudo ./flash.sh –-no-flash --sign -u <keyfile> <device_name> mmcblk0p1
• For Jetson Nano (production module) and Jetson TX1 only:
$ sudo ./flash.sh --no-flash --sign -x 0x21 -y PKC -u <keyfile> <device_name> mmcblk0p1
• For zero-key signing on all modules:
$ sudo ./flash.sh –-no-flash <device_name> mmcblk0p1
• Using SBK and PKC-key signing:
Applies to: Jetson Xavier NX series, Jetson AGX Xavier, and Jetson TX2 series
1. Navigate to the directory where you installed L4T.
2. Place the Jetson device into Force Recovery mode.
3. Enter the command:
$ sudo./flash.sh –-no-flash --sign -u <pkc_keyfile> -v <sbk_keyfile> <device_name> mmcblk0p1
Note: | Neither the PKC key file nor the SBK key file may be placed under the Bootloader directory. If you do not specify -–user_key in the command, the flashing utility uses a zero-key as user key. |
• Using user, SBK, and PKC-key signing:
Applies to: Jetson Xavier NX series, Jetson AGX Xavier series, and Jetson TX2 series
1. Navigate to the directory where you installed L4T.
2. Place the Jetson device into Force Recovery mode.
3. Enter the command:
$ sudo ./flash.sh –-no-flash --sign -u <pkc_keyfile> -v <sbk_keyfile> --user_key <user_keyfile> <device_name> mmcblk0p1
Note: | None of the PKC key file, SBK key file, and user key file may be placed under the Bootloader directory. |
2. Flash:
1. Navigate to the directory where you installed L4T.
2. Place the Jetson device into Force Recovery mode.
3. Enter the commands:
$ cd bootloader
$ sudo bash ./flashcmd.txt
Note: | Be sure to press and reset the recovery button even if the Jetson device is still in recovery mode after fusing. |
To sign and flash with initrd using PKC-key or zero-key signing or both PKC-key and SBK-key
1. Put the Jetson device into Force Recovery mode.
2. Enter this command to sign the image:
$ sudo ./tools/kernel_flash/l4t_initrd_flash.sh --no-flash -u <pkc_keyfile> [-v <sbk_keyfile>] <board_name> <rootdev>
• <rootdev> specifies the device on which the root file system is located, as described in the topic
Basic Flash Script Usage.
3. Enter this command to flash the target device:
$ sudo ./tools/kernel_flash/l4t_initrd_flash.sh --flash-only -u <pkc_keyfile> [-v <sbk_keyfile>] <board_name> <rootdev>
Where
<board_name> and
<rootdev> are the same as in step
2,
above.
Accessing the Fuse from the Target
The Jetson Secure Boot package provides means to access fuses from the target board after it boots up.
To access the fuse from the target board
1. Copy the <top>.../Linux_for_Tegra/pkc/tegrafuse.sh script to the ubuntu@<target IP address>.
2. To access the target’s fuses from the target board, login to the target board. To display all fuses, enter the command:
$ sudo ./tegrafuse.sh
To access the fuse from the target board via force recovery mode
Applies to: Jetson Xavier NX series, Jetson AGX Xavier series, and Jetson TX2 series only
1. Navigate to the directory where you installed L4T.
2. Place the Jetson device into Force Recovery mode.
3. Enter the command:
$ sudo ./odmfuseread.sh -i <0x18 or 0x19> [-k <pkc_keyfile>] [-S <sbk_keyfile>] <device_name>
Fusing to Multiple Jetson Devices
NVIDIA provides a tool and instructions for fusing Jetson devices efficiently in a factory environment. This tool is part of the Secure Boot package, and is available in the Linux_for_Tegra folder. Instructions for using the tool are in README_Massfuse.txt, located in the same folder.
Building and Flashing a Factory-Signed Firmware Blob
L4T provides two example implementations for flashing factory-signed firmware in a factory environment.
To building the firmware blob in a trusted environment
• See “Building the Massflash Blob in Trusted Environment” in Linux_for_Tegra/README_Massflash.txt.
To flash the firmware blob in a factory environment
• See “Flashing the Massflash Blob in Untrusted Environment” in Linux_for_Tegra/README_Massflash.txt.
Signing and Encrypting Kernel, Kernel-DTB, Initrd, and extlinux.conf Files
Applies to: Jetson Xavier NX series and Jetson AGX Xavier series
To support Secure Boot, the kernel, kernel-dtb, initrd, and extlinux.conf files must be encrypted and signed with keys to generate encrypted files and signature files.
The RSA key pair file (<keyfile> in the script command below) is used to generate a signature file for authenticating a file.
A 128-bit key (<encrypt_keyfile> in the script command below) is used to encrypt a file.
To sign kernel, kernel-dtb, initrd, and extlinux.conf files
1. Navigate to the Linux_for_Tegra/ directory on the host system,
2. Enter this command:
$ ./l4t_sign_image.sh --file <filename> --chip 0x19 --key <keyfile>] --encrypt_key <encrypt_keyfile> --type <filetype> --minratchet_config <ratchet>
Where:
• <filename> is a kernel, kernel-dtb, initrd, or extlinux.conf file to be encrypted and signed.
The script replaces this file, so save a copy of the old file before you run the script.
The script stores a signature file named <filename>.sig in the directory that contains <filename>.
For details about the use of signature files to authenticate a kernel, kernel-dtb, or initrd file, see the section Kernel Boot Sequence Using extlinux.conf in topic Jetson Xavier NX series and Jetson AGX Xavier Series Boot Flow.
• <keyfile> is an RSA key pair file (a .pem file). It provides values to fill key fields in the signature file. If the key option is not specified, key fields are filled with 0’s.
• <encrypt_keyfile> is the pathname to a file that contains four 32-bit big-endian numbers in hexadecimal format. It is the same file as the <user_keyfile> used to flash the target, and contains the same key as that used to generate the EKB.
• <filetype> is the type of the file. The command supports three types: kernel, kernel_dtb, and data.
• <ratchet> is the path of the ratchet configuration file. The file is at this location:
• For NVIDIA Jetson Xavier NX series:
Linux_for_Tegra/bootloader/t186ref/BCT/tegra194-mb1-bct-ratchet-p3668.cfg
• For NVIDIA Jetson AGX Xavier series:
Linux_for_Tegra/bootloader/t186ref/BCT/tegra194-mb1-bct-ratchet-p2888-0000-p2822-0000.cfg