绥化市网站建设_网站建设公司_支付系统_seo优化-山西省网站建设公司

📺B站视频讲解（Bilibili）：博主个人介绍

📘《Yocto项目实战教程》京东购买链接：Yocto项目实战教程

Jetson Orin Secure Boot 完整笔记：shim、L4TLauncher、GRUB 的关系与实战落地

目标读者：已经能把 Jetson Orin 刷机、进 UEFI 菜单、看得懂/boot/efi，但对“Secure Boot 到底验谁、shim/L4TLauncher/GRUB 各干什么、FUSE 和 UEFI Secure Boot 的边界在哪里”还不够踏实的人。
你现在遇到的典型困惑：
“UEFI 安全启动用 RSA 验签它加载的代码”——到底加载谁？
我这里只有BOOTAA64.efi，没看到 shim，是不是缺了什么？
FUSE 里是不是也放着内核验签公钥？谁去读 FUSE？
这篇把概念和实操放在同一条线上：先把关系讲清楚，再给你一套能落地的 Jetson Orin Secure Boot 操作路线（带命令、带检查点、带常见坑）。

0. 先给一个结论：你没有 shim，是正常的

在 ARM64 的 UEFI 规范约定里，默认启动入口通常就是：

\EFI\BOOT\BOOTAA64.EFI

Jetson 的默认 OS Loader 就是L4TLauncher，它通常就放在这个默认入口位置，因此你在设备上看到：

/boot/efi/EFI/BOOT/BOOTAA64.efi

完全符合 Jetson 的默认设计。

shim 不是 UEFI Secure Boot 的必选组件。

你只有BOOTAA64.efi，往往意味着：
- UEFI → L4TLauncher(BOOTAA64.efi) → 加载内核/DTB/initrd → 启动 Linux
只有当你走“发行版通用方案”（常见于 PC）时，才会出现：
- UEFI → shim → GRUB → Linux

Jetson 官方文档也明确写了：默认 OS Loader 是L4TLauncher，要用 GRUB 启动需要先备份默认的BOOTAA64.efi并安装 grub。

1. shim / L4TLauncher / GRUB：三者到底是什么关系？

1.1 L4TLauncher：Jetson 默认的“OS Loader”（UEFI 应用）

把L4TLauncher理解成：

一个由 UEFI 加载执行的EFI 程序（PE/COFF 格式）
职责类似“简化版 bootloader”
它知道 Jetson 的分区/启动配置细节，负责把内核、DTB、initrd 凑齐，然后启动。

因此你看到的BOOTAA64.efi，在 Jetson 默认 BSP 下基本就是 L4TLauncher。

1.2 GRUB：通用的二级引导器（功能强、生态成熟）

把GRUB理解成：

同样是一个EFI 程序（grubaa64.efi之类）
特点：菜单、脚本、读取多种文件系统、选择内核、传参数、做复杂启动逻辑
在 Jetson 上属于“可选方案”：你可以把默认入口从 L4TLauncher 换成 GRUB。

Jetson 的“Grub 支持”章节给的典型路线就是：

备份BOOTAA64.efi（默认 L4TLauncher）
安装grub-efi-arm64-bin
grub-install到 ESP
配置grub.cfg

1.3 shim：不是“必需”，而是“桥梁”

shim最准确的理解方式：

shim 是一个很小的 EFI 程序
它的存在意义通常是：
- 让系统在“平台固件只信任某些上游证书（典型：Microsoft UEFI CA）”的情况下
- 仍然能启动你自己的 GRUB/内核（通过 shim 的 MOK/自管理密钥机制）

在 Jetson 的默认链路里，你自己就是平台方/系统集成方，通常并不需要通过“微软签名 shim”来换取通用兼容性，所以默认没有 shim。

总结成一句话：
L4TLauncher：Jetson 默认的 EFI OS Loader
GRUB：可选的通用二级引导器（你可以替换默认 loader）
shim：可选的“跨证书生态桥梁”，不是 Secure Boot 必需组件

