getentropy(2) is in POSIX-2024, so adjust the #include visibility,
change the "too much" error to EINVAL, add GETENTROPY_MAX to
<limits.h> (via sys/syslimits.h), and update the manpage.

ok deraadt@

Make arc4random() depend on less subsystems by decoupling extract_entropy()
from the enqueue_randomness() logic.

Add add_event_data() which just enqueues some data into the event buffer
which can be

Make arc4random() depend on less subsystems by decoupling extract_entropy()
from the enqueue_randomness() logic.

Add add_event_data() which just enqueues some data into the event buffer
which can be used by extract_entropy(). On top of this remove the
timeout_del() call in dequeue_randomness() it does serve any meaningful
reason.
OK kettenis@ deraadt@ mpi@

show more ...

In dequeue_randomness() use an atomic instruction to increase the
rnd_event_cons. This way even concurrent calls to dequeue_randomness()
will use some different events.
OK deraadt@ djm@

Delete obsolete /* ARGSUSED */ lint comments.

ok miod@ millert@

Style: always use *retval and never retval[0] in syscalls,
to reflect that retval is just a single return value.

ok miod@

Make comment match the code.

Since rnd.c r1.127, there is only one stirring polynomial.

s/poll/pool

ansi

slight copyright update regarding recent work

introduce "cpu_rnd_messybits" for use instead of nanotime in dev/rnd.c.

rnd.c uses nanotime to get access to some bits that change quickly
between events that it can mix into the entropy pool. it do

introduce "cpu_rnd_messybits" for use instead of nanotime in dev/rnd.c.

rnd.c uses nanotime to get access to some bits that change quickly
between events that it can mix into the entropy pool. it doesn't
use nanotime to get a monotonically increasing set or ordered and
accurate timestamps, it just wants something with bits that change.

there's been discussions for years about letting rnd use a clock
that's super fast to read, but not necessarily accurate, but it
wasn't until recently that i figured out it wasn't interested in
time at all, so things like keeping a fast clock coherent between
cpu cores or correct according to ntp is unecessary. this means we
can just let rnd read the cycle counters on cpus and things will
be fine. cpus with cycle counters that vary in their speed and
arent kept consistent between cores may even be desirable in this
context.

so this is the first step in converting rnd.c to reading cycle
counter. it copies the nanotime backend to each arch, and they can
replace it with something MD as a second step later on.

djm@ suggested rnd_messybytes, but we landed on cpu_rnd_messybits.
thanks to visa for his eyes.
ok deraadt@ visa@
deraadt@ says he will help handle any MD fallout that occurs.

show more ...

dev/rndvar.h no longer has statistical interfaces (removed during various
conversion steps). it only contains kernel prototypes for 4 interfaces,
all of which legitimately belong in sys/systm.h, whi

dev/rndvar.h no longer has statistical interfaces (removed during various
conversion steps). it only contains kernel prototypes for 4 interfaces,
all of which legitimately belong in sys/systm.h, which are already included
by all enqueue_randomness() users.

show more ...

3 includes not needed

Update comment block at the top to describe (a) the ring damage logic,
and (b) the boot-time acceleration.

Rewrite the entropy enqueue ring to collect damage asyncronously, and adapt the
dequeue to mix a selection of "best" ring entries. Change the dequeue timeout
to exponentially backoff because excessi

Rewrite the entropy enqueue ring to collect damage asyncronously, and adapt the
dequeue to mix a selection of "best" ring entries. Change the dequeue timeout
to exponentially backoff because excessive pool buffer generation is pointless
-- rekey's generally happen at 1.6MB and a long timeout, a lot of cpu cycles
were being wasted.

During boot-up (before timeouts work) aggressively consume enqueue damage
and rekey every time, to accelerate entropy injection into the chacha ring.

The goal is to compensate rapidly for weak seeding in unidentifiable
conditions, and ensure quality to arc4random() calls early in boot.
ok kettenis visa

show more ...

For large reads from /dev/random, use the arc4random_ctx_*() functions
instead of hand-rolling the same code to set up a temporary ChaCha
instance.
tweak/ok semarie@, ok deraadt@

Pass bootblock indicator RB_GOODRANDOM to random_start(). Future work
will frantically compensate.
ok kettenis

During the rekey operation, we feedback 1 word to the lowest level.
But it was a constant, that is really silly. Pass back the first
word from the middle layer.
ok visa

entropy_add_ptr and entropy_input_rotate are only used inside
enqueue_randomness(), so make them local static instead of global.

be more consistant about with using sizeof(object) rather than the constant
defining the [size]

Describe the purpose of add_entropy_words() in simpler terms.

The description of the enqueue_randomness() input parameter was crazy untrue.

Explain enqueue_randomness() better. It is the supply-entropy function,
and change wording from 'entropy queue', what we have is a ring which
collects 'damage' from successive calls until drawn down

The long explanation for CRC stirring isn't helping. If anything
it suggests we should reconsider this mechanism and do something
simpler... delete the explanation for now.

The main comment block from 1996 has become highly inaccurate and
misleading, so rewrite it.

The interesting parts are bootblock-seeding from file + hwrng,
arc4random() being available incredibly ea

The main comment block from 1996 has become highly inaccurate and
misleading, so rewrite it.

The interesting parts are bootblock-seeding from file + hwrng,
arc4random() being available incredibly early, and seperate timeouts
to pull entropy data forward into a stir of the chacha state (one for
entropy ring crc whitening into a buffer, the 2nd for buffer folding
into the chacha)

Now that it is better documented, I can try to improve each component.

show more ...

remove unneccessary include files