David Drysdale 注意到 FreeBSD 已经支持 Capsicum 后，希望将 Capsicum 安全特性添加到 Linux 中。Capsicum 定义了细粒度的安全权限，类似于文件系统 capabilities。但正如 David 发现的那样，Capsicum 也存在一些争议。

Capsicum 已经存在一段时间了，并在 2010 年的 USENIX 论文中进行了描述：http://www.cl.cam.ac.uk/research/security/capsicum/papers/2010usenix-security-capsicum-website.pdf。

部分争议仅仅是因为它与 capabilities 的相似性。正如 Eric Biderman 在讨论中指出的那样，可以实现接近 Capsicum 功能的特性作为 capabilities 的扩展，但是直接实现 Capsicum 将需要在内核中创建一个全新的（且广泛的）抽象层。尽管 David 认为 capabilities 实际上无法扩展到足以匹配 Capsicum 的细粒度安全控制。

Capsicum 在其自身的开发者社区中也存在争议。例如，正如 Eric 所描述的那样，它缺乏关于如何撤销权限的规范。而且，David 指出，这是因为社区无法就如何最好地完成这项工作达成一致。David 引用了 Ben Laurie 在 2011 年发送给 cl-capsicum-discuss 邮件列表的电子邮件，Ben 在邮件中说，“这将需要额外的簿记来查找和撤销未完成的 capabilities，这需要知道如何访问 capabilities，以及它们是否源自正在撤销的 capability。它还需要一个用于撤销的授权模型。前两点意味着在数据结构操作和同步方面需要额外的开销。”

鉴于 Capsicum 开发者社区内部持续存在的争议以及关键特性规范的相应缺失，并且鉴于内核中已经存在执行类似功能的 capabilities 以及 Capsicum 补丁的侵入性，Eric 反对 David 在 Linux 中实现 Capsicum。

但是，鉴于 capabilities 比 Capsicum 的安全特性粗粒度得多，以至于 capabilities 实际上无法扩展到足以模仿 Capsicum 的特性，并且鉴于 FreeBSD 已经在其内核中实现了 Capsicum，表明这是可以做到的，并且可能有人想要它，看来仍然会有很多人有兴趣将 Capsicum 引入 Linux 内核。

有时不清楚是代码中存在错误，还是仅仅是书面规范中存在错误。Henrique de Moraes Holschuh 注意到 Intel 软件开发者手册（第 3A 卷，第 9.11.6 节）明确指出，微码 更新需要 P6 系列 CPU、奔腾 4 和 至强 进行 16 字节对齐。但是，内核微码驱动程序中的代码并未强制执行该对齐。

事实上，Henrique 的调查发现，一些 Intel 芯片，例如 Xeon X5550 和第二代 i5 芯片，在实践中只需要 4 字节对齐，而不是 16 字节。但是，为了符合文档规范，他建议修复内核代码以匹配规范。

Borislav Petkov 对此表示反对。他说 Henrique 是在没有问题的地方找问题。他说 Henrique 只是发现了 Intel 文档中的一个错误，因为对齐问题在现实世界中显然不是问题。他建议提醒 Intel 的人注意文档问题并继续前进。正如他所说，“如果处理器接受非 16 字节对齐的更新，你为什么要在意呢？”

但是，正如 H. Peter Anvin 所说，书面规范是 Intel 保证某些行为可以工作的保证。如果内核忽略该规范，则可能会在以后导致细微的错误。而且，Bill Davidsen 说，如果内核忽略了对齐要求，并且“如果该要求在未来的某个版本中强制执行，并且更新随后以某种疯狂的方式失败，那么供应商有理由声称‘我告诉过你’。”

最终结果是 Henrique 提交了一些补丁，使微码驱动程序强制执行 16 字节对齐要求。