鉴于我们有一个带有 GRUB 引导加载程序的 USB 记忆棒,如何判断(从 Linux 命令行)
- 是否是UEFI?
- 是否是安全启动并验证一下?
至于研究,有创建此类加载器的指南,但是,我找不到如何判断现有加载器。
答案1
如果您在 USB 记忆棒上看到一个分区,其根目录包含一个名为EFI
或的子目录efi
(UEFI 应该不区分文件名的大小写),则它可能是可 UEFI 引导的。理想情况下,该分区应具有 FAT32 文件系统,但某些 UEFI 固件也支持其他文件系统类型,例如 ISO9660、NTFS 或 HFS+。
在可移动介质上,64 位 x86 硬件的实际 UEFI 引导加载程序将是路径 中的文件<partition root>/efi/boot/bootx64.efi
。这实际上是可移动媒体引导加载程序的标准路径名。在永久操作系统安装中,引导加载程序路径名将改为<partition root>/efi/<OS vendor or Linux distribution name>/<something>.efi
.操作系统安装程序会将此路径名存储到 UEFI NVRAM 启动变量中,这与 BIOS 设置类似,但实际上有一个标准化接口,允许操作系统在运行时查询和操作它。
在 Linux 中,efibootmgr -v
命令是显示 UEFI NVRAM 引导变量的一种方式; bootloaderbootctl
的命令也会systemd-boot
显示一些引导变量信息。
可移动介质可能同时支持 BIOS 引导和 UEFI 引导。在这种情况下,它将包括两个引导加载程序:一个嵌入在 MBR 中的 BIOS 兼容引导加载程序(可能是 SYSLINUX),以及如上所述的 UEFI 兼容引导加载程序。
如果您使用该file
命令来识别文件的类型.efi
,它会显示如下内容:
# file bootx64.efi
bootx64.efi: PE32+ executable (EFI application) x86-64 (stripped to external PDB), for MS Windows
换句话说,UEFI 引导加载程序使用与 Microsoft Windows 相同的可执行文件格式。 PE32+是64位可执行格式;如果您看到 32 位 UEFI 实现,它可能使用 32 位 PE32 格式(不带符号+
)。
注意:UEFI 支持多种硬件架构。某些 ARM 系统也可能使用 UEFI。
安全启动是 UEFI 的子集。非 UEFI 引导加载程序无法兼容安全引导。要查看.efi
文件是否嵌入了安全启动签名,您可以使用pesign -S -i filename.efi
.
# pesign -S -i bootx64.efi
---------------------------------------------
certificate address is 0x7fb0f0f8dd80
Content was not encrypted.
Content is detached; signature cannot be verified.
The signer's common name is Microsoft Windows UEFI Driver Publisher
No signer email address.
No signing time included.
There were certs or crls included.
---------------------------------------------
如果不存在安全启动签名,则输出将如下所示:
# pesign -S -i ipxe.efi
No signatures found.
由于市场上大多数 UEFI PC 的安全启动固件中都包含 Microsoft 的签名证书,并且 Microsoft 还为其他人提供 UEFI 引导加载程序签名服务,因此在兼容安全启动的 Linux 引导加载程序上最常见的签名可能是微软的。
如果带有 GRUB 的可移动介质与安全启动兼容,则实际<partition root>/efi/boot/bootx64.efi
文件很可能是垫片预加载器。在安全启动系统上永久安装 Linux 时,您会发现 shim 预加载器shimx64.efi
。它可以为发行版维护者自己的签名证书添加安全启动支持,也可以选择为系统所有者自己的证书(称为 MOK = 机器所有者密钥)添加安全启动支持。不幸的是,这是必要的,因为并非所有 UEFI 固件实现都允许以任何简单的方式自定义固件中包含的安全启动密钥。
添加证书后,填充程序预加载程序将加载实际的引导加载程序,grubx64.efi
在同一目录中命名。 (从技术上讲,它实际上不必是 GRUB;这只是编程到 shim 预加载器中的默认文件名。)该文件也必须经过签名,但很可能是使用发行版维护者自己的证书而不是 Microsoft 的证书进行签名。
这样做的目的是允许发行版维护者根据需要轻松打包和发布 GRUB 的更新版本,因为它们现在可以使用发行版维护者自己的密钥进行签名。如果需要更新 shim 预加载器,发行版维护者将需要联系 Microsoft 以重新签名更新的 shim。