软件安全 on 安洛的小窝

Arch Linux 配置 UKI+TPM PCR policies 解锁 LUKS 分区

Mon, 26 Jan 2026 12:46:59 +0000

封面图：https://www.bilibili.com/opus/992929256980873221

前言

一直以来，我都是使用 TPM 绑定 PCR 7+12 hash 来自动解锁 LUKS 分区。然而，一来这样没有测量内核（PCR#11），二来这样任何内核参数的修改都会触发解锁失败，带来了很多不方便。TPM PCR policies 提供了一种机制，允许对 PCR 测量值进行签名，当系统启动时，TPM 会通过和硬盘密钥一起写入的公钥来验证该签名，当签名验证成功时，释放硬盘密钥。而像 PCR#11 这样的只和内核映像相关的测量值很容易计算。因此，我们可以在生成内核映像之后，提前计算测量值并进行签名；下次启动时，TPM 验证该签名正确，就会释放密钥，从而允许更新内核映像并不破坏 TPM 自动解锁。

本文使用以下工具：

sbctl
systemd-boot
mkinitcpio
systemd-ukify
systemd-cryptenroll

本文希望达成以下结果：

将内核、内核参数、initrd 等组件打包成统一内核映像（UKI）。当我自己在系统内执行此生成时，不会导致 TPM 自动解锁失败，从而允许内核升级和内核参数修改；而外部的修改尝试会导致解锁失败，即禁止内核替换以及启动时编辑内核参数。

注意：安全启动和 TPM policies 都会利用签名来进行验证。下文中尽量区分开这两种情况。我在进行此次配置之前已经配置好了 sbctl 安全启动，因此不再涉及相关内容。sbctl 如果已经配置好了和 mkinitcpio 协作的，不需要修改，配置依然有效。如果你还没有配置，可以参考安全启动#sbctl 进行配置，sbctl 自带所有钩子，只需要配置 sbctl 本身即可，不需要手动签名，非常简单。

生成 UKI

我之前使用的是一般的内核+initrd方式启动，因此首先需要切换到 UKI。

统一内核映像（Unified Kernel Image，UKI）是一个可执行文件，可直接从 UEFI 固件进行启动，也可以无需或通过简单的配置由引导加载器自动生成。它将一个 UEFI boot stub 程序（例如 systemd-stub(7)）、一个 Linux 内核映像、一个 initrd 以及其它资源打包到了单个 UEFI PE 文件中。

该文件，也就是包括其下的所有元件都可以很方便地进行签名，以便与安全启动一起使用。

我使用 mkinitcpio+systemd-ukify 的方式生成 UKI。使用 mkinitcpio 是因为它与 Arch Linux 集成更好，像是 sbctl 包就有 mkinitcpio hook，可以自动对 mkinitcpio 生成的文件进行安全启动签名。使用 systemd-ukify 是因为它可以自动对内核映像进行 TPM policies 签名。这两个组件配合得非常好，安装 systemd-ukify 后，mkinitcpio 就会自动用它来生成 UKI，并且 mkinitcpio 的配置也可以自动传递给 systemd-ukify，systemd-ukify 这边只需要添加 TPM policies 相关的配置即可。

首先安装 systemd-ukify。

然后进行 mkinitcpio 的配置。该部分主要参考统一内核映像#mkinitcpio。首先配置内核命令行，也就是root=啊，quiet splash之类的，可以在/etc/kernel/cmdline下进行单文件配置，或者在/etc/cmdline.d/*.conf下进行多文件配置。将原本启动引导器里面配置的参数移过来即可。然后，编辑/etc/mkinitcpio.d/$LINUX.preset（$LINUX通常是内核包名），取消*_uki选项前面的注释，并修改其值为合适的路径，主要是修改esp为你自己的esp分区名。最后，就可以先尝试生成一下 UKI。

1
2

sudo mkdir -p esp/EFI/Linux
sudo mkinitcpio -p $LINUX

应该没有错误输出，且有Using ukify to build UKI字样。

然后，就可以进行 systemd-ukify 的配置。首先复制配置模板：

`1`	`sudo cp /usr/lib/kernel/uki.conf /etc/kernel/uki.conf`

然后，编辑/etc/kernel/uki.conf文件。我们使用 mkinitcpio 进行大部分配置，因此 systemd-ukify 这里我们只进行最简单的配置，仅仅配置 PCRSignature 小节。取消

1
2
3

