| Age | Commit message (Collapse) | Author |
|
|
|
|
|
so revert previous commits to fix build. I'll look at rereverting when
toolchain/47644 is fixed and clean buildtests are again possible.
|
|
|
|
This allows a few highly desirable things to happen:
1) Linux support, which is included in this commit (thanks to wanq for
sending me the magic bits for accessing /dev/net/tun)
2) Reusing the kernel-side of the interface for devices such as
hardware packet processors which interact directly with user vm spaces
(not included in the commit).
|
|
and hypervisor.
|
|
<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.
|
|
|
|
|
|
|
|
it's not going to be MPSAFE.
|
|
it a little less eager to panic.
|
|
"ifconfig create". As previously, virt<n> interfaces with the
host's /dev/tap<n> (I guess it could be made explicit with
"ifconfig media", but leave it this way for now).
|
|
* deal with a tap quirk when it returns 0 bytes
|
|
|
|
check into the inline functions as well the fourth argument for
bpf_attach.
|
|
module which is linked into the kernel and cannot be unloaded.
The main purpose is to get the proper constructors run and create
any /dev nodes necessary for said component. Once more of the
kernel (e.g. networking stack and device drivers) are converted to
MODULE and devfs pops up from somewhere, rump components can be
retired.
|
|
#if NBPFILTER is no longer required in the client. This change
doesn't yet add support for loading bpf as a module, since drivers
can register before bpf is attached. However, callers of bpf can
now be modularized.
Dynamically loadable bpf could probably be done fairly easily with
coordination from the stub driver and the real driver by registering
attachments in the stub before the real driver is loaded and doing
a handoff. ... and I'm not going to ponder the depths of unload
here.
Tested with i386/MONOLITHIC, modified MONOLITHIC without bpf and rump.
|
|
|
|
|
|
No functional change.
|
|
with 17 per chain (previous i'm-too-lazy-for-my-forloop value was
of course 16).
|
|
opened fd's will also be non-blocking.
(yeayea, i'll fix the kernel some day, but I don't want to reboot
my host OS now)
|
|
are present. This works in userspace as opposed relying in link
sets, which fail miserably. Later, when the networking stack
becomes modularized, we can move to a dynamic scheme like with file
systems.
Also, this change allows us to do proper autoconfig, namely attach
the loopback interface iff it is present.
|
|
it has no backend it can always be attached and is therefore
convenient for testing ifconfig.
|
|
in multicast hugging.
|
|
* create "unique" enaddr
* do send in async context
|
|
ether_ifattach() should point to a struct ethercom.
|
|
|
|
|
|
place later).
|
|
|
|
(address assignment probably needs some more work if we want to
support multiple interfaces).
hat tip to Quentin Garnier
|
|
is an ethernet multicast address. TCP does not like ethernet
multicast addresses.
|
|
for any sensible operation when running the entire TCP/IP stack in
userspace (as opposed to libsockin which uses host kernel networking
to provide PF_INET).
While this basically works (although it is quite barebones), it
depends on some bit of cleanup in librump and is not built by
default yet.
|