2. 你必须补齐的关键知识：Jetson 的 Secure Boot 分两层

Jetson 文档里 “Secure Boot” 很容易让人误解为“UEFI Secure Boot”。但在 Jetson Orin 上，真正严谨的划分是：

2.1 第 1 层：SoC/BootROM 级 Secure Boot（FUSE Root-of-Trust）

这一层回答的是：

上电后最早跑起来的代码，凭什么可信？

Jetson 的BootROM是芯片内固化的根信任
它会使用**烧进 FUSE 的密钥信息（更准确是公钥哈希等）**去验证下一阶段启动组件
这条链通常涵盖：BCT、早期 bootloader、直到 UEFI（具体细节取决于平台）

你问“谁去 FUSE 读公钥？”：

BootROM/早期 boot 阶段去读
目的：把“启动链前半段”锁死，防止别人替换 UEFI/前级固件来绕过后面的策略

重要：
只做 UEFI Secure Boot 而不做这层（不烧 fuse），在强对手模型下仍可能被“替换 UEFI/bootloader”绕过。

2.2 第 2 层：UEFI Secure Boot（PK/KEK/db/dbx）

这一层回答的是：

UEFI 接下来要执行的 EFI 程序，凭什么可信？

UEFI Secure Boot 会验证：

UEFI 要加载并执行的EFI 镜像（PE/COFF），例如：
- BOOTAA64.efi（L4TLauncher 或你换成 GRUB）
- grubaa64.efi
- 以及某些配置下的“EFI stub 内核”（内核也能作为 EFI 镜像被加载）

UEFI Secure Boot 的信任根来源不是 FUSE，而是 UEFI 变量里的：

PK / KEK / db / dbx

关键边界：
FUSE/BootROM 链：保证“UEFI 本身”不能被随便换
UEFI Secure Boot：保证“UEFI 之后加载的 EFI 镜像”可信

这也是 Jetson 文档中一句非常关键的话（你需要记牢）：

使用 FUSE 的 root-of-trust 链到 Bootloader（UEFI）结束；之后由 UEFI 使用自己的 Security Keys 体系去认证 payload。

3. 把整条启动链画出来：谁验证谁？

下面用一张“文字链路图”把角色对齐：

上电 ↓ BootROM（芯片固化） ├─ 读取 FUSE（公钥哈希/安全开关等） └─ 验证下一阶段镜像 ↓ MB1 / MB2 / 早期固件（平台相关） └─ 继续验证/加载 ↓ UEFI（Bootloader） ├─ (UEFI Secure Boot) 用 PK/KEK/db/dbx 验证它要执行的 EFI 镜像 └─ 执行 OS Loader： ├─ 默认：L4TLauncher（/EFI/BOOT/BOOTAA64.EFI） └─ 可选：GRUB（/EFI/ubuntu/grubaa64.efi 或被你放到 BOOTAA64.EFI） ↓ Linux Kernel（可能是 EFI stub 启动） ↓ initrd + DTB + rootfs ↓ 系统运行时（模块签名/IMA/dm-verity… 属于“另一层”）

这张图回答你之前的疑惑：

UEFI 通常不会跑去读 FUSE 来验内核。
“UEFI 验证它加载的代码”中的“代码”，在 Secure Boot 语境下主要指：
- 它要执行的 EFI 镜像（.efi/ PE/COFF）

4. 你要做“安全 + 加密”的 Secure Boot：应该选哪些功能？

在 Jetson Orin 上谈“安全加密 secure boot”，一般至少有三档目标：

4.1 档位 A：只做 UEFI Secure Boot（不烧 fuse）

你能得到：
- UEFI 会验证 EFI 镜像签名（比如你的BOOTAA64.efi、GRUB 等）
- 可在开发阶段快速试错（可通过重置 Secure Boot keys 或 noPK 方式回退，具体看启用方式）
你缺失的：
- 如果对手能替换早期固件/UEFI，本质上能绕过后续策略