#[PCRSignature:NAME]
#PCRPrivateKey=/etc/systemd/tpm2-pcr-private-key.pem
#PCRPublicKey=/etc/systemd/tpm2-pcr-public-key.pem

这三行的注释。把 NAME 修改为 default。

然后，根据这个路径生成相应的签名密钥对。

1
2
3

sudo ukify genkey \         
        --pcr-private-key=/etc/systemd/tpm2-pcr-private-key.pem \
        --pcr-public-key=/etc/systemd/tpm2-pcr-public-key.pem

完成后再次生成 UKI

`1`	`sudo mkinitcpio -p $LINUX`

应该能看到类似

1
2
3

  -> Using ukify to build UKI
Using config file: /etc/kernel/uki.conf
+ /usr/lib/systemd/systemd-measure sign ...

这样的输出。至此，有签名的 UKI 就生成完成了。

我使用 systemd-boot 引导，它会自动检测 UKI，不需要额外写配置。如果你使用其它引导器，请自行查阅相关文档。

写入 TPM 和加密密钥

在完成 UKI 签名之后，就可以写入 TPM 和加密密钥了。这个过程其实很简单，因为我们在默认路径生成了 pubkey，systemd 检测到有 pubkey 就会自动把它写入 TPM 并绑定到 PCR#11。因此只需要

1
2

#$DISK_DEVICE_PATH 就是 /dev 下你的加密硬盘路径
sudo systemd-cryptenroll --tpm2-device=auto $DISK_DEVICE_PATH

你可以用

`1`	`sudo cryptsetup luksDump $DISK_DEVICE_PATH \| grep pcr`

检查，应该可以看到

`1`	`tpm2-pubkey-pcrs: 11`

字样。

当然，更流行的做法是加上 PCR#7 的绑定。PCR#7 是安全启动状态，比如关闭安全启动就不能自动解锁，加强安全性。PCR#7 一般不会变化，如果变了一般是 fwupd 导致的，而要预计算这个变化需要先解决这个 issue。因此目前还是只能用静态哈希来绑定，不能用 PCR policy。

1
2

# --wipe-slot=tpm2 是抹除之前写入的和 tpm 关联的密钥
sudo systemd-cryptenroll --wipe-slot=tpm2 --tpm2-device=auto --tpm2-pcrs=7 $DISK_DEVICE_PATH

重启电脑，应该可以自动解锁。

清理工作

既然有了 UKI，那一般的 initrd image 就用不上了。编辑 /etc/mkinitcpio.d/$LINUX.preset，注释掉*_image选项，然后删除对应的initranfs-*-.img文件。另外引导器里面相应的引导入口也可以删掉了，对于 systemd-boot，自定义引导入口位于 $esp/loader/entries/。如果只用 UKI，那所有引导入口都可以删除，因为 systemd-boot 会自动检测 UKI，不需要自己写引导入口。

缓冲区溢出漏洞及缓解机制

Wed, 20 Nov 2024 16:37:15 +0800

封面图：https://www.bilibili.com/opus/993288080028860441

引言

迄今为止，缓冲区溢出已被识别为最常见且最危险的漏洞。根据 2019 年通用漏洞和暴露（CVE）列表，它是报告频率最高的漏洞，报告了超过 400 个漏洞。截至 2021 年 5 月，CVE 数据库中报告的缓冲区溢出漏洞数量已达到 13,700 多个。在所有缓冲区溢出漏洞中，基于栈的缓冲区溢出是最常见的类型。本文将介绍各种用于缓解缓冲区溢出漏洞的机制和它们的绕过方法，并介绍最近的一个栈溢出漏洞 CVE-2024-9632。

基于硬件的缓解技术

基于硬件的缓解技术中，最著名的就是 NX（No-eXecute）技术。NX 技术是一种硬件支持的内存保护技术，它通过在内存页表中设置一个标志位来防止代码执行。当试图执行一个被标记为不可执行的内存区域时，CPU 会产生一个异常，从而阻止攻击者执行恶意代码。还有一些其它的研究工作，如 SmashGuard 通过在 CPU 上实现一个硬件堆栈来保存返回地址，HSDefender 通过设计安全的call指令来防止栈溢出攻击等。以下主要介绍 NX 技术。

NX技术

