GKE made an inquiry about the source of entropy for /dev/hwrng. Their public documentation (https://cloud.google.com/compute/docs/instances/enabling-virtio-rng) specifies that virtio_rng is the default, but they observed that the TPM's RNG is used instead on current GKE images. Besides aligning with their public docs, using virtio_rng means that the host is responsible for providing the most secure hardware entropy source, which is a better default than assuming that the most secure source on that particular machine is the TPM (or RDRAND instructions, etc).
[Fix]
Configure CONFIG_HW_RANDOM_VIRTIO=y for all targeted kernels.
[Test Plan]
Executing
$ cat /sys/devices/virtual/misc/hw_random/rng_current
Should return "virtio_rng.0"
[Regression potential]
There should be a very low chance of regression. Hardware RNG entropy sources in theory are identical in behavior, and the test plan above can determine what the active source of entropy is.
SRU Justification
[Impact]
GKE made an inquiry about the source of entropy for /dev/hwrng. Their public documentation (https:/ /cloud. google. com/compute/ docs/instances/ enabling- virtio- rng) specifies that virtio_rng is the default, but they observed that the TPM's RNG is used instead on current GKE images. Besides aligning with their public docs, using virtio_rng means that the host is responsible for providing the most secure hardware entropy source, which is a better default than assuming that the most secure source on that particular machine is the TPM (or RDRAND instructions, etc).
[Fix]
Configure CONFIG_ HW_RANDOM_ VIRTIO= y for all targeted kernels.
[Test Plan]
Executing virtual/ misc/hw_ random/ rng_current
$ cat /sys/devices/
Should return "virtio_rng.0"
[Regression potential]
There should be a very low chance of regression. Hardware RNG entropy sources in theory are identical in behavior, and the test plan above can determine what the active source of entropy is.