适用：开发验证、安全机制联调、对物理攻击不敏感的场景。

4.2 档位 B：BootROM/FUSE Secure Boot + UEFI Secure Boot（生产推荐）

你能得到：
- root-of-trust 从 BootROM 开始，早期固件/UEFI 不能被随便替换
- UEFI 后续加载的 EFI 镜像也被签名约束

适用：量产/有较强对抗需求。

4.3 档位 C：在 B 的基础上再启用“payload 加密/变量保护”等

Jetson 的文档里还提供了更强的选项（常见需求是：

UEFI Payload Encryption：把 initrd / kernel / DTB 等 payload 加密，启动时由可信环境解密并认证
UEFI Variable Protection：防止/检测 UEFI 变量被篡改（需要用户认证 key，结合 EKB/OP-TEE）

适用：不仅要“不能被换”，还要“不能被偷/不能被离线复制分析”。

5. 实战前准备：确认你现在的启动方式与检查点

5.1 你现在是谁在启动：L4TLauncher 还是 GRUB？

你已经验证了：

ls/boot/efi/EFI/BOOT# BOOTAA64.efi

这说明默认入口存在。进一步你可以：

sudoefibootmgr -v

如果 BootOrder/Boot#### 指向\EFI\BOOT\BOOTAA64.EFI，那就是默认路径
如果指向\EFI\ubuntu\grubaa64.efi或你自定义的路径，那你在走 GRUB。

5.2 检查 Secure Boot 当前状态

在 Linux 下常用两个检查：

# 方法 1：直接读 UEFI 变量 SecureBoot（返回 0/1）# 注意：不同发行版上 efivar 读取需要权限sudoefivar -n 8be4df61-93ca-11d2-aa0d-00e098032b8c-SecureBoot# 方法 2：mokutil（有时更直观）sudomokutil --sb-state

如果你能进 UEFI 菜单（你截图的 Secure Boot Configuration 页面），也可以直观看到当前状态。

5.3 备份 ESP（非常建议）

因为你后面会改BOOTAA64.efi、装 GRUB、甚至启用 Secure Boot：

sudomkdir-p /opt/esp-backupsudocp-a /boot/efi/EFI /opt/esp-backup/

如果你打算尝试 GRUB（官方流程就是先备份默认BOOTAA64.efi）：

sudomv/boot/efi/EFI/BOOT/BOOTAA64.efi /boot/efi/EFI/BOOT/Backup_BOOTAA64.efi

6. 实战 Part 1：把 GRUB 装起来（可选，但能帮你理解“UEFI 到底验谁”）

如果你要把启动链改成：

UEFI → GRUB → Linux

按 Jetson 官方“Grub 支持”流程（核心命令如下）：

sudoapt-getupdatesudoapt-getinstallgrub-efi-arm64-bin# 安装 grub 到 ESPsudogrub-install --bootloader-id=Ubuntu --efi-directory=/boot/efi --target=arm64-efi# 生成 grub 配置（你会在后面编辑 40_custom 或 /etc/default/grub）sudogrub-mkconfig-o /boot/grub/grub.cfg# 或发行版常用的sudoupdate-grub

做完后：

find/boot/efi -maxdepth4-iname"*.efi"-print

你应该能看到类似：

/boot/efi/EFI/ubuntu/grubaa64.efi
默认入口/boot/efi/EFI/BOOT/BOOTAA64.efi（可能还是 L4TLauncher，除非你替换）

注意：Jetson 的默认链路并不强制你用 GRUB。你做这一步的意义是：
你会非常直观地看到：UEFI Secure Boot 约束的是这些 EFI 文件。

7. 实战 Part 2：UEFI Secure Boot（不烧 fuse）怎么做？

7.1 UEFI Secure Boot 的四类关键对象

你需要把这四个变量/数据库建立起来：

PK（Platform Key）：最高权威，存在则表示进入 User Mode（Secure Boot 生效）
KEK（Key Exchange Key）：更新/管理 db/dbx 的“中间权限”
db（允许列表）：允许执行的签名证书/哈希
dbx（吊销列表）：明确禁止的签名/哈希

