Messages in this thread |  | | Date | Thu, 26 Apr 2018 19:56:30 -0400 | From | "Theodore Y. Ts'o" <> | Subject | Re: Linux messages full of `random: get_random_u32 called from` |
| |
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
|  |