Linux x86_64 UEFI 启动

小立爱学习

已于 2024-06-20 16:36:41 修改

阅读量1.8k

点赞数 7

分类专栏：系统安全文章标签： linux 服务器安全架构

于 2024-05-23 16:43:27 首次发布

本文链接：https://blog.csdn.net/weixin_45030965/article/details/139146665

版权

系统安全专栏收录该内容

50 篇文章 10 订阅

订阅专栏

前言

本文以 centos 7 （3.10.0 ），x86_64平台为例。

固件保存在主板上的 ROM 中，是计算机上电后执行的第一段程序。固件启动阶段的核心功能包括硬件初始化、硬件自检和加载 bootloader，最终会把控制权转交给给 bootloader。
固件启动阶段主要有两种启动方式：Legacy BIOS 和 UEFI。

Linux系统是使用UEFI还是BIOS启动，查看/sys/firmware/efi是否存在：

# ls /sys/firmware/efi
config_table  efivars  esrt  fw_platform_size  fw_vendor  runtime  runtime-map  systab  vars

其启动过程如下：
在这里插入图片描述

一、UEFI

Unified Extensible Firmware Interface（UEFI）统一可扩展固件接口是一种规范，定义了用于启动计算机硬件的平台固件的架构，以及其与操作系统进行交互的接口。
在这里插入图片描述

UEFI取代了BIOS，后者存在于所有兼容IBM PC的个人计算机的引导ROM中，尽管它可以通过CSM引导提供与BIOS的向后兼容性。
与其前身BIOS相反，BIOS最初由IBM作为专有软件创建的事实上的标准，UEFI是由一个行业联盟维护的开放标准。

由EFI规范定义的接口包括包含平台信息的数据表，以及可供操作系统加载程序和操作系统使用的引导和运行时服务。UEFI固件相对于BIOS提供了几个技术优势：
（1）能够引导包含大容量分区（超过2 TB）的磁盘，使用GUID分区表（GPT - GUID Partition Table）进行分区。
（2）灵活的预操作系统环境，包括网络功能、图形用户界面（GUI）和多语言支持。
（3）支持32位（例如IA-32、ARM32）或64位（例如x64、AArch64）的预操作系统环境。
（4）使用C语言进行编程。
（5）使用Python解释器进行UEFI Shell的Python编程。
（6）模块化设计，允许固件和驱动程序的灵活组合和替换。
（7）向后和向前的兼容性，可以与旧版本的EFI固件和新版本的UEFI固件兼容。
（8）安全性：BIOS不包含内置的安全措施，例如安全启动(Secure Boot)。EFI支持安全启动，可以防止未经授权的操作系统或恶意软件篡改启动过程。

UEFI的目的是控制引导过程（通过引导服务）并提供系统固件和操作系统（通过运行时服务）间的接口。和 BIOS 不同的是，它有自己的独立于 CPU 的架构和设备驱动。UEFI 可以挂载分区并读取某些文件系统。
当 x86 计算机装备了 UEFI 引导时，接口搜索系统存储里标签为特定全局唯一标识符（globally unique identifier，GUID） (GUID) 的分区，该标签将其标记为EFI 系统分区（EFI System Partition，ESP）。这个分区包含为 EFI 架构编译的应用程序，其中可能包括引导装载程序和工具软件。UEFI 系统包括可以根据缺省配置引导系统、或提示用户选择要引导的操作系统的 EFI 引导管理程序。

二、Disk device compatibility

2.1 GPT 磁盘分区表

2.1.1 简介

除了使用主引导记录（MBR）的标准PC磁盘分区方案外，UEFI还与GUID分区表（GPT）分区方案配合使用，GPT分区方案摆脱了MBR的许多限制。特别是，MBR对磁盘分区数量和大小的限制（每个磁盘最多四个主分区，每个磁盘最大容量为2 TB，即2 × 240字节）得到放宽。更具体地说，GPT允许最大磁盘和分区大小达到8 ZiB（8 × 270字节）。

GPT分区方案相比MBR具有更大的灵活性和扩展性，可以支持更大容量的磁盘和更多的分区。它还提供了更好的数据完整性和可靠性，支持磁盘自我修复和冗余存储。因此，在使用UEFI的系统中，可以利用GPT分区方案来充分利用大容量磁盘和更多的分区布局选项。

GUID Partition Table（GPT）是一种用于物理计算机存储设备（如硬盘驱动器或固态硬盘）分区表布局的标准，它使用全局唯一标识符（UUID）或全局唯一标识符（GUID）来标识分区。作为统一可扩展固件接口（UEFI）标准的一部分（作为PC BIOS的替代方案由统一EFI论坛提议），GPT也被一些BIOS使用，这是由于主引导记录（MBR）分区表的限制，MBR分区表使用32位用于传统512字节磁盘扇区的逻辑块寻址（LBA）。

可以使用 blkid 命令查看分区属性：

# blkid /dev/sda1

所有现代个人计算机操作系统都支持GPT。其中一些，包括基于x86架构的macOS和微软Windows，仅支持在具有EFI固件的系统上从GPT分区引导，但FreeBSD和大多数Linux发行版可以在具有BIOS或EFI固件接口的系统上从GPT分区引导。

如下图所示：
在这里插入图片描述
与MBR类似，GPT使用逻辑块寻址（LBA）代替历史上的柱面-磁头-扇区（CHS）寻址。保护性MBR存储在LBA 0处，GPT头部存储在LBA 1处，并在最后一个LBA处备份GPT头部。GPT头部包含对分区表（分区项数组）的指针，通常位于LBA 2处。每个分区表上的条目大小为128字节。UEFI规范规定，无论扇区大小如何，分区项数组都分配了至少16,384字节的空间。因此，在具有512字节扇区的磁盘上，至少使用32个扇区用于分区项数组，而第一个可用块位于LBA 34或更高位置；而在具有4,096字节扇区的磁盘上，至少使用4个扇区用于分区项数组，而第一个可用块位于LBA 6或更高位置。

2.1.2 Linux

在Linux中启用对GPT的支持需要在内核配置期间打开CONFIG_EFI_PARTITION选项（EFI GUID分区支持）。此选项允许Linux在系统固件将系统控制权交给Linux后，识别和使用GPT磁盘。

# cat /boot/config-3.10.0-693.el7.x86_64 | grep CONFIG_EFI_PARTITION
CONFIG_EFI_PARTITION=y

