Public bug reported:
[Impact]
AWS Graviton 2 instances do not have enough entropy available at boot,
so any task that require entropy (even reading few bytes from
/dev/random) will be stuck forever.
[Fix]
The proper fix for this problem is to correctly refill the entropy pool
with some real random data using some hardware-generated randomness.
In the meantime a reasonable workaround can be to apply the following
upstream commits:
e2fce99e354a random: make /dev/random be almost like /dev/urandom
2da22381aba4 random: ignore GRND_RANDOM in getentropy(2)
d05185e92b8d random: Add a urandom_read_nowait() for random APIs that don't warn
f0b40adf2716 random: Don't wake crng_init_wait when crng_init == 1
2eee343eb5e9 random: add GRND_INSECURE to return best-effort non-cryptographic
bytes
In this way the system will not run out of entropy and will be able to
provide best-effort randomness in any case, preventing the out of
entropy issue on the AWS Gravion 2 instances.
[Test plan]
Execute the following command on any m6g instance:
dd bs=32 count=1 if=/dev/random of=/dev/null
This should return quickly, if not it means that the system does not
have enough entropy available. When the problem happens this command
hangs forever.
[Where problems could occur]
This changes affect the read semantics of /dev/random to be the same as
/dev/urandom except that reads will block until the CRNG is ready. This
should not materially break any API. Any code that worked without these
changes should work at least as well as before. However, applications
that have strict randomness requirements might be affected by the
provided best-effort randomness, so we may need to apply more
commits/changes to introduce a proper hardware entropy support on
Graviton 2 instances to provide a better quality of randomness. In the
meantime these upstream changes consist a reasonable workaround to
prevent applications from hanging forever on the mg6.* instances.
** Affects: linux-aws (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-aws in Ubuntu.
https://bugs.launchpad.net/bugs/1927692
Title:
AWS: out of entropy on Graviton 2 instances types (mg6.*)
Status in linux-aws package in Ubuntu:
New
Bug description:
[Impact]
AWS Graviton 2 instances do not have enough entropy available at boot,
so any task that require entropy (even reading few bytes from
/dev/random) will be stuck forever.
[Fix]
The proper fix for this problem is to correctly refill the entropy
pool with some real random data using some hardware-generated
randomness.
In the meantime a reasonable workaround can be to apply the following
upstream commits:
e2fce99e354a random: make /dev/random be almost like /dev/urandom
2da22381aba4 random: ignore GRND_RANDOM in getentropy(2)
d05185e92b8d random: Add a urandom_read_nowait() for random APIs that don't
warn
f0b40adf2716 random: Don't wake crng_init_wait when crng_init == 1
2eee343eb5e9 random: add GRND_INSECURE to return best-effort
non-cryptographic bytes
In this way the system will not run out of entropy and will be able to
provide best-effort randomness in any case, preventing the out of
entropy issue on the AWS Gravion 2 instances.
[Test plan]
Execute the following command on any m6g instance:
dd bs=32 count=1 if=/dev/random of=/dev/null
This should return quickly, if not it means that the system does not
have enough entropy available. When the problem happens this command
hangs forever.
[Where problems could occur]
This changes affect the read semantics of /dev/random to be the same
as /dev/urandom except that reads will block until the CRNG is ready.
This should not materially break any API. Any code that worked without
these changes should work at least as well as before. However,
applications that have strict randomness requirements might be
affected by the provided best-effort randomness, so we may need to
apply more commits/changes to introduce a proper hardware entropy
support on Graviton 2 instances to provide a better quality of
randomness. In the meantime these upstream changes consist a
reasonable workaround to prevent applications from hanging forever on
the mg6.* instances.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-aws/+bug/1927692/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : [email protected]
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
