Re: Linux messages full of `random: get_random_u32 called from`

["Theodore Y. Ts'o" <tytso@mit.edu>]

On Thu, Apr 26, 2018 at 01:22:02PM -0700, Sultan Alsawaf wrote:
> 
> Also, regardless of what's hanging on CRNG init, CRNG should be able to init on its own in a timely
> manner without the need for user-provided entropy. Userspace was working fine before the recent CRNG
> kernel changes, so I don't think this is a userspace bug.

The CRNG changes were needed because were erroneously saying that the
entropy pool was securely initialized before it really was.  Saying
that CRNG should be able to init on its own is much like saying, "Ted
should be able to fly wherever he wants in his own personal Gulfstream
V."  It would certainly be _nice_ if I could afford my personal jet.
I certainly wish I were that rich.  But the problem is that dollars
(or Euro's) are like entropy, they don't just magically drop out of
the sky.

If there isn't user-provided entropy, and the hardware isn't providing
sufficient entropy, where did you think the kernel is supposed to get
the entropy from?  Should it dial 1-800-TRUST-NSA?

>From the dmesg log, you have a Chromebook Acer 14.  I'm guessing the
problem is that Chromebooks have hardware tries *very* hard not to
issue interrupts, since that helps with power savings.  The following
from your dmesg is very interesting:

[    0.526786] tpm tpm0: [Firmware Bug]: TPM interrupt not working, polling instead

I suspect this isn't a firmware bug; it's the hardware working as
intended / working as designed, for power savings reasons.

So there are two ways to fix this that I can see.  One is to try to
adjust userspace so that it allows the boot to proceed.  As there is
more activity, the disk completion interrupts, the user typing their
username/password into the login screen, etc., there will be timing
events which can be used to harvest entropy.

The other approach would be to compile the kernel with
CONFIG_HW_RANDOM_TPM and to modify drivers/char/tpm/tpm-chip.c tot
initalize chip->hwrng.quality = 500.  We've historically made this
something that the system administrator must set via sysfs.  This is
because we wanted system adminisrators to explicitly say that they
trust the any hardware manufacturer that (a) they haven't been paid by
your choice of the Chinese MSS or the US NSA to introduce a backdoor,i
and (b) they are competent to actually implemnt a _secure_ hardware
random number generator.  Sadly, this has not always been the case.
Please see:

	https://www.chromium.org/chromium-os/tpm_firmware_update

And note that your Edgar Chromebook is one the list of devices that
have a TPM with the buggy firmware.  Fortunately this particular TPM
bug only affects RSA prime generation, so as far as I know there is no
_known_ vulerability in your TPM's hardware random number generator.
B ut we want it to be _your_ responsibility to decide you are willing
to truste it.  I certainly don't want to be legally liable --- or even
have the moral responsibility --- of guaranteeing that every single
TPM out there is bug-free(tm).

					- Ted