UEFI 验证 EFI 镜像时的核心逻辑可以简单记成：

签名链能被db信任
且不在dbx吊销列表中

7.2 生成 UEFI Secure Boot keys（在 Host 上做更稳）

建议在你的Linux_for_Tegra目录里创建一个uefi_keys/工作目录（很多 Jetson 文档也是按这个组织）。

下面给一套“演示级别”的命令（自签证书），生产环境请走你自己的 CA/证书流程：

mkdir-p uefi_keyscduefi_keys# 生成一个 GUID，EFI Signature List 里会用到GUID=$(uuidgen)# 1) 生成 PK（Platform Key）openssl req -newkey rsa:2048 -nodes -keyout PK.key -new -x509 -sha256 -days3650\-subj"/CN=My Jetson Platform Key/"-out PK.crt cert-to-efi-sig-list -g"$GUID"PK.crt PK.esl# 2) 生成 KEKopenssl req -newkey rsa:2048 -nodes -keyout KEK.key -new -x509 -sha256 -days3650\-subj"/CN=My Jetson KEK/"-out KEK.crt cert-to-efi-sig-list -g"$GUID"KEK.crt KEK.esl# 3) 生成 db（Signature Database）openssl req -newkey rsa:2048 -nodes -keyout db.key -new -x509 -sha256 -days3650\-subj"/CN=My Jetson DB/"-out db.crt cert-to-efi-sig-list -g"$GUID"db.crt db.esl

接下来要生成*.auth文件，用于目标机上通过efi-updatevar写入变量（带认证）：

# 生成 PK.auth（用于最终“上锁”）sign-efi-sig-list -k PK.key -c PK.crt PK PK.esl PK.auth# 生成 KEK.auth（通常由 PK 签）sign-efi-sig-list -k PK.key -c PK.crt KEK KEK.esl KEK.auth# 生成 db.auth（通常由 KEK 或 PK 签，具体策略看你流程）# 常见是由 KEK 签 db；有的流程示例也用 PK 签 dbsign-efi-sig-list -k KEK.key -c KEK.crt db db.esl db.auth

小提醒：
cert-to-efi-sig-list和sign-efi-sig-list来自efitools（host/target 都可能需要）
上面命令适合你快速理解链路，不代表生产最佳实践

7.3 三种启用方式：Flash-time / Capsule / 运行时工具

Jetson 文档给了三种“启用 UEFI Secure Boot”的方法。你可以按你的项目选择：

刷机时启用（Flash time）

优点：流程最一致，适合生产
缺点：启用后更难回退（通常要重刷）

Capsule update 启用

优点：适合现场升级/OTA 场景
缺点：体系更复杂

系统起来后，用 Ubuntu prompt 工具启用（efi-updatevar）

优点：开发期最友好，能快速验证
缺点：需要你确保权限控制、避免被随意重置

下面给你“运行时工具启用”的一套稳妥顺序（一定要记住顺序）：

先写db、KEK
最后写PK（PK 写入后就进入 User Mode，Secure Boot 真正生效）

目标机（Jetson）上：

# 安装工具（按发行版情况调整）sudoapt-getupdatesudoapt-getinstall-y efitools efivar# 把 host 生成的 *.auth 传到目标机（示例路径）sudomkdir-p /uefi_keys# 你可以用 scp 或 U 盘，这里只给示例# scp <host>:/path/to/uefi_keys/*.auth /uefi_keys/# 1) 先写入 db、KEKsudoefi-updatevar -f /uefi_keys/db.auth dbsudoefi-updatevar -f /uefi_keys/KEK.auth KEK# 2) 最后写入 PK（这一刻开始“上锁”）sudoefi-updatevar -f /uefi_keys/PK.auth PK# 重启sudoreboot

重启后验证：

sudoefivar -n 8be4df61-93ca-11d2-aa0d-00e098032b8c-SecureBoot# 期望返回 1（或变量值里显示 01）

