Skip to content

hwrng, virtio-rng: init-time fixes

Amit Shah lkml stable virtualization 2 versions – In review

Get series with b4
b4 am [email protected]

Versions newest first · linked by author and title

  1. v3 Latest2 patches 5 repliesIn review
  2. v22 patches 20 repliesSuperseded

Changes in v3 from the cover letter

- Kees Cook pointed out a weird side-effect: devices which have ->init() registered get their randomness added to the system each time they're switched in, but devices that don't have the init callback don't contribute to system randomness more than once. The weirdness is resolved here by using the randomness each time hwrng_init() is attempted, irrespective of the existence of the device's ->init() callback.

Patches in v3 No applies recorded yet

#Subject and filesSizeRepliesApplied
1/2hwrng: fetch randomness only after device initdrivers/char/hw_random/core.c+33 -81 reply
2/2virtio: rng: ensure reads happen after successful probedrivers/char/hw_random/core.c drivers/char/hw_random/virtio-rng.c+16 -00 replies

Reviews trailers per patch

All 2 patches have a Reviewed-by or Acked-by.

PatchJason Cooper
1/2R-b
2/2R-b

Trailers given in replies are filled; those carried in the patches from earlier versions are outlined with dashes.

Read the v3 thread

Cover letter [PATCH v3 0/2] hwrng, virtio-rng: init-time fixes

v3:
- Kees Cook pointed out a weird side-effect: devices which have ->init() registered get their randomness added to the system each time they're switched in, but devices that don't have the init callback don't contribute to system randomness more than once. The weirdness is resolved here by using the randomness each time hwrng_init() is attempted, irrespective of the existence of the device's ->init() callback.

v2:
- this now separates both the patches; the virtio-rng fix is self-contained
- re-work hwrng core to fetch randomness at device init time if ->init() is registered by the device, instead of not calling it at all.
- virtio-rng: introduce a probe_done bool to ensure we don't ask host for data before successful probe

Hi,

When booting a recent kernel under KVM with the virtio-rng device enabled, the boot process was stalling. Bisect pointed to a commit made during the 3.15 window to fetch randomness from newly-registered devices in the hwrng core. The details are in the patches.

Turns out there were two bugs: the initial randomness was being fetched w/o the device being initialized in cases where the init callback was registered and the device wasn't the first device being added to the hwrng core (unrelated to the virtio-rng case). The second bug is virtio can't communicate with the host without the device probe is successfully completed.

The impact of this change is that a sole virtio-rng device in a system won't be able to contribute to the initial randomness. If a second virtio-rng device is hot-plugged, its input will be used. Though that scenario is extremely unlikely (why have two virtio-rng devices at all?).

This isn't any different from the current behaviour, though - virtio-rng currently doesn't contribute to initial system randomness, and continues not to do so. A better way to get virtio-rng to contribute initially to the system random pool can be worked out later.

Please apply,

Amit Shah (2):
hwrng: fetch randomness only after device init
virtio: rng: ensure reads happen after successful probe

 drivers/char/hw_random/core.c       | 47 ++++++++++++++++++++++++++++++-------
 drivers/char/hw_random/virtio-rng.c | 10 ++++++++
 2 files changed, 49 insertions(+), 8 deletions(-)
Signature · 1 line
1.9.3