为了向后兼容，Linux可以在基于BIOS的系统中使用GPT磁盘进行数据存储和引导，因为GRUB 2和Linux都支持GPT。这样的设置通常被称为BIOS-GPT。由于GPT包含保护性MBR，基于BIOS的计算机可以使用存储在保护性MBR引导代码区域中的GPT感知引导加载程序从GPT磁盘引导。对于GRUB而言，这样的配置需要一个BIOS引导分区，以便GRUB嵌入其二级代码，因为GPT分区磁盘中不存在MBR之后的空隙（该空隙被GPT的主头和主分区表占用）。这个分区通常为1 MB大小，在GPT方案中，该分区的全局唯一标识符（GUID）为21686148-6449-6E6F-744E-656564454649，仅在BIOS-GPT设置中由GRUB使用。从GRUB的角度来看，在MBR分区方案中不存在这种分区类型。如果系统是基于UEFI的，则不需要此分区，因为在这种情况下不需要嵌入第二阶段代码。

UEFI系统可以访问GPT磁盘并直接从中引导，这允许Linux使用UEFI引导方法。在UEFI系统上从GPT磁盘引导Linux涉及创建EFI系统分区（ESP），其中包含UEFI应用程序，如引导加载程序、操作系统内核和实用工具。这样的设置通常被称为UEFI-GPT，建议ESP的大小至少为512 MB，并且使用FAT32文件系统进行格式化以实现最大的兼容性。

为了向后兼容，一些UEFI实现还通过兼容性支持模块（CSM）支持从MBR分区的磁盘引导，该模块提供了传统BIOS兼容性。在这种情况下，在UEFI系统上引导Linux与在传统基于BIOS的系统上引导相同。

2.2 ESP（EFI）文件系统

2.2.1 简介

EFI（可扩展固件接口）系统分区或ESP是存储设备（通常是硬盘驱动器或固态硬盘）上的一个分区，用于具有统一可扩展固件接口（UEFI）的计算机。当计算机启动时，UEFI固件加载存储在ESP上的文件以启动操作系统和各种实用程序。

ESP包含已安装操作系统的引导加载程序、引导管理器或内核映像（通常包含在其他分区中），用于在启动时由固件使用的硬件设备的设备驱动程序文件，旨在在引导操作系统之前运行的系统实用程序，以及数据文件，如错误日志。

EFI系统分区使用基于FAT文件系统的文件系统进行格式化，其规范基于UEFI规范并作为其一部分进行维护；因此，文件系统规范独立于原始的FAT规范。在GUID分区表（GPT）方案中，EFI系统分区的全局唯一标识符（GUID）是C12A7328-F81F-11D2-BA4B-00A0C93EC93B，而在主引导记录（MBR）分区表方案中，其标识符为0xEF。无论是GPT还是MBR分区的磁盘都可以包含EFI系统分区，因为UEFI固件需要支持这两种分区方案。此外，还支持用于CD-ROM和DVD的El Torito引导格式。

UEFI通过将分区的第一个块（扇区）保留为兼容性代码来提供与传统系统的向后兼容性，实际上创建了一个传统的引导扇区。在传统基于BIOS的系统中，将分区的第一个扇区加载到内存中，并将执行权转移到该代码上。UEFI固件不会执行MBR中的代码，除非通过兼容性支持模块（CSM）以传统BIOS模式引导。

UEFI规范要求完全支持MBR分区表。然而，某些UEFI实现在检测到引导磁盘上的某些类型的分区表时立即切换到基于BIOS的CSM引导，从而有效地阻止了从包含在MBR分区磁盘上的EFI系统分区进行UEFI引导。

UEFI固件支持从可移动存储设备（如USB闪存驱动器）引导。为此，可移动设备使用FAT12、FAT16或FAT32文件系统进行格式化，同时需要根据标准ESP文件层次结构存储引导加载程序，或者通过向系统的引导管理器提供引导加载程序的完整路径。另一方面，固定驱动器上始终期望FAT32文件系统。

如果计算机已经在EFI模式下启动，则ESP很可能安装在/boot/EFI。可以尝试在shell提示符下键入df /boot/efi。如果ESP安装在此位置，它将显示为一个单独的安装点：

# fdisk -l
......
磁盘标签类型：gpt
......
#         Start          End    Size  Type            Name
 1         2048       411647    200M  EFI System      EFI System Partition
......

# df -T /boot/efi/EFI/
文件系统       类型  1K-块  已用   可用 已用% 挂载点
/dev/sda1      vfat 204580 11596 192984    6% /boot/efi

# tree /boot/efi/EFI/
/boot/efi/EFI/
├── BOOT
│   ├── BOOTX64.EFI
│   ├── fallback.efi
│   └── fbx64.efi
└── centos
    ├── BOOT.CSV
    ├── BOOTX64.CSV
    ├── fonts
    │   └── unicode.pf2
    ├── fw
    ├── fwupia32.efi
    ├── fwupx64.efi
    ├── grub.cfg
    ├── grubenv
    ├── grubx64.efi
    ├── mmx64.efi
    ├── MokManager.efi
    ├── shim.efi
    ├── shimx64-centos.efi
    └── shimx64.efi

/boot/efi使用的vfat文件系统。

注意：尽管/boot/efi是ESP最常见的装载点，但也可以使用其他装载点。有些用户喜欢在/boot上安装ESP，因为这种做法会导致Linux内核自动放置在ESP上，如果您使用的是ELILO、SYSLINUX或内核的EFI存根加载程序（通常与rEFInd或gumbibot/systemd引导结合使用），这很有用。另一方面，如果您的包系统在/boot中创建符号链接，那么在/boot上安装ESP将使内核升级复杂化。dpkg工具有时会这样做，因此Debian、Ubuntu和其他使用Debian包的发行版不希望在/boot上安装ESP。

2.2.2 Linux

GRUB 2、elilo和systemd-boot是传统的、功能齐全的独立UEFI引导管理器（也称为引导加载管理器），用于Linux。一旦被UEFI固件加载，它们可以访问和引导来自它们所支持的所有设备、分区和文件系统的内核映像，而不仅限于EFI系统分区。

