Commit Graph

26 Commits

Author SHA1 Message Date
pjd
aebc765efa Add support for AES-XTS.
Obtained from:	OpenBSD
MFC after:	1 week
2010-09-23 11:52:32 +00:00
gnn
38b76f0623 Integrate the Camellia Block Cipher. For more information see RFC 4132
and its bibliography.

Submitted by:   Tomoyuki Okazaki <okazaki at kick dot gr dot jp>
MFC after:      1 month
2007-05-09 19:37:02 +00:00
sam
f96ba7ffda Overhaul driver/subsystem api's:
o make all crypto drivers have a device_t; pseudo drivers like the s/w
  crypto driver synthesize one
o change the api between the crypto subsystem and drivers to use kobj;
  cryptodev_if.m defines this api
o use the fact that all crypto drivers now have a device_t to add support
  for specifying which of several potential devices to use when doing
  crypto operations
o add new ioctls that allow user apps to select a specific crypto device
  to use (previous ioctls maintained for compatibility)
o overhaul crypto subsystem code to eliminate lots of cruft and hide
  implementation details from drivers
o bring in numerous fixes from Michale Richardson/hifn; mostly for
  795x parts
o add an optional mechanism for mmap'ing the hifn 795x public key h/w
  to user space for use by openssl (not enabled by default)
o update crypto test tools to use new ioctl's and add cmd line options
  to specify a device to use for tests

These changes will also enable much future work on improving the core
crypto subsystem; including proper load balancing and interposing code
between the core and drivers to dispatch small operations to the s/w
driver as appropriate.

These changes were instigated by the work of Michael Richardson.

Reviewed by:	pjd
Approved by:	re
2007-03-21 03:42:51 +00:00
pjd
f055dbf32b - Replace COPYDATA() and COPYBACK() macros with crypto_copydata() and
crypto_copyback() functions.
- Add crypto_apply() function.

