硬件错误很难编码处理。在某些情况下，它们是不可能编码处理的。一种特殊的硬件错误是机器检查异常 (MCE)，这意味着 CPU 出现问题。在 Windows 系统上，它是蓝屏死机的原因之一。

每个人都希望妥善处理硬件错误，因为这可能意味着能够获得一些关于实际发生问题的指示，而不是完全没有信息。

安迪·卢托米尔斯基 最近提出了一些代码来清理 不可屏蔽中断 (NMI)，这通常也表明某种硬件故障。但在讨论过程中，人们提出了关于如何处理各种情况的问题——例如，当 MCE 紧随 NMI 之后出现时。通常，NMI 不会被任何其他代码中断，但是否应该为 MCE 破例？如果操作系统在已经处理另一个硬件错误时检测到 CPU 错误，它应该优先处理更紧急的 CPU 问题还是不处理？

对此进行了一些辩论，但最终 林纳斯·托瓦兹 表示，MCE 意味着系统已经死了。他说，任何试图在软件中处理它的尝试都只是为了尽可能优雅地崩溃。但他认为，内核在这种情况下不应该做出任何复杂的努力，因为最终结果仍然是崩溃。死锁、竞争条件和其他通常很重要的问题，在这种情况下根本不重要。他说，尽最大努力记录事件，然后忘记其余的。

在其他地方，他更强烈地阐述说：“坦率地说，MCE 设计得很糟糕。它是一堆狗屎，任何声称他们的工作是为了系统稳定性的硬件设计师都是在胡说八道。这是一个不应该做什么的典型例子，以及你如何实际上可以传播原本可能是局部且可恢复的错误，并使其成为全局且不可恢复的错误。” 他补充说

同步 MCE 对于同步错误来说很好，但是试图将它们“同步”到其他 CPU（在这些 CPU 上，它们不是同步错误）是一个重大错误。外部错误穿透 irq 上下文是错误的，穿透 NMI 简直是不可原谅的。

如果操作系统随后决定关闭整台机器，操作系统——而不是硬件——可以选择做一些会穿透其他 CPU 的 NMI 阻塞（特别是 init/reset）的事情，但如果硬件自行执行此操作，那就是坏了，如果这是真的。

托尼·勒克 指出，英特尔 实际上计划在未来的机器中修复这个问题，尽管他承认芯片的周转时间可能非常长。然而，正如 鲍里斯拉夫·佩特科夫 指出的那样，即使修复程序投入使用后，Linux 仍然需要支持有缺陷的硬件。

容器安全 的走钢丝式平衡存在一些争议。一个群体认为容器应该能够做独立系统可以做的任何事情。另一个群体认为，某些能力会使容器本身不安全。第一个群体说，如果没有这些功能，容器就不能真正提供完整的环境。第二个群体说，这就是现实。

塞思·福尔希 最近发布了一些补丁，允许容器化系统像非容器化系统一样看到热插拔设备。但这显然太过分了。格雷格·克罗赫-哈特曼 表示，他早就明确表示反对向设备添加命名空间。而且，这正是塞思的代码使热插拔设备对容器化系统可见的方式。

事实证明，确实存在希望容器化系统能够看到热插拔设备的有效用例。迈克尔·H·沃菲尔德 描述了其中一个用例。而且，塞思描述了他自己的用例——他需要热插拔支持才能在容器内实现环回设备。

格雷格说，在容器中支持环回设备是一个非常糟糕的主意，因为它提供了各种机会将数据从容器泄漏到主机系统——这是一种安全违规行为。

他说这不是容器的“正常”用例。对此，塞尔吉·哈林 回复说，非容器化系统使用的任何功能都是容器化系统的“正常”用例。

塞尔吉认为，这些功能不可避免地会进入容器。无法阻止它们进入。只要容器排除非容器化系统中包含的功能，就会有人有动力来弥合差距。为什么不现在就弥合差距，并在漏洞出现时修复它们呢？

但理查德说：“有很多事情会严重伤害你。使用用户命名空间，我们向普通用户暴露了一个非常大的攻击面。[...] 我同意用户命名空间是正确的方向，用 LSM 来掩盖安全问题要糟糕得多。但我们必须确保我们不要过快地添加太多功能。”

而且，格雷格补充说，塞思的代码太粗糙，只实现了塞思需要的东西，而不是解决如何在容器中正确处理命名空间这一总体问题。

格雷格还说他支持容器内的环回设备，但他和 詹姆斯·博特姆利 都说安全问题是真实存在的，并且实现必须考虑到这些问题。仅仅实现该功能然后修复错误是不够的。该功能需要一个适当的设计来解决这些担忧。