立足于不稳固的基础

我们有责任让世界上的系统安全可靠地运行。

尊敬的 KV， 到现在，我确信您已经看到了 CrowdStrike 的新闻，我不禁想象您对真正导致如此多问题的原因有自己的看法。科技和非科技新闻都充斥着对问题原因的解释：糟糕的测试、对一家公司关键基础设施的过度依赖、允许关键模块故障阻止进一步的远程更新……这样的例子不胜枚举。关于这个话题已经说了很多，似乎很多都只是指责，我想知道是否有人触及了问题的核心，或者他们是否永远不会触及，我们只能忍受这类中断——就像小型的 Y2K，只是更糟糕。

错失核心

尊敬的 Heartless，像任何没有与世隔绝的人一样，我确实看到了 CrowdStrike 的问题登上新闻，我很高兴我的航班在系统关闭前起飞了，因为在航班起飞后指出和嘲笑比那些被困在地面上的人容易得多。航班中断只是这次故障最明显的部分，因为机场排起的长队很容易成为新闻报道的素材。但 CrowdStrike 不仅仅是搞砸了持续数天的航空旅行；它还影响了医院和诊所、银行和 ATM 机，以及人们每天使用的许多其他系统。

对于从事计算机安全工作的人来说，这实际上是我们一直等待的一天：一个清晰的“我早就告诉过你！”的例子，可以向非技术人员以及技术人员解释。你不需要理解空指针异常就能明白，当你的电脑不能工作时，世界也无法正常运转。这可能是这场灾难最好的部分（如果有什么最好的部分的话）：据我们所知，没有人因此丧生，这很好，而且现在每个人都知道，我们建立的世界建立在非常不稳固的基础之上。这是我们很多人一直在等待的警钟。现在的问题是：我们会接电话吗？

关于这一切是如何发生的，已经有很多文字描述，从空指针异常的低级解释，到测试如何错过这个问题，以及或许我们不应该允许远程推送软件来阻止系统在没有人工干预的情况下启动。

现在要问的问题不是“我们如何在当前状态下更好地锁定事物？”或“我们如何拥有更好的开发实践，以便我们不会在操作系统代码的最底层推送空指针错误？” 这些都是好问题，但它们不是问题的核心。

核心在于系统的构建方式——特别是系统软件——使用不安全的语言在不安全的硬件上构建，而这些硬件连接到一个没有人可以信任的网络上。

让我们从硬件层开始，逐步向上。当前的计算机硬件是一个极其复杂的野兽，由各种相互连接的元素组成，总体而言，这些元素彼此信任。

我所说的信任是什么意思？以计算机内存问题为例，我们的空指针错误就是由此产生的。大多数内存软件漏洞都源于任何人都可以进行指针运算这一事实。取一个内存地址，加上或减去一个数字，瞧！——你就得到了另一个可能有效的内存地址。

正是这种类型的游戏是大多数计算机病毒的核心，并且启发了多年来尝试的许多类型的安全保护，例如 ASLR（地址空间布局随机化）、硬件中的 no-execute 位、W^X（写入异或执行）权限以及许多其他。这些保护措施的历史参差不齐，有时只能在短时间内发挥作用，然后在作为计算机安全的军备竞赛中被克服。硬件问题的核心是，我们继续假装我们正在使用 1970 年代的小型计算机，并且晶体管非常珍贵，但事实并非如此。

指针运算问题有解决方案，但它们需要投入更多资源来构建更安全的计算机架构。我在这里指的是能力机器，例如 1970 年代在剑桥大学建造的那种机器。在能力机器中，只有能力，而不仅仅是裸地址，这些能力受到硬件的密码学保护。你不能简单地将一个整数加到一个能力上以获得另一个不同的能力，因为硬件不允许发生这种数学运算。但是能力需要更大的地址空间，在某些情况下，本地指针的大小会增加一倍，这对内存、TLB（转换后备缓冲区）和计算机的其他部分都有影响。在 1970 年代，这种成本是令人望而却步的，但现在不应该如此，当然，如果好处是更可靠和安全的系统，则更不应该如此。

此类系统的原型已经开发出来，并且是积极研究的一部分。现在是时候将这些系统投入生产了，尤其是在关键基础设施周围。但那么，现在还有什么不是关键基础设施呢？谁知道你可以用一次糟糕的推送来摧毁世界各地的值机亭？当能力首次被提出时，世界不是靠计算机运行的。

今天，情况已经不同了，现在是时候改变我们的计算方式了。当然还有其他方法，甚至超越能力机器，来利用摩尔定律赋予我们的丰富资源，从而打破有利于安全的平衡。现在是时候发现这些方法是什么了。

一种强调安全性的选择是 CHERI（Capability Hardware Enhanced RISC Instructions，能力硬件增强 RISC 指令）。有关概述，请参阅 Robert N. M. Watson、Simon W. Moore、Peter Sewell 和 Peter G. Neumann 的“CHERI 简介”（https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-941.pdf）。

上升到软件层面，我们面临两个主要问题。现在有大量的低级软件，是用 C 语言构建的，它基于对硬件的非常陈旧的理解——1970 年代适用的计算模型。C 是一种不安全的语言，基本上是带有 for 循环的汇编程序。C 的优点是为现代处理器生成高效的代码。这一事实，加上它在 Unix 以及其他系统软件中的长期和历史使用，意味着几乎每个计算系统的最低层——从 Windows 到 Linux 和 Android，再到 macOS，再到 BSD，以及几乎每个实时或嵌入式操作系统——都是用 C 语言编写的。当数据包从互联网传输到计算机时，它始终由 C 语言编写的代码处理。

