据我所知，UEFI 及其安全启动存在严重问题，而且肯定不是前进的方向。
看：https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface#Criticism
还这里它说：
对于 SecureBoot，需要验证签名的 UEFI 系统不是开源的。即使它是开源的，这并不意味着系统预装了您用于签名的密钥。
所以我想问 UEFI 安全启动是否有一个开源版本？
答案1
最接近 UEFI 替代方案的是核心引导。
答案2
实际上，验证安全启动签名的部分是打开。它是英特尔 TianoCore 的一部分。问题是，当您购买现成的硬件时，无法检查硬件供应商实际放入的内容。但这是 PC 固件的普遍问题，而不是安全启动本身的问题。
开源操作系统本身（例如 Linux 或 FreeBSD）中安全启动的系统端也是完全开源的。
安全启动确实有其问题 - 签名方案非常糟糕 - 但“缺乏开放性”并不是其中之一。
答案3
这并不是真正的直接替代方案，也可能不是您正在寻找的，但需要 TPM（可信平台模块）的类似解决方案称为“可信启动”或 tboot。它在一些关键方面有所不同，但其最终目标是相同的 - 在引导链和系统状态中建立一定程度的信任。
Tboot 本身实际上是一个称为 MLE（或测量启动环境）概念的开源实现。简而言之，它是一团二进制代码，执行并利用 Intel TXT 将机器置于特权和可信状态，然后可以对操作系统和相关组件进行测量（TPM 1.2 中的 SHA-1 哈希值），以及将它们推送到 TPM 以安全存储。例如，在 Linux 中，tboot 可以设置为在内核加载之前立即执行，它将生成内核二进制文件、内核参数和 initramfs 映像的哈希值，并将它们分别发送到 TPM。
此外，TPM 和兼容的主板/BIOS 还允许在启动过程的早期对系统中的各种组件进行测量，例如 BIOS 映像本身、自定义 BIOS 设置、PCI 卡固件（GPU、NIC 等） ）、引导加载程序（例如 grub）等等。您可能想知道这些测量有什么用处？好吧，他们自己并不多。相反，当且仅当这些测量值是特定值时，TPM 可用于执行许多操作，例如读取/写入 TPM NVRAM，或解密只有 TPM 可以解密的密钥。这些测量结果还可以安全地（如果需要的话可以匿名）传送给另一方，以便该方可以远程建立信任。随后，如果 TPM 在其 PCR 中有一些特定的测量，系统可以被设计为仅启动或执行某些软件，这意味着它启动了一组特定的软件 - 即它提供了完整性。
从根本上讲，TPM 和 tboot 相结合提供了广泛的系统覆盖范围，至少在纸面上据我所知，可以通过使用 API 将哈希值发送到 TPM 进行存储来扩展以测量/哈希几乎任何您想要的内容。需要注意的一件重要事情是，哈希值不会简单地直接加载到 TPM 中。相反，当哈希值要存储在 TPM（PCR 或平台配置寄存器）的内部寄存器中时，它会与寄存器的先前值连接，并对 blob 进行哈希处理，并将结果存储在寄存器中。结果是每个寄存器都会累积状态，并且一路上的任何差异都会导致最终值发生变化。这称为 tpm“扩展”。
从根本上讲，我认为 TPM 和 tboot 提供的功能比安全启动多得多。 TPM 是一种通用加密协处理器，可用于安全存储、RNG、向其他主机报告系统状态（证明）等。
与安全启动不同的是，安全启动利用签名并在签名未签出时停止启动过程，而 TPM/tboot 不使用签名，也不会直接停止启动序列。相反，系统必须设计为通过要求 TPM 执行某些操作来防止启动失败，只有当系统处于某种定义的状态（如果需要）时，它才会执行这些操作。
至于您对开源位及其透明度的担忧，即使是 tboot/TPM 也会深入到隐式信任的层次，实际上，这在我看来是不可避免的信仰飞跃，除非实际上每个软件都是开源的，以及硬件，以及硬件原理图都被理解了。对于 tboot 和 TPM，这种隐式信任一直延伸到芯片组和处理器本身。据称，公钥校验和被嵌入到芯片组中，处理器微代码使用该校验和来启动信任链。我所拥有的文本中并未完全解释此校验和，但所解释的是签名是由驻留在 BIOS 映像中的代码块上的处理器微代码验证的，该代码块对于 SRTM 称为 BIOS ACM，对于 DRTM 称为 SINIT ACM。当然，为了验证签名，必须使用公钥，我的猜测是，由于空间原因，公钥嵌入到 ACM 中，并根据前面提到的硬件驻留校验和进行验证。