Ubuntu 是否会在内核中启用 RANDOM_TRUST_CPU，会有什么影响？

Question

根据这篇来自 2018-08-28 的 The Register 文章和其他文章，Linux 内核版本 4.19 将有一个名为RANDOM_TRUST_CPU. 这里还有一个链接到补丁作者的邮件列表条目，包括实际的代码更改。据我所知，这将允许系统在某些情况下加速启动过程，无需等到从各种来源收集到足够的熵来安全地为随机数生成器播种，而是跳过该部分并仅依赖于 CPU 的内置 -在随机数生成器中。

这会削弱系统的加密安全性，因为它（如果我理解正确的话）不仅依赖 CPU 作为单一的熵源，而且如果 CPU 的实现不可信（错误、故意的后门、 ……）。

• 内核的随机数生成器是否会一直只从 CPU 的生成器初始化，还是只在早期启动阶段进行初始化，然后将更多来自“传统”源的熵添加到池中，从而提高加密安全性时间再次回到当前/旧水平？

• 由于这显然是一个编译时标志，Ubuntu 存储库中提供的内核包是否会启用或禁用此标志？

• 除了从现在开始自己编译内核之外，是否还有一种选择加入或退出的方法？

• 有没有办法实际测试这是否会对启动时间产生影响？目前是否有关于在启动期间等待熵所花费的时间的任何指标？

• 哪些 Ubuntu 版本甚至可以运行 4.19 或更高版本的内核？

Answer 1

首先，合理地，无论是否使用 CPU 的内置 HWRNG（例如RDRAND在 Intel 中），系统的加密安全性（其不可预测性）都不会以任何方式改变，否则，正如您所指出的那样，不可避免地削弱了 RNG（以及任何依赖它的东西）的安全性。

简单总结一下，在引导过程中，内核加载随机驱动程序后，Linux RNG 会初始化所有随机池（熵池，它们只是保存随机数据的内存区域），包括主池（输入池），通过与来自HWRNG如果可用熵填充它们，否则通过random_get_entropy()，这是一个宏get_cycles()，它的实现与结构变化（例如，在aarch64一个在读CNTVCT_EL0寄存器完成，这是怎样的一个频率计数器，实际上不是时钟速率，而是通过读取 TSC reg 在 x86-64 中使用）。所有这些数据都被提供给一个主要的密码状态 ( primary_crng, 类型的对象struct crng_state，这是ChaCha20 算法的实现），其中包含 384 个真正随机位的密钥，最终提供给/dev/urandom接口。

现在有了这个上下文，为了回答你的问题，内核的 RNG 实际初始化通过rand_initialize()，作为early_initcall，显然只发生在启动时（像所有的一样*_initcall()），特别是，在最后start_kernel()，内核例程rest_init()被调用的地方，第一个它所做的事情是产生一个内核线程 ( kernel_init) ，目的之一是启动该 initcall （还要注意它add_device_randomness()甚至在之前被调用，但实际上并没有添加任何熵数据）；并因此是，每个源，所述ChaCha20，初级和阻挡池将与被初始化的密状态arch_get_random_long()，这使得使用的RDRAND在x86处理器（指令再次，如果是可用的，并且如果它是，内核警告你这一点）。我不会说它是唯一使用的来源（即使RDRAND可用），因为，至少：

1. 固件时间被使用并在初始化期间混入池中（可能不是那么熵，攻击者仍然必须以极高的精度推断时间戳）；

2. 还有另一个小池（每个 CPU 一个，称为快速池），它从 收集熵add_interrupt_randomness()，它使用 IRQ（理论上还有其他内核事件，甚至一些来自 CPU 硬件 RNG 的种子，如果有的话）作为输入，全部混合，并且然后它被注入到输入池中。这几乎每一秒都在发生。

因此，从 HWRNG 和其他来源收集熵的过程一起发生；当然，第一个在场景中占主导地位（因为熵质量肯定更高，它是一个真正的 RNG），并且在启动时发生，并且从用户空间，每当使用伪随机设备（或getrandom()系统调用）时。但是，在第二种情况下，池已经初始化，并且只是primary_crng（密码状态）重新播种。是的，正如您所指出的，CPU 内置 RNG 肯定会提高整体随机性。

最后我要补充一点，特别是在嵌入式系统中，可能缺少一些源噪声（如键盘、硬盘等），HWRNG 的使用将产生重大影响。请注意，始终根据文档，如果您担心安全性，您可以RDRAND在引入 之前禁用way的内核使用RANDOM_TRUST_CPU。