EFI系统分区的挂载点取决于所使用的引导加载器。较旧的引导加载器如GRUB 2和lilo/elilo默认为/boot/efi。或者，systemd-boot更喜欢/efi或/boot而不是/boot/efi，这是因为嵌套的autofs挂载可能导致潜在的复杂问题。无论挂载点路径如何，其内容在Linux引导后是可访问的。

对于GRUB2：

 tree /boot/efi/
/boot/efi/
└── EFI
    ├── BOOT
    │   ├── BOOTX64.EFI
    │   ├── fallback.efi
    │   └── fbx64.efi
    └── centos
        ├── BOOT.CSV
        ├── BOOTX64.CSV
        ├── fonts
        │   └── unicode.pf2
        ├── fw
        ├── fwupia32.efi
        ├── fwupx64.efi
        ├── grub.cfg
        ├── grubenv
        ├── grubx64.efi
        ├── mmx64.efi
        ├── MokManager.efi
        ├── shim.efi
        ├── shimx64-centos.efi
        └── shimx64.efi

Linux Kernel EFI Boot Stub

EFI Boot Stub使得在不使用传统UEFI引导加载器的情况下，可以引导Linux内核映像。通过伪装成PE/COFF可执行映像，并对固件呈现为UEFI应用程序，启用EFI Boot Stub的Linux内核映像可以直接由UEFI固件加载和执行。这样的内核映像仍然可以由基于BIOS的引导加载器加载和运行；因此，EFI Boot Stub允许单个内核映像在任何引导环境中工作。

Linux内核对EFI Boot Stub的支持通过在内核配置中打开CONFIG_EFI_STUB（EFI stub支持）选项来启用。它被合并到Linux内核主线版本的3.3版中，于2012年3月18日发布。

# cat /boot/config-3.10.0-693.el7.x86_64 | grep CONFIG_EFI_STUB
CONFIG_EFI_STUB=y

Systemd-boot是一个简单的UEFI引导管理器，它加载和运行配置的EFI映像，仅访问EFI系统分区。配置文件片段、内核映像和initrd映像需要驻留在EFI系统分区上，因为systemd-boot不提供访问其他分区或文件系统上的文件的支持。Linux内核需要使用CONFIG_EFI_STUB=y进行构建，以便可以直接作为UEFI映像执行。

通过EFI Stub，Linux内核可以被直接被编译成UEFI的app，可以直接被UEFI固件识别和启动，完全不需要借助第三方bootloader了。

在x86和ARM平台上，内核的zImage/bzImage可以伪装成PE/COFF映像，从而使EFI固件加载程序将其作为EFI可执行文件加载。修改bzImage头部的代码以及固件加载程序跳转到的EFI特定入口点共同被称为"EFI boot stub"，它们分别位于arch/x86/boot/header.S和drivers/firmware/efi/libstub/x86-stub.c。对于ARM架构，EFI stub实现在arch/arm/boot/compressed/efi-header.S和drivers/firmware/efi/libstub/arm32-stub.c中。在不同架构之间共享的EFI stub代码位于drivers/firmware/efi/libstub目录下。

对于arm64架构，没有压缩内核的支持，因此Image本身伪装成PE/COFF映像，并且EFI stub链接到内核中。arm64的EFI stub位于drivers/firmware/efi/libstub/arm64.c和drivers/firmware/efi/libstub/arm64-stub.c中。

通过使用EFI boot stub，可以在没有传统EFI引导加载程序（如grub或elilo）的情况下引导Linux内核。由于EFI boot stub执行了引导加载程序的任务，在某种意义上它就是引导加载程序。

启用EFI boot stub需要使用CONFIG_EFI_STUB内核选项。

请参考：
https://www.kernel.org/doc/html/latest/admin-guide/efi-stub.html
https://zhuanlan.zhihu.com/p/28708585

三、UEFI + GPT + grub2

3.1 简介

bootloader 启动阶段的核心功能是加载内核和 initramfs，并将控制权交给内核。

Centos7 的 bootloader 为 GRUB 2，根据启动方式的不同，可分成两种引导方式：BIOS+MBR+grub2 和 UEFI+GPT+grub2。

从GPT分区磁盘引导UEFI系统通常被称为UEFI-GPT引导。

这里主要描述UEFI+GPT+grub2引导方式。

这种引导方式，固件 UEFI 从 ESP 分区文件系统下读取 bootloader。Centos ESP 分区文件系统采用 vfat，其目录结构如下：

# tree /boot/efi/EFI/
/boot/efi/EFI/
├── BOOT
│   ├── BOOTX64.EFI
│   ├── fallback.efi
│   └── fbx64.efi
└── centos
    ├── BOOT.CSV
    ├── BOOTX64.CSV
    ├── fonts
    │   └── unicode.pf2
    ├── fw
    ├── fwupia32.efi
    ├── fwupx64.efi
    ├── grub.cfg
    ├── grubenv
    ├── grubx64.efi
    ├── mmx64.efi
    ├── MokManager.efi
    ├── shim.efi
    ├── shimx64-centos.efi
    └── shimx64.efi

与传统的PC BIOS不同，UEFI不依赖于引导扇区，而是在UEFI规范中定义了一个引导管理器。当计算机启动时，引导管理器会检查引导配置，并根据其设置执行指定的操作系统引导加载程序或操作系统内核（通常是引导加载程序）。引导配置由存储在NVRAM中的变量定义，包括指示操作系统加载程序或操作系统内核的文件系统路径的变量。

UEFI可以自动检测操作系统引导加载程序，这使得从可移动设备（如USB闪存驱动器）进行简单的引导成为可能。这种自动检测依赖于标准化的操作系统引导加载程序的文件路径，路径的格式取决于计算机架构。例如，在x86-64系统上，操作系统加载程序的文件路径为 /boot/efi/EFI/BOOT/BOOTX64.EFI，而在ARM64架构上为/boot/efi/EFI/BOOT/BOOTAA64.EFI。

# file /boot/efi/EFI/BOOT/BOOTX64.EFI
/boot/efi/EFI/BOOT/BOOTX64.EFI: PE32+ executable (EFI application) x86-64 (stripped to external PDB), for MS Windows

# file /boot/efi/EFI/BOOT/BOOTAA64.EFI
/boot/efi/EFI/BOOT/BOOTAA64.EFI: PE32+ executable (EFI application) Aarch64 (stripped to external PDB), for MS Windows

3.2 引导方式

