1) Move core entropy-pool code and source/sink/sample management code
to sys/kern from sys/dev.
2) Remove use of NRND as test for presence of entropy-pool code throughout
source tree.
3) Remove use of RND_ENABLED in device drivers as microoptimization to
avoid expensive operations on disabled entropy sources; make the
rnd_add calls do this directly so all callers benefit.
4) Fix bug in recent rnd_add_data()/rnd_add_uint32() changes that might
have lead to slight entropy overestimation for some sources.
5) Add new source types for environmental sensors, power sensors, VM
system events, and skew between clocks, with a sample implementation
for each.
ok releng to go in before the branch due to the difficulty of later
pullup (widespread #ifdef removal and moved files). Tested with release
builds on amd64 and evbarm and live testing on amd64.
<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.
in if_tlp_pci.c... The name code really needs to be fixed so that it does
not have a buffer overflow again:
1. the cardbus and eisa code don't initialize sc_name; it probably should?
2. tlp_attach() seems to print the name and the ethernet address, but
the pci front end seems to do the same.
3. some of the name determination code in the pci front-end does not guarantee
nul terminated strings.
Really, all this name code is just bloat and another place for bugs to hide.
than a max size Ethernet frame without getting a frame-too-long error. VPC
seems to be adding 4 zeros at the end of every frame. Detect this condition
and simply truncate the packet to a max size Ethernet frame.
I now have no problems with networking on NetBSD inside Virtual PC 6.
TULIPF_BLE /* data is big endian */
TULIPF_DBO /* descriptor is big endian */
These setting is required for Big-endian bus front-end (such as APbus for
newsmips) to work with tulip. Also,
sc_maxburst
member is added to the tulip_softc to limit the maximum burst length.
This member defaults to zero which means no restriction for burst length.
98715* series.
The MX98715AEC-[C,E] use a different location in the serial eerom for
LED control, and programming it with the original location's values
caused unpredictable behavior.
Also, start integrating fixes where media changes on an adapter
under load may fail. There's more work to be done here, but I need
to sort out our internal changes a little more carefully.
cardbus_get_capability() [mirror change already made to if_tlp_pci.c]
- if_tlp_cardbus.c: If we don't find an ISV SROM, try to grab the
Ethernet address from the CIS.
- if_tlp_cardbus.c: set CardBus cards to store-and-forward mode from
the get-go.
- Put the TxThresh tables in tulipvar.h, and use them in the CardBus
and PCI front-ends to go to store-and-forward mode.
- Document the Xircom X3201-3 clone a little more.
timeout()/untimeout() API:
- Clients supply callout handle storage, thus eliminating problems of
resource allocation.
- Insertion and removal of callouts is constant time, important as
this facility is used quite a lot in the kernel.
The old timeout()/untimeout() API has been removed from the kernel.
more efficient on genuine DEC chips, but some clones apparently Lose Badly
if you use chain mode. To further complicate things, some clones *only*
do chain mode, so make this whole mess conditional.
- The Xircom doesn't bring itself out of reset; we have to do it.
- The Xircom requires transmit buffers to be aligned to 4 bytes, too.
Partially from Rafal Boni (though the Tx buffer alignment issue is
handled much differently in this version).
this consistently, and it doesn't always work even when the chip
supports it.
- Make sure things DMA'd to the chip that the chip interprets are in
little-endian mode.
riastradh