你在 UEFI 菜单里看到的“Reset Secure Boot Keys”等选项，本质上就是在动这套 PK/KEK/db/dbx。

8. 实战 Part 3：UEFI Secure Boot 到底“验谁”？你需要签哪些文件？

这里回到你最开始的问题：“UEFI 验证它加载的代码”，到底是哪段代码？

8.1 最保守的回答：UEFI 验证它要执行的 EFI 镜像

最典型的就是：

/boot/efi/EFI/BOOT/BOOTAA64.efi（你现在这颗）
/boot/efi/EFI/ubuntu/grubaa64.efi（如果你装了 grub）
以及 UEFI 可能加载的其他.efi应用（如诊断工具、UEFI Shell，如果启用的话）

因此：如果你启用了 UEFI Secure Boot，最起码要保证BOOTAA64.efi是用db信任的证书签过的。

8.2 如果你用 GRUB：你还要签 GRUB 本体

常见做法是用sbsigntool：

sudoapt-getinstall-y sbsigntool# 假设你要签 grubaa64.efisudosbsign --key db.key --cert db.crt\--output /boot/efi/EFI/ubuntu/grubaa64.signed.efi\/boot/efi/EFI/ubuntu/grubaa64.efi# 用签过的替换原文件（操作前备份！）sudocp-a /boot/efi/EFI/ubuntu/grubaa64.efi /boot/efi/EFI/ubuntu/grubaa64.efi.baksudomv/boot/efi/EFI/ubuntu/grubaa64.signed.efi /boot/efi/EFI/ubuntu/grubaa64.efi# 验证签名信息sbverify --list /boot/efi/EFI/ubuntu/grubaa64.efi

8.3 内核要不要签？取决于你的“内核是怎么被加载的”

这是很多人第二大误区：

UEFI Secure Boot 只直接管 EFI 镜像（PE/COFF）。
Linux 内核既可能作为“普通文件”被某个 loader 读入，也可能以EFI stub形式作为 EFI 镜像被加载。

你怎么确认自己的内核是否是 EFI 形式？可以试试：

file/boot/Image# 或者如果你使用的是 /boot/vmlinuz-*file/boot/vmlinuz*

如果显示类似 “PE32+ executable” 等，说明它可能是 EFI stub 格式

如果你的内核以 EFI stub 方式被 UEFI/GRUB 直接加载，那么你也需要对内核镜像做类似签名：

sudosbsign --key db.key --cert db.crt\--output /boot/Image.signed /boot/Imagesudocp-a /boot/Image /boot/Image.baksudomv/boot/Image.signed /boot/Image

注意：Jetson 的默认 L4TLauncher 路径/内核加载方式可能随 BSP 版本和你的配置不同而不同。
最稳妥的策略是：
先确定“UEFI 实际 LoadImage/StartImage 的对象是谁”（最少是BOOTAA64.efi）
再决定内核是否处于 UEFI Secure Boot 的直接验证范围

9. 实战 Part 4（生产核心）：把 root-of-trust 拉到 BootROM（烧 fuse）

如果你要做“面向生产”的 Secure Boot，通常会把第 1 层（BootROM/FUSE Secure Boot）也启用。

超重要提醒：
烧 fuse 是不可逆的，做错可能直接“变砖”
强烈建议：
先用备用板做演练
使用--test/ 离线生成 fuse blob 等方式做预演
在流程成熟后再进入量产

9.1 Jetson Orin 的 PKC 选择：RSA-3K 或 ECDSA

Jetson Orin 系列支持的 PKC 类型通常包括：

RSA 3K（RSA-3072）
ECDSA P-256
ECDSA P-521

并且对 Orin：

RSA-2048 不再支持（很多老经验在 Orin 上会踩坑）

生成 PKC key 的示例（以 ECDSA 为例）：

# ECDSA P-256openssl ecparam -name prime256v1 -genkey -noout -out ecp256.pem# ECDSA P-521openssl ecparam -name secp521r1 -genkey -noout -out ecp521.pem

