ACK/Cmnt: [SRU][F/aws][PATCH 0/5] AWS: fix out of entropy on Graviton 2 instances types (mg6.*)

Guilherme Piccoli gpiccoli at canonical.com
Fri May 7 10:58:09 UTC 2021


On Fri, May 7, 2021 at 5:16 AM Andrea Righi <andrea.righi at canonical.com> wrote:
>
> BugLink: https://bugs.launchpad.net/bugs/1927692
>
> [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:
>
>  30c08efec888 random: make /dev/random be almost like /dev/urandom
>  48446f198f9a random: ignore GRND_RANDOM in getentropy(2)
>  75551dbf112c random: add GRND_INSECURE to return best-effort non-cryptographic bytes
>  c6f1deb15878 random: Add a urandom_read_nowait() for random APIs that don't warn
>  4c8d062186d9 random: Don't wake crng_init_wait when crng_init == 1
>
> 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.
>
> ----------------------------------------------------------------
> Andy Lutomirski (5):
>       random: add GRND_INSECURE to return best-effort non-cryptographic bytes
>       random: Don't wake crng_init_wait when crng_init == 1
>       random: Add a urandom_read_nowait() for random APIs that don't warn
>       random: ignore GRND_RANDOM in getentropy(2)
>       random: make /dev/random be almost like /dev/urandom
>
>  drivers/char/random.c       | 81 +++++++++++++++++++++++++++++++++------------------------------------------------
>  include/uapi/linux/random.h |  4 +++-
>  2 files changed, 36 insertions(+), 49 deletions(-)
>
>

Thanks Andrea, LGTM. I wonder if we plan to apply these commits to all
5.4-based kernels - are they in 5.8? If so, I feel it is worth to add
them to all 5.4-based kernels, entropy blocking is a PITA and usually
lead to multiple complains due to boot problems. I understand though
that this is more urgent to AWS...so mandatory to apply in F/AWS!
That said:

Acked-by: Guilherme G. Piccoli <gpiccoli at canonical.com>



More information about the kernel-team mailing list