必须验证整个uefi启动链，因secure boot下固件先加载shimx64.efi再跳转grubx64.efi，攻击者可篡改shim、替换grub、劫持启动项或注入grub.cfg恶意指令，单验grubx64.efi会遗漏这些关键攻击面。
直接结论：不能只校验 grubx64.efi 文件本身，必须验证整个 UEFI 启动链——从固件加载的 shimx64.efi 开始，逐级比对签名、哈希与路径一致性。
为什么单看 grubx64.efi 容易漏掉攻击点
在启用 Secure Boot 的现代 Linux（如 RHEL 9、Ubuntu 22.04+）中，UEFI 固件并不直接加载 grubx64.efi。它先加载微软签名的 shimx64.efi，再由 shim 验证并跳转到 grubx64.efi（或 mmx64.efi）。攻击者可能：
- 替换
shimx64.efi为带后门的伪造版本（绕过 Secure Boot 检查） - 篡改
grubx64.efi但保留合法签名（利用已泄露密钥或 shim 漏洞） - 在 ESP 分区中多放一个伪装的
grubx64.efi，并通过efibootmgr修改启动项指向它 - 不碰 EFI 文件，而是在
grub.cfg中注入恶意linuxefi/initrdefi路径
用绝对路径工具交叉验证 EFI 分区内容
别依赖 ls 或 file ——它们可能已被污染。进 Live 环境后，挂载 ESP 分区（通常是 /dev/sda1 或 /dev/nvme0n1p1），然后用可信基础命令检查：
- 确认挂载点：
sudo mount /dev/sda1 /mnt/efi（注意：不是/boot/efi，那是系统内的路径） - 列出所有引导文件哈希：
/usr/bin/sha256sum /mnt/efi/EFI/*/shimx64.efi /mnt/efi/EFI/*/grubx64.efi 2>/dev/null - 检查文件时间戳是否异常：
/usr/bin/stat /mnt/efi/EFI/*/shimx64.efi /mnt/efi/EFI/*/grubx64.efi（重点关注mtime是否在非维护时段变更） - 确认当前启动项实际指向哪个文件：
sudo efibootmgr -v | grep -A2 "BootCurrent\|HD\(P[0-9]+\)"，提取出类似HD(Part2,Sect0)\/EFI\/ubuntu\/grubx64.efi的路径，再手动去/mnt/efi下核对该路径是否存在且未被 symlink 劫持
比对签名与可信哈希值
仅比文件大小或哈希不够——攻击者可重打包签名二进制。真正有效的验证是：
- 用
sbverify检查签名有效性（需安装sbsigntools）：sbverify --cert /usr/share/doc/sbsigntools/uefi-ca-certs.pem /mnt/efi/EFI/ubuntu/shimx64.efi - 下载对应发行版的官方 ISO（如 Ubuntu 22.04.4 Desktop amd64），挂载后提取原始
shimx64.efi和grubx64.efi，计算sha256sum并比对 - 若使用 RHEL/CentOS，用
rpm -Vf /boot/efi/EFI/redhat/shimx64.efi（前提是该文件由 RPM 包管理） - 注意：
grubx64.efi在多数发行版中**不由 RPM/DEB 管理**，它随grub2-efi-x64包安装但不被包管理器跟踪，所以rpm -Vf常返回 “not installed”，不能据此排除篡改
容易被忽略的隐蔽篡改点
最常被跳过的其实是启动项元数据和配置层：
-
efibootmgr -v输出中，同一启动项可能有多个“File Path”字段（尤其在虚拟机或某些 OEM 固件中），需逐个确认 -
/mnt/efi/EFI/ubuntu/grub.cfg可能被注入insmod加载恶意模块，或修改set root=指向伪造分区 - 某些攻击会把真实
grubx64.efi改名为grubx64.efi.bak，再放一个同名后门文件——ls看不出，但stat能看出 inode 变更 - ESP 分区若被格式化为 exFAT（极少见但存在），部分 Linux 工具无法正确读取长文件名或权限，导致误判
真正难的是确认“谁在控制启动流程”：固件变量、shim、grub.cfg、内核参数，四层都得对得上。任何一层脱节，都可能让校验看起来正常，实则早已失守。