# tree /boot/efi/EFI/
/boot/efi/EFI/
├── BOOT
│   ├── BOOTX64.EFI
│   ├── fallback.efi
│   └── fbx64.efi
└── centos
    ├── BOOT.CSV
    ├── BOOTX64.CSV
    ├── fonts
    │   └── unicode.pf2
    ├── fw
    ├── fwupia32.efi
    ├── fwupx64.efi
    ├── grub.cfg
    ├── grubenv
    ├── grubx64.efi
    ├── mmx64.efi
    ├── MokManager.efi
    ├── shim.efi
    ├── shimx64-centos.efi
    └── shimx64.efi

引导方式如下：

x86_64: uefi ==> shimx64.efi ==> grubx64.efi ==> /boot/efi/EFI/centos/grub.cfg ==> vmlinuz & initramfs

x86 架构系统中，shimx64.efi 和 grubx64.efi 是 UEFI 启动方式下的 bootloader，他们以文件的形式存在于磁盘的 /boot/efi/EFI/centos 目录下，UEFI 可以直接识别文件系统，并获取 shimx64.efi 加载到内存运行，然后 shimx64.efi 获取 grubx64.efi，grubx64.efi 则通过 grub.cfg 寻找 vmlinuz 和 initfamfs，并将其加载到内存中。

Centos 中 BOOTX64.EFI 是 shimx64.efi 的复制。第一次启动时，固件中无引导条目，默认会加载 ESP 分区下 EFI/BOOT/BOOTX64.EFI，BOOTX64.EFI 加载 fbx64.efi，fbx64.efi 根据 EFI/centos/BOOTX64.CSV 文件向固件注册引导项 Centos，并将引导程序指向 /EFI/centos/shimx64.efi，跳转到 shimx64.efi，shimx64.efi最终会加载 grubx64.efi，grubx64.efi根据 grub.cfg 读取并加载内核和 initramfs，并将控制权交给内核。从第二次启动开始，因为固件中已注册了 Centos引导项，所以直接从 shimx64.efi 启动。

首次启动：

UEFI --> BOOTX64.EFI --> fbx64.efi --> shimx64.efi --> grubx64.efi --> grub.cfg --> vmlinuz & initramfs

非首次启动：

UEFI --> shimx64.efi --> grubx64.efi --> grub.cfg --> vmlinuz & initramfs

shim 的作用主要是安全启动，grubx64.efi 完成实际的引导。

在大多数Linux发行版中，用于UEFI启动的引导加载程序通常是shim.efi或者grubx64.efi。shim.efi是一个轻量级的引导加载程序，主要用于支持安全启动（Secure Boot）功能，并随后加载grubx64.efi（GRUB2），GRUB2是更为复杂的引导加载器，它可以加载Linux内核和初始化RAM磁盘（initrd/initramfs），进而启动操作系统。

对于启用Secure Boot的UEFI系统，整个GRUB核心映像和引导过程所需的所有GRUB模块通常被写入EFI系统分区（ESP）中的一个单独文件，通常命名为grubx64.efi。这是GRUB的x86_64-efi变体。

为了使UEFI Secure Boot固件接受此文件，它必须是一个符合Microsoft PE+格式的二进制文件，并具有有效的签名。签名可以来自系统固件接受的Secure Boot密钥之一，Secure Boot兼容性shim（shimx64.efi）的提供者，或者可选地由系统管理员安装的机器所有者密钥（MOK）。

3.3 BOOTX64.EFI

BOOTX64.EFI 是一个通用的引导加载程序文件，具有较高的权限，并可以在各种环境下启动计算机。无论计算机是否安装了操作系统，如果存在 BOOTX64.EFI 文件，UEFI 固件将使用它作为默认的引导加载程序。

BOOTX64.EFI 具有广泛的应用场景，可以用于各种目的，包括维护、安装计算机系统以及启动不同的操作系统。通过使用 BOOTX64.EFI，您可以进入各种模式，如 EFI Shell、ISO、Windows、Linux 等，从而在不同的环境下启动计算机。

BOOTX64.EFI 是一种UEFI引导加载程序文件，用于在64位x86架构的计算机上启动操作系统。它是与UEFI固件兼容的引导加载程序，负责加载操作系统内核并引导系统启动。

在UEFI系统中，BOOTX64.EFI通常被用作默认的引导加载程序。当计算机启动时，UEFI固件会查找并执行BOOTX64.EFI文件，从而启动操作系统。

BOOTX64.EFI通常与特定的操作系统或引导管理器相关联。例如，在Windows系统中，UEFI固件会加载BOOTX64.EFI来引导Windows操作系统。类似地，在某些Linux发行版中，UEFI固件也会加载BOOTX64.EFI来引导该发行版的内核和引导程序。

需要注意的是，BOOTX64.EFI的文件名可能因操作系统和计算机制造商而有所不同。不同的操作系统和引导环境可能使用不同的文件名来执行相同的功能。例如，某些Linux发行版可能使用grubx64.efi或shimx64.efi作为默认的引导加载程序文件。

BOOTX64.EFI文件是UEFI系统的启动管理器，它会在计算机启动时被加载到内存中，然后启动操作系统的安装程序或引导管理器。这个文件通常位于Linux ISO image的EFI目录下，它可以被用来启动UEFI系统安装程序或启动其他操作系统的引导管理器。

总结来说，BOOTX64.EFI是一种UEFI引导加载程序文件，用于在64位x86计算机上启动操作系统。它是与UEFI固件兼容的引导加载程序，负责加载操作系统内核并引导系统启动。具体的文件名可能因操作系统和计算机制造商而有所不同。

3.4 shimx64.efi

shimx64.efi 是一个用于 UEFI Secure Boot 的特殊引导加载程序。它在 Linux 系统中的 BOOT 阶段用于启动操作系统，并提供了 UEFI Secure Boot 的支持。

在启用 UEFI Secure Boot 的系统中，引导加载程序必须具有受信任的数字签名才能被固件信任并加载。然而，某些 Linux 发行版的引导加载程序（如 GRUB）可能没有预先被签名，因而无法通过 Secure Boot 的验证。

为了解决这个问题，UEFI 固件允许使用一个称为 “shim” 的中间引导加载程序。shimx64.efi 就是 shim 的一个典型实现，适用于 x86-64 架构的系统。