如果你坚持 RSA-3K（示例）：

# RSA-3072openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:3072 -out rsa3k.pem

9.2 PublicKeyHash：不是把公钥直接烧进去，而是烧 hash

在 Jetson 的流程里，一般是把PublicKeyHash烧进 fuse。

生成 PublicKeyHash 的典型命令是用 BSP 提供的工具（示例）：

# 在 Linux_for_Tegra 目录下./tegrasign_v3.py --pubkeyhash<pkc.pubkey><pkc.hash>--key<pkc.pem># 输出里会给出一个 tegra-fuse format (big-endian) 的十六进制串# 你把它写进 fuse 配置文件的 PublicKeyHash 字段

9.3 SBK / KEK / K1/K2 / EKB：别把“所有钥匙”混成一把

你会在 Jetson Secure Boot 文档里看到多类 key：

PKC：用来做“签名验证”的根（fuse burn 的通常是其 hash）
SBK（如果平台支持）：用于对部分 boot 镜像做加密
K1/K2/KEK：用于密钥封装/派生/其他安全服务
EKB（Encrypted Key Blob）：把某些“运行时需要的 key”放在一个受保护的容器里（常用于 payload 加密、变量保护等功能）

这几类 key 不是一回事，也不应该“为了省事用同一把”。

9.4 Fuse Configuration File：把要烧的 fuse 明确写出来

Jetson 的 fuse 配置文件通常是一个 XML，里面逐条列出 fuse 名称与值。

示例（只表达结构，不建议直接照搬值）：

<genericfuseMagicId="0x45535546"version="1.0.0"><fusename="PublicKeyHash"size="64"value="0x..."/><fusename="BootSecurityInfo"size="4"value="0x1"/><fusename="SecurityMode"size="4"value="0x1"/></genericfuse>

关键点：
fuse 的烧写顺序可能有依赖关系
文档明确提醒：工具不会自动检查依赖，顺序错了可能直接不可用

9.5 烧 fuse：开发期一定先用 --test

不同 BSP 版本在“烧 fuse 工具链”上会有变迁：

老流程常见odmfuse.sh
新版本（Jetson Linux 36.x）更推荐工厂级的 FSKP（Factory Secure Key Provisioning）工具链
但文档也说明：FSKP 与odmfuse.sh使用同样的 fuse 配置格式和 key 格式

典型策略（概念上）：

用--test做一次完整预演
确认输出与预期一致
再执行真正烧写

具体命令会与机型、板卡配置、chip id、连接方式有关。建议严格按 NVIDIA Secure Boot 文档中“Orin 对应章节”的命令模板填写。

9.6 Flash secured images：让镜像也走“签名/加密”通道

烧完 fuse 后，你刷机必须走“带密钥”的签名流程，否则设备会拒绝启动。

Jetson 工具链里经常体现为：

flash.sh -u <pkc_keyfile> -v <sbk_keyfile> ...
或l4t_initrd_flash.sh ... -u <pkc_keyfile> [-v <sbk_keyfile>] ...

同理：如果你要在刷机阶段同时启用 UEFI Secure Boot，也会出现类似：

--uefi-keys uefi_keys/uefi_keys.conf

这就把“两层 secure boot”串在一条产线命令里：

BootROM/FUSE 链从上电就开始验证
UEFI Secure Boot接力验证后续 EFI payload

10. “安全 + 加密”进阶：UEFI Payload Encryption（让 kernel/initrd/DTB 不可裸奔）

如果你的目标不仅是“不能被篡改”，还要“不能被拷走离线分析”，可以考虑启用UEFI Payload Encryption。

核心要点：

加密对象通常包括：
- initrd
- kernel（rootfs 中的 + 分区中的）
- kernel-dtb（rootfs 中的 + 分区中的）
启用条件：
- 必须同时启用 UEFI Secure Boot
还需要：
- 准备用户加密 key（例如 256-bit，big-endian hex）
- 生成/配置 EKB（Encrypted Key Blob）

