random: crng init 卡死几分钟的 haveged / rng-tools / virtio-rng 加速

linux内核启动时crng init卡住是因等待足够熵，属主动保护机制；推荐优先使用rng-tools5配合virtio-rng硬件透传，haveged在虚拟机中熵质量不可靠。

为什么 crng init 卡住几分钟？

Linux 内核在启动时会等待足够的熵（entropy）来初始化密码学随机数生成器（CRNG），表现为 dmesg 中卡在 random: crng init done 之前，且系统响应迟缓。这不是 bug，而是内核的主动保护机制：没有足够熵时，/dev/random 会阻塞，连带影响 sshd、systemd、容器拉起等依赖随机源的服务。

haveged 和 rng-tools 哪个更靠谱？

两者都试图向内核熵池注入熵，但原理和稳定性差异明显：

• haveged 基于 CPU 时间戳抖动提取熵，无需硬件支持，但在虚拟机（尤其是 KVM/QEMU）中可能因定时器虚拟化失真导致熵质量低，甚至被内核拒绝（haveged: getrusage() failed 或静默不注入）
• rng-tools 是传统方案，需配合硬件 RNG 设备（如 /dev/hwrng）；在无硬件时可启用 --fill-watermark 模式轮询注入，但若底层没可用 RNG，它会空转或报错 Failed to open entropy source /dev/hwrng
• 现代推荐优先用 rng-tools5（debian/ubuntu）或 rng-tools（RHEL/centos 8+），并确保配置指向真实熵源

virtio-rng 在 KVM 虚拟机里怎么配才生效？

这是最干净的解法——把宿主机的硬件 RNG 透传给客户机。但常见失效点不在客户机配置，而在宿主机和 QEMU 启动参数：

• 宿主机必须有可用 RNG 设备（ls -l /dev/hwrng 存在且可读），常见于 Intel RDRAND（rdrand 模块已加载）或 amd rng_core + tpm-rng
• QEMU 启动时需显式添加：-device virtio-rng-pci,rng=rng0,max-bytes=1024,period=1000 -Object rng-random,filename=/dev/hwrng,id=rng0
• 客户机内核需启用：CONFIG_HW_RANDOM_VIRTIO=y（通常默认开启），启动后应看到 dmesg | grep -i rng 输出 virtio_rng virtio0: registered as random source
• 验证是否生效：cat /sys/devices/virtual/misc/hwrng/rng_current 应返回 virtio_rng；watch -n1 'cat /proc/sys/kernel/random/entropy_avail' 启动后应快速升至 2000+，而非长期卡在 100–200

绕过 crng init 卡顿的临时手段（慎用）

仅限调试或嵌入式受限环境，生产系统不建议：

• 加内核启动参数：random.trust_cpu=on（告诉内核信任 RDRAND/AMD X86_RDRAND 指令产出的熵），适用于较新 CPU 且 bios 开启了相关特性
• 强制提前初始化：echo 1 > /proc/sys/kernel/random/urandom_min_reseed_secs（无效）；真正起效的是在 initramfs 阶段注入熵，例如在 dracut 配置中加入 rd.random=1 并确保 rng-tools 已打包进 initramfs
• 绝对不要用 rngd -r /dev/urandom —— 这是用伪随机数充熵，违反密码学前提，crng init 可能跳过但后续密钥极可能被预测

真正卡住时，先看 dmesg | grep -i -E 'random|rng|entropy'，再确认 /dev/hwrng 是否存在、virtio-rng 设备是否被识别、rngd 进程是否在跑且没报 open 失败——多数问题出在链路断在第一环，而不是工具选错。