在冯诺依曼架构中，使用相同的内存空间来存储代码和数据。这是通过分页来实现的，但分页机制不允许用户在特定内存区域上独立设置读写和执行权限，而仅允许三种权限：non-accessible、readable-executable（RX）和 readablewriteable-executable（RWX）。因此，如果页面设置了可读写，那么它就一定是可执行的。攻击者可以利用这一点，将恶意代码注入到内存中，并通过覆盖返回地址的方式来执行恶意代码。为了解决这个问题，NX技术被引入到现代 CPU 中。

操作系统可以通过操作NX位来将某些内存区域标记为不可执行。NX 的位号是 63，这是页表中最高有效位。如果特定页面的 NX 位设置为 0，则可以执行该代码；如果设置为 1，则它是仅包含数据的不可执行页面。NX（no-execute）功能仅适用于 64 位模式。NX 功能的一个重要之处在于它是运行时策略，应用无需重新编译即可从此功能中受益。操作系统利用 NX 位将堆栈/堆内存标记为不可执行，从而防止了相当一部分利用缓冲区溢出的代码注入攻击。

NX技术的绕过

为了绕过 NX 技术，一种常见的思路是代码重用攻击。代码重用攻击是一种利用程序中已有的代码片段来实现攻击目的的攻击方式。这种攻击方式不需要向内存中注入恶意代码。ROP攻击是一种高级形式的代码重用攻击。以下介绍 ROP 攻击的基本原理。

ROP攻击

ROP 使用预先存在的名为 “gadgets” 的小指令序列来实施攻击。这些 gadgets 是结合在一起可以执行高级任务的短指令序列。gadgets 必须是有效的以返回指令结尾指令序列，从而让 CPU 继续执行下一个 gadgets 或有效载荷。在发起攻击时，攻击者通常会用跳转到第一个 gadgets 的代码指针覆盖堆栈上保存的返回地址。ROP 攻击的流程图如下：

常见的可用于 ROP 攻击的 gadgets 包括 pop rdi; ret 和 system() 等。system() 函数可以执行系统命令，而 pop rdi; ret 可以将参数传递给 system() 函数。通过将这两个 gadgets 结合在一起，攻击者可以执行任意系统命令。在查找 gadgets 的步骤，攻击者可以通过各种调试器和反汇编工具来在二进制文件中查找这些指令。

基于操作系统的缓解技术

有许多基于操作系统的缓解技术。例如 libsafe 通过修改标准库来提供更安全的函数，地址混淆和二进制搅拌技术都是在加载时对目标二进制文件进行修改，以使攻击者难以找到目标函数的地址。而最常见的基于操作系统的缓解技术是 ASLR 技术。以下主要介绍 ASLR 技术。

ASLR技术

在上文中介绍了 ROP，其必须知道 gadgets 的地址。ASLR随机化进程各个部分的基址，包括堆栈、堆、共享库和可执行文件。因此，攻击者不能每次都使用相同的漏洞来滥用相同的易受攻击的程序。每次程序运行时，系统会将程序的代码段、堆、栈以及动态库加载到不同的随机地址。攻击者无法直接预测这些关键区域的精确地址，从而难以利用固定地址的内存漏洞。

ASLR技术的绕过

在 32 位系统中，ASLR 技术的绕过相对容易，因为 32 位系统的内存地址空间相对较小，ASLR 的随机性有限，地址中通常只有 8 或 16 位被随机化。攻击者可以通过不断尝试可能的内存地址来暴力破解 ASLR。在 64 位系统中，地址中有 40 位被随机化，因此暴力破解的难度大大增加。但是，攻击者仍然可以通过泄露内存地址和信息泄露等方式来绕过 ASLR。以下主要介绍信息泄露技术。

信息泄露技术

信息泄露技术的流程如下：

其中一种信息泄露方法是利用过程链接表（PLT）和全局偏移表（GOT）这两种数据结构。PLT 是一种数据结构，用于调用外部函数，这些函数的地址在运行时由动态链接器解析。GOT 是一个数组，其中包含进程当前使用的全局变量和库函数的绝对地址。当程序调用函数时，查找 PLT 中的条目，条目中包含跳转指令，可以跳转到 GOT 中的条目。GOT 调用动态链接器来获取函数地址并存储在自己的条目中，这样程序就可以通过函数地址来调用函数。如下图所示。

通过获取 PLT 和 GOT 中的地址，攻击者可以泄露程序中的地址信息，从而绕过 ASLR。具体地说，利用调试器可以获取某个函数的 PLT 地址，之后反汇编该地址的指令就能获得 GOT 的地址。通过获得 GOT 中的地址，攻击者可以获取到函数的绝对地址。之后通过库文件来获取其它函数和该函数的相对偏移，就可以利用该函数的地址加上相对偏移来调用任意库函数。

