启动期间LUKS错误

alg: drbg: could not allocate DRNG handle for ... 

在我们创build的虚拟机启动过程中,我只能在控制台上看到这个错误。 编辑:2/5/16 – 我也看到它在一些裸机安装。 (它确实继续完全启动。)我认为这与虚拟硬件有关,缺less(兼容的)随机数生成器。 问题是我无法评估严重程度。 encryption强度是否受损? (我是否应该关心这个错误?) 我该如何解决?

我们在CentOS 6.7下使用QEMU / KVM。 如果你真的认为它会有帮助,我可以做一个示例系统的virsh dumpxml 。 我们正在使用Anaconda默认密码/密钥大小 。 (AES-XTS-plain64 / 512)

这是我在linux-crypto邮件列表上find的最早的参考资料 。 不幸的是,这有点过头了。

http://www.mail-archive.com/linux-crypto%40vger.kernel.org/msg10398.html

alg:drbg:无法分配DRNG句柄...

特别是,我不相信这会影响你的encryption强度。

我已经检查了源代码,只要我正在解释我读的是正确的,你不必担心这一点。

这段代码属于模块“stdrng”。 至less在Fedora 23上,这是内核而不是作为内核模块导出的。

当初始化stdrng时,会发生以下调用。

在encryption/ drbg.c初始化从这里开始。

 1997 module_init(drbg_init); 

这注册了系统已知的所有drbgs。

 1985 for (j = 0; ARRAY_SIZE(drbg_cores) > j; j++, i++) 1986 drbg_fill_array(&drbg_algs[i], &drbg_cores[j], 1); 1987 for (j = 0; ARRAY_SIZE(drbg_cores) > j; j++, i++) 1988 drbg_fill_array(&drbg_algs[i], &drbg_cores[j], 0); 

然后它将它传递给执行初始化的辅助函数:

 1989 return crypto_register_rngs(drbg_algs, (ARRAY_SIZE(drbg_cores) * 2)); 

crypto/rng.c这只是遍历每个rng注册它..

 210 for (i = 0; i < count; i++) { 211 ret = crypto_register_rng(algs + i); 212 if (ret) 213 goto err; 214 } 

这个函数做了一堆初始化步骤,然后调用另一个函数进行分配。

 196 return crypto_register_alg(base); 

什么不是那么明显是注册过程中发生了什么。

内核中内置的另一个称为tcrypt模块接收正在插入的新algorithm的通知。 一旦它看到一个新的注册algorithm,它会安排一个testing。 这就是你在屏幕上看到的输出。

testing完成后,algorithm进入TESTED状态。 如果testing失败,我 (我无法find产生这种行为的位),它是不可选的search,如果你传递正确的标志。

testing是否通过肯定是内部存储的。

除此之外,调用psudeo随机数生成器将导致按照crypto/drbg.c注释规定的强度顺序对algorithm列表进行迭代

 107 /* 108 * The order of the DRBG definitions here matter: every DRBG is registered 109 * as stdrng. Each DRBG receives an increasing cra_priority values the later 110 * they are defined in this array (see drbg_fill_array). 111 * 

因为最强的一个不会失败(hmac sha256),即使可以被选中,也不太可能使用失败的那个。

总结 –

  • stdrng模块需要某些东西时会发生这种情况。
  • 它加载所有已知的algorithm。
  • 所有加载algorithm都经过testing。 有些可能会失败(为什么不考虑在这个答案)。
  • testing失败的algorithm应该稍后可供select。
  • PRNGS是按照强度sorting的,强大的PRNGS是先通过的。
  • 依靠stdrng东西不应该使用这些algorithm作为PRNG源的基础。

您可以使用以下命令查看哪些algorithm已成功并通过了testing:

  grep -EC5 'selftest.*passed' /proc/crypto 

您也可以通过“优先级”字段查看select优先级。 根据模块作者,值越高,PRNG越强。

所以,很高兴在这里错了,因为我不认为自己是一个内核程序员,但最后 –

加载stdrng时,似乎从可接受algorithm列表中select其他algorithm,这些algorithm被认为比失败algorithm更强大,加上失败的algorithm不可能被选中。

因此,我相信这在使用luks时不会对您造成额外的风险。

我该如何解决?

根据红帽知识库 ,您必须将“ctr”内核模块添加到您的initrd。 他们的指示也说包括'ecb',虽然似乎问题是'ctr'模块没有被加载。

 dracut -f -v --add-drivers "ctr ecb" 

订户可以看到完整的信息。 我不确定是否允许我在这里重新发表,所以我已经解释了完整的解决scheme。

https://access.redhat.com/solutions/2249181

编辑9/29/2016:

您还可以将这些驱动程序添加到/etc/dracut.conf以便将它们添加到内核升级上的新的initramfs。 否则,你的症状会在几个月后重新出现。 ;)

 add_drivers+="ctr ecb"