d/freebsd-skq
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
956d4fb965
freebsd-skq/sys/opencrypto/cryptodev.c

1180 lines
26 KiB
C
Raw Normal View History

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
/* $OpenBSD: cryptodev.c,v 1.52 2002/06/19 07:22:46 deraadt Exp $ */
/* -> /*- for license, minor formatting changes
2005-01-07 02:29:27 +00:00
/*-
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
* Copyright (c) 2001 Theo de Raadt
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
* Copyright (c) 2002-2006 Sam Leffler, Errno Consulting
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
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
* 3. The name of the author may not be used to endorse or promote products
* derived from this software without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
* IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
* IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
* INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
* NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
* DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
* THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
* THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*
* Effort sponsored in part by the Defense Advanced Research Projects
* Agency (DARPA) and Air Force Research Laboratory, Air Force
* Materiel Command, USAF, under agreement number F30602-01-2-0537.
*/
Use __FBSDID().
2003-06-11 05:57:50 +00:00
#include <sys/cdefs.h>
__FBSDID("$FreeBSD$");
Add compat32 shims for opencrypto(4). Reviewed by: bz MFC after: 3 weeks
2010-07-29 20:42:20 +00:00
#include "opt_compat.h"
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
#include <sys/param.h>
#include <sys/systm.h>
#include <sys/malloc.h>
#include <sys/mbuf.h>
#include <sys/lock.h>
#include <sys/mutex.h>
#include <sys/sysctl.h>
#include <sys/file.h>
#include <sys/filedesc.h>
#include <sys/errno.h>
#include <sys/uio.h>
#include <sys/random.h>
#include <sys/conf.h>
#include <sys/kernel.h>
add missing #include <sys/module.h>
2004-05-30 20:27:19 +00:00
#include <sys/module.h>
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
#include <sys/fcntl.h>
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
#include <sys/bus.h>
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
#include <opencrypto/cryptodev.h>
#include <opencrypto/xform.h>
Add compat32 shims for opencrypto(4). Reviewed by: bz MFC after: 3 weeks
2010-07-29 20:42:20 +00:00
#ifdef COMPAT_FREEBSD32
#include <sys/mount.h>
#include <compat/freebsd32/freebsd32.h>
struct session_op32 {
u_int32_t cipher;
u_int32_t mac;
u_int32_t keylen;
u_int32_t key;
int mackeylen;
u_int32_t mackey;
u_int32_t ses;
};
struct session2_op32 {
u_int32_t cipher;
u_int32_t mac;
u_int32_t keylen;
u_int32_t key;
int mackeylen;
u_int32_t mackey;
u_int32_t ses;
int crid;
int pad[4];
};
struct crypt_op32 {
u_int32_t ses;
u_int16_t op;
u_int16_t flags;
u_int len;
u_int32_t src, dst;
u_int32_t mac;
u_int32_t iv;
};
struct crparam32 {
u_int32_t crp_p;
u_int crp_nbits;
};
struct crypt_kop32 {
u_int crk_op;
u_int crk_status;
u_short crk_iparams;
u_short crk_oparams;
u_int crk_crid;
struct crparam32 crk_param[CRK_MAXPARAM];
};
struct cryptotstat32 {
struct timespec32 acc;
struct timespec32 min;
struct timespec32 max;
u_int32_t count;
};
struct cryptostats32 {
u_int32_t cs_ops;
u_int32_t cs_errs;
u_int32_t cs_kops;
u_int32_t cs_kerrs;
u_int32_t cs_intrs;
u_int32_t cs_rets;
u_int32_t cs_blocks;
u_int32_t cs_kblocks;
struct cryptotstat32 cs_invoke;
struct cryptotstat32 cs_done;
struct cryptotstat32 cs_cb;
struct cryptotstat32 cs_finis;
};
#define CIOCGSESSION32 _IOWR('c', 101, struct session_op32)
#define CIOCCRYPT32 _IOWR('c', 103, struct crypt_op32)
#define CIOCKEY32 _IOWR('c', 104, struct crypt_kop32)
#define CIOCGSESSION232 _IOWR('c', 106, struct session2_op32)
#define CIOCKEY232 _IOWR('c', 107, struct crypt_kop32)
static void
session_op_from_32(const struct session_op32 *from, struct session_op *to)
{
CP(*from, *to, cipher);
CP(*from, *to, mac);
CP(*from, *to, keylen);
PTRIN_CP(*from, *to, key);
CP(*from, *to, mackeylen);
PTRIN_CP(*from, *to, mackey);
CP(*from, *to, ses);
}
static void
session2_op_from_32(const struct session2_op32 *from, struct session2_op *to)
{
session_op_from_32((const struct session_op32 *)from,
(struct session_op *)to);
CP(*from, *to, crid);
}
static void
session_op_to_32(const struct session_op *from, struct session_op32 *to)
{
CP(*from, *to, cipher);
CP(*from, *to, mac);
CP(*from, *to, keylen);
PTROUT_CP(*from, *to, key);
CP(*from, *to, mackeylen);
PTROUT_CP(*from, *to, mackey);
CP(*from, *to, ses);
}
static void
session2_op_to_32(const struct session2_op *from, struct session2_op32 *to)
{
session_op_to_32((const struct session_op *)from,
(struct session_op32 *)to);
CP(*from, *to, crid);
}
static void
crypt_op_from_32(const struct crypt_op32 *from, struct crypt_op *to)
{
CP(*from, *to, ses);
CP(*from, *to, op);
CP(*from, *to, flags);
CP(*from, *to, len);
PTRIN_CP(*from, *to, src);
PTRIN_CP(*from, *to, dst);
PTRIN_CP(*from, *to, mac);
PTRIN_CP(*from, *to, iv);
}
static void
crypt_op_to_32(const struct crypt_op *from, struct crypt_op32 *to)
{
CP(*from, *to, ses);
CP(*from, *to, op);
CP(*from, *to, flags);
CP(*from, *to, len);
PTROUT_CP(*from, *to, src);
PTROUT_CP(*from, *to, dst);
PTROUT_CP(*from, *to, mac);
PTROUT_CP(*from, *to, iv);
}
static void
crparam_from_32(const struct crparam32 *from, struct crparam *to)
{
PTRIN_CP(*from, *to, crp_p);
CP(*from, *to, crp_nbits);
}
static void
crparam_to_32(const struct crparam *from, struct crparam32 *to)
{
PTROUT_CP(*from, *to, crp_p);
CP(*from, *to, crp_nbits);
}
static void
crypt_kop_from_32(const struct crypt_kop32 *from, struct crypt_kop *to)
{
int i;
CP(*from, *to, crk_op);
CP(*from, *to, crk_status);
CP(*from, *to, crk_iparams);
CP(*from, *to, crk_oparams);
CP(*from, *to, crk_crid);
for (i = 0; i < CRK_MAXPARAM; i++)
crparam_from_32(&from->crk_param[i], &to->crk_param[i]);
}
static void
crypt_kop_to_32(const struct crypt_kop *from, struct crypt_kop32 *to)
{
int i;
CP(*from, *to, crk_op);
CP(*from, *to, crk_status);
CP(*from, *to, crk_iparams);
CP(*from, *to, crk_oparams);
CP(*from, *to, crk_crid);
for (i = 0; i < CRK_MAXPARAM; i++)
crparam_to_32(&from->crk_param[i], &to->crk_param[i]);
}
#endif
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
struct csession {
TAILQ_ENTRY(csession) next;
u_int64_t sid;
u_int32_t ses;
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
struct mtx lock; /* for op submission */
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
u_int32_t cipher;
struct enc_xform *txform;
u_int32_t mac;
struct auth_hash *thash;
caddr_t key;
int keylen;
u_char tmp_iv[EALG_MAX_BLOCK_LEN];
caddr_t mackey;
int mackeylen;
eliminate an unnecessary 8Kbyte bzero that was being done for each submitted operation Submitted by: Thor Lancelot Simon Reviewed by: jhb Approved by: re (jhb)
2003-11-19 22:42:34 +00:00
struct iovec iovec;
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
struct uio uio;
int error;
};
struct fcrypt {
TAILQ_HEAD(csessionlist, csession) csessions;
int sesn;
};
static int cryptof_rw(struct file *fp, struct uio *uio,
struct ucred *cred, int flags, struct thread *);
Make ftruncate a 'struct file' operation rather than a vnode operation. This makes it possible to support ftruncate() on non-vnode file types in the future. - 'struct fileops' grows a 'fo_truncate' method to handle an ftruncate() on a given file descriptor. - ftruncate() moves to kern/sys_generic.c and now just fetches a file object and invokes fo_truncate(). - The vnode-specific portions of ftruncate() move to vn_truncate() in vfs_vnops.c which implements fo_truncate() for vnode file types. - Non-vnode file types return EINVAL in their fo_truncate() method. Submitted by: rwatson
2008-01-07 20:05:19 +00:00
static int cryptof_truncate(struct file *, off_t, struct ucred *,
struct thread *);
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
static int cryptof_ioctl(struct file *, u_long, void *,
struct ucred *, struct thread *);
static int cryptof_poll(struct file *, int, struct ucred *, struct thread *);
static int cryptof_kqfilter(struct file *, struct knote *);
static int cryptof_stat(struct file *, struct stat *,
struct ucred *, struct thread *);
static int cryptof_close(struct file *, struct thread *);
static struct fileops cryptofops = {
Initialize struct fileops with C99 sparse initialization.
2003-06-18 18:16:40 +00:00
.fo_read = cryptof_rw,
.fo_write = cryptof_rw,
Make ftruncate a 'struct file' operation rather than a vnode operation. This makes it possible to support ftruncate() on non-vnode file types in the future. - 'struct fileops' grows a 'fo_truncate' method to handle an ftruncate() on a given file descriptor. - ftruncate() moves to kern/sys_generic.c and now just fetches a file object and invokes fo_truncate(). - The vnode-specific portions of ftruncate() move to vn_truncate() in vfs_vnops.c which implements fo_truncate() for vnode file types. - Non-vnode file types return EINVAL in their fo_truncate() method. Submitted by: rwatson
2008-01-07 20:05:19 +00:00
.fo_truncate = cryptof_truncate,
Initialize struct fileops with C99 sparse initialization.
2003-06-18 18:16:40 +00:00
.fo_ioctl = cryptof_ioctl,
.fo_poll = cryptof_poll,
.fo_kqfilter = cryptof_kqfilter,
.fo_stat = cryptof_stat,
Add the fo_chown and fo_chmod methods to struct fileops and use them to implement fchown(2) and fchmod(2) support for several file types that previously lacked it. Add MAC entries for chown/chmod done on posix shared memory and (old) in-kernel posix semaphores. Based on the submission by: glebius Reviewed by: rwatson Approved by: re (bz)
2011-08-16 20:07:47 +00:00
.fo_close = cryptof_close,
.fo_chmod = invfo_chmod,
.fo_chown = invfo_chown,
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
};
static struct csession *csefind(struct fcrypt *, u_int);
static int csedelete(struct fcrypt *, struct csession *);
static struct csession *cseadd(struct fcrypt *, struct csession *);
static struct csession *csecreate(struct fcrypt *, u_int64_t, caddr_t,
u_int64_t, caddr_t, u_int64_t, u_int32_t, u_int32_t, struct enc_xform *,
struct auth_hash *);
static int csefree(struct csession *);
static int cryptodev_op(struct csession *, struct crypt_op *,
struct ucred *, struct thread *td);
static int cryptodev_key(struct crypt_kop *);
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
static int cryptodev_find(struct crypt_find_op *);
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
static int
cryptof_rw(
struct file *fp,
struct uio *uio,
struct ucred *active_cred,
int flags,
struct thread *td)
{
return (EIO);
}
Make ftruncate a 'struct file' operation rather than a vnode operation. This makes it possible to support ftruncate() on non-vnode file types in the future. - 'struct fileops' grows a 'fo_truncate' method to handle an ftruncate() on a given file descriptor. - ftruncate() moves to kern/sys_generic.c and now just fetches a file object and invokes fo_truncate(). - The vnode-specific portions of ftruncate() move to vn_truncate() in vfs_vnops.c which implements fo_truncate() for vnode file types. - Non-vnode file types return EINVAL in their fo_truncate() method. Submitted by: rwatson
2008-01-07 20:05:19 +00:00
static int
cryptof_truncate(
struct file *fp,
off_t length,
struct ucred *active_cred,
struct thread *td)
{
return (EINVAL);
}
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
/*
* Check a crypto identifier to see if it requested
* a software device/driver. This can be done either
* by device name/class or through search constraints.
*/
static int
checkforsoftware(int crid)
{
if (crid & CRYPTOCAP_F_SOFTWARE)
return EINVAL; /* XXX */
if ((crid & CRYPTOCAP_F_HARDWARE) == 0 &&
(crypto_getcaps(crid) & CRYPTOCAP_F_HARDWARE) == 0)
return EINVAL; /* XXX */
return 0;
}
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
/* ARGSUSED */
static int
cryptof_ioctl(
struct file *fp,
u_long cmd,
void *data,
struct ucred *active_cred,
struct thread *td)
{
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
#define SES2(p) ((struct session2_op *)p)
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
struct cryptoini cria, crie;
Bow to the whining masses and change a union back into void *. Retain removal of unnecessary casts and throw in some minor cleanups to see if anyone complains, just for the hell of it.
2003-01-13 00:33:17 +00:00
struct fcrypt *fcr = fp->f_data;
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
struct csession *cse;
struct session_op *sop;
struct crypt_op *cop;
struct enc_xform *txform = NULL;
struct auth_hash *thash = NULL;
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
struct crypt_kop *kop;
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
u_int64_t sid;
u_int32_t ses;
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
int error = 0, crid;
Add compat32 shims for opencrypto(4). Reviewed by: bz MFC after: 3 weeks
2010-07-29 20:42:20 +00:00
#ifdef COMPAT_FREEBSD32
struct session2_op sopc;
struct crypt_op copc;
struct crypt_kop kopc;
#endif
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
switch (cmd) {
case CIOCGSESSION:
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
case CIOCGSESSION2:
Add compat32 shims for opencrypto(4). Reviewed by: bz MFC after: 3 weeks
2010-07-29 20:42:20 +00:00
#ifdef COMPAT_FREEBSD32
case CIOCGSESSION32:
case CIOCGSESSION232:
if (cmd == CIOCGSESSION32) {
session_op_from_32(data, (struct session_op *)&sopc);
sop = (struct session_op *)&sopc;
} else if (cmd == CIOCGSESSION232) {
session2_op_from_32(data, &sopc);
sop = (struct session_op *)&sopc;
} else
#endif
sop = (struct session_op *)data;
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
switch (sop->cipher) {
case 0:
break;
case CRYPTO_DES_CBC:
txform = &enc_xform_des;
break;
case CRYPTO_3DES_CBC:
txform = &enc_xform_3des;
break;
case CRYPTO_BLF_CBC:
txform = &enc_xform_blf;
break;
case CRYPTO_CAST_CBC:
txform = &enc_xform_cast5;
break;
case CRYPTO_SKIPJACK_CBC:
txform = &enc_xform_skipjack;
break;
case CRYPTO_AES_CBC:
txform = &enc_xform_rijndael128;
break;
Add support for AES-XTS. Obtained from: OpenBSD MFC after: 1 week
2010-09-23 11:52:32 +00:00
case CRYPTO_AES_XTS:
txform = &enc_xform_aes_xts;
break;
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
case CRYPTO_NULL_CBC:
txform = &enc_xform_null;
break;
case CRYPTO_ARC4:
txform = &enc_xform_arc4;
break;
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
case CRYPTO_CAMELLIA_CBC:
txform = &enc_xform_camellia;
break;
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
default:
return (EINVAL);
}
switch (sop->mac) {
case 0:
break;
case CRYPTO_MD5_HMAC:
- 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
thash = &auth_hash_hmac_md5;
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
break;
case CRYPTO_SHA1_HMAC:
- 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
thash = &auth_hash_hmac_sha1;
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
break;
- 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
case CRYPTO_SHA2_256_HMAC:
thash = &auth_hash_hmac_sha2_256;
break;
case CRYPTO_SHA2_384_HMAC:
thash = &auth_hash_hmac_sha2_384;
break;
case CRYPTO_SHA2_512_HMAC:
thash = &auth_hash_hmac_sha2_512;
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
break;
case CRYPTO_RIPEMD160_HMAC:
- 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
thash = &auth_hash_hmac_ripemd_160;
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
break;
#ifdef notdef
case CRYPTO_MD5:
thash = &auth_hash_md5;
break;
case CRYPTO_SHA1:
thash = &auth_hash_sha1;
break;
#endif
case CRYPTO_NULL_HMAC:
thash = &auth_hash_null;
break;
default:
return (EINVAL);
}
bzero(&crie, sizeof(crie));
bzero(&cria, sizeof(cria));
if (txform) {
crie.cri_alg = txform->type;
crie.cri_klen = sop->keylen * 8;
if (sop->keylen > txform->maxkey ||
sop->keylen < txform->minkey) {
error = EINVAL;
goto bail;
}
Fix a number of style issues in the MALLOC / FREE commit. I've tried to be careful not to fix anything that was already broken; the NFSv4 code is particularly bad in this respect.
2008-10-23 20:26:15 +00:00
crie.cri_key = malloc(crie.cri_klen / 8,
M_XDATA, M_WAITOK);
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
if ((error = copyin(sop->key, crie.cri_key,
crie.cri_klen / 8)))
goto bail;
if (thash)
crie.cri_next = &cria;
}
if (thash) {
cria.cri_alg = thash->type;
cria.cri_klen = sop->mackeylen * 8;
if (sop->mackeylen != thash->keysize) {
error = EINVAL;
goto bail;
}
if (cria.cri_klen) {
Fix a number of style issues in the MALLOC / FREE commit. I've tried to be careful not to fix anything that was already broken; the NFSv4 code is particularly bad in this respect.
2008-10-23 20:26:15 +00:00
cria.cri_key = malloc(cria.cri_klen / 8,
M_XDATA, M_WAITOK);
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
if ((error = copyin(sop->mackey, cria.cri_key,
cria.cri_klen / 8)))
goto bail;
}
}
Fix typo in comment.
2010-08-11 16:53:45 +00:00
/* NB: CIOCGSESSION2 has the crid */
Add compat32 shims for opencrypto(4). Reviewed by: bz MFC after: 3 weeks
2010-07-29 20:42:20 +00:00
if (cmd == CIOCGSESSION2
#ifdef COMPAT_FREEBSD32
|| cmd == CIOCGSESSION232
#endif
) {
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
crid = SES2(sop)->crid;
error = checkforsoftware(crid);
If kern.cryptodevallowsoft is TRUE allow also for symmetric software crypto in kernel. Useful for testing. Reviewed by: sam
2006-05-17 18:01:51 +00:00
if (error)
goto bail;
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
} else
crid = CRYPTOCAP_F_HARDWARE;
error = crypto_newsession(&sid, (txform ? &crie : &cria), crid);
if (error)
goto bail;
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
cse = csecreate(fcr, sid, crie.cri_key, crie.cri_klen,
cria.cri_key, cria.cri_klen, sop->cipher, sop->mac, txform,
thash);
if (cse == NULL) {
crypto_freesession(sid);
error = EINVAL;
goto bail;
}
sop->ses = cse->ses;
Add compat32 shims for opencrypto(4). Reviewed by: bz MFC after: 3 weeks
2010-07-29 20:42:20 +00:00
if (cmd == CIOCGSESSION2
#ifdef COMPAT_FREEBSD32
|| cmd == CIOCGSESSION232
#endif
) {
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
/* return hardware/driver id */
SES2(sop)->crid = CRYPTO_SESID2HID(cse->sid);
}
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
bail:
if (error) {
if (crie.cri_key)
Retire the MALLOC and FREE macros. They are an abomination unto style(9). MFC after: 3 months
2008-10-23 15:53:51 +00:00
free(crie.cri_key, M_XDATA);
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
if (cria.cri_key)
Retire the MALLOC and FREE macros. They are an abomination unto style(9). MFC after: 3 months
2008-10-23 15:53:51 +00:00
free(cria.cri_key, M_XDATA);
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
}
Add compat32 shims for opencrypto(4). Reviewed by: bz MFC after: 3 weeks
2010-07-29 20:42:20 +00:00
#ifdef COMPAT_FREEBSD32
else {
if (cmd == CIOCGSESSION32)
session_op_to_32(sop, data);
else if (cmd == CIOCGSESSION232)
session2_op_to_32((struct session2_op *)sop,
data);
}
#endif
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
break;
case CIOCFSESSION:
ses = *(u_int32_t *)data;
cse = csefind(fcr, ses);
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
if (cse == NULL)
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
return (EINVAL);
csedelete(fcr, cse);
error = csefree(cse);
break;
case CIOCCRYPT:
Add compat32 shims for opencrypto(4). Reviewed by: bz MFC after: 3 weeks
2010-07-29 20:42:20 +00:00
#ifdef COMPAT_FREEBSD32
case CIOCCRYPT32:
if (cmd == CIOCCRYPT32) {
cop = &copc;
crypt_op_from_32(data, cop);
} else
#endif
cop = (struct crypt_op *)data;
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
cse = csefind(fcr, cop->ses);
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
if (cse == NULL)
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
return (EINVAL);
error = cryptodev_op(cse, cop, active_cred, td);
Add compat32 shims for opencrypto(4). Reviewed by: bz MFC after: 3 weeks
2010-07-29 20:42:20 +00:00
#ifdef COMPAT_FREEBSD32
if (error == 0 && cmd == CIOCCRYPT32)
crypt_op_to_32(cop, data);
#endif
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
break;
case CIOCKEY:
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
case CIOCKEY2:
Add compat32 shims for opencrypto(4). Reviewed by: bz MFC after: 3 weeks
2010-07-29 20:42:20 +00:00
#ifdef COMPAT_FREEBSD32
case CIOCKEY32:
case CIOCKEY232:
#endif
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
if (!crypto_userasymcrypto)
return (EPERM); /* XXX compat? */
Add compat32 shims for opencrypto(4). Reviewed by: bz MFC after: 3 weeks
2010-07-29 20:42:20 +00:00
#ifdef COMPAT_FREEBSD32
if (cmd == CIOCKEY32 || cmd == CIOCKEY232) {
kop = &kopc;
crypt_kop_from_32(data, kop);
} else
#endif
kop = (struct crypt_kop *)data;
if (cmd == CIOCKEY
#ifdef COMPAT_FREEBSD32
|| cmd == CIOCKEY32
#endif
) {
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
/* NB: crypto core enforces s/w driver use */
kop->crk_crid =
CRYPTOCAP_F_HARDWARE | CRYPTOCAP_F_SOFTWARE;
}
Add compat32 shims for opencrypto(4). Reviewed by: bz MFC after: 3 weeks
2010-07-29 20:42:20 +00:00
mtx_lock(&Giant);
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
error = cryptodev_key(kop);
mtx_unlock(&Giant);
Add compat32 shims for opencrypto(4). Reviewed by: bz MFC after: 3 weeks
2010-07-29 20:42:20 +00:00
#ifdef COMPAT_FREEBSD32
if (cmd == CIOCKEY32 || cmd == CIOCKEY232)
crypt_kop_to_32(kop, data);
#endif
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
break;
case CIOCASYMFEAT:
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
if (!crypto_userasymcrypto) {
/*
* NB: if user asym crypto operations are
* not permitted return "no algorithms"
* so well-behaved applications will just
* fallback to doing them in software.
*/
*(int *)data = 0;
} else
error = crypto_getfeat((int *)data);
break;
case CIOCFINDDEV:
error = cryptodev_find((struct crypt_find_op *)data);
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
break;
default:
error = EINVAL;
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
break;
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
}
return (error);
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
#undef SES2
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
}
static int cryptodev_cb(void *);
static int
cryptodev_op(
struct csession *cse,
struct crypt_op *cop,
struct ucred *active_cred,
struct thread *td)
{
struct cryptop *crp = NULL;
struct cryptodesc *crde = NULL, *crda = NULL;
eliminate an unnecessary 8Kbyte bzero that was being done for each submitted operation Submitted by: Thor Lancelot Simon Reviewed by: jhb Approved by: re (jhb)
2003-11-19 22:42:34 +00:00
int error;
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
if (cop->len > 256*1024-4)
return (E2BIG);
Fix bogus check. It was possible to panic the kernel by giving 0 length. 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
2005-08-18 11:58:03 +00:00
if (cse->txform) {
if (cop->len == 0 || (cop->len % cse->txform->blocksize) != 0)
return (EINVAL);
}
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
eliminate an unnecessary 8Kbyte bzero that was being done for each submitted operation Submitted by: Thor Lancelot Simon Reviewed by: jhb Approved by: re (jhb)
2003-11-19 22:42:34 +00:00
cse->uio.uio_iov = &cse->iovec;
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
cse->uio.uio_iovcnt = 1;
eliminate an unnecessary 8Kbyte bzero that was being done for each submitted operation Submitted by: Thor Lancelot Simon Reviewed by: jhb Approved by: re (jhb)
2003-11-19 22:42:34 +00:00
cse->uio.uio_offset = 0;
cse->uio.uio_resid = cop->len;
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
cse->uio.uio_segflg = UIO_SYSSPACE;
cse->uio.uio_rw = UIO_WRITE;
cse->uio.uio_td = td;
cse->uio.uio_iov[0].iov_len = cop->len;
Fix cryptodev UIO creation. Cryptodev uses UIO structure do get data from userspace and pass it to cryptographic engines. Initially UIO size is equal to size of data passed to engine, but if UIO is prepared for hash calculation an additional small space is created to hold result of operation. While creating space for the result, UIO I/O vector size is correctly extended, but uio_resid field in UIO structure is not modified. As bus_dma code uses uio_resid field to determine size of UIO DMA mapping, resulting mapping hasn't correct size. This leads to a crash if all the following conditions are met: 1. Hardware cryptographic accelerator writes result of hash operation using DMA. 2. Size of input data is less or equal than (n * PAGE_SIZE), 3. Size of input data plus size of hash result is grather than (n * PAGE_SIZE, where n is the same as in point 2. This patch fixes this problem by adding size of the extenstion to uio_resid field in UIO structure. Submitted by: Piotr Ziecik kosmo ! semihalf dot com Reviewed by: philip Obtained from: Semihalf
2009-05-23 13:23:46 +00:00
if (cse->thash) {
Fix usage of HMAC algorithms via /dev/crypto.
2006-05-22 16:24:11 +00:00
cse->uio.uio_iov[0].iov_len += cse->thash->hashsize;
Fix cryptodev UIO creation. Cryptodev uses UIO structure do get data from userspace and pass it to cryptographic engines. Initially UIO size is equal to size of data passed to engine, but if UIO is prepared for hash calculation an additional small space is created to hold result of operation. While creating space for the result, UIO I/O vector size is correctly extended, but uio_resid field in UIO structure is not modified. As bus_dma code uses uio_resid field to determine size of UIO DMA mapping, resulting mapping hasn't correct size. This leads to a crash if all the following conditions are met: 1. Hardware cryptographic accelerator writes result of hash operation using DMA. 2. Size of input data is less or equal than (n * PAGE_SIZE), 3. Size of input data plus size of hash result is grather than (n * PAGE_SIZE, where n is the same as in point 2. This patch fixes this problem by adding size of the extenstion to uio_resid field in UIO structure. Submitted by: Piotr Ziecik kosmo ! semihalf dot com Reviewed by: philip Obtained from: Semihalf
2009-05-23 13:23:46 +00:00
cse->uio.uio_resid += cse->thash->hashsize;
}
Fix usage of HMAC algorithms via /dev/crypto.
2006-05-22 16:24:11 +00:00
cse->uio.uio_iov[0].iov_base = malloc(cse->uio.uio_iov[0].iov_len,
M_XDATA, M_WAITOK);
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
crp = crypto_getreq((cse->txform != NULL) + (cse->thash != NULL));
if (crp == NULL) {
error = ENOMEM;
goto bail;
}
if (cse->thash) {
crda = crp->crp_desc;
if (cse->txform)
crde = crda->crd_next;
} else {
if (cse->txform)
crde = crp->crp_desc;
else {
error = EINVAL;
goto bail;
}
}
if ((error = copyin(cop->src, cse->uio.uio_iov[0].iov_base, cop->len)))
goto bail;
if (crda) {
crda->crd_skip = 0;
crda->crd_len = cop->len;
Fix usage of HMAC algorithms via /dev/crypto.
2006-05-22 16:24:11 +00:00
crda->crd_inject = cop->len;
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
crda->crd_alg = cse->mac;
crda->crd_key = cse->mackey;
crda->crd_klen = cse->mackeylen * 8;
}
if (crde) {
if (cop->op == COP_ENCRYPT)
crde->crd_flags |= CRD_F_ENCRYPT;
else
crde->crd_flags &= ~CRD_F_ENCRYPT;
crde->crd_len = cop->len;
crde->crd_inject = 0;
crde->crd_alg = cse->cipher;
crde->crd_key = cse->key;
crde->crd_klen = cse->keylen * 8;
}
crp->crp_ilen = cop->len;
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
crp->crp_flags = CRYPTO_F_IOV | CRYPTO_F_CBIMM
| (cop->flags & COP_F_BATCH);
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
crp->crp_buf = (caddr_t)&cse->uio;
crp->crp_callback = (int (*) (struct cryptop *)) cryptodev_cb;
crp->crp_sid = cse->sid;
crp->crp_opaque = (void *)cse;
if (cop->iv) {
if (crde == NULL) {
error = EINVAL;
goto bail;
}
if (cse->cipher == CRYPTO_ARC4) { /* XXX use flag? */
error = EINVAL;
goto bail;
}
if ((error = copyin(cop->iv, cse->tmp_iv, cse->txform->blocksize)))
goto bail;
bcopy(cse->tmp_iv, crde->crd_iv, cse->txform->blocksize);
crde->crd_flags |= CRD_F_IV_EXPLICIT | CRD_F_IV_PRESENT;
crde->crd_skip = 0;
} else if (cse->cipher == CRYPTO_ARC4) { /* XXX use flag? */
crde->crd_skip = 0;
} else if (crde) {
crde->crd_flags |= CRD_F_IV_PRESENT;
crde->crd_skip = cse->txform->blocksize;
crde->crd_len -= cse->txform->blocksize;
}
Fix usage of HMAC algorithms via /dev/crypto.
2006-05-22 16:24:11 +00:00
if (cop->mac && crda == NULL) {
error = EINVAL;
goto bail;
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
}
If crypto operation is finished with EAGAIN, don't repeat operation from the return context, but from the original context. Before repeating operation clear DONE flag and error. Reviewed by: sam Obtained from: Wheel Sp. z o.o. (http://www.wheel.pl)
2009-09-04 09:48:18 +00:00
again:
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
/*
* Let the dispatch run unlocked, then, interlock against the
* callback before checking if the operation completed and going
* to sleep. This insures drivers don't inherit our lock which
* results in a lock order reversal between crypto_dispatch forced
* entry and the crypto_done callback into us.
*/
error = crypto_dispatch(crp);
mtx_lock(&cse->lock);
if (error == 0 && (crp->crp_flags & CRYPTO_F_DONE) == 0)
error = msleep(crp, &cse->lock, PWAIT, "crydev", 0);
mtx_unlock(&cse->lock);
if (error != 0)
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
goto bail;
If crypto operation is finished with EAGAIN, don't repeat operation from the return context, but from the original context. Before repeating operation clear DONE flag and error. Reviewed by: sam Obtained from: Wheel Sp. z o.o. (http://www.wheel.pl)
2009-09-04 09:48:18 +00:00
if (crp->crp_etype == EAGAIN) {
crp->crp_etype = 0;
crp->crp_flags &= ~CRYPTO_F_DONE;
goto again;
}
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
if (crp->crp_etype != 0) {
error = crp->crp_etype;
goto bail;
}
if (cse->error) {
error = cse->error;
goto bail;
}
if (cop->dst &&
(error = copyout(cse->uio.uio_iov[0].iov_base, cop->dst, cop->len)))
goto bail;
if (cop->mac &&
Fix usage of HMAC algorithms via /dev/crypto.
2006-05-22 16:24:11 +00:00
(error = copyout((caddr_t)cse->uio.uio_iov[0].iov_base + cop->len,
cop->mac, cse->thash->hashsize)))
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
goto bail;
bail:
if (crp)
crypto_freereq(crp);
if (cse->uio.uio_iov[0].iov_base)
free(cse->uio.uio_iov[0].iov_base, M_XDATA);
return (error);
}
static int
cryptodev_cb(void *op)
{
struct cryptop *crp = (struct cryptop *) op;
struct csession *cse = (struct csession *)crp->crp_opaque;
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
mtx_lock(&cse->lock);
If crypto operation is finished with EAGAIN, don't repeat operation from the return context, but from the original context. Before repeating operation clear DONE flag and error. Reviewed by: sam Obtained from: Wheel Sp. z o.o. (http://www.wheel.pl)
2009-09-04 09:48:18 +00:00
cse->error = crp->crp_etype;
wakeup_one(crp);
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
mtx_unlock(&cse->lock);
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
return (0);
}
static int
cryptodevkey_cb(void *op)
{
struct cryptkop *krp = (struct cryptkop *) op;
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
wakeup_one(krp);
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
return (0);
}
static int
cryptodev_key(struct crypt_kop *kop)
{
struct cryptkop *krp = NULL;
int error = EINVAL;
int in, out, size, i;
if (kop->crk_iparams + kop->crk_oparams > CRK_MAXPARAM) {
return (EFBIG);
}
in = kop->crk_iparams;
out = kop->crk_oparams;
switch (kop->crk_op) {
case CRK_MOD_EXP:
if (in == 3 && out == 1)
break;
return (EINVAL);
case CRK_MOD_EXP_CRT:
if (in == 6 && out == 1)
break;
return (EINVAL);
case CRK_DSA_SIGN:
if (in == 5 && out == 2)
break;
return (EINVAL);
case CRK_DSA_VERIFY:
if (in == 7 && out == 0)
break;
return (EINVAL);
case CRK_DH_COMPUTE_KEY:
if (in == 3 && out == 1)
break;
return (EINVAL);
default:
return (EINVAL);
}
Deny attempt to malloc unbounded amount of the memory. Convert malloc()/bzero() to malloc(M_ZERO). Obtained from: OpenBSD MFC after: 3 days Approved by: re (kensmith)
2007-10-08 20:08:34 +00:00
krp = (struct cryptkop *)malloc(sizeof *krp, M_XDATA, M_WAITOK|M_ZERO);
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
if (!krp)
return (ENOMEM);
krp->krp_op = kop->crk_op;
krp->krp_status = kop->crk_status;
krp->krp_iparams = kop->crk_iparams;
krp->krp_oparams = kop->crk_oparams;
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
krp->krp_crid = kop->crk_crid;
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
krp->krp_status = 0;
krp->krp_callback = (int (*) (struct cryptkop *)) cryptodevkey_cb;
Deny attempt to malloc unbounded amount of the memory. Convert malloc()/bzero() to malloc(M_ZERO). Obtained from: OpenBSD MFC after: 3 days Approved by: re (kensmith)
2007-10-08 20:08:34 +00:00
for (i = 0; i < CRK_MAXPARAM; i++) {
if (kop->crk_param[i].crp_nbits > 65536)
/* Limit is the same as in OpenBSD */
goto fail;
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
krp->krp_param[i].crp_nbits = kop->crk_param[i].crp_nbits;
Deny attempt to malloc unbounded amount of the memory. Convert malloc()/bzero() to malloc(M_ZERO). Obtained from: OpenBSD MFC after: 3 days Approved by: re (kensmith)
2007-10-08 20:08:34 +00:00
}
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
for (i = 0; i < krp->krp_iparams + krp->krp_oparams; i++) {
size = (krp->krp_param[i].crp_nbits + 7) / 8;
if (size == 0)
continue;
Retire the MALLOC and FREE macros. They are an abomination unto style(9). MFC after: 3 months
2008-10-23 15:53:51 +00:00
krp->krp_param[i].crp_p = malloc(size, M_XDATA, M_WAITOK);
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
if (i >= krp->krp_iparams)
continue;
error = copyin(kop->crk_param[i].crp_p, krp->krp_param[i].crp_p, size);
if (error)
goto fail;
}
error = crypto_kdispatch(krp);
if (error)
goto fail;
error = tsleep(krp, PSOCK, "crydev", 0);
if (error) {
/* XXX can this happen? if so, how do we recover? */
goto fail;
}
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
kop->crk_crid = krp->krp_crid; /* device that did the work */
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
if (krp->krp_status != 0) {
error = krp->krp_status;
goto fail;
}
for (i = krp->krp_iparams; i < krp->krp_iparams + krp->krp_oparams; i++) {
size = (krp->krp_param[i].crp_nbits + 7) / 8;
if (size == 0)
continue;
error = copyout(krp->krp_param[i].crp_p, kop->crk_param[i].crp_p, size);
if (error)
goto fail;
}
fail:
if (krp) {
kop->crk_status = krp->krp_status;
for (i = 0; i < CRK_MAXPARAM; i++) {
if (krp->krp_param[i].crp_p)
Retire the MALLOC and FREE macros. They are an abomination unto style(9). MFC after: 3 months
2008-10-23 15:53:51 +00:00
free(krp->krp_param[i].crp_p, M_XDATA);
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
}
free(krp, M_XDATA);
}
return (error);
}
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
static int
cryptodev_find(struct crypt_find_op *find)
{
device_t dev;
if (find->crid != -1) {
dev = crypto_find_device_byhid(find->crid);
if (dev == NULL)
return (ENOENT);
strlcpy(find->name, device_get_nameunit(dev),
sizeof(find->name));
} else {
find->crid = crypto_find_driver(find->name);
if (find->crid == -1)
return (ENOENT);
}
return (0);
}
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
/* ARGSUSED */
static int
cryptof_poll(
struct file *fp,
int events,
struct ucred *active_cred,
struct thread *td)
{
return (0);
}
/* ARGSUSED */
static int
cryptof_kqfilter(struct file *fp, struct knote *kn)
{
return (0);
}
/* ARGSUSED */
static int
cryptof_stat(
struct file *fp,
struct stat *sb,
struct ucred *active_cred,
struct thread *td)
{
return (EOPNOTSUPP);
}
/* ARGSUSED */
static int
cryptof_close(struct file *fp, struct thread *td)
{
Bow to the whining masses and change a union back into void *. Retain removal of unnecessary casts and throw in some minor cleanups to see if anyone complains, just for the hell of it.
2003-01-13 00:33:17 +00:00
struct fcrypt *fcr = fp->f_data;
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
struct csession *cse;
while ((cse = TAILQ_FIRST(&fcr->csessions))) {
TAILQ_REMOVE(&fcr->csessions, cse, next);
(void)csefree(cse);
}
Retire the MALLOC and FREE macros. They are an abomination unto style(9). MFC after: 3 months
2008-10-23 15:53:51 +00:00
free(fcr, M_XDATA);
Bow to the whining masses and change a union back into void *. Retain removal of unnecessary casts and throw in some minor cleanups to see if anyone complains, just for the hell of it.
2003-01-13 00:33:17 +00:00
fp->f_data = NULL;
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
return 0;
}
static struct csession *
csefind(struct fcrypt *fcr, u_int ses)
{
struct csession *cse;
TAILQ_FOREACH(cse, &fcr->csessions, next)
if (cse->ses == ses)
return (cse);
return (NULL);
}
static int
csedelete(struct fcrypt *fcr, struct csession *cse_del)
{
struct csession *cse;
TAILQ_FOREACH(cse, &fcr->csessions, next) {
if (cse == cse_del) {
TAILQ_REMOVE(&fcr->csessions, cse, next);
return (1);
}
}
return (0);
}
static struct csession *
cseadd(struct fcrypt *fcr, struct csession *cse)
{
TAILQ_INSERT_TAIL(&fcr->csessions, cse, next);
cse->ses = fcr->sesn++;
return (cse);
}
struct csession *
csecreate(struct fcrypt *fcr, u_int64_t sid, caddr_t key, u_int64_t keylen,
caddr_t mackey, u_int64_t mackeylen, u_int32_t cipher, u_int32_t mac,
struct enc_xform *txform, struct auth_hash *thash)
{
struct csession *cse;
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
#ifdef INVARIANTS
/* NB: required when mtx_init is built with INVARIANTS */
Fix a number of style issues in the MALLOC / FREE commit. I've tried to be careful not to fix anything that was already broken; the NFSv4 code is particularly bad in this respect.
2008-10-23 20:26:15 +00:00
cse = malloc(sizeof(struct csession), M_XDATA, M_NOWAIT | M_ZERO);
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
#else
Fix a number of style issues in the MALLOC / FREE commit. I've tried to be careful not to fix anything that was already broken; the NFSv4 code is particularly bad in this respect.
2008-10-23 20:26:15 +00:00
cse = malloc(sizeof(struct csession), M_XDATA, M_NOWAIT);
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
#endif
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
if (cse == NULL)
return NULL;
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
mtx_init(&cse->lock, "cryptodev", "crypto session lock", MTX_DEF);
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
cse->key = key;
cse->keylen = keylen/8;
cse->mackey = mackey;
cse->mackeylen = mackeylen/8;
cse->sid = sid;
cse->cipher = cipher;
cse->mac = mac;
cse->txform = txform;
cse->thash = thash;
cseadd(fcr, cse);
return (cse);
}
static int
csefree(struct csession *cse)
{
int error;
error = crypto_freesession(cse->sid);
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
mtx_destroy(&cse->lock);
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
if (cse->key)
Retire the MALLOC and FREE macros. They are an abomination unto style(9). MFC after: 3 months
2008-10-23 15:53:51 +00:00
free(cse->key, M_XDATA);
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
if (cse->mackey)
Retire the MALLOC and FREE macros. They are an abomination unto style(9). MFC after: 3 months
2008-10-23 15:53:51 +00:00
free(cse->mackey, M_XDATA);
free(cse, M_XDATA);
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
return (error);
}
static int
Do the dreaded s/dev_t/struct cdev */ Bump __FreeBSD_version accordingly.
2004-06-16 09:47:26 +00:00
cryptoopen(struct cdev *dev, int oflags, int devtype, struct thread *td)
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
{
return (0);
}
static int
Do the dreaded s/dev_t/struct cdev */ Bump __FreeBSD_version accordingly.
2004-06-16 09:47:26 +00:00
cryptoread(struct cdev *dev, struct uio *uio, int ioflag)
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
{
return (EIO);
}
static int
Do the dreaded s/dev_t/struct cdev */ Bump __FreeBSD_version accordingly.
2004-06-16 09:47:26 +00:00
cryptowrite(struct cdev *dev, struct uio *uio, int ioflag)
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
{
return (EIO);
}
static int
Do the dreaded s/dev_t/struct cdev */ Bump __FreeBSD_version accordingly.
2004-06-16 09:47:26 +00:00
cryptoioctl(struct cdev *dev, u_long cmd, caddr_t data, int flag, struct thread *td)
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
{
struct file *f;
struct fcrypt *fcr;
int fd, error;
switch (cmd) {
case CRIOGET:
Fix a number of style issues in the MALLOC / FREE commit. I've tried to be careful not to fix anything that was already broken; the NFSv4 code is particularly bad in this respect.
2008-10-23 20:26:15 +00:00
fcr = malloc(sizeof(struct fcrypt), M_XDATA, M_WAITOK);
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
TAILQ_INIT(&fcr->csessions);
fcr->sesn = 0;
After the r219999 is merged to stable/8, rename fallocf(9) to falloc(9) and remove the falloc() version that lacks flag argument. This is done to reduce the KPI bloat. Requested by: jhb X-MFC-note: do not
2011-04-01 13:28:34 +00:00
error = falloc(td, &f, &fd, 0);
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
if (error) {
Retire the MALLOC and FREE macros. They are an abomination unto style(9). MFC after: 3 months
2008-10-23 15:53:51 +00:00
free(fcr, M_XDATA);
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
return (error);
}
falloc allocates a file structure and adds it to the file descriptor table, acquiring the necessary locks as it works. It usually returns two references to the new descriptor: one in the descriptor table and one via a pointer argument. As falloc releases the FILEDESC lock before returning, there is a potential for a process to close the reference in the file descriptor table before falloc's caller gets to use the file. I don't think this can happen in practice at the moment, because Giant indirectly protects closes. To stop the file being completly closed in this situation, this change makes falloc set the refcount to two when both references are returned. This makes life easier for several of falloc's callers, because the first thing they previously did was grab an extra reference on the file. Reviewed by: iedowse Idea run past: jhb
2003-10-19 20:41:07 +00:00
/* falloc automatically provides an extra reference to 'f'. */
Remove explicit locking of struct file. - Introduce a finit() which is used to initailize the fields of struct file in such a way that the ops vector is only valid after the data, type, and flags are valid. - Protect f_flag and f_count with atomic operations. - Remove the global list of all files and associated accounting. - Rewrite the unp garbage collection such that it no longer requires the global list of all files and instead uses a list of all unp sockets. - Mark sockets in the accept queue so we don't incorrectly gc them. Tested by: kris, pho
2007-12-30 01:42:15 +00:00
finit(f, FREAD | FWRITE, DTYPE_CRYPTO, fcr, &cryptofops);
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
*(u_int32_t *)data = fd;
fdrop(f, td);
break;
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
case CRIOFINDDEV:
error = cryptodev_find((struct crypt_find_op *)data);
break;
case CRIOASYMFEAT:
error = crypto_getfeat((int *)data);
break;
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
default:
error = EINVAL;
break;
}
return (error);
}
static struct cdevsw crypto_cdevsw = {
Device megapatch 4/6: 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.
2004-02-21 21:10:55 +00:00
.d_version = D_VERSION,
.d_flags = D_NEEDGIANT,
Gigacommit to improve device-driver source compatibility between branches: Initialize struct cdevsw using C99 sparse initializtion and remove all initializations to default values. This patch is automatically generated and has been tested by compiling LINT with all the fields in struct cdevsw in reverse order on alpha, sparc64 and i386. Approved by: re(scottl)
2003-03-03 12:15:54 +00:00
.d_open = cryptoopen,
.d_read = cryptoread,
.d_write = cryptowrite,
.d_ioctl = cryptoioctl,
.d_name = "crypto",
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
};
Do the dreaded s/dev_t/struct cdev */ Bump __FreeBSD_version accordingly.
2004-06-16 09:47:26 +00:00
static struct cdev *crypto_dev;
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
/*
* Initialization code, both for static and dynamic loading.
*/
static int
cryptodev_modevent(module_t mod, int type, void *unused)
{
switch (type) {
case MOD_LOAD:
if (bootverbose)
printf("crypto: <crypto device>\n");
correct minor # in make_dev call Submitted by: Doug Ambrisko" <ambrisko@verniernetworks.com>
2002-11-08 23:07:41 +00:00
crypto_dev = make_dev(&crypto_cdevsw, 0,
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
UID_ROOT, GID_WHEEL, 0666,
"crypto");
return 0;
case MOD_UNLOAD:
/*XXX disallow if active sessions */
destroy_dev(crypto_dev);
return 0;
}
return EINVAL;
}
static moduledata_t cryptodev_mod = {
"cryptodev",
cryptodev_modevent,
Revert previous commit... Pointyhat to: kevlo (myself)
2012-10-10 08:36:38 +00:00
0
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
};
MODULE_VERSION(cryptodev, 1);
DECLARE_MODULE(cryptodev, cryptodev_mod, SI_SUB_PSEUDO, SI_ORDER_ANY);
Module-ize the 'core' crypto stuff. This may still need to be compiled into the kernel by default (if required), but other modules can now depend() on this. Fix inter-module dependancy. Earlier version OK'ed by: sam
2002-10-16 14:31:34 +00:00
MODULE_DEPEND(cryptodev, crypto, 1, 1, 1);
This patch fixes a problem, which exists if you have IPSEC in your kernel 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)
2006-02-27 16:56:22 +00:00
MODULE_DEPEND(cryptodev, zlib, 1, 1, 1);
Reference in New Issue Copy Permalink