另外，printf() 函数也是一个常用的信息泄露工具。如果攻击者可以修改 printf() 函数的格式控制字符串，就可以泄露栈上的数据。例如，通过 %lx 格式控制字符，攻击者就可以获得泄露的内存地址。

基于编译器的缓解技术

有许多缓解技术在编译器这一层面实现。其中一些可视为对基于操作系统和硬件的缓解技术的补充。例如，PIC 技术将代码编译为位置无关的机器码指令，从而让这些指令可以被加载到任意地址；PIE 技术编译出的可执行文件的不同部分可以使用不同的基址，从而增加了攻击者猜测基址的难度。这两个技术都是 ASLR 的补充。另一些技术则从其它方面进行保护，例如 StackGuard, ProPolice, Address Sanitizer 等。基于编译器的缓解技术很多，且大多数都在主流编译器中有广泛应用，无法一一列举，以下主要介绍 RELRO 和 StackGuard 两种技术。

RELRO技术

RELRO 技术是一种保护机制，用于防止全局偏移表（GOT）被攻击者利用。在首次调用共享库函数时，动态链接器会将 GOT 表中的地址填充为真实地址。也就是说，GOT 表在程序运行时是可写的。并且，GOT 表需要位于已知位置，因为它包含了程序运行时的必要信息。这给了攻击者一个机会，可以通过覆盖 GOT 表中的地址来执行恶意代码。

RELRO 技术通过将 GOT 表标记为只读来解决这个问题。RELRO 技术有两种类型：Partial RELRO 和 Full RELRO。Partial RELRO 会在程序启动时将 GOT 表的部分标记为只读，通常只保护不频繁改变的全局变量和一些只读数据段。动态链接中的某些函数指针仍可能被攻击者利用。Full RELRO比Partial RELRO更安全，它会在程序加载完成后，将整个GOT段标记为只读。所有GOT表项，包括动态链接的函数指针，都会被标记为只读，彻底防止了指针修改。其缺点是对程序启动速度影响较大，因为它要求在程序运行前完成所有符号解析。

RELRO技术的绕过

RELRO 技术的绕过方法主要针对 Partial RELRO。对于 Partial RELRO，动态链接中的某些函数指针未受保护，例如 printf() 函数。可以通过覆写 GOT 表中的 printf() 函数指针来执行任意代码。

StackGuard 技术

StackGuard 通过在返回地址旁边插入一个“护符”（Canary）来防止返回地址被修改。该护符将会挡在缓冲区和返回地址之间。在函数体执行完毕后，控制返回前，它会将护符与保存在其它位置的副本进行比较，只有当护符保持不变时，才会跳转到函数的返回地址。在常规的栈溢出攻击中，攻击者采用的方法是线性、顺序且按升序覆盖字节。这使得在不覆盖护符的情况下改变返回地址几乎不可能。

StackGuard 技术的绕过

绕过 StackGuard 技术的主要思路是想办法找到护符的值。刚刚提到，护符位于缓冲区和返回地址之间的某个位置，同时在其它位置还会有护符的副本；在程序返回时，为了检查护符是否被篡改，护符通常还会被加载到寄存器中。这些情况为信息泄露攻击提供了机会。通过信息泄露攻击，攻击者可以获取到护符的值，从而绕过 StackGuard 技术。

漏洞 CVE-2024-9632 介绍

CVE-2024-9632 漏洞是一个缓冲区溢出漏洞。该漏洞存在于 xorg-xserver 中。该软件是 Linux 系统下最常见的显示服务器，用于管理图形显示设备。本地攻击者可以通过利用该漏洞发起拒绝服务攻击，如果 xorg-xserver 以 root 权限运行，攻击者还能获得提升的权限，甚至完全控制系统。该漏洞被标记为高危险性。

漏洞原理

产生漏洞的代码如下：

        XkbSymInterpretPtr sym;
        unsigned int skipped = 0;

        if ((unsigned) (req->firstSI + req->nSI) > compat->num_si) {
            compat->num_si = req->firstSI + req->nSI;
            compat->sym_interpret = reallocarray(compat->sym_interpret,
                                                 compat->num_si,
                                                 sizeof(XkbSymInterpretRec));
            if (!compat->sym_interpret) {
                compat->num_si = 0;
                return BadAlloc;
            }
        }