示例：生成用户加密 key（256-bit）

# 生成 32 字节随机数，并转成十六进制python3 -<<'PY' import os print(os.urandom(32).hex()) PY# 把输出保存为 user_encryption.key（按文档要求的格式：big-endian hex）

刷机阶段启用通常类似：

--uefi-keys ... --uefi-enc <user_encryption.key>

注意：L4TLauncher 可能无法“检测你是否开启了 payload 加密”，它会根据 EKB 中是否存在相应 key、以及 UEFI Secure Boot 状态来决定是否尝试解密。

11. 你该如何把项目落地：一套推荐的“从易到难”路线

下面给你一条非常实用、能减少踩坑的路线（每一步都有可验证的检查点）：

Step 1：搞清楚当前链路（只读，不动系统）

ls /boot/efi/EFI/BOOT看默认入口
sudo efibootmgr -v看 BootOrder 指向谁
sudo mokutil --sb-state/sudo efivar ... SecureBoot看 Secure Boot 状态

Step 2：先做 UEFI Secure Boot（不烧 fuse）验证理解

生成 PK/KEK/db/dbx（先用自签练手）
在开发板上用efi-updatevar按顺序写入（db/KEK → PK）
确认启用后：
- 未签名的 EFI 镜像是否会被拒绝
- 签名后的是否可启动

Step 3：确定你需要的 OS Loader 形态

继续用默认L4TLauncher（最省心）
或切换GRUB（更通用、更可控，但你得维护 grub.cfg 与签名）
shim 一般不需要，除非你明确要走“微软签名生态/MOK”那套流程

Step 4：进入生产：启用 BootROM/FUSE Secure Boot（谨慎）

把 key 管理、备份、权限、产线流程先定下来
演练--test/ 离线生成 fuse blob
再进行不可逆烧写

Step 5（可选）：启用 Payload Encryption / Variable Protection

这一步对密钥生命周期、EKB、OTA 更新策略要求更高
建议先把“只验签”的体系跑稳，再上“加密”

12. 你现在最需要记住的三句话（补齐知识瑕疵）

你没有 shim 是正常的：Jetson 默认就是BOOTAA64.efi = L4TLauncher，GRUB 是可选方案。
Jetson Secure Boot 分两层：

BootROM/FUSE：把“UEFI 本身”锁死，root-of-trust 从上电开始
UEFI Secure Boot：用 PK/KEK/db/dbx 去验 UEFI 之后加载的 EFI 镜像

“UEFI 验证它加载的代码”主要指 EFI 镜像：

最少是BOOTAA64.efi
如果你装了 GRUB，还包括grubaa64.efi
内核是否被 UEFI 直接验，取决于它是否以 EFI stub 形式被加载（要用file等命令确认）

参考资料（官方/权威）

为了避免“口口相传”带来的偏差，下面列的是你可以直接对照的官方文档页面。链接放在代码块里（复制即可打开）。

NVIDIA Jetson Linux Developer Guide（R36.4.4）- UEFI Adaptation / Grub support https://docs.nvidia.com/jetson/archives/r36.4.4/DeveloperGuide/SD/Bootloader/UEFI.html NVIDIA Jetson Linux Developer Guide（R36.4.3）- Security / Secure Boot（含 UEFI Secure Boot、--uefi-keys、payload encryption 等） https://docs.nvidia.com/jetson/archives/r36.4.3/DeveloperGuide/SD/Security/SecureBoot.html NVIDIA Jetson Linux Developer Guide（R35.4.1）- Secure Boot（同主题旧版，但包含一些更详细的示例段落） https://docs.nvidia.com/jetson/archives/r35.4.1/DeveloperGuide/text/SD/Security/SecureBoot.html Canonical Ubuntu for Jetson - Secure Boot（专注 UEFI Secure Boot，强调它不覆盖 UEFI 之前阶段） https://canonical-ubuntu-for-jetson.readthedocs-hosted.com/how-to/secure-boot/