#
f8e8a06d |
|
10-Oct-2020 |
Conrad Meyer <cem@FreeBSD.org> |
random(4) FenestrasX: Push root seed version to arc4random(3) Push the root seed version to userspace through the VDSO page, if the RANDOM_FENESTRASX algorithm is enabled. Otherwise, there is no functional change. The mechanism can be disabled with debug.fxrng_vdso_enable=0. arc4random(3) obtains a pointer to the root seed version published by the kernel in the shared page at allocation time. Like arc4random(9), it maintains its own per-process copy of the seed version corresponding to the root seed version at the time it last rekeyed. On read requests, the process seed version is compared with the version published in the shared page; if they do not match, arc4random(3) reseeds from the kernel before providing generated output. This change does not implement the FenestrasX concept of PCPU userspace generators seeded from a per-process base generator. That change is left for future discussion/work. Reviewed by: kib (previous version) Approved by: csprng (me -- only touching FXRNG here) Differential Revision: https://reviews.freebsd.org/D22839
|
#
10b1a175 |
|
10-Oct-2020 |
Conrad Meyer <cem@FreeBSD.org> |
arc4random(9): Integrate with RANDOM_FENESTRASX push-reseed There is no functional change for the existing Fortuna random(4) implementation, which remains the default in GENERIC. In the FenestrasX model, when the root CSPRNG is reseeded from pools due to an (infrequent) timer, child CSPRNGs can cheaply detect this condition and reseed. To do so, they just need to track an additional 64-bit value in the associated state, and compare it against the root seed version (generation) on random reads. This revision integrates arc4random(9) into that model without substantially changing the design or implementation of arc4random(9). The motivation is that arc4random(9) is immediately reseeded when the backing random(4) implementation has additional entropy. This is arguably most important during boot, when fenestrasX is reseeding at 1, 3, 9, 27, etc., second intervals. Today, arc4random(9) has a hardcoded 300 second reseed window. Without this mechanism, if arc4random(9) gets weak entropy during initial seed (and arc4random(9) is used early in boot, so this is quite possible), it may continue to emit poorly seeded output for 5 minutes. The FenestrasX push-reseed scheme corrects consumers, like arc4random(9), as soon as possible. Reviewed by: markm Approved by: csprng (markm) Differential Revision: https://reviews.freebsd.org/D22838
|
#
a3c41f8b |
|
10-Oct-2020 |
Conrad Meyer <cem@FreeBSD.org> |
Add "Fenestras X" alternative /dev/random implementation Fortuna remains the default; no functional change to GENERIC. Big picture: - Scalable entropy generation with per-CPU, buffered local generators. - "Push" system for reseeding child generators when root PRNG is reseeded. (Design can be extended to arc4random(9) and userspace generators.) - Similar entropy pooling system to Fortuna, but starts with a single pool to quickly bootstrap as much entropy as possible early on. - Reseeding from pooled entropy based on time schedule. The time interval starts small and grows exponentially until reaching a cap. Again, the goal is to have the RNG state depend on as much entropy as possible quickly, but still periodically incorporate new entropy for the same reasons as Fortuna. Notable design choices in this implementation that differ from those specified in the whitepaper: - Blake2B instead of SHA-2 512 for entropy pooling - Chacha20 instead of AES-CTR DRBG - Initial seeding. We support more platforms and not all of them use loader(8). So we have to grab the initial entropy sources in kernel mode instead, as much as possible. Fortuna didn't have any mechanism for this aside from the special case of loader-provided previous-boot entropy, so most of these sources remain TODO after this commit. Reviewed by: markm Approved by: csprng (markm) Differential Revision: https://reviews.freebsd.org/D22837
|