NetBSD/sys/arch/xen/include
tls 3afd44cf08 First step of random number subsystem rework described in
<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.
2011-11-19 22:51:18 +00:00
..
amd64
i386
xen3-public
balloon.h
bus_private.h
evtchn.h Merge jym-xensuspend branch in -current. ok bouyer@. 2011-09-20 00:12:23 +00:00
granttables.h Merge jym-xensuspend branch in -current. ok bouyer@. 2011-09-20 00:12:23 +00:00
hypervisor.h [merging from cherry-xenmp] bring in bouyer@'s changes via: 2011-11-19 17:13:39 +00:00
i82093var.h
i82489var.h
if_xennetvar.h
intr.h Make event/interrupt handling MP aware 2011-08-11 17:58:59 +00:00
intrdefs.h Add an ipi callback to force hypervisor callback. this is useful to "re-route" interrupts to a given vcpu 2011-11-07 15:51:31 +00:00
kernfs_machdep.h
Makefile
mpacpi.h
pci_machdep.h
pic.h
shutdown_xenbus.h Merge jym-xensuspend branch in -current. ok bouyer@. 2011-09-20 00:12:23 +00:00
vcpuvar.h
xbdvar.h First step of random number subsystem rework described in 2011-11-19 22:51:18 +00:00
xen_shm.h
xen.h Merge jym-xensuspend branch in -current. ok bouyer@. 2011-09-20 00:12:23 +00:00
xenbus.h Merge jym-xensuspend branch in -current. ok bouyer@. 2011-09-20 00:12:23 +00:00
xenfunc.h
xenio3.h
xenio_gntdev.h
xenio.h
xennet_checksum.h
xenpmap.h Expose the PG_k #define pt/pd bit to both xen and "baremetal" x86. This is required, since kernel pages are mapped with user permissions in XEN/amd64 since the VM kernel runs in ring3. Since XEN/i386(including PAE) runs in ring1, supervisor mode is appropriate for these ports. We need to share this since the pmap implementation is still shared. Once the xen implementation is sufficiently independant of the x86 one, this can be made private to xen/include/xenpmap.h 2011-11-08 17:16:52 +00:00