soft interrupt driven operation.
Add a polling mode of operation -- now we can ask hardware random number
generators to top us up just when we need it (bcm2835_rng and amdpm
converted as examples).
Fix a stall noticed with repeated reads from /dev/random while testing.
only RW_WRITERs for these, and no RW_READERs, so no need to incur the
extra overhead of allowing for both. As discussed on tech-kern.
For piixpm and ichsmb, the acquire/release protocol needs to be used,
even if the request is I2C_F_POLL'd (or if the device supports only
polled mode). Otherwise multiple requests can be running at the same
time, and they stomp on each other and create anomolous results.
Part 2 addresses my PR kern/45889
3 ACKs from releng
<20111022023242.BA26F14A158@mail.netbsd.org>. This change includes
the following:
An initial cleanup and minor reorganization of the entropy pool
code in sys/dev/rnd.c and sys/dev/rndpool.c. Several bugs are
fixed. Some effort is made to accumulate entropy more quickly at
boot time.
A generic interface, "rndsink", is added, for stream generators to
request that they be re-keyed with good quality entropy from the pool
as soon as it is available.
The arc4random()/arc4randbytes() implementation in libkern is
adjusted to use the rndsink interface for rekeying, which helps
address the problem of low-quality keys at boot time.
An implementation of the FIPS 140-2 statistical tests for random
number generator quality is provided (libkern/rngtest.c). This
is based on Greg Rose's implementation from Qualcomm.
A new random stream generator, nist_ctr_drbg, is provided. It is
based on an implementation of the NIST SP800-90 CTR_DRBG by
Henric Jungheim. This generator users AES in a modified counter
mode to generate a backtracking-resistant random stream.
An abstraction layer, "cprng", is provided for in-kernel consumers
of randomness. The arc4random/arc4randbytes API is deprecated for
in-kernel use. It is replaced by "cprng_strong". The current
cprng_fast implementation wraps the existing arc4random
implementation. The current cprng_strong implementation wraps the
new CTR_DRBG implementation. Both interfaces are rekeyed from
the entropy pool automatically at intervals justifiable from best
current cryptographic practice.
In some quick tests, cprng_fast() is about the same speed as
the old arc4randbytes(), and cprng_strong() is about 20% faster
than rnd_extract_data(). Performance is expected to improve.
The AES code in src/crypto/rijndael is no longer an optional
kernel component, as it is required by cprng_strong, which is
not an optional kernel component.
The entropy pool output is subjected to the rngtest tests at
startup time; if it fails, the system will reboot. There is
approximately a 3/10000 chance of a false positive from these
tests. Entropy pool _input_ from hardware random numbers is
subjected to the rngtest tests at attach time, as well as the
FIPS continuous-output test, to detect bad or stuck hardware
RNGs; if any are detected, they are detached, but the system
continues to run.
A problem with rndctl(8) is fixed -- datastructures with
pointers in arrays are no longer passed to userspace (this
was not a security problem, but rather a major issue for
compat32). A new kernel will require a new rndctl.
The sysctl kern.arandom() and kern.urandom() nodes are hooked
up to the new generators, but the /dev/*random pseudodevices
are not, yet.
Manual pages for the new kernel interfaces are forthcoming.
The "pci0 dev 1 function 2" aka "System Management" on the nForce chipset
isn't detected on the Xbox. If XBOX is defined and arch_i386_is_xbox is
true, force intrline to 12 and map the system management IO space at
0x8000. We can now call iic_smbus_intr when a system management interrupt
takes place.
While we're here, make amdpm_smbus honour the I2C_F_POLL flag.
The Xbox no longer resets when you press the eject button.
and ADT 7463c thermal and voltage monitor found on the Tyan S2881 and S2882-D
(and probably other boards as well). We do not currently support any kind
of detection of the i2c address of the thermal monitor; it appears to be
at 0x2D on the S2881 and 0x2E on the S2882-D (kernel config examples
forthcoming).
From PR kern/32463 submitted by Anil Gopinath, anil_public@yahoo.com.
