| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Working on cleansing use of (SI_SUB_FOO + 1) construct through the kernel
I found a repeating pattern. Often a developer adds a module that depends
on certain subsystem to be fully instantiated and they want to put their
module SYSINIT right at the end of the SI_SUB_FOO. Such module usually
expects that nothing else within this subsystem shall depend on the
module.
The problem with SI_ORDER_ANY which practically was "the last" until this
change is that it is used very widely and people treat it literally as
"any", well, because this is what the name says. This lead to many parts
that could have dependencies later to be added as SI_ORDER_ANY.
So, our developer with the new subsystem that depends on SI_SUB_FOO has
three options:
1) Use SI_ORDER_ANY, but grep around ther kernel for other SI_SUB_FOO
entries to make sure that no dependencies are set to SI_ORDER_ANY. And in
case they are, shift them up and recheck if dependencies of those
dependencies are met.
2) Take next subsystem in sysinit list. However, the next one can be
SI_SUB_BAR, that is completely irrelevant from SI_SUB_FOO, and our
developer doesn't want to put his module's SYSINIT into SI_SUB_BAR, cause
it is ugly.
3) Use the (SI_SUB_FOO + 1) construct that violates -Werror=assign-enum.
The SI_ORDER_LAST solves this hard choice. If you know that nothing is
going to depend on your module within SI_SUB_FOO, but you depend on
SI_SUB_FOO, just use SI_ORDER_LAST.
Reviewed by: markj, emaste
Differential Revision: https://reviews.freebsd.org/D58709
|
| |
|
|
|
|
|
|
|
|
|
| |
and one that will be with us in the long-term future.
(this helps reduce diffs in the future and for down-stream users
that trim entropy sources). Also, move deprecated (removed in 16.0)
sources to the bottom of the list to reduce changes to 15.x.
Reviewed by: glebius
Obtained from: Juniper Networks
Differential Revision: https://reviews.freebsd.org/D53311
|
| |
|
|
|
|
|
|
| |
Ensure that the number of elements of random_source_descr[]
and fxrng_ent_char[] matches that of enum random_entropy_source.
Reviewed by: cem
Differential Revision: https://reviews.freebsd.org/D53255
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Hifn 7955 & 7956 only supports deprecated & NIST disallowed
algorithms (NIST SP800-224idp): SHA1 and SHA1-HMAC.
Furthermore the entropy RNG of the Hifn 7751, 7951, 7811, 7955,
and 7956 has no NIST Entropy Source Validation (ESV) certificate
and cannot be used in a FIPS-140-3 nor Common Criteara environment.
Furthermore the most prolific instance for FreeBSD was the
Soekris Engineering vpn1201, vpn1211, vpn1401, and vpn1411
offerings. These are all 32-bit only processors. The i386
kernel was de-supported in 15.0.
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D53182
|
| |
|
|
|
|
|
|
| |
Reviewed by: cem
Fixes: 1492c8c0d qcom_rnd: add initial qualcomm prng driver.
Fixes: 9eecef052 Add an Armv8 rndr random number provider
Fixes: b2f8b2dc8 sys: Add an SMCCC Random Number Generator driver
Differential Revision: https://reviews.freebsd.org/D53292
|
| |
|
|
|
|
| |
Reviewed by: cem
Fixes: 3a1298 random: add RDSEED as a provably unique entropy source
Differential Revision: https://reviews.freebsd.org/D53291
|
| |
|
|
|
|
|
|
| |
It was used for Octeon MIPS and all producers have been removed
from the source tree.
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D53146
|
| |
|
|
|
|
|
|
|
|
| |
Otherwise we get a NULL pointer dereference when writing to /dev/random.
PR: 288826
Reviewed by: cem
MFC after: 1 week
Fixes: fa8db724ae6e ("random: Treat writes to /dev/random as separate from /entropy")
Differential Revision: https://reviews.freebsd.org/D52633
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Switch to using sys/stdarg.h for va_list type and va_* builtins.
Make an attempt to insert the include in a sensible place. Where
style(9) was followed this is easy, where it was ignored, aim for the
first block of sys/*.h headers and don't get too fussy or try to fix
other style bugs.
Reviewed by: imp
Exp-run by: antoine (PR 286274)
Pull Request: https://github.com/freebsd/freebsd-src/pull/1595
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Apply the following automated changes to try to eliminate
no-longer-needed sys/cdefs.h includes as well as now-empty
blank lines in a row.
Remove /^#if.*\n#endif.*\n#include\s+<sys/cdefs.h>.*\n/
Remove /\n+#include\s+<sys/cdefs.h>.*\n+#if.*\n#endif.*\n+/
Remove /\n+#if.*\n#endif.*\n+/
Remove /^#if.*\n#endif.*\n/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/types.h>/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/param.h>/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/capsicum.h>/
Sponsored by: Netflix
|
| |
|
|
| |
Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/
|
| |
|
|
| |
Remove /^\s*\*\n \*\s+\$FreeBSD\$$\n/
|
| |
|
|
|
|
|
|
|
| |
The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of BSD-2-Clause.
Discussed with: pfg
MFC After: 3 days
Sponsored by: Netflix
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
74cf7cae4d22 ("softclock: Use dedicated ithreads for running callouts.")
switched callouts away from the swi infrastructure. It turns out that
this was a major source of entropy in early boot, which we've now lost.
As a result, first boot on hardware without a 'fast' entropy source
would block waiting for fortuna to be seeded with little hope of
progressing without manual intervention.
Let's resolve it by explicitly harvesting entropy in callout_process()
if we've handled any callouts. cc/curthread/now seem to be reasonable
sources of entropy, so use those.
Discussed with: jhb (also proposed initial patch)
Reported by: many
Reviewed by: cem, markm (both csprng)
Differential Revision: https://reviews.freebsd.org/D34150
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
Notes:
svn path=/head/; revision=366622
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
Notes:
svn path=/head/; revision=366621
|
|
|
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
Notes:
svn path=/head/; revision=366620
|
