Aren/NetBSD
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
1f23e23664
NetBSD/sys/opencrypto/files.opencrypto

31 lines
993 B
Plaintext
Raw Normal View History

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-20 02:51:18 +04:00
# $NetBSD: files.opencrypto,v 1.25 2011/11/19 22:51:30 tls Exp $
Commit initial NetBSD port of the OpenCrypto Framework (OCF). This code is derived from Sam Leffler's FreeBSD port of OCF, which is in turn a port of Angelos Keromytis's OpenBSD work. Credit to Sam and Angelos, any blame for the NetBSD port to me.
2003-07-26 01:12:39 +04:00
#
#
nuke trailing whitespace
2005-02-27 01:31:44 +03:00
# Opencrypto framework.
Split opencrypto configuration into an attribute, usable by inkernel clients, and a pseudo-device for userspace access. The attribute is named `opencrypto'. The pseudo-device is renamed to "crypto", which has a dependency on "opencrypto". The sys/conf/majors entry and pseudo-device attach entrypoint are updated to match the new pseudo-device name. Fast IPsec (sys/netipsec/files.ipsec) now lists a dependency on the "opencrypto" attribute. Drivers for crypto accelerators (ubsec, hifn775x) also pull in opencrypto, as providers of opencrypto transforms.
2003-12-31 19:44:26 +03:00
# Devices that provide crypto transforms via opencrypto, or subsystems
# that use the opencrypto framework, should list opencrypto as a dependency
# to pull in the framework.
Move the opencrypto defpseudo into files.opencrypto.
2003-08-24 23:21:11 +04:00
- De-couple the software crypto implementation from the rest of the framework. There is no need to waste the space if you are only using algoritms provided by hardware accelerators. To get the software implementations, add "pseudo-device swcr" to your kernel config. - Lazily initialize the opencrypto framework when crypto drivers (either hardware or swcr) register themselves with the framework.
2005-11-25 19:16:46 +03:00
define opencrypto
file opencrypto/criov.c opencrypto
Commit initial NetBSD port of the OpenCrypto Framework (OCF). This code is derived from Sam Leffler's FreeBSD port of OCF, which is in turn a port of Angelos Keromytis's OpenBSD work. Credit to Sam and Angelos, any blame for the NetBSD port to me.
2003-07-26 01:12:39 +04:00
file opencrypto/xform.c opencrypto
Split opencrypto configuration into an attribute, usable by inkernel clients, and a pseudo-device for userspace access. The attribute is named `opencrypto'. The pseudo-device is renamed to "crypto", which has a dependency on "opencrypto". The sys/conf/majors entry and pseudo-device attach entrypoint are updated to match the new pseudo-device name. Fast IPsec (sys/netipsec/files.ipsec) now lists a dependency on the "opencrypto" attribute. Drivers for crypto accelerators (ubsec, hifn775x) also pull in opencrypto, as providers of opencrypto transforms.
2003-12-31 19:44:26 +03:00
file opencrypto/crypto.c opencrypto
Cleanup traces of previous standalone m_apply()/m_getptr().
2003-07-27 07:34:39 +04:00
- De-couple the software crypto implementation from the rest of the framework. There is no need to waste the space if you are only using algoritms provided by hardware accelerators. To get the software implementations, add "pseudo-device swcr" to your kernel config. - Lazily initialize the opencrypto framework when crypto drivers (either hardware or swcr) register themselves with the framework.
2005-11-25 19:16:46 +03:00
# Pseudo-device that provides software implementations of various cryptographic
# algorithms.
swcr -> swcrypto
2005-11-25 19:41:31 +03:00
defpseudo swcrypto: opencrypto,
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-20 02:51:18 +04:00
blowfish, des, cast128, skipjack, camellia
swcr -> swcrypto
2005-11-25 19:41:31 +03:00
file opencrypto/cryptosoft.c swcrypto
file opencrypto/deflate.c swcrypto # wrapper around zlib
copy AES-XCBC-MAC support from KAME IPSEC to FAST_IPSEC For this to fit, an API change in cryptosoft was adopted from OpenBSD (addition of a "Setkey" method to hashes) which was done for GCM/GMAC support there, so it might be useful in the future anyway. tested against KAME IPSEC AFAICT, FAST_IPSEC now supports as much as KAME.
2011-05-24 23:10:08 +04:00
file opencrypto/aesxcbcmac.c swcrypto
pull in AES-GCM/GMAC support from OpenBSD This is still somewhat experimental. Tested between 2 similar boxes so far. There is much potential for performance improvement. For now, I've changed the gmac code to accept any data alignment, as the "char *" pointer suggests. As the code is practically used, 32-bit alignment can be assumed, at the cost of data copies. I don't know whether bytewise access or copies are worse performance-wise. For efficient implementations using SSE2 instructions on x86, even stricter alignment requirements might arise.
2011-05-27 01:50:02 +04:00
file opencrypto/gmac.c swcrypto
Split opencrypto configuration into an attribute, usable by inkernel clients, and a pseudo-device for userspace access. The attribute is named `opencrypto'. The pseudo-device is renamed to "crypto", which has a dependency on "opencrypto". The sys/conf/majors entry and pseudo-device attach entrypoint are updated to match the new pseudo-device name. Fast IPsec (sys/netipsec/files.ipsec) now lists a dependency on the "opencrypto" attribute. Drivers for crypto accelerators (ubsec, hifn775x) also pull in opencrypto, as providers of opencrypto transforms.
2003-12-31 19:44:26 +03:00
# Pseudo-device for userspace access to opencrypto
# (and thus crypto hardware accelerators).
- De-couple the software crypto implementation from the rest of the framework. There is no need to waste the space if you are only using algoritms provided by hardware accelerators. To get the software implementations, add "pseudo-device swcr" to your kernel config. - Lazily initialize the opencrypto framework when crypto drivers (either hardware or swcr) register themselves with the framework.
2005-11-25 19:16:46 +03:00
defpseudo crypto: opencrypto
Split opencrypto configuration into an attribute, usable by inkernel clients, and a pseudo-device for userspace access. The attribute is named `opencrypto'. The pseudo-device is renamed to "crypto", which has a dependency on "opencrypto". The sys/conf/majors entry and pseudo-device attach entrypoint are updated to match the new pseudo-device name. Fast IPsec (sys/netipsec/files.ipsec) now lists a dependency on the "opencrypto" attribute. Drivers for crypto accelerators (ubsec, hifn775x) also pull in opencrypto, as providers of opencrypto transforms.
2003-12-31 19:44:26 +03:00
file opencrypto/cryptodev.c crypto
make the compatibility code conditional on COMPAT_50
2011-02-19 19:26:34 +03:00
file opencrypto/ocryptodev.c crypto & compat_50
Rework opencrypto to use a spin mutex (crypto_mtx) instead of "splcrypto" (actually splnet) and condvars instead of tsleep/wakeup. Fix a few miscellaneous problems and add some debugging printfs while there. Restore set of CRYPTO_F_DONE in crypto_done() which was lost at some point after this code came from FreeBSD -- it made it impossible to wait properly for a condition. Add flags analogous to the "crp" flags to the key operation's krp struct. Add a new flag, CRYPTO_F_ONRETQ which tells us a request finished before the kthread had a chance to dequeue it and call its callback -- this was letting requests stick on the queues before even though done and copied out. Callers of crypto_newsession() or crypto_freesession() must now take the mutex. Change netipsec to do so. Dispatch takes the mutex itself as needed. This was tested fairly extensively with the cryptosoft backend and lightly with a new hardware driver. It has not been tested with FAST_IPSEC; I am unable to ascertain whether FAST_IPSEC currently works at all in our tree. pjd@FreeBSD.ORG, ad@NetBSD.ORG, and darran@snark.us pointed me in the right direction several times in the course of this. Remaining bugs are mine alone.
2008-02-04 03:35:34 +03:00
defflag opt_ocf.h CRYPTO_DEBUG CRYPTO_TIMING
Reference in New Issue Copy Permalink