History log of /freebsd-9.3-release/sys/dev/random/randomdev_soft.c
Revision Date Author Comments
(<<< Hide modified files)
(Show modified files >>>)
# 267654 19-Jun-2014 gjb

Copy stable/9 to releng/9.3 as part of the 9.3-RELEASE cycle.

Approved by: re (implicit)
Sponsored by: The FreeBSD Foundation

# 249915 25-Apr-2013 ache

MFC r249631

Attempt to mitigate poor initialization of arc4 by one-shot
reinitialization from yarrow right after good entropy is harvested.

Approved by: secteam (delphij)


# 247511 28-Feb-2013 delphij

MFC r247334:

Correct a typo introduced in r153575, which gives inverted logic when
handling blocking semantics when seeding.

PR: kern/143298
Submitted by: James Juran <james juran baesystems com>
Reviewed by: markm


# 225736 22-Sep-2011 kensmith

Copy head to stable/9 as part of 9.0-RELEASE release cycle.

Approved by: re (implicit)


# 218909 21-Feb-2011 brucec

Fix typos - remove duplicate "the".

PR: bin/154928
Submitted by: Eitan Adler <lists at eitanadler.com>
MFC after: 3 days


# 192774 25-May-2009 markm

There is rubbish here
It is time to take it out
Now it is cleaner


# 185254 24-Nov-2008 cperciva

Make sure arc4random(9) is properly seeded when /etc/rc.d/initrandom returns.

Approved by: so (cperciva)
Approved by: re (kensmith)
Security: FreeBSD-SA-08:11.arc4random


# 172836 20-Oct-2007 julian

Rename the kthread_xxx (e.g. kthread_create()) calls
to kproc_xxx as they actually make whole processes.
Thos makes way for us to add REAL kthread_create() and friends
that actually make theads. it turns out that most of these
calls actually end up being moved back to the thread version
when it's added. but we need to make this cosmetic change first.

I'd LOVE to do this rename in 7.0 so that we can eventually MFC the
new kthread_xxx() calls.


# 170067 28-May-2007 rwatson

Don't save SYSCTL_ADD_*() results in a local variable just to throw them
away; preserve the ones that are needed for further calls in the init
function and ignore the rest entirely.

Found with: Coverity Prevent(tm)
CID: 563


# 167086 27-Feb-2007 jhb

Use pause() rather than tsleep() on stack variables and function pointers.


# 157815 17-Apr-2006 jhb

Change msleep() and tsleep() to not alter the calling thread's priority
if the specified priority is zero. This avoids a race where the calling
thread could read a snapshot of it's current priority, then a different
thread could change the first thread's priority, then the original thread
would call sched_prio() inside msleep() undoing the change made by the
second thread. I used a priority of zero as no thread that calls msleep()
or tsleep() should be specifying a priority of zero anyway.

The various places that passed 'curthread->td_priority' or some variant
as the priority now pass 0.


# 153575 20-Dec-2005 ps

Remove GIANT from device random.

Submitted by: ups


# 144291 29-Mar-2005 markm

Revert to the more correct array size, and correct a KASSERT to
only allow proper values. ENTROPYSOURCE is a maxval+1, not an
allowable number.

Suggested loose protons in the solution: phk
Prefers to keep the pH close to seven: markm


# 143793 18-Mar-2005 phk

Fix off-by-one (too little!) array size problem.

Detected by: Coverity (ID#661)


# 139194 22-Dec-2004 phk

Check O_NONBLOCK not IO_NDELAY.

Don't include vnode.h


# 137276 05-Nov-2004 jhb

Don't change the priority to PUSER when sleeping, just keep the current
priority.


# 137152 03-Nov-2004 rwatson

(1) Move from O(n) list copies to O(1) list concatenation, which is
supported for STAILQ via STAILQ_CONCAT().

(2) Maintain a count of the number of entries in the thread-local entropy
fifo so that we can keep the other fifo counts in synch.

MFC after: 3 weeks
MFC with: randomdev_soft.c revisions 1.5 and 1.6
Suggested by: jhb (1)


# 136434 12-Oct-2004 rwatson

Assert that the entropy source category provided by a caller submitting
entropy is valid, as an invalid source will cause dereferencing of an
array of queues to an incorrect memory location.


# 136338 09-Oct-2004 rwatson

Modify entropy harvesting locking strategy:

- Trade off granularity to reduce overhead, since the current model
doesn't appear to reduce contention substantially: move to a single
harvest mutex protecting harvesting queues, rather than one mutex
per source plus a mutex for the free list.

- Reduce mutex operations in a harvesting event to 2 from 4, and
maintain lockless read to avoid mutex operations if the queue is
full.

- When reaping harvested entries from the queue, move all entries from
the queue at once, and when done with them, insert them all into a
thread-local queue for processing; then insert them all into the
empty fifo at once. This reduces O(4n) mutex operations to O(2)
mutex operations per wakeup.

In the future, we may want to look at re-introducing granularity,
although perhaps at the granularity of the source rather than the
source class; both the new and old strategies would cause contention
between different instances of the same source (i.e., multiple
network interfaces).

Reviewed by: markm


# 133465 11-Aug-2004 rwatson

Perform a lockless read to test whether an entropy havesting fifo is
full, avoiding the cost of mutex operations if it is. We re-test
once the mutex is acquired to make sure it's still true before doing
the -modify-write part of the read-modify-write. Note that due to
the maximum fifo depth being pretty deep, this is unlikely to improve
harvesting performance yet.

Approved by: markm


# 132346 18-Jul-2004 markm

Start the entropy device insecure/unblocked. I'll be handing over
responsibility for critical randomness requirements (like sshd)
to rc.d/*

Requested by: many


# 128320 16-Apr-2004 markm

Default to harvesting everything. This is to help give a faster
startup. harvesting can be turned OFF in etc/rc.d/* if it is a
burden.


# 128059 09-Apr-2004 markm

Reorganise the entropy device so that high-yield entropy sources
can more easily be used INSTEAD OF the hard-working Yarrow.
The only hardware source used at this point is the one inside
the VIA C3 Nehemiah (Stepping 3 and above) CPU. More sources will
be added in due course. Contributions welcome!