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

[Tim Gardner]

Acked-by: Tim Gardner <tim.gardner at canonical.com>

I'm not sure I fully understand patch 5, but it is a clean cherry-pick 
and testing shows it to at least not block anymore. As for how random 
the information is that is returned I can't say.

On 5/7/21 2:15 AM, Andrea Righi 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(-)
> 
> 

-- 
-----------
Tim Gardner
Canonical, Inc