而这，再加上前面提到的硬件问题，构成了巨大的安全挑战。当 C 语言被编写出来时，还没有互联网，ARPANET（对于那些甚至还记得这个名字的人来说）的所有节点都可以写在餐巾纸上。用 C 这样的不安全语言编写将连接到互联网的代码根本是不合适的。我们试图让它工作，我们看到了结果。

第二个问题是系统软件本身。Unix 被认为是相对于 Multics 的巨大胜利，因为 Unix 更简单，只引入了两个域：内核和用户空间。用户空间程序通过虚拟内存相互保护。但是内核——任何内核——都是一个巨大的共享状态 blob，其中包含数百万行代码。对于现在日常使用的任何操作系统来说，情况都是如此——Windows、Unix 或运行在你连接 WiFi 的灯开关上的任何小型嵌入式操作系统。

是什么构成了这个巨大的 blob？设备驱动程序！质量参差不齐的设备驱动程序——有些人可能会说质量可疑——其中任何一个都可以探测和刺探系统的任何部分，只要它可以制造有效的内存地址。一旦某些东西突破了操作系统的内核边界，游戏就结束了，因为操作系统是“一切共享”。

现代系统软件方法建议我们不仅用类型安全的语言（如 Rust）编写所有新系统，而且还以同样的方式重写我们已经拥有的东西。但这在经济上是不切实际的。想象一下用一种新语言重写任何主要的操作系统，对其进行测试，部署它等等，需要花费多少钱。我的意思是，KV 会很乐意接受 10% 的成本来运行这个项目，但饮料账单会令人震惊。

多管齐下的方法是摆脱当前困境的唯一途径，在这种方法中，我们尽可能利用类型安全的语言（如 Rust），并决定哪些硬件实际上是关键的并且必须更换。（你想打赌某个地方的水坝控制软件运行的是 Windows 吗？我敢肯定它就是。）

整个 CrowdStrike 灾难的发生都是由于硬件和系统软件中的架构问题。

我们应该构建使编写病毒变得困难的系统，而不是儿戏。但现在这是一个昂贵的命题。

我们哄骗人类在所有事情上使用计算机。现在我们有责任让这些系统安全可靠地运行，这是我们对世界的责任。

George V. Neville-Neil 为乐趣和盈利而从事网络和操作系统代码方面的工作。他还教授各种与编程相关的课程。他的兴趣领域是计算机安全、操作系统、网络、时间协议以及大型代码库的维护和管理。他是The Kollected Kode Vicious 的作者，并且与 Marshall Kirk McKusick 和 Robert N. M. Watson 合著了The Design and Implementation of the FreeBSD Operating System。近 20 年来，他一直是专栏作家，更为人所知的名字是 Kode Vicious。自 2014 年以来，他一直是剑桥大学的工业访问学者，在那里他参与了几个与计算机安全相关的项目。他获得了马萨诸塞州波士顿东北大学的计算机科学学士学位，并且是、Usenix Association 和 IEEE 的成员。他的软件不仅在地球上运行，而且还作为 VxWorks 的一部分部署在 NASA 的火星任务中。他是一位狂热的自行车爱好者和旅行家，目前居住在纽约市。

最初发表于 Queue 第 22 卷，第 5 期—
在数字图书馆中评论这篇文章

更多相关文章

Jinnan Guo, Peter Pietzuch, Andrew Paverd, Kapil Vaswani - 使用机密联邦学习的可信 AI
安全性、隐私性、问责制、透明度和公平性原则是现代 AI 法规的基石。经典的 FL 在设计时非常强调安全性和隐私性，但牺牲了透明度和问责制。CFL 通过将 FL 与 TEE 和承诺相结合，弥补了这一差距。此外，CFL 还带来了其他理想的安全属性，例如基于代码的访问控制、模型机密性以及推理期间的模型保护。机密计算的最新进展，例如机密容器和机密 GPU，意味着现有的 FL 框架可以无缝扩展以支持具有低开销的 CFL。

Raluca Ada Popa - 机密计算还是密码学计算？
通过 MPC/同态加密与硬件飞地进行安全计算，需要在部署、安全性和性能之间进行权衡。关于性能，您想到的工作负载非常重要。对于简单的求和、低阶多项式或简单的机器学习任务等简单工作负载，这两种方法都可以在实践中投入使用，但对于复杂的计算（例如复杂的 SQL 分析或训练大型机器学习模型），目前只有硬件飞地方法在许多实际部署场景中足够实用。

Matthew A. Johnson, Stavros Volos, Ken Gordon, Sean T. Allen, Christoph M. Wintersteiger, Sylvan Clebsch, John Starks, Manuel Costa - 机密容器组
此处介绍的实验表明，Parma（在 Azure 容器实例上驱动机密容器的架构）增加的额外性能开销不到底层 TEE 增加的开销的百分之一。重要的是，Parma 确保了容器组在所有可达状态下的安全不变性，该不变性植根于证明报告中。这允许外部第三方与容器安全地通信，从而支持各种需要机密访问安全数据的容器化工作流程。公司获得了在云中运行其最机密工作流程的优势，而无需在其安全要求上妥协。

Charles Garcia-Tobin, Mark Knight - 使用 Arm CCA 提升安全性
机密计算有很大的潜力通过将监管系统从 TCB 中移除来提高通用计算平台的安全性，从而减小 TCB 的大小、攻击面以及安全架构师必须考虑的攻击向量。机密计算需要在平台硬件和软件方面进行创新，但这些创新有可能增强对计算的信任，尤其是在第三方拥有或控制的设备上。机密计算的早期消费者将需要自行决定他们选择信任的平台。