shimx64.efi 本身是由 UEFI 固件预先信任的，因此可以通过 Secure Boot 的验证。它的主要作用是加载并启动 GRUB 或其他 Linux 发行版的引导加载程序。由于 shimx64.efi 是经过签名并可信任的，它可以作为信任链的一部分，允许其他未签名的引导加载程序或内核模块被加载，并确保系统的启动过程是安全的。

因此，当使用 UEFI Secure Boot 启动 Linux 系统时，shimx64.efi 是作为引导加载程序使用的，它负责加载并启动其他组件，如 GRUB 或操作系统内核，以确保在启动过程中的安全性和完整性。

3.5 grubx64.efi

（1）
grubx64.efi 是 GRUB 引导加载程序的一个文件，用于在 UEFI 系统中启动操作系统。它是 GRUB 的 UEFI 版本，专门设计用于 x86-64 架构的计算机。

grubx64.efi是GNU GRUB引导管理器的UEFI版本，它是一种常用的引导程序，被广泛应用于Linux系统中。当计算机使用UEFI启动时，UEFI固件会查找EFI目录下的grubx64.efi文件，并将其加载到内存中。然后，grubx64.efi将会显示一个菜单，列出可用的操作系统和内核，允许用户选择要启动的操作系统或内核。在Linux ISO image中，grubx64.efi文件通常被用作引导管理器，用于启动Linux操作系统的安装程序。

在 UEFI 系统中，grubx64.efi 被用作主引导加载程序，负责加载操作系统内核和初始化 RAM 文件系统（initramfs）。它是由 GRUB 提供的一个可信的引导加载程序，通常与 shimx64.efi 结合使用，以支持 UEFI Secure Boot。

grubx64.efi 的配置文件通常位于 /boot/grub/grub.cfg 或 /etc/grub.d/ 目录中。在配置文件中，可以定义引导菜单，包括可供选择的操作系统、启动参数和其他设置。

GRUB 具有强大的功能和灵活性，可以处理多个操作系统的引导和配置。它支持多个文件系统，可以通过配置文件进行自定义和扩展。通过编辑和配置 grubx64.efi 的配置文件，可以修改引导菜单、添加新的启动选项、设置默认启动项等。

对于Linux发行版，grubx64.efi是GRUB2在UEFI环境下的引导加载程序。虽然Grub是开源软件，理论上可以编译和定制，但通常情况下，个人用户不是通过直接编辑.efi文件来配置GRUB，而是通过编辑其配置文件（如/boot/grub/grub.cfg）来更改引导菜单、内核选项等。如果确实需要修改源代码，那也是先修改源代码然后重新编译生成新的.efi文件。

总结来说，grubx64.efi 是 GRUB 引导加载程序的 UEFI 版本，用于在 UEFI 系统中启动操作系统。它与 shimx64.efi 结合使用，提供了强大的引导和配置功能，使用户能够灵活地管理和启动多个操作系统。

（2）
grubx64.efi文件是怎么找到grub.cfg文件的:

在UEFI系统中，grubx64.efi引导管理器启动后，它会搜索EFI系统分区中的特定目录和文件，以找到grub.cfg配置文件。具体来说，grubx64.efi通常会按照以下顺序搜索grub.cfg文件：

首先，grubx64.efi会在EFI目录下搜索grub.cfg文件。如果在EFI目录下找到了grub.cfg文件，它会直接加载并执行该文件。

如果在EFI目录下没有找到grub.cfg文件，grubx64.efi会继续搜索EFI目录下的/boot/grub目录。在该目录下，它会尝试查找grub.cfg文件，并加载执行该文件。

如果在/boot/grub目录下也没有找到grub.cfg文件，grubx64.efi会继续搜索EFI系统分区中的其他目录，包括/efi/{distro}/、/efi/boot/等，以查找grub.cfg文件。

一旦grubx64.efi找到了grub.cfg文件，它就会将文件加载到内存中，并根据文件中的配置信息启动相应的操作系统或内核。注意，grub.cfg文件的位置和名称可能因Linux发行版和安装方式而有所不同，但通常情况下，它们会遵循上述搜索规则。

四、安全启动

BIOS在防范预启动恶意软件感染方面提供的保护很少；在BIOS引导路径中，操作系统隐式信任作为引导加载程序执行的任何内容。直到2012年末，这在大多数生产EFI实现中也是如此。然而，Secure Boot旨在为预启动过程添加一层保护。启用Secure Boot后，固件会检查执行的任何EFI程序上是否存在加密签名。如果加密签名缺失、与计算机的NVRAM中保存的密钥不对应，或者在NVRAM中列入黑名单，则固件将拒绝执行该程序。当然，这只是过程的开始；一个受信任的EFI引导加载程序必须以安全的方式继续引导过程，最终导致一个本身就是安全的操作系统。恶意软件作者需要获取恶意软件的签名，如果用户以安全方式控制自己的系统密钥，这将是困难的。因此，可以阻止预启动恶意软件。在更高层面上，事情可能会出现很多问题，但Secure Boot至少提供了一个基础，用于保护整个计算机系统——至少在理论上！

UEFI规范中对Secure Boot的描述并未提供任何创建密钥信任网的机制。仅仅根据UEFI规范，人们可能会认为Secure Boot将以站点方式实施；站点的管理员可以签署他们使用的引导加载程序，从而排除恶意软件作者。然而，微软在其Windows 8认证计划中包含了一个要求，要求桌面和笔记本电脑制造商出货时启用Secure Boot。实际上，这意味着厂商必须在其计算机上包含微软的密钥，除非计算机制造商包含其他密钥，否则只有由微软签名的引导加载程序才能正常工作。

UEFI Secure Boot（UEFI 安全引导）是一种验证机制，用于确保固件启动的代码是可信的。

正确、安全地使用 UEFI Secure Boot 需要对每个在引导时加载的二进制文件进行验证，验证过程是通过与固件中的已知密钥进行比对。这些密钥标识了可信的供应商和二进制文件的来源，或者通过加密哈希算法识别的特定可信二进制文件。

大多数 x86 硬件出厂时都预装了微软的密钥。这意味着我们通常可以依赖这些系统中的固件信任由微软签名的二进制文件，而 Linux 社区在很大程度上依赖这个假设来实现 Secure Boot。例如，Red Hat 和 SUSE 也采用了相同的流程。

