关于康威定律和软件堆栈的思考

在我找工作的过程中，我和很多不同层次的人谈过话。我想分享我一直在思考的一个问题，也许你可以想出一些聪明的解决方案来解决它。

康威定律规定“设计系统…的组织。被限制为设计是这些组织的交流结构的复制品。“。

如果您将康威定律应用于软件堆栈和开放源码软件的所有层，您会发现一个问题：各层软件之间没有足够的通信。

我见过一群硬件工程师，我特意问了他们每个人对使用一块芯片供多个用户使用有何感想。当然，这就是云的用例。所有的硬件工程师要么大笑，要么惊恐，响亮的反应是“你疯了，以为硬件是用来安全地隔离多个用户的。”“幽灵党”和“熔毁”也证明了这一点。投机性执行是一个旨在提高处理器速度的功能，但从来没有考虑过黑客攻击运行多租户计算的东西的矢量，比如云提供商。看起来软件层和硬件层应该更好地沟通…。

这只是一个例子，让我们反转一下交互。我和一群固件和内核工程师谈过，他们都希望来自芯片供应商的固件复杂度更低。例如，固件和内核工程师似乎一致投票认为CPU供应商不应该在他们的固件中包含运行时服务或SMM。开源固件和内核开发者更愿意在他们的堆栈层次上处理这些问题。固件中的所有复杂性都会导致被忽视的错误和奇怪的行为，这些错误和行为不能从内核开发人员层和/或用户空间进行控制或调试。更不用说，很多CPU供应商的固件都是专有的，所以很难知道IFA bug是否真的是固件bug。

另一个例子是SoftLayer的黑客攻击。黑客从云提供商提供的裸机主机上修改了BMC上的固件，这表明了另一个错误，那就是对堆栈的其他层和整个系统视而不见，没有意识到这一点。

让我们往上移一点，看看我个人经历过的东西。我在容器运行时方面做了很多工作。我还从事kubernetes方面的工作，我惊恐地发现人们正在运行具有多个客户进程的多租户Kubernetes集群，也就是用于隔离不受信任的进程。Kubernetes的架构不是为此而设计的。

一种常见的误解是“装点门面”。例如，Kubernetes中有一种特性阻止向容器内执行。这只需阻止Kubernetes中的API调用即可实现。如果一个人可以访问集群，我可以想到大约40种不同的方法来执行到一个容器中，并完全绕过这个“特性”和kubernetes。说仅仅使用Kubernetes中的“安全功能”在任何方面都不足以保证安全，这是一种常见的模式。

所有这些问题决不是小问题。它们在堆栈的各个层都有沟通错误。他们认为界面或功能是安全的，因为它只是一个装点门面的东西，只需多了解一点关于堆栈的知识就可以绕过它。我真的很喜欢莉亚·基斯纳给出的建议：“要着眼长远，而不只是放眼全局。”在构建系统时，我们应该更多地这样做。

我一直在琢磨的想法是：我们如何解决这个问题？这是像GitHub这样的代码托管提供商应该解决的问题吗？但是，这不包括所有不在该平台上的项目。我们如何促进堆栈各层之间更好的通信？我们怎样才能使其中的一些内容自动化呢？或者答案很简单，自己拥有堆栈的所有层？