黑盒何时应该透明？

何时替换并非真正的替换？

亲爱的KV，

我们一直在与一家第三方供应商合作，他们为我们的一个系统提供关键组件。由于供应链问题，他们试图将我们“升级”到这个组件的更新版本，并且他们说这是一个旧版本的直接替换。他们一直说这个组件应该被视为一个黑盒，但在我们的测试中，我们发现原始部件和更新部件之间存在许多差异。这些不仅仅是简单的错误，而是系统底层重要的技术变更。如果能将这个组件视为直接替换品，而不用为此烦恼，那就太好了，但到目前为止我所看到的并没有让我感到有信心。我理解他们的观点，API是相同的，但我总觉得这还不够。组件何时才是真正的直接替换品？我应该在什么时候更加警惕？

进退两难

亲爱的进退两难，

你的来信引出了两个想法：一个是关于时事，另一个是关于永恒的问题，“黑盒何时应该透明？”

虽然我们都知道疫情给地球带来了难以置信的死亡和破坏，过去两年让以前非常无聊的供应链领域受到了前所未有的关注，但太阳照常升起，世界仍在运转——也就是说，世界还没有末日。说实话，如果真的末日了，对我来说倒是个不错的休息。供应链问题既是真实存在的，也是当今世界为一切事物找的最新借口。如果我有孩子（让我们都庆幸我没有），我估计他们会对老师说，“供应链吃了我的作业。”

在这一点上，当供应商的第一个借口是供应链问题时，KV 非常怀疑。当然，除非你为你购买的任何东西找到了第二个供应商，否则这种怀疑也无济于事，你可以用它来对你的犯错的供应商施压。

永恒的问题，“何时替换并非真正的替换？”将永远困扰着技术领域。不幸的是，相信可以将他们提供的任何东西都视为具有固定 API 的不透明盒子的人，为数众多。这种信念来自于物理世界，在物理世界中，盒子就是盒子，砖块就是砖块，你为什么要关心你的砖块是用不同的材料制成的呢？

问题就在这里：这种比喻在物理世界中和在软件和硬件领域中一样，很快就会失效。两块砖可能都是红色的，因此给外部用户呈现出相同的外观和感觉，但如果它们是由不同的材料制成的，那么它们就具有不同的特性——例如，强度，但我们也考虑一些不太明显的特性，比如它们的重量。可以堆叠在一起建造墙壁的砖块数量取决于它们的重量以及强度。如果你使用重但弱的砖块，嗯，你可以想象会发生什么，如果你想象不到，那就试试——只是不要告诉你的健康保险计划这是 KV 建议的。假设你没有用又重又弱的砖块建造墙壁，但在几年后，你用更新、更重、更弱的砖块替换了一些损坏的砖块。这里的关键是，你不会想站在那堵墙附近。

KV 一直在重复提及的一个话题，一个可能让他想喝酒的话题，就是软件的可塑性。我一直回到这个问题，因为正是这种可塑性经常导致软件和系统工程的灾难性失败。你提到你看到了新组件的时序问题。我很难想象有什么情况比关键组件的时序变化更危险的了。时序错误已经是很难追踪和修复的错误之一，如果关键组件的时序出现偏差，很可能会影响系统，祝你好运，祝你调试顺利。我可以推荐三份金酒，一份伏特加，少许金鸡纳利莱，加冰摇匀，再加一片柠檬吗？你会感谢我的，因为从现在到你的交付日期无限期推迟，你都会在晚上祈祷。那些希望站在“API 即合同”流沙上的人，欢迎他们这样做，但我不会向他们抛出绳索。

在这些情况下，正确的答案是向供应商索取尽可能多的信息，以降低接受这个所谓的替换品带来的风险。首先，索取测试计划和测试输出，以便你可以了解他们是否以与你的用例相关的方式测试了该组件。仅仅因为他们测试了某个东西，并不意味着他们测试了你的产品关心的所有部分。事实上，他们不太可能这样做。他们可能只测试了那些与 API 连接的部分，而不是当系统中的组件发生变化时可能出现的边缘情况。

其次，索取新旧部件之间差异的完整报告。对于硬件，这意味着底层技术（例如，旧部件是 90 纳米，新部件是 45 纳米）以及任何电压变化，以及内部结构。我见过替换部件将整个 CPU 核心放入曾经是固定功能的数字电子器件中，这简直是疯了，但是有人，在某个地方，因为为产品增加了“灵活性”而不是因为增加风险而被橡胶警棍殴打而受到表扬。

最后，确保你为任何你认为关键的组件都有第二个供应商。这本应是不言而喻的，但是，既然我说出来了，那就意味着你知道这已经成为很多人的问题，我看到很多人在升级完全摧毁他们的产品后，看起来像行尸走肉一样。

哦，你确实问过什么时候应该警惕。我的意思是，很明显答案是，永远。

KV

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

最初发表于 Queue 第 20 卷，第 2 期——
在数字图书馆中评论本文

更多相关文章

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

Raluca Ada Popa - 机密计算还是密码计算？
通过 MPC/同态加密与硬件飞地进行安全计算，需要在部署、安全性和性能之间进行权衡。关于性能，重要的是你考虑的工作负载类型。对于简单的 workloads，例如简单的求和、低阶多项式或简单的机器学习任务，这两种方法在实践中都可以使用，但对于复杂的计算，例如复杂的 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 的大小、攻击面以及安全架构师必须考虑的攻击向量，来提高通用计算平台的安全性。机密计算需要在平台硬件和软件方面进行创新，但这些创新有可能增强对计算的信任，尤其是在第三方拥有或控制的设备上。机密计算的早期消费者将需要就他们选择信任的平台做出自己的决定。