许多 ARM 和其他架构也支持 UEFI Secure Boot，但可能没有在固件中预装密钥。在这些架构上，可能需要使用由硬件所有者加载到固件中的证书重新签名引导映像。

请参考：https://www.rodsbooks.com/efi-bootloaders/secureboot.html

4.1 简介

Secure Boot（安全启动）是一项在UEFI（统一可扩展固件接口）标准中的安全功能，旨在为预引导过程添加一层保护。它通过维护一个加密签名的二进制文件列表来验证引导时运行的程序是否经过授权或禁止，从而提高机器核心引导组件（引导管理器、内核、initramfs）未被篡改的可信度。

简单来说，所谓安全启动，就是主板厂商在 UEFI 的 ROM 中内置了一个公钥，操作系统发行方用对应的私钥，去给系统的内核，或者引导器签名。这样，系统启动的时候，UEFI 会用 ROM 中内置的对应公钥，去验证这个内核，或者引导器是否为发行方提供的。如果是，那么验证通过，可以正常启动；如果不是，那么启动就会被终止。

私钥签名，公钥验证。

UEFI规范定义了一种称为Secure Boot的协议（BIOS不具备这样的内置安全机制），可以通过阻止加载未使用可接受数字签名签名的UEFI驱动程序或操作系统引导加载程序来保护引导过程。并未指定驱动程序的签名具体的机械细节。当启用Secure Boot时，它最初处于“设置”模式，允许将称为“平台密钥”（PK）的公钥写入固件。一旦密钥被写入，Secure Boot进入“用户”模式，只有使用平台密钥签名的UEFI驱动程序和操作系统引导加载程序才能被固件加载。可以将其他证书添加到存储在内存中的数据库中的“密钥交换密钥”（KEK）中，以允许使用其他证书，但它们仍然必须与平台密钥的私有部分有关联。Secure Boot也可以设置为“自定义”模式，在该模式下可以向系统中添加不与私钥匹配的其他公钥。

在2011年，微软宣布获得其Windows 8操作系统认证的计算机必须预装微软的公钥并启用Secure Boot。随后，该公司被批评者和自由软件/开源倡导者（包括自由软件基金会）指责试图利用UEFI的Secure Boot功能阻碍或完全阻止安装诸如Linux等替代操作系统。微软否认Secure Boot要求旨在形成闭环，并通过明确规定，获得Windows 8认证的基于x86架构的系统必须允许Secure Boot进入自定义模式或被禁用，但在使用ARM架构的系统上不允许。Windows 10允许OEM厂商决定用户是否可以管理其x86系统的Secure Boot。

其他开发人员对在Linux系统中实现Secure Boot的法律和实际问题提出了担忧。前红帽开发人员Matthew Garrett指出，GNU通用公共许可证第3版的条款可能会阻止在未向发行版的开发人员披露私钥的情况下使用GNU GRand Unified Bootloader（不过，自由软件基金会已经澄清了其立场，保证提供密钥的责任由硬件制造商承担），而对于启用了Secure Boot的高级用户来说，构建能够正常工作的自定义内核而不进行自签名也是困难的。其他开发人员建议提供带有另一个密钥的已签名的Linux版本，但指出说服OEM厂商随同微软密钥一起提供所需密钥将会很困难。

几个主要的Linux发行版已经针对Secure Boot开发了不同的实现方式。Garrett本人开发了一个称为shim的最小化引导加载程序，它是一个预编译、已签名的引导加载程序，允许用户单独信任Linux发行版提供的密钥。Ubuntu 12.10使用一个较旧版本的shim，预先配置为使用Canonical自己的密钥，仅验证引导加载程序并允许加载未签名的内核。开发人员认为仅签名引导加载程序的做法更可行，因为一个可信任的内核只能保护用户空间，而不能保护Secure Boot旨在增加保护的预引导状态。这也允许用户构建自己的内核并使用自定义内核模块，而无需重新配置系统。Canonical还维护自己的私钥，用于签名预装在运行该操作系统的经过认证的OEM计算机上的Ubuntu安装，并且还计划强制执行Secure Boot要求，即需要在固件中包含Canonical密钥和微软密钥（出于兼容性原因）。Fedora也使用shim，但要求内核及其模块也必须签名。

关于操作系统内核及其模块是否必须签名存在争议；虽然UEFI规范并没有要求，但微软声称他们的合同要求如此，并保留撤销用于签署可能用于破坏系统安全性的代码的任何证书的权利。在Windows中，如果启用了Secure Boot，所有内核驱动程序必须经过数字签名；非WHQL驱动程序可能会被拒绝加载。2013年2月，另一位红帽开发人员试图提交一个补丁给Linux内核，使其能够解析由微软签2011年，微软宣布获得其Windows 8操作系统认证的计算机必须预装微软的公钥并启用Secure Boot功能。这一举措引起了批评者和自由软件/开源倡导者（包括自由软件基金会）的指责，称微软试图利用UEFI的Secure Boot功能限制或完全阻止安装其他操作系统（如Linux）。微软否认Secure Boot要求旨在形成闭环，并明确规定获得Windows 8认证的基于x86架构的系统必须允许Secure Boot进入自定义模式或禁用，但使用ARM架构的系统则不受此限制。Windows 10允许OEM厂商决定用户是否可以管理其x86系统的Secure Boot。

关于在Linux系统中实现Secure Boot的法律和实际问题引起了其他开发人员的关注。前红帽开发人员Matthew Garrett指出，GNU通用公共许可证第3版的条款可能会阻止在未向发行版开发人员披露私钥的情况下使用GNU GRand Unified Bootloader。不过，自由软件基金会已经澄清了其立场，确保提供密钥的责任由硬件制造商承担。对于启用了Secure Boot的高级用户来说，构建能够与Secure Boot启用一起使用的自定义内核而无需自签名也是困难的。其他开发人员提议提供带有另一个密钥的已签名Linux版本，但指出说服OEM厂商将所需密钥与微软密钥一起提供可能很困难。

许多主要的Linux发行版现在都支持UEFI Secure Boot，例如RHEL（RHEL 7及更高版本）、CentOS（CentOS 7及更高版本）、Ubuntu、Fedora、Debian（Debian 10及更高版本）、OpenSUSE和SUSE Linux。这些发行版采用了不同的Secure Boot实现方式，例如使用shim引导加载程序、签名引导加载程序和内核，以及允许自定义内核等。

