Page MenuHomeFreeBSD

virtio_random: timeout rather than blocking entropy collection
Needs ReviewPublic

Authored by kevans on Sep 18 2021, 7:41 AM.
Tags
None
Referenced Files
Unknown Object (File)
Dec 28 2023, 9:06 PM
Unknown Object (File)
Dec 19 2023, 10:45 PM
Unknown Object (File)
Dec 3 2023, 9:56 PM
Unknown Object (File)
Dec 2 2023, 4:40 AM
Unknown Object (File)
Nov 28 2023, 4:05 AM
Unknown Object (File)
Nov 23 2023, 6:37 AM
Unknown Object (File)
Sep 14 2023, 11:18 PM
Unknown Object (File)
Jun 27 2023, 5:35 AM
Subscribers

Details

Reviewers
bryanv
jrtc27
Group Reviewers
csprng
Summary

Some virtio-rng providers are known to ratelimit to rates below what
random(4) expects for 'fast' sources. Because we read all sources
serially, this lowers the overall quality of the pool while driving up
CPU utilization to some extent as we spend more time spinning in
virtqueue_poll().

This commit by default times out polling at 2ms. This is based on a
rough estimate of how long this should take with fortuna to avoid
impact:

10hz / RANDOM_FORTUNA_NPOOLS(32) calls = ~3ms per call at most to avoid
bringing everyone down; shave off 1ms of 'other overhead' to arrive at
2ms for the poll itself.

If we end up timing out, the next iteration will simply drop the result
on the floor -- we can't quickly know how long it's been sitting in the
now heap-allocated buffer, because it may have been enqueued on the last
read of this source in random_sources_feed().

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 41587
Build 38476: arc lint + arc unit

Event Timeline

As mentioned earlier in the stack I don’t think this mitigation is great.

Edit: if we pursue this mitigation, we also need to poll at device unload so we can free the softc.

sys/dev/virtio/random/virtio_random.c
262

This doesn’t make sense starting at “after it’s” - ie just end the sentence at “safer to discard it.”