我在 Haswell 笔记本电脑上使用 Ubuntu 20.04 for Windows 10 (WSL2),每秒大约获得 0.6 字节。等待 10 秒后总共 6 个字节。这是无法接受的。问题是什么?
编辑:这仅在 WSL2 模式下运行时才出现问题。 WSL1 = 40MiB/秒 WSL2 = 0.6 字节/秒
答案1
/dev/random
Linux 中的 和都是/dev/urandom
加密安全的伪随机数生成器。在旧版本的 Linux 内核中,/dev/random
一旦初始化就会阻塞,直到积累了足够的额外熵,而/dev/urandom
不会。由于 WSL2 是具有真实 Linux 内核的虚拟机,因此它具有一组有限的熵源,可以从中获取熵,并且必须依赖主机系统来获取大部分熵。然而,只要它在启动时收到足够的熵,就可以安全地使用 CSPRNG。
听起来在您的环境中,CSPRNG 已在 Windows 启动时播种,但并未以高速率重新播种。这很好,但它会导致/dev/random
阻塞比您想要的更频繁。归根结底,这是WSL2的配置问题。
WSL1 可能没有这个问题,因为在这种情况下,/dev/random
可能不会阻塞并且只使用系统 CSPRNG,例如/dev/urandom
.在更新版本的 Linux,唯一发生/dev/random
阻塞的情况是启动时没有积累足够的熵来为 CSPRNG 播种一次;否则,它完全等同于/dev/urandom
。做出此决定是因为,只要池已正确初始化,两个接口中就不存在合理的安全差异。
由于在这些情况下没有可测量的差异,因此 if/dev/random
是阻塞的并且对您来说太慢,正确的做法是使用/dev/urandom
,因为它们是相同 CSPRNG(基于 ChaCha20)的输出。无论如何,上游 Linux 行为可能会成为 WSL2 未来版本中的默认行为,因为 Microsoft 最终将合并更新版本的 Linux。
答案2
我自己还没有在 WSL2 Ubuntu 中测试过这一点,但不久前我在 CentOS 6 VM 上遇到了类似的问题。安装并运行该haveged
服务解决了我的 /dev/random 速度慢的问题。也许值得尝试一下。
Linux 池随机性通过 /dev/random 和 /dev/urandom 设备接口进行分发。填充 /dev/random 池的标准机制可能不足以满足对高需求或有限用户交互的系统的需求。在这些情况下,haged 可以作为特权守护进程运行,只要 /dev/random 中的随机位供应量低于设备的低水位线,即可填充 /dev/random 池。
https://manpages.ubuntu.com/manpages/focal/man8/haveged.8.html
否则,就像 @bk2204 所说, /dev/urandom 可能是你最好的选择。