4.2 keys

这一章节参考：
https://zhuanlan.zhihu.com/p/375393014
https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot
https://blog.hansenpartnership.com/the-meaning-of-all-the-uefi-keys/

Secure Boot（安全启动）实现使用以下密钥：
（1）平台密钥（Platform Key，PK）
顶层密钥（Top-level key）。
（2）密钥交换密钥（Key Exchange Key，KEK）
用于签名“签名数据库”（Signature Database）和“禁止签名数据库”（Forbidden Signatures Database）更新的密钥。
（3）签名数据库（Signature Database，db）
包含允许的EFI二进制文件的密钥和/或哈希值。
（4）禁止签名数据库（Forbidden Signatures Database，dbx）
包含被拒绝的EFI二进制文件的密钥和/或哈希值。

要使用安全启动，至少需要PK、KEK和db密钥。虽然可以添加多个KEK、db和dbx证书，但只允许一个Platform Key。

要更新KEK，必须要有PK；要想更新db或者dbx，必须有KEK。

4.2.1 Platform Key (PK)

PK（Platform Key）是最高等级的信任锚点，由OEM或者企业IT拥有。

平台密钥是对平台的密钥，并存储在PK变量中。它的作用是控制对PK变量和KEK变量的访问。在大多数实现中，一次只能存储一个密钥在PK中，并且PK只能是X509密钥。

如果PK变量被清除（通过经过身份验证的变量写入或特殊用户出现的固件操作），平台必须立即进入设置模式。

只能使用由平台密钥签名的身份验证描述符来更新PK变量。

注意：平台密钥不能用于签署用于执行的二进制文件。

4.2.2 Key Exchange Key (KEK)

次一级的是密钥交换密钥（Key Exchange Key,简称KEK）数据库，里面可以是多个CA，但目前大多数机器里面只有美国微软公司的CA。

密钥交换密钥用于更新签名数据库，并存储在KEK变量中。它可以用于更新当前的签名数据库，也可以用于签署用于有效执行的二进制文件。在大多数当前的实现中，KEK变量可以包含多个密钥，这些密钥可以是X509或RSA2048类型的任何密钥，其中任何一个都可以执行密钥交换密钥的功能。

只能使用由平台密钥（platform key）签名的身份验证描述符来更新KEK变量。

4.2.3 Signature Database (db)

签名数据库用于在平台以安全模式运行时验证已签名的EFI二进制文件和可加载的ROM。它存储在db变量中。db变量可以包含一组混合的密钥、签名或哈希值。在安全启动模式下，将比较EFI二进制文件中存储的签名（或如果没有签名，则是SHA-256哈希值）与数据库中的条目。如果以下条件之一成立，则将执行该映像：
（1）映像未签名且其SHA-256哈希值在数据库中。
（2）映像已签名且签名本身在数据库中。
（3）映像已签名且签名密钥在数据库中（并且签名有效）。

只能使用由密钥交换密钥（key exchange key）签名的身份验证描述符来更新db变量。

4.2.4 Forbidden Signatures Database (dbx)

禁止签名数据库用于在平台以安全模式运行时使EFI二进制文件和可加载的ROM无效。它存储在dbx变量中。dbx变量可以包含密钥、签名或哈希值。在安全启动模式下，将比较EFI二进制文件中存储的签名（或使用SHA-256计算的哈希值，如果二进制文件未签名）与数据库中的条目。如果满足以下条件之一，则拒绝执行：
（1）二进制文件未签名且其SHA-256哈希值在dbx中。
（2）映像已签名且签名与dbx中的条目匹配。
（3）映像已签名且用于创建签名的密钥与dbx中的条目匹配。

注意：由于未签名的二进制文件会自动被拒绝执行，因此将哈希值添加到dbx中仅防止该映像通过在签名数据库中具有其哈希值的条目而被授权执行。

只能使用由密钥交换密钥（key exchange key）签名的身份验证描述符来更新dbx变量。

4.3 Linux

mokutil 命令用于管理机主密钥（MOK），这些密钥由 shim 层用于验证 grub2和内核映像，也可用于验证安全启动是否启用。

验证安全启动是否启用：

# mokutil --sb-state
or
# bootctl

查看当前所有已注册的密钥：

# mokutil --list-enrolled

在Ubuntu上，除了initrd映像之外，所有预计作为引导过程的一部分加载的预构建二进制文件都由Canonical的UEFI证书签名。Canonical的UEFI证书被嵌入在由微软签名的shim加载程序中，因此本身隐式地受到信任。

在没有预加载来自微软的签名证书的架构或系统上，用户可以替换shim或grub上的现有签名，并根据其自己在系统固件中导入的证书进行验证。

系统引导时，固件根据固件BootEntry变量加载shim二进制文件。Ubuntu在安装时安装自己的BootEntry，并且在每次更新GRUB引导加载程序时可能会更新它。由于shim二进制文件由微软签名，因此在与固件中已存在的证书进行验证时，它被固件验证和接受。由于shim二进制文件嵌入了Canonical的证书以及自己的信任数据库，因此引导环境的其他元素除了被预加载在固件中的可接受证书之一签名外，还可以使用Canonical的UEFI密钥签名。

shim加载完成后，接下来加载的是第二阶段映像。这可以是两种情况之一：如果系统正常启动，则加载GRUB；如果需要进行密钥管理任务，则加载MokManager，这是由固件变量配置的（通常在之前运行系统时更改）。

如果正常引导，GRUB二进制文件（grub*.efi）将被加载，并尝试根据所有先前已知的受信任来源进行验证。Ubuntu的GRUB二进制文件由Canonical的UEFI密钥签名，因此成功通过验证，引导过程继续进行。

如果引导以执行密钥管理任务，将加载MokManager二进制文件（mm*.efi）。通过由shim签名的临时密钥对MokManager二进制文件进行了明确的信任。这意味着只有与特定shim二进制文件一起构建的MokManager二进制文件才被允许运行，并且限制了使用受损工具的可能性。MokManager允许在系统控制台上的任何用户注册密钥、删除受信任的密钥、注册二进制哈希并在shim级别切换Secure Boot验证，但大多数任务需要输入先前设置的密码以确认控制台上的用户确实是请求更改的人。这些密码只在单次shim/MokManager运行期间保留，并在完成或取消过程后立即清除。完成密钥管理后，系统将重新启动，而不仅仅继续引导，因为可能需要密钥管理更改才能成功完成引导。