This will allow for more code simplification.
2006-06-04 22:15:13 +00:00
pjd
b966da31ff Move COPYDATA() and COPYBACK() macros to cryptodev.h, they will be used
in padlock(4) as well.
2006-06-04 15:10:12 +00:00
pjd
1dc756f405 - Remove HMAC_BLOCK_LEN, it serves no purpose.
- Use defines of used algorithm instead of HMAC_BLOCK_LEN.
2006-06-04 14:49:34 +00:00
pjd
7fa49327cd - Use define of an algorithm with the biggest block length to describe
EALG_MAX_BLOCK_LEN instead of hardcoded value.
- Kill an unused define.
2006-06-04 14:36:42 +00:00
pjd
2eba50f53d Rename HMAC_BLOCK_MAXLEN to HMAC_MAX_BLOCK_LEN to be consistent with
EALG_MAX_BLOCK_LEN.
2006-06-04 14:29:42 +00:00
pjd
ec1159e0d5 Rename AALG_MAX_RESULT_LEN to HASH_MAX_LEN to look more constent with
other defines.
2006-06-04 14:25:16 +00:00
pjd
d6c88e2e50 - Add defines with hash length for each hash algorithm.
- 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.
2006-06-04 14:20:47 +00:00
pjd
83d28e2330 Remove (now unused) crp_mac field. 2006-05-22 16:27:27 +00:00
pjd
61873b7dc9 Document how we synchronize access to the fields in the cryptocap
structure.
2006-05-22 07:49:42 +00:00
pjd
4de9eb667b - Fix a very old bug in HMAC/SHA{384,512}. When HMAC is using SHA384
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
2006-05-17 18:24:17 +00:00
pjd
eaddfa446c - Make opencrypto more SMP friendly by dropping the queue lock around
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
2006-05-17 18:12:44 +00:00
pjd
b51022e9f7 Remove cri_rnd. It is not used.
Reviewed by:	sam
2006-05-17 18:04:51 +00:00
pjd
5a9dad02c2 Forgot about adding cuio_apply() here.
Reviewed by:	sam
2006-05-17 17:58:05 +00:00
imp
f0bf889d0d /* -> /*- for license, minor formatting changes 2005-01-07 02:29:27 +00:00
phk
16b5363af4 Add CRD_F_KEY_EXPLICIT which allows the key to be changed per
operation, just like it was possible to change the IV.

Currently supported on Hifn and software engines only.

Approved by:	sam@
2004-02-02 17:06:34 +00:00
bms
3eb53d90ef Push m_apply() and m_getptr() up into the colleciton of standard mbuf
routines, and purge them from opencrypto.

Reviewed by:	sam
Obtained from:	NetBSD
Sponsored by:	spc.org
2003-12-15 21:49:41 +00:00
sam
e6dfb3860a consolidate callback optimization check in one location by adding a flag
for crypto operations that indicates the crypto code should do the check
in crypto_done

MFC after:	1 day
2003-06-30 05:09:32 +00:00
sam
e6589a620a Add support to eliminate a context switch per crypto op when using the
software crypto device:

o record crypto device capabilities in each session id
o add a capability that indicates if the crypto driver operates synchronously
o tag the software crypto driver as operating synchronously

This commit also introduces crypto session id macros that cleanup their
construction and querying.
2003-06-27 20:07:10 +00:00
sam
fd016d7448 Flush my local cache of cryto subsystem fixes:
o add a ``done'' flag for crypto operations; this is set when the operation
  completes and is intended for callers to check operations that may complete
  ``prematurely'' because of direct callbacks
o close a race for operations where the crypto driver returns ERESTART: we
  need to hold the q lock to insure the blocked state for the driver and any
  driver-private state is consistent; otherwise drivers may take an interrupt
  and notify the crypto subsystem that it can unblock the driver but operations
  will be left queued and never be processed
o close a race in /dev/crypto where operations can complete before the caller
  can sleep waiting for the callback: use a per-session mutex and the new done
  flag to handle this
o correct crypto_dispatch's handling of operations where the driver returns
  ERESTART: the return value must be zero and not ERESTART, otherwise the
  caller may free the crypto request despite it being queued for later handling
  (this typically results in a later panic)
o change crypto mutex ``names'' so witness printouts and the like are more
  meaningful
2003-06-02 23:28:06 +00:00
sam
9da403e48c o add a CRYPTO_F_CBIMM flag to symmetric ops to indicate the callback
should be done in crypto_done rather than in the callback thread
o use this flag to mark operations from /dev/crypto since the callback
  routine just does a wakeup; this eliminates the last unneeded ctx switch
o change CRYPTO_F_NODELAY to CRYPTO_F_BATCH with an inverted meaning
  so "0" becomes the default/desired setting (needed for user-mode
  compatibility with openbsd)
o change crypto_dispatch to honor CRYPTO_F_BATCH instead of always
  dispatching immediately
o remove uses of CRYPTO_F_NODELAY
o define COP_F_BATCH for ops submitted through /dev/crypto and pass
  this on to the op that is submitted

Similar changes and more eventually coming for asymmetric ops.

MFC if re gives approval.
2003-02-23 07:25:48 +00:00
sam
b452c09708 MFS: crypto timing support; purge usercrypto sysctl (just don't config
cryptodev or kldunload cryptodev module); crypto statistcs; remove
unused alloctype field from crypto op to offset addition of the
performance time stamp

Supported by:	Vernier Networks
2003-01-03 06:16:59 +00:00
sam
d1b4781c0c remove CIOGSSESSION (get software session); it was added only for testing 2002-10-07 18:37:31 +00:00
sam
91416784e4 In-kernel crypto framework derived from openbsd. This facility provides
a consistent interface to h/w and s/w crypto algorithms for use by the
kernel and (for h/w at least) by user-mode apps.  Access for user-level
code is through a /dev/crypto device that'll eventually be used by openssl
to (potentially) accelerate many applications.  Coming soon is an IPsec
that makes use of this service to accelerate ESP, AH, and IPCOMP protocols.

Included here is the "core" crypto support, /dev/crypto driver, various
crypto algorithms that are not already present in the KAME crypto area,
and support routines used by crypto device drivers.

Obtained from:	openbsd
2002-10-04 20:31:23 +00:00