其中，compat->sym_interpret 是一个数组，存储了 XkbSymInterpretRec 类型的结构体，每个结构体表示一种键盘符号（symbol）与修饰符（modifier）组合的解释方式。该解释方式用于决定在特定符号与修饰符输入下应该执行的操作，例如：

激活一个功能键。
触发一个特定的动作（如执行 XFree86 私有动作 XkbSA_XFree86Private）。

而 compat->num_si 是一个整型变量，记录当前 compat->sym_interpret 数组中元素的个数。

在这段代码中没有出现的还有一个变量，那就是 compat->size_si。该变量用于记录 compat->sym_interpret 数组的容量。它和 compat->num_si 的区别在于，compat->num_si 记录的是当前数组中的元素个数，而 compat->size_si 记录的是数组的容量。也就是说，在理想情况下，compat->num_si 应该永远小于等于 compat->size_si。当 compat->num_si 等于 compat->size_si 时，表示数组已满。

xorg-xserver 允许客户端发起更新 compat->sym_interpret 数组的请求。请求中的 firstSI 和 nSI 字段分别表示要更新的数组元素的起始位置和更新的元素个数。当它们之和超过了当前元素个数时，表示客户端需要增加数组的大小。reallocarray 函数会重新分配内存，以容纳新的元素。这就是这段代码的主要工作。

然而，这段代码中仅仅更新了 compat->num_si，而没有更新 compat->size_si。这样就可能不再满足上文提到的 compat->num_si 应永远小于等于 compat->size_si 的假设。在之后，它调用 reallocarray 将 compat->sym_interpret 调整为了 compat->num_si 的大小。这就导致数组被分配到的内存空间超过了它本应占有的内存空间 compat->size_si，从而导致了缓冲区溢出漏洞。攻击者可以通过构造一个特别长的更新请求来触发这个漏洞。

防御措施

以下是修复补丁，相关链接

