Arm64架构Linux的UEFI安全启动现状分析

Arm设备无处不在，其中许多运行着Linux系统。该操作系统也为全球的云计算和IT环境提供动力。然而，x86仍然是全球计算机硬件的主导架构，统一可扩展固件接口(UEFI)与安全启动已成为标准。那么从Arm的角度来看，UEFI的情况如何呢？

作为快速回顾：UEFI最初由英特尔为其基于Itanium的高端数据中心计算机开发。那是在90年代末和2000年代初，当时它简称为EFI（可扩展固件接口）。2005年，英特尔将其开发工作移交给统一EFI论坛。大约在同一时间，第一个名为Tiano的UEFI开源实现也发布了。几年后，很明显传统BIOS（基本输入/输出系统）将被新的固件技术所取代。

UEFI解决了一些可扩展性挑战，如大磁盘问题，以及安全问题。这就是安全启动出现的背景。但这一演进步骤基本未受关注，直到2011年底微软宣布Windows 8硬件认证将要求UEFI和安全启动。这一公告在Linux社区引起了担忧和激烈讨论。为什么？很快发现Linux在这些设备上默认无法启动。看起来需要重大努力和游说工作才能克服这一挑战。

但回到x86平台。很快就有了可行的解决方案，它不仅被不同的Linux供应商和社区采用，也得到了微软的支持。诀窍是一个名为shim的小型EFI二进制文件，由微软签名。获得Windows制造商的认可意味着在启用安全启动时，UEFI会愉快地执行它。Shim为安全地将其他证书和签名引入固件打开了一扇门。那些需要更精细控制或包含更多自己代码的用户可以将机器所有者密钥(MOK)注册到UEFI安全启动过程中。

这种设置在x86世界中运行良好了相当长时间，被Ubuntu、Fedora和openSUSE等系统使用。主要的Linux发行版——包括企业版和社区版——都带有微软签名的shim。在安装过程中，用于签名引导加载程序、内核及其模块的证书会被添加到UEFI中。信任硬件和固件并启用安全启动将允许Linux正常启动。用户不会注意到任何差异。

**强势的Arm策略**

树莓派等设备及其单板计算机克隆版本的巨大成功，近年来大大增加了该硬件平台的采用率。毫不意外，Linux在Arm上的安装也是如此。如今每个人都在谈论AARCH64或Arm64，这是Arm的64位版本。虽然32位变体按UEFI规范正式支持，但它们实际上不起重要作用。

整个话题有两个不同方面。第一个是考虑随硬件提供何种UEFI功能。第二个与Linux如何处理它有关。

虽然核心UEFI规范与架构无关，但其在基于Arm的设备上的实现有所不同。Arm世界的工作方式与x86不同。芯片制造商不是几家而是数十家。记住Arm公司本身只发布芯片设计规范。芯片的实际实现由其他公司完成。由于硬件的这种多样性，固件没有统一的画面。每个芯片供应商通常生产自己的固件，通常不可替换/不兼容其他产品。更糟糕的是，它不是UEFI，这可能意味着没有安全启动。

但是有一些共同点：那些Arm设备上Linux引导加载程序的事实标准。这个名为U-boot的软件确实提供了UEFI规范的兼容性并允许安全启动。然而，走这条路时有两个主要考虑因素。首先，u-boot本身不带任何预部署的证书和密钥。这与x86世界发生的情况有巨大差异。在那里，人们可以期望至少微软的证书和密钥在安装的固件中可用。

需要澄清的是，u-boot本身不是固件。供应商固件存储在板上的芯片中。然后这个固件加载u-boot，u-boot存储在外部驱动器上，例如USB或SD卡。U-boot然后提供标准并加载Linux。

要使用u-boot启用安全启动，您需要创建和部署自己的证书和密钥。这有点麻烦，因为没有GUI，而且显然非常特定于这个引导加载程序。此外，用户还需要签名u-boot加载的任何内容。

但也有另一个不同的选择。通过u-boot启动包含几个阶段，可以偷偷切换到UEFI。这里的挑战不是实现启动序列偏差——而是该硬件特定UEFI实现的可用性。有树莓派3和4以及其他一些基于Arm的设备的工作示例。所谓的RK3588芯片看起来特别有前景。这种方法的好处是几乎与x86世界已知的用户体验相同。

**软件方面的生活**

从Linux操作系统的角度来看是什么样的？

考虑到x86端UEFI安全启动的性质，人们不会期望任何意外。技术、源代码、流程——它们独立于硬件平台。因此，在x86世界中有效的任何东西在Arm端也应该/将会有效。现实表明，对于Debian、Canonical/Ubuntu和SUSE来说确实如此。这意味着相应的发行版——社区版和企业版——只需在启用UEFI安全启动和预部署微软密钥/证书的情况下在Arm上安装即可。

然而，在Red Hat生态系统中工作的人可能会得到截然不同和令人惊讶的结果。社区变体Fedora带有未签名的shim。因此，安装无法开箱即用。在RHEL（Red Hat企业Linux）端，惊喜更大。shim已签名，但不是使用微软证书/密钥。相反，使用了Red Hat的证书。在这两种情况下，最好的前进方式是在禁用安全启动的情况下安装Linux。之后用户可以创建和部署自己的证书和密钥，使shim或grub2二进制文件对UEFI可信。

有趣的是，基于Red Hat代码的CentOS Stream和Alma Linux准备得更好。它们带有微软签名的shim。根据相关邮件列表的讨论，至少Fedora很快就能开箱即用，这是有希望的。

最终结论是什么？凭借来自x86端的所有经验和知识，Linux社区已经做好了在Arm平台上实现UEFI安全启动的充分准备。如上所述，有轻微的初期问题机会，但总体来说看起来很不错。

挑战部分在硬件/固件端。不能期望UEFI是已发货Arm设备的一部分。它可以后来集成，但不总是可以，且选项有限。最好的希望基于引导加载程序u-boot，无论是独立的还是链式加载基于EDKII项目的硬件特定UEFI实现。

Q&A

Q1：UEFI安全启动在Arm设备上为什么比x86更复杂？

A：主要原因是Arm生态系统的多样性。与x86只有少数几家制造商不同，Arm有数十家芯片制造商，每个供应商通常生产自己的固件，通常不可替换且不兼容其他产品。更重要的是，许多Arm设备的固件并非UEFI，这意味着可能没有安全启动功能。

Q2：u-boot在Arm设备的UEFI安全启动中起什么作用？

A：u-boot是Arm设备上Linux的事实标准引导加载程序，它提供UEFI规范兼容性并支持安全启动。但与x86不同，u-boot本身不带预部署的证书和密钥，用户需要创建和部署自己的证书和密钥来启用安全启动。

Q3：不同Linux发行版在Arm64安全启动支持上有什么差异？

A：Debian、Ubuntu和SUSE可以直接在启用UEFI安全启动的Arm设备上安装。但Red Hat生态系统有所不同：Fedora的shim未签名，RHEL使用Red Hat而非微软签名。CentOS Stream和Alma Linux则带有微软签名的shim，支持更好。