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

[Andrea Righi]

On Fri, May 07, 2021 at 07:58:09AM -0300, Guilherme Piccoli wrote:
> 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>

Thanks for the review Guilherme. These commits are all applied to all
our kernels >= 5.8 already and I agree that this patch set should
probably target all 5.4 kernels (especially the cloud kernels that can
easily go out of entropy). However, I would do more tests and more
investigation before applying it across the board, since it doesn't seem
to be a blocker for the other kernels.

-Andrea