[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: lack of boot-time entropy on arm64 ec2 instances



On Wed, Jan 08, 2020 at 02:48:13PM -0500, Noah Meyerhans wrote:
> The buster arm64 images on Amazon EC2 appear to have insufficient
> entropy at boot, and thus take several minutes to complete the boot
> process.
> 
> There are a couple of potential fixes (or at least workarounds) for this
> problem, but none is entirely perfect.
>
> ...
> 
> I'm not aware of any other options.  Given the above, it seems that
> haveged is the only really feasible choice right now.  Does anyone
> disagree with that assessment?  Are there options I've missed?

I was under the impression that Amazon provided virtio-rng support for
its VM's?  Or does that not apply for their arm64 Vm's?  If they do
support virtio-rng, it might just be an issue of building the cloud
kernel with that option enabled.

Another approach would be to cherry pick 50ee7529ec45 ("random: try to
actively add entropy rather than passively wait for it").  I'm pretty
confident that it's probably fine ("it's fine.  it's fine.  Really,
it's fine") for x86.  In particular, at least x86 has RDRAND, so even
if it's utterly predictable to someone who has detailed information
about the CPU's microarchitecture, it probably won't be a diaster.

Upstream, it's enabled for all architectures, because Linus thinks
hanging at boot is a worse problem than a insufficiently initialized
CRNG.  I'm not at all convinced that it's safe for all ARM and RISC-V
CPU's.  On the other hand, I don't think it's going to be any worse
that haveged (which I don't really trust on all architectures either),
and it has the advantage of not requiring any additional userspace
packages.

						- Ted


Reply to: