PDF开源固件
步入内核背后的世界。
Jessie Frazelle
Windows、Linux 和 macOS 等操作系统都有内核。内核控制对系统资源的访问。它包含允许多个进程共享硬件机制（如 CPU、内存、磁盘 I/O 和网络）的逻辑。
当计算机启动时，用于初始化 DRAM（动态随机存取存储器）、硅和设备的主要接口是固件。固件使用引导加载程序初始化操作系统。您可能听说过 GRUB（源自 Grand Unified Bootloader），它是 Linux 发行版常用的引导加载程序。
每台计算机或服务器通常都配备由其制造商生产的固件。固件存在于 SSD（固态硬盘）/HD（硬盘）、键盘、鼠标、CPU、网卡和其他设备中。
固件中的漏洞可能会造成很大危害，因为固件负责许多特权操作。例如，考虑对 SoftLayer3（一家裸机云服务提供商）的黑客攻击，其中 BMC（基板管理控制器）被黑客入侵以留下后门，以便在客户使用后重新配置服务器时，黑客仍然可以访问该服务器。任何云提供商的最低标准是为用户提供一台机器，该机器在使用后被干净彻底地擦除。这显然违反了该承诺。
更糟糕的是，大多数固件都是专有的。以最高权限运行的代码具有最低的可见性。这导致了可能同时影响多个平台用户的漏洞和事件。对于黑客来说，这就像猫薄荷。
开源固件可以通过使固件的行为更加可见且不太可能造成危害，从而帮助将计算带到一个更安全的地方。本文的目标是让读者感到有能力要求供应商做得更多，从而帮助推动这一变革。
这是对一个复杂主题的介绍；某些章节仅触及表面，但目的是提供开源固件世界的全貌。
特权级别
今天的计算机具有各种特权级别。
• Ring 3 — 用户空间。此环具有最少的特权。这是用户程序运行的地方。用户空间沙箱可以进一步限制特权。
• Ring 0 — 内核。这是操作系统内核；开源操作系统允许查看内核背后的代码。
• Ring -1 — Hypervisor（虚拟机监控器）。此 VMM（虚拟机监控器）创建和运行虚拟机。Xen、KVM、bhyve 等开源虚拟机监控器提供了查看此环背后代码的途径。
• Ring -2 — SMM（系统管理模式）、UEFI（统一可扩展固件接口）内核。这是控制所有 CPU 资源的专有代码（稍后详细介绍）。
• Ring -3 — 管理引擎。这是专有代码，只要主板接收到电源，即使它已关闭，该代码也会运行（稍后详细介绍）。
此摘要清楚地表明，Ring -1 到 3 可以选择使用开源软件，并且对软件具有大量的可见性和控制权。Ring -1 以下的特权级别允许较少的控制，但随着开源固件社区和项目的发展，情况正在改善。
最不可思议的是，可见性最低的代码却拥有最高的特权。这正是开源固件旨在解决的问题。该生态系统的目标是专注于使固件更不容易造成危害，并使其行为更加可见。
Ring -2：SMM、UEFI 内核
此环控制所有 CPU 资源。SMM 对其顶部的堆栈的其余部分是不可见的。它最初用于电源管理和系统硬件控制。它处理系统事件，例如内存或芯片组错误。
UEFI 是操作系统和 BIOS 固件之间的接口。EFI（UEFI 的前身）的创建是为了解决 BIOS 位和地址限制。从那时起，UEFI 规范中添加了更多功能，包括加密、网络和身份验证。UEFI 内核非常复杂，包含数百万行代码。它由启动服务和运行时服务组成。如果您想深入研究，规范 (https://uefi.org/specifications) 非常冗长。UEFI 应用程序（例如 UEFI shell、GRUB、Gummiboot 或 Windows Boot Manager）可以选择在启动后处于活动状态。
UEFI 内核是许多漏洞的常见载体，因为它具有与许多不同平台上使用的某些相同的专有代码。GRUB 和 Windows Boot Manager 等引导加载程序是平台特定的。UEFI 内核在多个平台上共享，使其成为攻击者的绝佳目标。
此外，由于只有 UEFI 可以重写自身，因此可以使漏洞持久存在。这是因为 UEFI 存在于处理器的固件中，通常存储在 SPI（串行外围接口）闪存中。即使用户擦除整个操作系统或安装新的硬盘驱动器，攻击也会在 SPI 闪存中持续存在。
Ring -3：管理引擎
在英特尔 (x86) 的情况下，Ring -3 是 Intel Management Engine（英特尔管理引擎）7。它可以打开节点并以不可见的方式重新映像磁盘。它有一个运行 Minix11 的内核，以及一个 Web 服务器和整个网络堆栈。因此，Minix 是世界上使用最广泛的操作系统。管理引擎中有很多功能；可能需要一整天才能列出所有功能，但有很多资源可用于深入研究更多细节。16
在 Ring -2 和 Ring -3 之间，我们的堆栈中至少还有两个半内核，它们具有许多功能。这些内核中的每一个都有自己的网络堆栈和 Web 服务器，这是不必要的，并且可能很危险，特别是如果您不希望这些环通过网络联系以更新自身。代码也可以修改自身并在断电和重新安装后持续存在。这些环中的代码实际上在做什么，我们几乎看不到，考虑到这些环具有最高的特权，这令人恐惧。
它们都有漏洞
对于任何人来说，Ring -2 和 Ring -3 都有相当多的漏洞应该不足为奇。这里的漏洞发生时具有巨大的影响范围。例如，Intel Management Engine 的 Web 服务器中存在一个错误。14 七年没有人意识到该错误的存在。
我们如何才能做得更好？
固件项目
固件项目通常存储在 SPI 闪存中。
u-boot 和 coreboot
u-boot (https://www.chromium.org/developers/u-boot) 和 coreboot (https://www.coreboot.org/) 是开源固件。它们处理硅和 DRAM 初始化。Google Chromebook 同时使用两者：x86 上使用 coreboot，其余部分使用 u-boot。这是 Google 验证启动2 的一部分方式。验证启动降低了恶意软件的风险，允许安全的软件更新，并确保设备上软件的完整性。
Coreboot 的设计理念是“执行确保硬件可用所需的最低限度，然后将控制权传递给称为有效负载的不同程序” (https://doc.coreboot.org)。在这种情况下，有效负载是 LinuxBoot。
LinuxBoot
LinuxBoot (https://www.linuxboot.org/)，以前称为 Non-extensible Reduced Firmware 或 NERF (https://trmm.net/NERF)，处理设备驱动程序、管理网络堆栈并提供多用户、多任务环境。它使用 Linux 构建，以便单个内核可以用于多个板。可以说，最好使用具有大量关注的开源内核，而不是两个半其他内核，它们都是不同的且封闭的。这意味着您正在通过使用更少的代码变体来减少攻击面，并且您正在努力依赖开源代码。Linux 通过用强化的 Linux 驱动程序替换最少测试的固件驱动程序来提高启动可靠性。（Linux 比大多数专有系统都经过了更严格的审查；它受到了广泛的关注，因为它被广泛使用。）
通过使用已经有工具的内核，固件开发人员可以使用他们已经知道的工具进行构建。当他们需要编写签名验证、磁盘解密等逻辑时，他们可以使用一种现代、易于审计、可维护和可读的语言。
运行时
运行时使系统能够使用开源固件并运行自定义编程逻辑。
Heads
Heads (http://osresearch.net/) 是 coreboot 的一种配置，它具有安全配置的 Linux 内核作为 coreboot 有效负载。它适用于服务器和笔记本电脑。该项目由 Trammel Hudson 发起，受到多年固件漏洞研究的影响 (Thunderstrike, https://trmm.net/Thunderstrike; 和 Thunderstrike 2, https://trmm.net/Thunderstrike_2)。
u-root
u-root (https://github.com/u-root/u-root) 是一组 Golang 用户空间工具和引导加载程序。它用作 LinuxBoot 中 Linux 内核的 initramfs。
通过开源，这种新的固件堆栈有助于提高以前非常专有的许多组件的可见性。使用 LinuxBoot 使启动时间快了 20 倍。12 将开放计算节点启动到 Linux shell 从 8 分钟缩短到 17 秒，速度提高了 32 倍。
所有其他固件呢？
许多其他设备也需要开源固件。这些设备包括以下内容
• EC（嵌入式控制器）/SIO（超级 I/O）。这适用于移动设备和桌面平台。它控制键盘、温度监控等。
• TPM（可信平台模块）。这是加密密钥的安全家园。
• BMC（基板管理控制器）/ME（管理引擎）。BMC 与服务器平台相关联，而 ME 通常与客户端平台相关联。对于开源 BMC，有两个项目：OpenBMC (https://github.com/openbmc/openbmc) 和 u-bmc (https://github.com/u-root/u-bmc)。me_cleaner (https://github.com/corna/me_cleaner) 是用于将 Intel Management Engine 清理到最小必要功能的项目。
• NIC（网络接口控制器）。开放计算项目正在进行 NIC 3.013 的工作，这是 NIC 的规范。
• GPU（图形处理单元）。
• HDD（硬盘驱动器）/SSD（固态硬盘）。
• eMMC（嵌入式 MultiMediaCard (eMMC)/UFS（通用闪存存储）。移动系统的存储设备。
• 电源。
• CPLD（复杂可编程逻辑器件）、FPGA（现场可编程门阵列）。可编程逻辑组件。
• 风扇。
开源固件不仅对于提供堆栈的可见性是必要的，而且对于验证机器上软件的状态也是必要的。
英特尔的 Boot Guard
Boot Guard 应该验证处理器的固件签名。对于英特尔处理器，问题在于只有英特尔拥有用于签署固件包的密钥。这使得无法在这些处理器上使用 coreboot 和 LinuxBoot 或其等效项作为固件。如果您尝试这样做，固件将不会使用英特尔的密钥签名，并且启动失败的尝试将使主板变砖。
Matthew Garrett 关于 Boot Guard 的一篇文章强调了用户在固件方面的自由的重要性。1 硬件的所有者也有权拥有固件。Boot Guard 阻止了这一点。在 2018 年开源固件会议5 的安全主题演讲中，Trammel Hudson 描述了他如何找到绕过 Boot Guard6 的漏洞 (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-12169)；bugzilla 详细信息可以在 https://bugzilla.tianocore.org/show_bug.cgi?id=1614 中找到。该错误允许攻击者使用未签名的固件并正常启动，完全否定了 Boot Guard 的目的。
信任根
信任根的目标应该是验证安装在硬件每个组件中的软件是否是预期的软件。这样，您就可以毫无疑问地知道并验证硬件是否被黑客入侵。由于您对硬件中许多地方运行的代码几乎没有或根本没有可见性，因此目前很难做到这一点。您如何真正知道组件中的固件没有漏洞或没有任何后门？没有坚实的信任根，您就无法知道。
每个云服务和供应商似乎都有自己实现信任根的方式。微软有 Cerberus15，谷歌有 Titan18，亚马逊有 Nitro4。
Paul McMillan 和 Matt King 在 2018 年做了一个关于大规模保护硬件安全的演示文稿。8 它详细介绍了如何保护裸机安全，同时还让客户访问裸机。当客户将硬件退回给他们时，他们需要持续可靠地确保客户的任何东西都不会隐藏在硬件的任何组件中。
所有云服务都需要确保在客户使用计算资源后，他们运行的硬件没有受到损害。
平台固件弹性
芯片供应商正在根据 NIST（国家标准与技术研究院）指南17 投资 PFR（平台固件弹性）。这些指南侧重于确保固件保持完整性状态，检测到何时被损坏，并将固件碎片恢复到完整性状态。
供应商一直在围绕 NIST 关于 PFR 的指南构建功能。英特尔6 和 Lattice Semiconductor10 各自都有一个版本。OCP（开放计算项目）关于英特尔固件创新的演讲9 指出，英特尔正在使用 PFR 来交付微软 Cerberus 的认证原则。
挑战
开源固件的一个挑战涉及威胁模型。您是否拥有信任根以及该信任根如何运作取决于威胁模型。让我们通过一个例子深入探讨一下。如果您是一家拥有自己云的企业，您的威胁模型将阻止您使用任何可能包含漏洞或后门并威胁您的业务或客户数据的固件。在这种情况下，您理想情况下希望获得完全开源的信任根，以及服务器或笔记本电脑中每个设备的开源固件，并具有可重现的构建，以确保完整性。这将使您对正在运行的固件及其组成的逻辑具有最大的可见性。
另一个挑战是为所有设备编写固件。供应商在其系统中使用了很多设备选项，因此如果没有设备供应商的帮助，支持这么多设备将很困难。例如，考虑一下许多不同的供应商制造 DRAM 或 SSD。
如何帮助
本文的目标是提供一些关于使用开源固件构建的内容以及为什么使固件开源如此重要的见解。为了帮助这项工作，请帮助传播信息。尝试使用重视开源固件组件的平台。Chromebook 是一个很好的例子，Purism (https://puri.sm/) 计算机也是如此。询问您的提供商，他们正在做些什么来推进开源固件事业或使用信任根来确保硬件安全。
致谢
非常感谢开源固件社区，并向 Ron Minnich、Trammel Hudson、Chris Koch、Rick Altherr 和 Zaolin 致以敬意，感谢他们在这段旅程中对我的帮助。
参考文献
1. Garrett, M. 2015. Intel Boot Guard, Coreboot and user freedom.; https://mjg59.dreamwidth.org/33981.html.
2. Glass, S. 2013. Verified boot in Chrome OS and how to make it work for you. Embedded Linux Conference Europe; https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/42038.pdf.
3. Goodin, D. 2019. Supermicro hardware weaknesses let researchers backdoor an IBM cloud server. arsTechnica; https://arstechnica.com/information-technology/2019/02/supermicro-hardware-weaknesses-let-researchers-backdoor-an-ibm-cloud-server/.
4. Hamilton, J. 2019. AWS Nitro System. Perspectives; https://perspectives.mvdirona.com/2019/02/aws-nitro-system/.
5. Hudson, T. 2018. Open Source Firmware Conference Security Keynote; https://trmm.net/OSFC_2018_Security_keynote#Boot_Guard.
6. Intel. 2017. Intel Data Center Block with Firmware Resilience. Solution Brief; https://www.intel.com/content/dam/www/public/us/en/documents/solution-briefs/firmware-resilience-blocks-solution-brief.pdf.
7. Intel. 2017. What is Intel© Management Engine? Intel; https://www.intel.com/content/www/us/en/support/articles/000008927/software/chipset-software.html.
8. King, M., McMillan, P. 2018. Securing bare metal hardware at scale. BSides PDX; https://www.youtube.com/watch?v=PEVVRkd-wPM
9. Kumar, M. J. 2018. OCP initiatives and Intel implementations; https://www.opencompute.org/files/Intel-System-Firmware-InnovationsMohanKumar-OCP18.pdf.
10. Lattice Semiconductors. 2018. Universal Platform Firmware Resiliency (PFR) — Servers; http://www.latticesemi.com/en/Solutions/Solutions/SolutionsDetails02/PFR.
11. Leroux, S. 2017. The truth about the Intel's hidden Minix OS and security concerns. It's FOSS; https://itsfoss.com/fact-intel-minix-case/.
12. Minnich, R., et al. 2017. Replace your exploit-ridden firmware with a Linux kernel; https://schd.ws/hosted_files/osseu17/84/Replace%20UEFI%20with%20Linux.pdf.
13. OCP Server Workgroup, OCP NIC subgroup. Open Compute Project OCP NIC 3.0 Design Specification Version 0.85b. 2018 https://www.opencompute.org/wiki/Server/Mezz
14. Newman, L. H. 2017. Hack brief: Intel fixes a critical bug that lingered for 7 dang years. Wired; https://www.wired.com/2017/05/hack-brief-intel-fixes-critical-bug-lingered-7-dang-years/.
15. Open Compute Project. 2018. Project Cerberus. GitHub; https://github.com/opencomputeproject/Project_Olympus/tree/master/Project_Cerberus.
16. Pataky, D. 2017. Intel Management Engine. Technische Universität Dresden; https://files.bitkeks.eu/docs/intelme-report.pdf.
17. Regenscheid, A. 2018. Platform Firmware Resiliency Guidelines. NIST Special Publication 800-193; https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-193.pdf.
18. Savagaonkar, U., et al. 2017. Titan in depth: Security in plaintext. Google Cloud; https://cloud.google.com/blog/products/gcp/titan-in-depth-security-in-plaintext.
相关文章
持续交付听起来很棒，但它在这里行得通吗？
这不是魔法，它只是需要在各个层面持续的日常改进。
Jez Humble
https://queue.org.cn/detail.cfm?id=3190610
迈向更高的精度
PTP 及其对 NTP 从业者的意义简介
Rick Ratzel 和 Rodney Greenstreet
https://queue.org.cn/detail.cfm?id=2354406
模拟器：过去（和未来）的虚拟机
告别旧式大型机的时候到了吗？
Bob Supnik
https://queue.org.cn/detail.cfm?id=1017002
Jessie Frazelle 是一位独立承包商。她曾在 GitHub、Microsoft、Google、Docker 以及之前的一堆初创公司担任工程师。
版权 © 2019 由所有者/作者持有。出版权已许可给 。
最初发表于 Queue vol. 17, no. 3—
在 数字图书馆 中评论本文
更多相关文章
Amanda Casari, Julia Ferraioli, Juniper Lovato - 超越存储库
关于开源的现有研究大多选择研究软件存储库而不是生态系统。开源存储库通常是指记录在版本控制系统中的工件，偶尔包括围绕存储库本身的交互。开源生态系统是指存储库、社区、它们的交互、激励、行为规范和文化的集合。开源的去中心化性质使得对生态系统进行整体分析成为一项艰巨的任务，社区和身份以有机和不断发展的方式交叉。尽管存在这些复杂性，但对软件安全和供应链日益严格的审查使得在进行关于开源的研究时，采取基于生态系统的方法至关重要。
Guenever Aldrich, Danny Tsang, Jason McKenney - 为不理解的项目经理提供三部分和谐
本文研究了系统采购工具箱中的三种工具，这些工具可以加快开发和采购速度，同时减轻项目风险：OSS、开放标准和 Agile/Scrum 软件开发流程都是 DoD 采购项目管理工具箱的强大补充。
Marshall Kirk McKusick, George V. Neville-Neil - FreeBSD 5.2 中的线程调度
繁忙的系统每秒做出数千个调度决策，因此做出调度决策的速度对于整个系统的性能至关重要。本文 - 摘自即将出版的书籍“FreeBSD 操作系统设计与实现” - 使用开源 FreeBSD 系统的示例来帮助我们理解线程调度。最初的 FreeBSD 调度程序是在 1980 年代为大型单处理器系统设计的。尽管它在今天的环境中仍然运行良好，但新的 ULE 调度程序是专门为优化多处理器和多线程环境而设计的。本文首先研究了原始 FreeBSD 调度程序，然后描述了新的 ULE 调度程序。
Bart Decrem - 桌面 Linux：你在哪里？
桌面 Linux 已经走了很长一段路 - 而且这是一段过山车般的旅程。在互联网泡沫的顶峰时期，大约在 Red Hat 首次公开募股的时候，人们期望 Linux 在短时间内在桌面上起飞。几年后，在股市崩盘和几家备受瞩目的 Linux 公司倒闭之后，评论员们很快宣布桌面 Linux 胎死腹中。
© 保留所有权利。