一旦系统继续引导到GRUB，GRUB过程将加载任何所需的配置（通常从ESP（EFI系统分区）加载配置，指向根分区或引导分区上的另一个配置文件），该配置将指向要加载的内核映像。

到目前为止，EFI应用程序完全可以访问系统固件，包括访问更改受信任固件变量的权限，因此要加载的内核也必须根据信任数据库进行验证。官方的Ubuntu内核由Canonical的UEFI密钥签名，因此它们成功通过验证，并将控制权移交给内核。initrd映像不会被验证。

对于非官方内核或用户构建的内核，如果用户希望在保留UEFI Secure Boot的全部功能的同时加载这些内核，还需要采取额外的步骤。当启用UEFI Secure Boot时，所有内核都必须经过签名才能被GRUB加载，因此用户需要进行签名。或者，用户可以在启用官方内核的情况下，通过使用’sudo mokutil --disable-validation’命令并在提示输入密码时提供密码，禁用shim中的验证，并重新启动；或者在固件中完全禁用Secure Boot。

到目前为止，任何验证要加载的映像失败都会导致关键错误，停止引导过程。系统不会继续引导，并且如果其他BootEntry变量可能包含有效和受信任的引导路径，可能会在一段时间后自动重新启动。

加载并验证的内核将禁用固件的Boot Services，从而降低权限并有效地切换到用户模式，其中对受信任变量的访问仅限于只读。鉴于内核模块的广泛权限，任何没有内核内置的模块在加载时也需要进行验证。由Canonical与官方内核一起构建和提供的模块由Canonical的UEFI密钥签名，因此受信任。用户自定义构建的模块需要用户在加载模块之前采取必要的步骤对模块进行签名。可以使用’kmodsign’命令来实现这一点。

未经签名的模块将被内核拒绝。使用insmod或modprobe尝试插入它们将失败并显示错误消息。

鉴于许多用户需要第三方模块才能使其系统正常工作或使某些设备正常运行，并且这些第三方模块需要在系统上进行本地构建以适应运行的内核，Ubuntu提供了工具化来自动化和简化签名过程。

4.4 Red Hat Enterprise Linux

可以使用签名的内核和签名的内核模块来加强系统的安全性。在启用了安全引导机制的基于 UEFI 的构建系统中，可以自我签名一个私有构建的内核或内核模块。另外，可以将公钥导入到要部署内核或内核模块的目标系统中。

如果启用了安全引导机制，则必须使用私钥签名以下所有组件，并使用对应的公钥进行身份验证：
（1）UEFI 操作系统引导装载程序（grub.efi）
（2）Red Hat Enterprise Linux 内核（vmlinux）
（3）所有内核模块（.ko）

如果这些组件中的任何一个都没有签名和验证，则系统将无法完成引导过程。

以RHEL 8为例，RHEL 8 包括：
（1）签名的引导装载程序
（2）签名的内核
（3）签名的内核模块

此外，签名的第一阶段引导装载程序和签名的内核包括嵌入的红帽公钥。这些签名的可执行二进制文件和嵌入式密钥可让 RHEL 8 在支持 UEFI 安全引导的系统上使用 UEFI 固件提供的 Microsoft UEFI 安全引导认证认证机构密钥安装、启动并运行。

备注：
不是所有基于 UEFI 的系统都包括对安全引导的支持。
构建系统（构建和签署内核模块）不需要启用 UEFI 安全引导，甚至不需要是基于 UEFI 的系统。

使用统一可扩展固件接口 (UEFI)安全引导技术，可以防止未由可信密钥签名的内核空间代码的执行。系统引导装载程序使用加密密钥进行签名。公钥的数据库（其包含在固件中）授权签名密钥。然后，可以在下一个阶段引导装载程序和内核中验证签名。

UEFI 安全引导建立了一个从固件到签名驱动程序和内核模块的信任链，如下所示：
（1）UEFI 私钥签名，公钥验证 shim 第一阶段引导装载程序。证书颁发机构 (CA — Microsoft第三方UEFI CA证书)反过来签署公钥。CA 存储在固件数据库中。
（2）shim 文件包含红帽公钥 Red Hat Secure Boot (CA 密钥 1) 来验证 GRUB 引导装载程序和内核。
（3）内核又包含用于验证驱动程序和模块的公钥。

备注：BIOS中的这个CA叫做UEFI CA，但实际上UEFI CA由微软管理，签名验证和批准都由微软和微软CA服务器进行，并收取一定费用。

详细请参考：为安全引导签名内核和模块

4.5 Using a Signed Boot Loader

使用由Microsoft密钥签名的引导加载程序是在启用Secure Boot的情况下引导的最简单和直接的方法。然而，这种方法也具有一定的限制。根据您使用的签名引导加载程序，您可能需要在尝试引导未签名的引导加载程序时处理引导时确认，或者在可引导的操作系统和内核方面存在一定的限制。截至2023年初，我知道有两个用于Linux的已签名引导加载程序：Fedora的Shim程序（也被Ubuntu、SUSE、Sabayon、ALT等使用）和Linux基金会的"PreLoader"。截至目前，可以找到几个已签名的Shim版本，至少有一个已签名的PreLoader版本。然而，PreLoader在很大程度上已经被放弃，因此主要是出于历史兴趣。我还会描述如何验证已签名引导加载程序的签名，以确保它是您所期望的。

PreLoader通过计算后续二进制文件的哈希值，并检查该哈希值是否存储在NVRAM中的数据库中来工作。相比之下，Shim最初通过检查二进制文件是否使用密码密钥进行了签名来工作；但是，最新版本的Shim支持这种方法和PreLoader使用的相同类型的哈希值。因此，Shim是更灵活的工具。它也更容易获取到最新的已签名版本。如果您想要启动尚未签名的二进制文件（例如自己编译的文件或由不签名其二进制文件的发行版维护者提供的文件），使用哈希值是个不错的选择。另一方面，使用哈希值意味着您需要注册您想要启动的每个未签名二进制文件的哈希值，可能包括每个内核和内核模块。这可能会带来一些麻烦，而使用密钥签名的二进制文件则更为优越，因为您只需注册每个密钥一次，最多。由于Shim更灵活且更容易获取到当前已签名的版本，Shim通常是首选的程序。