@@ -2990,13 +2990,13 @@ _XkbSetCompatMap(ClientPtr client, DeviceIntPtr dev,
         XkbSymInterpretPtr sym;
         unsigned int skipped = 0;
 
-        if ((unsigned) (req->firstSI + req->nSI) > compat->num_si) {
-            compat->num_si = req->firstSI + req->nSI;
+        if ((unsigned) (req->firstSI + req->nSI) > compat->size_si) {
+            compat->num_si = compat->size_si = req->firstSI + req->nSI;
             compat->sym_interpret = reallocarray(compat->sym_interpret,
-                                                 compat->num_si,
+                                                 compat->size_si,
                                                  sizeof(XkbSymInterpretRec));
             if (!compat->sym_interpret) {
-                compat->num_si = 0;
+                compat->num_si = compat->size_si = 0;
                 return BadAlloc;
             }
         }

从补丁文件中可以看出，主要的修复措施是在更新 compat->num_si 时，同时更新 compat->size_si。这样就保证了 compat->sym_interpret 数组的大小不会超过它的容量。

总结

本文介绍了缓冲区溢出漏洞的概念，以及各种缓解缓冲区溢出漏洞的技术。其中，NX 技术通过将内存区域标记为不可执行来防止代码注入攻击；ASLR 技术通过随机化进程各个部分的基址来增加攻击者猜测基址的难度；RELRO 技术通过将 GOT 表标记为只读来防止攻击者利用 GOT 表；StackGuard 技术通过在返回地址旁边插入一个护符来防止返回地址被修改。最后，本文介绍了一个最近的栈溢出漏洞 CVE-2024-9632 的原理和修复措施。可以看到，尽管有了这些防御措施，但仍然有很多方法可以绕过这些技术，而错误的代码实现也会导致漏洞的产生。现有的漏洞缓解技术仍有很大提升空间，值得进一步研究。同时开发者也应该在编写代码时遵循安全编程规范，同时关注最新的漏洞信息，及时修复已知的漏洞。

Manjaro Linux默认LUKS全盘加密解密慢，启动慢

Sun, 15 Jan 2023 12:22:26 +0800

前言

我的manjaro安装的时候选择了全盘安装，勾选luks加密。加密虽好，但是我发现这里有个问题，manjaro启动的时候解密时间非常的长，需要10s左右。这显然不正常。经过搜索，我发现这个问题很可能跟LUKS的iter-time这个参数有关https://bbs.archlinux.org/viewtopic.php?id=217193。以下是archwiki里面关于iter-time参数的介绍：

Number of milliseconds to spend with PBKDF2 passphrase processing. Release 1.7.0 changed defaults from 1000 to 2000 to “try to keep PBKDF2 iteration count still high enough and also still acceptable for users."[2]. This option is only relevant for LUKS operations that set or change passphrases, such as luksFormat or luksAddKey. Specifying 0 as parameter selects the compiled-in default..

大体上就是LUKS等待PBKDF2解密密钥的时间。默认是2000ms，这个数字对于新的机器来说其实有点太高了，现代cpu大多不需要这么长的解密时间。所以我们可以适当缩短这个时间。

正文

参考https://unix.stackexchange.com/questions/690138/how-to-modify-iter-time-on-a-existing-luks-partition,我们可以修改这个iter-time。使用以下命令：

`1`	`sudo cryptsetup luksChangeKey <device> --iter-time <time in ms>`

<device>填写LUKS加密的分区，可以用lsblk查看。<time in ms>填写以毫秒为单位的iter-time，我填了300，也有看到有人填60的。取决于你的cpu。这还会要求你修改密码，如果你不希望修改，你可以直接填写原来的密码。注意，这个命令需要执行两次，原因我下面讲。

表面上看，只需要执行一次命令，修改一次就可以了。然而实际上还是有问题。manjaro的全盘加密默认注册了两个key slot。slot 0是通过我们设置的密码加密的，而slot 0解锁之后会解密一个密钥文件，通过这个密钥再来解密slot 1，进而解密整个硬盘。上面的命令会修改slot 0，但是修改后却会将其放在slot 2的位置。LUKS是按顺序尝试解锁的，这会导致LUKS先尝试解锁slot 1，解锁失败后再尝试slot 2，白白浪费了时间。怎么办呢？很简单，我们再执行一次这个命令。这个命令是将修改后的key放在最小的空slot。第一次执行命令时，slot 0和slot 1都被占用，所以新key放在了slot 2。这时slot 0才被清除。所以第二次执行命令时，slot 1和slot 2都被占用，新key就会被放回slot 0。这样就能达成我们的目的了。

结语

经过以上调整，我的开机解密时间缩短到了原来的1/10不到，大大提高了开机速度，让我觉得之前的开机都是在浪费生命XD。另外也了解到了不少关于LUKS的知识。可见折腾好处多多，能用就行的思想要不得😛。

在全盘加密的Manjaro Linux上配置安全启动(Secure Boot)

Tue, 03 Jan 2023 22:10:46 +0800

本文已过期。GRUB的一次更新要求GRUB使用的字体也必须签名，这让GRUB配置安全启动变得麻烦。如果要配置Secure Boot，推荐换用systemd-boot或rEFInd等引导器。对于这些引导器，Arch Wiki的教程已非常详细。例如，我现在采用的systemd-boot+sbctl的方案，可参考https://wiki.archlinuxcn.org/wiki/UEFI/%E5%AE%89%E5%85%A8%E5%90%AF%E5%8A%A8#sbctl

前言

本文主要介绍使用shim+MOK+grub2实现安全启动全盘加密的Manjaro Linux。

首先说一下我的环境，我的电脑是宏碁spin5，Manjaro是使用的全盘安装，btrfs格式分区，勾选全盘加密。

在开始以下工作之前，建议先将secureboot恢复到出厂设置。

分析

首先当然要看看Arch Wiki。以下内容也大量借鉴了这篇wiki。

这里提到要发挥secure boot安全功能的建议：

设置一个强的硬件设置密码。（一般来说，在bios里面设置）
不使用默认的厂商密钥和第三方密钥。根据Archwiki的警告，有变砖风险，这里就不折腾了。
uefi直接启动内核，包括microcode和initramfs，不使用启动加载器。这主要是缩短启动信任链的长度，减少被攻击的环节。这个方案推荐和第2条一起食用，这样比较方便，这里也不折腾了。
启用全盘加密。避免能碰到你硬件的人乱动硬盘内容。
使用TPM加强secure boot。

然后简单看看实现secureboot的方案。

首先就是使用自己的密钥，优点是所有情况都在自己掌握之中，你可以完全控制签名哪些启动项来启动，非常安全。缺点是容易变砖，另外你需要对每个启动项签名，对于windows你也要自己配置。这里不采用这种方案，因为怕变砖。
其次是使用已经经过微软签名的启动加载器。这样的加载器有两个，一个是preload，一个是shim。preload只能使用hash来验证启动项目，并且在preload阶段使用它的hash tool来导入hash。这一来比较麻烦，每次启动加载器或者内核更新都要重新导入一遍hash，hash多了还要自己清理，二来preload阶段全盘加密没有解开，hash tool也访问不到内核镜像。所以放弃这个方案，使用shim。shim可以用hash，也可以用MOK，我们这里介绍的是shim+MOK的方案。

正文

释义

下文中，$esp指的是你的efi分区位置。请在所有提到$esp的地方自觉替换。下文中大多数命令需要root权限执行。

软件安装

你需要安装以下软件：

shim-signed (aur)
sbsigntools

设置shim

（注：本节部分有误。bootx64.efi是systemd-boot的默认位置。）备份bootx64.efi。这一般认为是电脑的默认启动项，我们用shim来代替他。

`1`	`mv $esp/EFI/boot/bootx64.efi $esp/EFI/boot/bootx64.efi.bak`

将shim复制到原来bootx64.efi的位置

1
2

cp /usr/share/shim-signed/shimx64.efi $esp/EFI/BOOT/BOOTx64.EFI
cp /usr/share/shim-signed/mmx64.efi $esp/EFI/BOOT/

最后，创建一个新的nvram入口指向shim

`1`	`efibootmgr --unicode --disk /dev/$disk --part $Y --create --label "Shim" --loader /EFI/BOOT/BOOTx64.EFI`

这里的$disk请替换成你的efi分区所在磁盘，大多数人应该是sda或者sdb，但是像我就是nvme0n1。$Y请替换成你的efi在这块磁盘上是第几个分区。这些可以通过lsblk命令得到。

设置grub

接下来，我们要对grub进行设置。要使grub能在secureboot模式下启动，grub必须集成了能让它读取到vmlinuz和initramfs的所有模块。你可以参考ubuntu的grub生成脚本来选择你所需要的模块。然后，将这些模块记录成环境变量使用。

作为参考，我是这么处理的。新建/etc/grub_modules文件，内容如下：

CD_MODULES="
	all_video
	boot
	btrfs
	cat
	chain
	configfile
	echo
	efifwsetup
	efinet
	ext2
	fat
	font
	gettext
	gfxmenu
	gfxterm
	gfxterm_background
	gzio
	halt
	help
	hfsplus
	iso9660
	jpeg
	keystatus
	loadenv
	loopback
	linux
	ls
	lsefi
	lsefimmap
	lsefisystab
	lssal
	memdisk
	minicmd
	normal
	ntfs
	part_apple
	part_msdos
	part_gpt
	password_pbkdf2
	png
	probe
	reboot
	regexp
	search
	search_fs_uuid
	search_fs_file
	search_label
	sleep
	smbios
	squash4
	test
	true
	video
	xfs
	zfs
	zfscrypt
	zfsinfo
	cpuid
	play
	tpm
	"
GRUB_MODULES="$CD_MODULES
	cryptodisk
	gcry_arcfour
	gcry_blowfish
	gcry_camellia
	gcry_cast5
	gcry_crc
	gcry_des
	gcry_dsa
	gcry_idea
	gcry_md4
	gcry_md5
	gcry_rfc2268
	gcry_rijndael
	gcry_rmd160
	gcry_rsa
	gcry_seed
	gcry_serpent
	gcry_sha1
	gcry_sha256
	gcry_sha512
	gcry_tiger
	gcry_twofish
	gcry_whirlpool
	luks
	lvm
	mdraid09
	mdraid1x
	raid5rec
	raid6rec
	"

之后source这个文件即可。

注意：如果你在grub启动后遭遇unkown tpm error问题，请删除tpm模块。

除了这些模块，你的grubx64.efi还需要有一个sbat小节。以下是完整的生成命令：

1
2

source /etc/grub_modules
grub-install --target=x86_64-efi --efi-directory=$esp --modules="${GRUB_MODULES}" --sbat /usr/share/grub/sbat.csv

签名

然后你需要创建MOK，也就是机器所有者密钥。这里建议你选择一个合适的工作目录进行生成。我选择了创建一个/etc/MOK目录。生成密钥并且签名。

mkdir -p /etc/MOK
cd /etc/MOK
openssl req -newkey rsa:4096 -nodes -keyout MOK.key -new -x509 -sha256 -days 3650 -subj "/CN=my Machine Owner Key/" -out MOK.crt
openssl x509 -outform DER -in MOK.crt -out MOK.cer
sbsign --key MOK.key --cert MOK.crt --output /boot/$vmlinuz /boot/$vmlinuz
sbsign --key MOK.key --cert MOK.crt --output $esp/EFI/Manjaro/grubx64.efi $esp/EFI/Manjaro/grubx64.efi

这里的$vmlinuz请替换成你自己的linux内核镜像文件名。你可以用

`1`	`ls /boot \| grep 'vmlinuz'`

得到你需要签名的文件的完整列表。

这里的$esp/EFI/Manjaro是Manjaro的grub默认配置文件生成grub的位置。这个位置可能有以下几种情况：

在没有配置文件的情况下执行grub-install，将会生成在$esp/EFI/grub
在通过grub-mkconfig等命令创建了grub配置文件的情况下，这个位置由/etc/default/grub中的GRUB_DISTRIBUTOR指定。例如在Manjaro中，这个值默认是manjaro，所以最终生成目录在$esp/EFI/Manjaro 请仔细确认你的grub生成位置。下文中提到$esp/EFI/Manjaro的地方，请自行替换。

签名完成后，将生成的MOK.cer复制到$esp/目录，为后续导入做准备。

完成

最后，将grub复制到shim同目录下。

`1`	`cp $esp/EFI/Manjaro/grubx64.efi $esp/EFI/boot/grubx64.efi`

然后重启电脑，启动项选shim进入shim，这时shim会有一个错误提示界面。不要慌，这是因为你的MOK文件还未导入MOK list。按页面提示进入MokManager，然后选择Enroll key，选择刚刚复制过来的MOK.cer，按提示导入这个密钥即可。

后续工作

虽然现在你的电脑已经支持secureboot了，但是对grub和对vmlinuz的签名是一次性的，一旦这两个软件更新，你就需要重新签名。这显然非常不方便。为此，我们可以设置两个pacman钩子，在这两个软件更新的时候自动进行签名。因为每个人终端环境不一样，比如我就无法直接使用archwiki上记载的hook。所以此处仅供参考。需要注意的是，以下命令并不检查签名情况，在已经签名的情况下依然会附加另一个签名，可能导致内核和grub不断增大。但以一般人更新的频率来看，应该不会有太大影响。

创建/usr/local/bin/sign_kernel_for_secureboot.sh，内容如下：

1
2

#! /bin/sh
/usr/bin/find /boot/ -maxdepth 1 -name 'vmlinuz-*' -exec /usr/bin/sh -c '/usr/bin/sbsign --key /etc/MOK/MOK.key --cert /etc/MOK/MOK.crt --output {} {};' \;

并且为其赋予可执行权限：

`1`	`sudo chmod +x /usr/local/bin/sign_kernel_for_secureboot.sh`

创建/etc/pacman.d/hooks/999-sign_kernel_for_secureboot.hook，内容如下：

[Trigger]
Operation = Install
Operation = Upgrade
Type = Package
Target = linux
Target = linux-lts
Target = linux-hardened
Target = linux-zen
Target = linux515

[Action]
Description = Signing kernel with Machine Owner Key for Secure Boot
When = PostTransaction
Exec = /usr/local/bin/sign_kernel_for_secureboot.sh
Depends = sbsigntools
Depends = findutils

这里的$linuxX自行替换成你的linux内核包名。例如对于manjaro的5.15内核，这里应该替换为linux515。

然后是对grub进行签名的钩子。

新建 /usr/local/bin/sign_grub_for_secureboot.sh 内容如下：

#! /bin/bash
source /etc/grub_modules
grub-install --target=x86_64-efi --efi-directory=$esp --modules="${GRUB_MODULES}" --sbat=/usr/share/grub/sbat.csv
sbsign --key /etc/MOK/MOK.key --cert /etc/MOK/MOK.crt --output $esp/EFI/Manjaro/grubx64.efi $esp/EFI/Manjaro/grubx64.efi
cp $esp/EFI/Manjaro/grubx64.efi $esp/EFI/boot/grubx64.efi

并且为其赋予可执行权限。

`1`	`sudo chmod +x /usr/local/bin/sign_grub_for_secureboot.sh`

新建 /etc/pacman.d/hooks/999-sign_grub_for_secureboot.hook 内容如下：

[Trigger]
Operation = Install
Operation = Upgrade
Type = Package
Target = grub

[Action]
Description = Signing kernel with Machine Owner Key for Secure Boot
When = PostTransaction
Exec = /usr/local/bin/sign_grub_for_secureboot.sh
Depends = sbsigntools
Depends = grub

完成。