which was demonstrated at Open Source Conference 2011 Kansai @ Kyoto
back in July:
http://www.NetBSD.org/gallery/events.html#opensourceconf2011-Kansai
- map 0xc0000000-0xffffffff PA region (which is mirror of PA 0x0-0x3fffffff)
to the same VA via %tt0 and %tt1 registers and move KVA space accordingly
(like luna68k does for its devices)
- save trap #0 vector for PROM function calls in early bootstrap
and register it to trap #14 to call it from kernel for console output
- add dumb romcall based tty attachment taken from src/sys/dev/ofw/ofcons.c
- add rom function call stubs from news68k/stand/common/romcalls.S
- remove IIOV() macro for device registers where now mapped PA==VA via %tt1
XXX: romcons is not enabled yet because there is no generic interface
XXX: to attach wskbd(4) to non wsdisplay(4) devices like this romcons.
sucking up to 8192 bytes out of the kernel arc4random() generator at a
time. Supposedly some very old application code uses this to rekey
other instances of RC4 in userspace (a truly great idea). Reduce the
limit to 256 bytes -- and note that it will probably be reduced to
sizeof(int) in the future, since this node is so documented.
<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.
http://mail-index.netbsd.org/source-changes/2011/10/22/msg028271.html
From the Log:
Log Message:
Various interrupt fixes, mainly:
keep a per-cpu mask of enabled events, and use it to get pending events.
A cpu-specific event (all of them at this time) should not be ever masked
by another CPU, because it may prevent the target CPU from seeing it
(the clock events all fires at once for example).
arithmetic, which may cause differences smaller than float precision
but still much larger than eps = 1e-30.
Forcing intermediate results to volatile variables removes the excess
precision.
Probably the combination of pow(4) ioctl and rtcalarm(8) does
not work for a long time, and nobody uses them.
I'll rewrite a part about power switch handler as a new device.
the header file and use that.
- sort the list of basic flags
- add MNT_RELATIME, ST_RELATIME
- mask all the op flags, for symmetry.
The real bit difference is (which is harmless):
- mount was missing MNT_EXTATTR
- update sets MNT_RDONLY twice
- ops also could or in MNT_GETARGS, but this is impossible because the
code would have chosen to do getargs then.
tsutsui