summaryrefslogtreecommitdiffstats
path: root/sys/opencrypto
Commit message (Collapse)AuthorAgeFilesLines
* When DIAGNOSTIC is defined, verify if we don't free crypto requests frompjd2006-06-061-0/+21
| | | | the crypto queue or from the return queue.
* Use newly added functions to simplify the code.pjd2006-06-041-82/+54
|
* - Replace COPYDATA() and COPYBACK() macros with crypto_copydata() andpjd2006-06-042-27/+47
| | | | | | | crypto_copyback() functions. - Add crypto_apply() function. This will allow for more code simplification.
* Prefer hardware crypto over software crypto.pjd2006-06-041-38/+74
| | | | | | Before the change if a hardware crypto driver was loaded after the software crypto driver, calling crypto_newsession() with hard=0, will always choose software crypto.
* Use newly added defines instead of magic values.pjd2006-06-041-16/+16
|
* Move COPYDATA() and COPYBACK() macros to cryptodev.h, they will be usedpjd2006-06-042-27/+27
| | | | in padlock(4) as well.
* - Remove HMAC_BLOCK_LEN, it serves no purpose.pjd2006-06-041-1/+0
| | | | - Use defines of used algorithm instead of HMAC_BLOCK_LEN.
* - Use define of an algorithm with the biggest block length to describepjd2006-06-041-3/+1
| | | | | EALG_MAX_BLOCK_LEN instead of hardcoded value. - Kill an unused define.
* Rename HMAC_BLOCK_MAXLEN to HMAC_MAX_BLOCK_LEN to be consistent withpjd2006-06-042-6/+6
| | | | EALG_MAX_BLOCK_LEN.
* Rename AALG_MAX_RESULT_LEN to HASH_MAX_LEN to look more constent withpjd2006-06-042-4/+4
| | | | other defines.
* - Add defines with hash length for each hash algorithm.pjd2006-06-041-4/+24
| | | | | | - Add defines with block length for each HMAC algorithm. - Add AES_BLOCK_LEN define which is an alias for RIJNDAEL128_BLOCK_LEN. - Add NULL_BLOCK_LEN define.
* Kill an unused argument.pjd2006-06-041-5/+5
|
* Remove (now unused) crp_mac field.pjd2006-05-221-1/+0
|
* Fix usage of HMAC algorithms via /dev/crypto.pjd2006-05-221-10/+10
|
* Improve the code responsible for waking up the crypto_proc thread.pjd2006-05-221-14/+11
| | | | | | | | | | | | | Checking if the queues are empty is not enough for the crypto_proc thread (it is enough for the crypto_ret_thread), because drivers can be marked as blocked. In a situation where we have operations related to different crypto drivers in the queue, it is possible that one driver is marked as blocked. In this case, the queue will not be empty and we won't wakeup the crypto_proc thread to execute operations for the others drivers. Simply setting a global variable to 1 when we goes to sleep and setting it back to 0 when we wake up is sufficient. The variable is protected with the queue lock.
* Don't wakeup the crypto_ret_proc thread if it is running already.pjd2006-05-221-2/+3
| | | | | | Before the change if the thread was working on symmetric operation, we would send unnecessary wakeup after adding asymmetric operation (when asym queue was empty) and vice versa.
* Don't set cc_kqblocked twice and don't increment cryptostats.cs_kblockspjd2006-05-221-2/+0
| | | | | | twice if we call crypto_kinvoke() from crypto_proc thread. This change also removes unprotected access to cc_kqblocked field (CRYPTO_Q_LOCK() should be used for protection).
* Document how we synchronize access to the fields in the cryptocappjd2006-05-221-6/+13
| | | | structure.
* We must synchronize access to cc_qblocked, because there could be a racepjd2006-05-221-17/+4
| | | | | | | | | | | | | where crypto_invoke() returns ERESTART and before we set cc_qblocked to 1, crypto_unblock() is called and sets it to 0. This way we mark device as blocked forever. Fix it by not setting cc_qblocked in the fast path and by protecting crypto_invoke() in the crypto_proc thread with CRYPTO_Q_LOCK(). This won't slow things down, because there is no contention - we have only one crypto thread. Actually it can be slightly faster, because we save two atomic ops per crypto request. The fast code path remains lock-less.
* Silent Coverity Prevent report by asserting that cap != NULL.pjd2006-05-181-2/+4
| | | | Coverity ID: 1414
* - Fix a very old bug in HMAC/SHA{384,512}. When HMAC is using SHA384pjd2006-05-176-132/+194
| | | | | | | | | | | | | | | | | | | | | | | | | | | | or SHA512, the blocksize is 128 bytes, not 64 bytes as anywhere else. The bug also exists in NetBSD, OpenBSD and various other independed implementations I look at. - We cannot decide which hash function to use for HMAC based on the key length, because any HMAC function can use any key length. To fix it split CRYPTO_SHA2_HMAC into three algorithm: CRYPTO_SHA2_256_HMAC, CRYPTO_SHA2_384_HMAC and CRYPTO_SHA2_512_HMAC. Those names are consistent with OpenBSD's naming. - Remove authsize field from auth_hash structure. - Allow consumer to define size of hash he wants to receive. This allows to use HMAC not only for IPsec, where 96 bits MAC is requested. The size of requested MAC is defined at newsession time in the cri_mlen field - when 0, entire MAC will be returned. - Add swcr_authprepare() function which prepares authentication key. - Allow to provide key for every authentication operation, not only at newsession time by honoring CRD_F_KEY_EXPLICIT flag. - Make giving key at newsession time optional - don't try to operate on it if its NULL. - Extend COPYBACK()/COPYDATA() macros to handle CRYPTO_BUF_CONTIG buffer type as well. - Accept CRYPTO_BUF_IOV buffer type in swcr_authcompute() as we have cuio_apply() now. - 16 bits for key length (SW_klen) is more than enough. Reviewed by: sam
* - Make opencrypto more SMP friendly by dropping the queue lock aroundpjd2006-05-172-145/+140
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | crypto_invoke(). This allows to serve multiple crypto requests in parallel and not bached requests are served lock-less. Drivers should not depend on the queue lock beeing held around crypto_invoke() and if they do, that's an error in the driver - it should do its own synchronization. - Don't forget to wakeup the crypto thread when new requests is queued and only if both symmetric and asymmetric queues are empty. - Symmetric requests use sessions and there is no way driver can disappear when there is an active session, so we don't need to check this, but assert this. This is also safe to not use the driver lock in this case. - Assymetric requests don't use sessions, so don't check the driver in crypto_kinvoke(). - Protect assymetric operation with the driver lock, because if there is no symmetric session, driver can disappear. - Don't send assymetric request to the driver if it is marked as blocked. - Add an XXX comment, because I don't think migration to another driver is safe when there are pending requests using freed session. - Remove 'hint' argument from crypto_kinvoke(), as it serves no purpose. - Don't hold the driver lock around kprocess method call, instead use cc_koperations to track number of in-progress requests. - Cleanup register/unregister code a bit. - Other small simplifications and cleanups. Reviewed by: sam
* Remove cri_rnd. It is not used.pjd2006-05-171-2/+0
| | | | Reviewed by: sam
* If kern.cryptodevallowsoft is TRUE allow also for symmetric software cryptopjd2006-05-171-2/+8
| | | | | | in kernel. Useful for testing. Reviewed by: sam
* Forgot about adding cuio_apply() here.pjd2006-05-171-0/+2
| | | | Reviewed by: sam
* - Implement cuio_apply(), an equivalent to m_apply(9).pjd2006-05-171-30/+49
| | | | | | | | - Implement CUIO_SKIP() macro which is only responsible for skipping the given number of bytes from iovec list. This allows to avoid duplicating the same code in three functions. Reviewed by: sam
* Be sure to wakeup the crypto thread when new request was queued.pjd2006-04-111-6/+8
| | | | | | This should fix a hang when starting cryptokeytest (and more). MFC after: 1 month
* - Simplify the code by using arc4rand(9) instead of arc4random(9) in a loop.pjd2006-04-101-22/+3
| | | | | | - Correct a comment. MFC after: 2 weeks
* Fix memory leak which occurs when crypto.ko module is unloaded.pjd2006-03-281-0/+9
| | | | | Discussed with: sam MFC after 3 days
* crypto.ko depends on zlib.wkoszek2006-03-041-0/+1
| | | | | | | Submitted by: Ben Kelly <bkelly at vadev.org> Approved by: rwatson Point hat to: me MFC after: 1 day
* This patch fixes a problem, which exists if you have IPSEC in your kernelwkoszek2006-02-271-0/+1
| | | | | | | | | | | and want to have crypto support loaded as KLD. By moving zlib to separate module and adding MODULE_DEPEND directives, it is possible to use such configuration without complication. Otherwise, since IPSEC is linked with zlib (just like crypto.ko) you'll get following error: interface zlib.1 already present in the KLD 'kernel'! Approved by: cognet (mentor)
* Fix bogus check. It was possible to panic the kernel by giving 0 length.pjd2005-08-181-2/+4
| | | | | | | | | This is actually a local DoS, as every user can use /dev/crypto if there is crypto hardware in the system and cryptodev.ko is loaded (or compiled into the kernel). Reported by: Mike Tancsa <mike@sentex.net> MFC after: 1 day
* Check key size for rijndael, as invalid key size can lead to kernel panic.pjd2005-08-161-0/+2
| | | | | | | | | It checked other algorithms against this bug and it seems they aren't affected. Reported by: Mike Tancsa <mike@sentex.net> PR: i386/84860 Reviewed by: phk, cperciva(x2)
* malloc.h relies on param.h for a definition of MAXCPU. I guess that there isscottl2005-05-301-0/+1
| | | | | other header pollution that makes this work right now, but it falls over when doing a RELENG_5 -> HEAD upgrade.
* just use crypto/rijndael, and nuke opencrypto/rindael.[ch].ume2005-03-113-1286/+1
| | | | | | the two became almost identical since latest KAME merge. Discussed with: sam
* - use 1/2 space for rijndael context in ipsecume2005-03-113-25/+14
| | | | | | | | - rijndael_set_key() always sets up full context - rijndaelKeySetupDec() gets back original protoype Reviewed by: sam Obtained from: OpenBSD
* refer opencrypto/cast.h directly.ume2005-03-111-1/+1
|
* Use dynamic major number allocation.phk2005-02-271-2/+0
|
* /* -> /*- for license, minor formatting changesimp2005-01-0720-20/+20
|
* Push Giant down through ioctl.phk2004-11-171-3/+16
| | | | | | | | | | | | | Don't grab Giant in the upper syscall/wrapper code NET_LOCK_GIANT in the socket code (sockets/fifos). mtx_lock(&Giant) in the vnode code. mtx_lock(&Giant) in the opencrypto code. (This may actually not be needed, but better safe than sorry). Devfs grabs Giant if the driver is marked as needing Giant.
* Don't acquire Giant in cryptof_close(), as the code is intended to berwatson2004-08-101-7/+0
| | | | | | able to run MPsafe (and appears to be MPsafe). Discussed with (some time ago): sam
* Push acquisition of Giant from fdrop_closed() into fo_close() so thatrwatson2004-07-221-0/+7
| | | | | | | | | | | | | | | | | | | | | | | individual file object implementations can optionally acquire Giant if they require it: - soo_close(): depends on debug.mpsafenet - pipe_close(): Giant not acquired - kqueue_close(): Giant required - vn_close(): Giant required - cryptof_close(): Giant required (conservative) Notes: Giant is still acquired in close() even when closing MPSAFE objects due to kqueue requiring Giant in the calling closef() code. Microbenchmarks indicate that this removal of Giant cuts 3%-3% off of pipe create/destroy pairs from user space with SMP compiled into the kernel. The cryptodev and opencrypto code appears MPSAFE, but I'm unable to test it extensively and so have left Giant over fo_close(). It can probably be removed given some testing and review.
* Do the dreaded s/dev_t/struct cdev */phk2004-06-161-5/+5
| | | | Bump __FreeBSD_version accordingly.
* add missing #include <sys/module.h>phk2004-05-302-0/+2
|
* kthread_exit() no longer requires Giant, so don't force callers to acquirejhb2004-03-051-1/+0
| | | | | | Giant just to call kthread_exit(). Requested by: many
* Device megapatch 4/6:phk2004-02-211-0/+2
| | | | | | | | Introduce d_version field in struct cdevsw, this must always be initialized to D_VERSION. Flip sense of D_NOGIANT flag to D_NEEDGIANT, this involves removing four D_NOGIANT flags and adding 145 D_NEEDGIANT flags.
* Do not aggressively unroll the AES implementation, in non-benchmarking usephk2004-02-041-2/+0
| | | | | | it is same speed on small cache cpus and slower on largecache cpus. Approved by: sam@
* Add CRD_F_KEY_EXPLICIT which allows the key to be changed perphk2004-02-022-0/+11
| | | | | | | | operation, just like it was possible to change the IV. Currently supported on Hifn and software engines only. Approved by: sam@
* style(9) pass and type fixups.bms2003-12-161-1/+1
| | | | Submitted by: bde
* Purge crmbuf.c as the routines are now in uipc_mbuf.c.bms2003-12-151-119/+0
| | | | | Reviewed by: sam Sponsored by: spc.org
OpenPOWER on IntegriCloud