背景
Shim 可以在编译期间内置一个证书（请参阅“Shim 密钥”段落这里）。然后可以使用相应的私钥对引导加载程序/管理器和内核进行签名。这种方法将 Microsoft 的 UEFI 签名从这些组件中抽象出来 - 只有 shim 需要 Microsoft 签名，其余的都需要分发签名，从而使它们能够快速更新和发布，同时维护信任链。
列入黑名单
如果在引导加载程序/管理器或内核中发现漏洞，则必须对其进行修补并签署和发布新版本。但我们不能再使用相同的签名密钥了，不是吗？如果我们这样做，那么 shim 仍然能够加载旧的、易受攻击的版本。如果这些漏洞可被利用来执行任意代码，那么攻击者就可以将它们转化为 bootkit 并绕过安全启动。这意味着必须使用新证书构建新的填充程序，并且旧填充程序的哈希必须在安全启动的 dbx 中列入黑名单。
我不太熟悉内核模块如何跨发行版进行签名和验证，尽管我大胆猜测在某些情况下它们是根据内核内置的证书进行签名和验证的。如果在任何模块中发现允许任意代码执行的漏洞，则必须使用新的内核密钥对其进行修补和签名，这意味着必须使用新的填充密钥对内核进行签名，这意味着旧的填充程序必须再次被重新签名。已列入 dbx 黑名单。
问题
从长远来看，这似乎不是一个可行的方法。引导加载程序、内核和内核模块中的漏洞不断被发现和修复，这意味着我们需要不断生成新的密钥对，使用新证书重建 shim，并将旧 shim 列入黑名单。此外，任何允许用户在启用安全启动时安装和/或运行它们的发行版，并且不提示用户将证书/哈希安装到安全启动数据库中，都可能使用带有发行版内置证书的填充程序。这意味着只要在上述任何组件中发现任意代码执行漏洞，我们就必须将所有受影响发行版的垫片列入黑名单。对于能够用自己的密钥替换 Microsoft 密钥的高级用户来说，这不会是问题，但普通用户似乎必须不断更新他们的 dbx 以保持安全。这里真的是这样吗？或者使用内置密钥的发行版数量太少而不会成为问题？