简而言之，没有。

这张图有很多问题，所以在谈论你的问题之前，我会先试着把事情弄清楚。

SRTM ~ 图表的左侧

该图建议交流模块将测量不正确的处理器。BIOS CRTM（Bios Boot Block）由 CPU 执行，用于测量 BIOS 固件。然后，它将测量结果（SHA1 哈希）返回给 TPM，而不是 BIOS。之后，执行将传递给 BIOS 固件。引导过程中的下一个元素也是如此。有关更多信息，请参阅此内容。

DRTM ~ 图表的右侧部分

同样，同样的评论也适用。SINIT AC 模块不测量处理器。一旦创建了安全的 CPU 包含的环境，模块签名将被验证并将其身份发送到 TPM (PCR 17)，然后它测量测量的启动环境 (MLE) 并将结果发送到 TPM (PCR 18)。

两者都提供相同的东西：一种我们可以测量运行环境的方法（即测量的信任根）。从技术上讲，这意味着在 TPM 的平台配置寄存器 (PCR) 中发送测量值——主要是用于 SRTM 的 PCR0 和用于 DRTM 的 PCR17。尽管如此，我们还没有对这些测量做任何事情。

好的，现在是问题。

简而言之，恶意用户总是可以选择不触发延迟启动/DRTM（TXT 的发送器操作），但重点是 TPM 的 PCR 将没有正确的值，因此某些元素（例如密钥）将无法访问。让我解释：

在tboot boot loader的情况下，启动控制策略（存储在 TPM NVRAM 中）定义了可以加载的 MLE 和 SINIT 模块（以及可选的 BIOS，即 PCONF）。只要不满足策略，就会触发 TXT 重置。此重置的结果是在系统重新启动之前无法执行延迟启动。无法执行延迟启动不会阻止某人使用系统 - 它不会停止引导过程或系统本身。但是，它确实会阻止某人访问 TPM 的 Locality 2。Locality 2 是扩展 PCR 19-22 所必需的（以及与 Locality 2 相关的任何密钥、TPM NVRAM 和其他资源）。

这里需要理解的重要一点是，Late Launch 并没有强制执行任何操作，它只是提供了一种进行测量并将其存储在 TPM 中的方法。只有这样，我们才能实施不同的行动。例如，如果目标是构建磁盘加密，则操作系统可以使用与所需/受信任的操作系统匹配的特定 PCR (17-22) 密封的密钥进行加密。现在这是重要的部分：如果没有加载正确的环境（例如，恶意用户更改了引导加载程序，没有触发延迟启动）PCRs 值将不匹配，因此解密操作系统的密钥将无法访问（解封不起作用）。

换句话说，PCRs 值反映了运行环境。SEAL 操作使用这些值作为密钥来加密数据。如果未加载正确的环境（PCR 不同），TPM 无法解密数据（UNSEAL）。

您可能想查看ITL 的 Anti-Evil-Mail。

希望这更清楚。