login
Search
Hello, following is a patchset providing an user-space interface to the kernel crypto API. It is based on the older, BSD-compatible, implementation, but the user-space interface is different. Major changes since the previous post: * "struct nlattr"-based extensible attributes used for extensibility of most operations, both for input and output attributes * algorithms (ciphers, key wrapping, key derivation) are identified using strings in the userspace API * Full compat_ioctl implementation * Version number added to the data format used when wrapping keys for storage * Patch set split into smaller parts, reordered to keep the tree buildable. (If you want to review primarily the user-space API, see patches 1,14,15,17,18.) The libtom* patches will probably still be too large for the mailing list; the whole patch set is also available at http://people.redhat.com/mitr/cryptodev-ncr/v2/ . Original patch set description follows. These are the major differences compared to the BSD-like interface: * The API supports key storage and management inside the kernel. An application can thus ask the kernel to generate a key; the key is then referenced via an integer identifier, and the application can be prevented from accessing the raw key data. Such a key can, if so configured, still be wrapped for key transport to the recipient of the message, and unwrapped by the recipient. The kernel key storage does not span system reboots, but applications can also wrap the keys for persistent storage, receiving an encrypted blob that does not reveal the raw key data, but can be later loaded back into the kernel. * More algorithms and mechanisms are supported by the API, including public key algorithms (RSA/DSA encryption and signing, D-H key derivation, key wrapping). Motivations for the extensions: governments are asking for more security features in the operating systems they procure, which make user-space implementations impractical. A few ...
This patch introduces the new user-space API, <ncr.h>. Quick overview: * open("/dev/crypto") to get a FD, which acts as a namespace for key and session identifiers. * ioctl(NCRIO_KEY_INIT) to allocate a key object; then generate the key material inside the kernel, load a plaintext key, unwrap a key, or derive a key. Similarly the key material can be copied out of the kernel or wrapped. * ioctl(NCRIO_SESSION_INIT) to allocate a crypto session (to encrypt, decrypt, hash, sign, or verify signature), then ioctl(NCRIO_SESSION_UPDATE) to act on chunks of data. Deallocate the session, and optionally retrieve session results (e.g. hash or signature), using ioctl(NCRIO_SESSION_FINAL). There is also NCRIO_SESSION_ONCE for an one-shot crypto operation using a single user->kernel context switch. Full documentation of the interface is in Documentation/crypto/userspace.txt . --- Documentation/crypto/userspace.txt | 510 ++++++++++++++++++++++++++++++++++++ include/linux/Kbuild | 1 + include/linux/ncr.h | 273 +++++++++++++++++++ 3 files changed, 784 insertions(+), 0 deletions(-) create mode 100644 Documentation/crypto/userspace.txt create mode 100644 include/linux/ncr.h diff --git a/Documentation/crypto/userspace.txt b/Documentation/crypto/userspace.txt new file mode 100644 index 0000000..5839fda --- /dev/null +++ b/Documentation/crypto/userspace.txt @@ -0,0 +1,510 @@ +CRYPTO(4) Linux Programmer’s Manual CRYPTO(4) + +NAME + /dev/crypto - kernel cryptographic module interface + +SYNOPSIS + #include <ncr.h> + int fd = open("/dev/crypto", O_RDWR); + int res = ioctl(fd, NCRIO..., &data); + +DESCRIPTION + The /dev/crypto device file provides an ioctl(2) interface to the ker- + nel-space crypto implementation. + + Each open(2) of the /dev/crypto file establishes a separate namespace + within which crypto operations work. ...
Why not using fixed-size fit-all members?
struct ncr_session_input_data {
__u64 data; /* user pointer, cast to/from u64 */
__u32 data_size; /* or __u64? */
};
struct ncr_session_output_buffer {
__u64 buffer;
__u64 result_size_ptr; /* can't this be a direct output member? */
__u32 buffer_size; /* or __u64? */
};
And then get rid of all the COMAPT code paths.
--
Stefan Richter
-=====-==-=- =--- =-=--
http://arcgraph.de/sr/
--
A reason is that using (void*) is cleaner as an API. It avoids the pointer to int casting and the warnings that such a cast will have. regards, Nikos --
Please add (another) 'c' entry to Documentation/ioctl/ioctl-number.txt. --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** --
Ugh... We already have one very nice key/keyring API in the kernel (see Documentation/keys.txt) that's being used for crypto keys for NFSv4, AFS, etc. Can't you just add a bunch of cryptoapi key types to that API instead? David Howells added to CC, since I believe he wrote most of that code initially. Cheers, Kyle Moffett --
It is not that simple. My understanding of the keyring API is that it allows exporting of the keys to user-space and this crypto API explicitly prevents that, so enhancing the API that way will remove the benefits of using it. It would be ideal to combine somehow those solutions but this is more elaborate work than adding a bunch of new key types. If anyone is interested in attempting that I'd be glad to help. regards, Nikos --
That's simple. Don't provide a read() key type operation, then. David --
Thanks for the updated patch-set. It does indeed fulfil some of the requirements raised earlier. However, as far as I can see this still does not address the extensibility. For example, say we want add an interface to allow the xoring of two arbitrary data streams using DMA offload, this interface would make that quite awkward. In fact the whole interface is really tailored to the traditional encryption/hash operations that BSD provided so I think this is not a good foundation for our user-space API. I will be looking at this myself so please stay tuned and be ready to yell if you see that your requirements are not met. Cheers, -- Email: Herbert Xu <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --
Although I think the current API could handle something like this, I also think it is undesirable to do so. The API was designed with cryptographic operations in mind, and its extensibility might better be judged on how it can incorporate future cryptographic protocols (sigma-proofs and other zero-knowledge protocols and other protocols that I might not know of). An XOR operation, doesn't really fit into a cryptographic API. It could however be included in the current design with some utility ioctls() that address such helper operations. Even better, I think a XOR operation deserves a system call, since it is quite useful in a variety of applications, not only cryptographic It supports much more than the openbsd API, but indeed it is designed with cryptographic operations in mind and this limitation can allow a semi-formal verification of its properties. I'll try to post a link to the design document as soon. regards, Nikos --
Hello, The document discussing the model, threats and design goals of this framework can be found at: https://www.cosic.esat.kuleuven.be/publications/article-1490.pdf Comments and suggestions are welcome. regards, Nikos PS. The existing (proposed) implementation covers about 90% of the design goals, the rest are work in progress. --
--- crypto/Kconfig | 5 +++++ crypto/Makefile | 2 ++ crypto/userspace/Makefile | 1 + 3 files changed, 8 insertions(+), 0 deletions(-) create mode 100644 crypto/userspace/Makefile diff --git a/crypto/Kconfig b/crypto/Kconfig index 81c185a..022768a 100644 --- a/crypto/Kconfig +++ b/crypto/Kconfig @@ -31,6 +31,11 @@ config CRYPTO_FIPS this is. Note that CRYPTO_ANSI_CPRNG is requred if this option is selected +config CRYPTO_USERSPACE + tristate "User-space crypto API" + help + This option provides an user-space API for cryptographic operations. + config CRYPTO_ALGAPI tristate select CRYPTO_ALGAPI2 diff --git a/crypto/Makefile b/crypto/Makefile index 9e8f619..d284dff 100644 --- a/crypto/Makefile +++ b/crypto/Makefile @@ -90,3 +90,5 @@ obj-$(CONFIG_CRYPTO_GHASH) += ghash-generic.o # obj-$(CONFIG_XOR_BLOCKS) += xor.o obj-$(CONFIG_ASYNC_CORE) += async_tx/ + +obj-$(CONFIG_CRYPTO_USERSPACE) += userspace/ diff --git a/crypto/userspace/Makefile b/crypto/userspace/Makefile new file mode 100644 index 0000000..b607b90 --- /dev/null +++ b/crypto/userspace/Makefile @@ -0,0 +1 @@ +ccflags-y += -I$(src)/libtommath -I$(src)/libtomcrypt/headers -I$(src) -DLTC_SOURCE -- 1.7.2.1 --
That's it, .c files will finally follow in the next patch.
---
crypto/userspace/cryptodev_int.h | 82 +++++++++++++
crypto/userspace/ncr-dh.h | 25 ++++
crypto/userspace/ncr-int.h | 245 ++++++++++++++++++++++++++++++++++++++
crypto/userspace/ncr-pk.h | 55 +++++++++
4 files changed, 407 insertions(+), 0 deletions(-)
create mode 100644 crypto/userspace/cryptodev_int.h
create mode 100644 crypto/userspace/ncr-dh.h
create mode 100644 crypto/userspace/ncr-int.h
create mode 100644 crypto/userspace/ncr-pk.h
diff --git a/crypto/userspace/cryptodev_int.h b/crypto/userspace/cryptodev_int.h
new file mode 100644
index 0000000..6754427
--- /dev/null
+++ b/crypto/userspace/cryptodev_int.h
@@ -0,0 +1,82 @@
+/* cipher stuff */
+#ifndef CRYPTODEV_INT_H
+# define CRYPTODEV_INT_H
+
+#include <linux/init.h>
+#include <linux/sched.h>
+#include <linux/fs.h>
+#include <linux/file.h>
+#include <linux/fdtable.h>
+#include <linux/miscdevice.h>
+#include <linux/module.h>
+#include <linux/moduleparam.h>
+#include <linux/ncr.h>
+#include <linux/scatterlist.h>
+
+#define PFX "cryptodev: "
+#define dprintk(level,severity,format,a...) \
+ do { \
+ if (level <= cryptodev_verbosity) \
+ printk(severity PFX "%s[%u]: " format, \
+ current->comm, current->pid, \
+ ##a); \
+ } while (0)
+
+extern int cryptodev_verbosity;
+
+/* For zero copy */
+int __get_userbuf(uint8_t __user *addr, uint32_t len, int write,
+ int pgcount, struct page **pg, struct scatterlist *sg);
+void release_user_pages(struct page **pg, int pagecount);
+
+/* last page - first page + 1 */
+#define PAGECOUNT(buf, buflen) \
+ ((((unsigned long)(buf + buflen - 1) & PAGE_MASK) >> PAGE_SHIFT) - \
+ (((unsigned long) buf & PAGE_MASK) >> PAGE_SHIFT) + 1)
+
+#define DEFAULT_PREALLOC_PAGES 32
+
+struct cipher_data
+{
+ int init; /* 0 uninitialized */
+ int blocksize;
+ int ivsize;
+ struct {
+ struct crypto_ablkcipher* ...Main entry points: NCR_GET_INPUT_ARGS: Read a fixed struct and any attached attributes from userspace NCR_GET_INPUT_ARGS_NO_OUTPUT: Same as above, and inform the users the kernel will attach no additional attributes. NCR_OUT_INIT/ncr_out_free: Allocate and free a context that allows operation handlers to return attributes to userspace. ncr_out_finish: Write the attributes from the context to userspace. Split like this so that only NCR_OUT_INIT (in future "ncr.c") deals with the raw ioctl() argument, but the specific operation can use this call to detect errors and perhaps clean up. ncr_out_*: Add attributes to the context. --- crypto/userspace/Makefile | 5 + crypto/userspace/utils.c | 297 +++++++++++++++++++++++++++++++++++++++++++++ crypto/userspace/utils.h | 98 +++++++++++++++ 3 files changed, 400 insertions(+), 0 deletions(-) create mode 100644 crypto/userspace/utils.c create mode 100644 crypto/userspace/utils.h diff --git a/crypto/userspace/Makefile b/crypto/userspace/Makefile index b607b90..f7f3ea2 100644 --- a/crypto/userspace/Makefile +++ b/crypto/userspace/Makefile @@ -1 +1,6 @@ ccflags-y += -I$(src)/libtommath -I$(src)/libtomcrypt/headers -I$(src) -DLTC_SOURCE + +cryptodev-objs := utils.o + + +obj-$(CONFIG_CRYPTO_USERSPACE) += cryptodev.o diff --git a/crypto/userspace/utils.c b/crypto/userspace/utils.c new file mode 100644 index 0000000..514833c --- /dev/null +++ b/crypto/userspace/utils.c @@ -0,0 +1,297 @@ +/* + * New driver for /dev/crypto device (aka CryptoDev) + * + * Copyright (c) 2010 Red Hat Inc. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version 2 + * of the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * ...
struct compat_xyz cannot be bigger than struct xyz, can it? -- Stefan Richter -=====-==-=- =--- =-=-- http://arcgraph.de/sr/ --
Same as the previous patch - the header file dependencies do not allow otherwise. (Reviewing this in detail is probably premature, we are considering replacing the implementation by something based on libgcrypt, which is more actively maintained and has been probably more thorouhgly examined for vulnerabilities.) --- crypto/userspace/libtomcrypt/headers/tomcrypt.h | 82 ++++ .../libtomcrypt/headers/tomcrypt_argchk.h | 36 ++ .../userspace/libtomcrypt/headers/tomcrypt_cfg.h | 135 +++++++ .../libtomcrypt/headers/tomcrypt_custom.h | 408 +++++++++++++++++++ .../userspace/libtomcrypt/headers/tomcrypt_hash.h | 14 + .../libtomcrypt/headers/tomcrypt_macros.h | 424 ++++++++++++++++++++ .../userspace/libtomcrypt/headers/tomcrypt_math.h | 13 + .../userspace/libtomcrypt/headers/tomcrypt_misc.h | 23 + crypto/userspace/libtomcrypt/headers/tomcrypt_pk.h | 359 +++++++++++++++++ .../userspace/libtomcrypt/headers/tomcrypt_pkcs.h | 67 +++ 10 files changed, 1561 insertions(+), 0 deletions(-) create mode 100644 crypto/userspace/libtomcrypt/headers/tomcrypt.h create mode 100644 crypto/userspace/libtomcrypt/headers/tomcrypt_argchk.h create mode 100644 crypto/userspace/libtomcrypt/headers/tomcrypt_cfg.h create mode 100644 crypto/userspace/libtomcrypt/headers/tomcrypt_custom.h create mode 100644 crypto/userspace/libtomcrypt/headers/tomcrypt_hash.h create mode 100644 crypto/userspace/libtomcrypt/headers/tomcrypt_macros.h create mode 100644 crypto/userspace/libtomcrypt/headers/tomcrypt_math.h create mode 100644 crypto/userspace/libtomcrypt/headers/tomcrypt_misc.h create mode 100644 crypto/userspace/libtomcrypt/headers/tomcrypt_pk.h create mode 100644 crypto/userspace/libtomcrypt/headers/tomcrypt_pkcs.h diff --git a/crypto/userspace/libtomcrypt/headers/tomcrypt.h b/crypto/userspace/libtomcrypt/headers/tomcrypt.h new file mode 100644 index 0000000..51fe804 --- /dev/null +++ b/crypto/userspace/libtomcrypt/headers/tomcrypt.h @@ -0,0 ...
This encapsulates allocation/deallocation of all necessary objects, dealing with the asynchronous nature of ablkcipher/ahash. Long term, I'm not quite sure this layer makes sense; For now, it provides a truly simple API for internal callers in libtomcrypt, at least. --- crypto/userspace/Makefile | 2 +- crypto/userspace/cryptodev_cipher.c | 339 +++++++++++++++++++++++++++++++++++ crypto/userspace/cryptodev_main.c | 13 ++ 3 files changed, 353 insertions(+), 1 deletions(-) create mode 100644 crypto/userspace/cryptodev_cipher.c create mode 100644 crypto/userspace/cryptodev_main.c diff --git a/crypto/userspace/Makefile b/crypto/userspace/Makefile index f7f3ea2..a37969b 100644 --- a/crypto/userspace/Makefile +++ b/crypto/userspace/Makefile @@ -1,6 +1,6 @@ ccflags-y += -I$(src)/libtommath -I$(src)/libtomcrypt/headers -I$(src) -DLTC_SOURCE -cryptodev-objs := utils.o +cryptodev-objs := cryptodev_main.o cryptodev_cipher.o utils.o obj-$(CONFIG_CRYPTO_USERSPACE) += cryptodev.o diff --git a/crypto/userspace/cryptodev_cipher.c b/crypto/userspace/cryptodev_cipher.c new file mode 100644 index 0000000..4e74fcc --- /dev/null +++ b/crypto/userspace/cryptodev_cipher.c @@ -0,0 +1,339 @@ +/* + * Driver for /dev/crypto device (aka CryptoDev) + * + * Copyright (c) 2010 Nikos Mavrogiannopoulos <nmav@gnutls.org> + * Portions Copyright (c) 2010 Michael Weiser + * Portions Copyright (c) 2010 Phil Sutter + * + * This file is part of linux cryptodev. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version 2 + * of the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more ...
---
crypto/userspace/cryptodev_main.c | 130 +++++++++++++++++++++++++++++++++++++
1 files changed, 130 insertions(+), 0 deletions(-)
diff --git a/crypto/userspace/cryptodev_main.c b/crypto/userspace/cryptodev_main.c
index a6712db..6ba9bd6 100644
--- a/crypto/userspace/cryptodev_main.c
+++ b/crypto/userspace/cryptodev_main.c
@@ -98,3 +98,133 @@ int __get_userbuf(uint8_t __user *addr, uint32_t len, int write,
return 0;
}
+/* ====== /dev/crypto ====== */
+
+static int
+cryptodev_open(struct inode *inode, struct file *filp)
+{
+ struct ncr_lists *ncr;
+ int ret;
+
+ ncr = ncr_init_lists();
+ if (ncr == NULL) {
+ return -ENOMEM;
+ }
+
+ ret = audit_log_crypto_op(AUDIT_CRYPTO_OP_CONTEXT_NEW, ncr->id, -1,
+ NULL, NULL, -1, NULL, 0, -1, NULL, 0);
+ if (ret < 0) {
+ ncr_deinit_lists(ncr);
+ return ret;
+ }
+
+ filp->private_data = ncr;
+ return 0;
+}
+
+static int
+cryptodev_release(struct inode *inode, struct file *filp)
+{
+ struct ncr_lists *ncr = filp->private_data;
+
+ if (ncr) {
+ audit_log_crypto_op(AUDIT_CRYPTO_OP_CONTEXT_DEL, ncr->id, -1,
+ NULL, NULL, -1, NULL, 0, -1, NULL, 0);
+ ncr_deinit_lists(ncr);
+ filp->private_data = NULL;
+ }
+
+ return 0;
+}
+
+static int
+cryptodev_ioctl(struct inode *inode, struct file *filp,
+ unsigned int cmd, unsigned long arg)
+{
+ void *ncr = filp->private_data;
+
+ if (unlikely(!ncr))
+ BUG();
+
+ return ncr_ioctl(ncr, cmd, arg);
+}
+
+/* compatibility code for 32bit userlands */
+#ifdef CONFIG_COMPAT
+
+static long
+cryptodev_compat_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
+{
+ void *ncr = file->private_data;
+
+ if (unlikely(!ncr))
+ BUG();
+
+ return ncr_compat_ioctl(ncr, cmd, arg);
+}
+
+#endif /* CONFIG_COMPAT */
+
+static const struct file_operations cryptodev_fops = {
+ .owner = THIS_MODULE,
+ .open = cryptodev_open,
+ .release = cryptodev_release,
+ .ioctl = cryptodev_ioctl,
+#ifdef CONFIG_COMPAT
+ .compat_ioctl = ...Add ioctl and compat_ioctl handling. This is the only file that
directly accesses structured data from userspace (other files may access
unformated data such as cipher input or multiple-precision integers).
Also add the last operation, ncr_master_key_set.
---
crypto/userspace/ncr.c | 405 ++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 405 insertions(+), 0 deletions(-)
diff --git a/crypto/userspace/ncr.c b/crypto/userspace/ncr.c
index 9fb56ad..ee812ab 100644
--- a/crypto/userspace/ncr.c
+++ b/crypto/userspace/ncr.c
@@ -44,6 +44,411 @@
*/
struct key_item_st master_key;
+static struct mutex lists_ida_mutex;
+static DEFINE_IDA(lists_ida);
+
+struct ncr_lists *ncr_init_lists(void)
+{
+ struct ncr_lists *lst;
+
+ lst = kmalloc(sizeof(*lst), GFP_KERNEL);
+ if(!lst) {
+ err();
+ return NULL;
+ }
+
+ memset(lst, 0, sizeof(*lst));
+
+ mutex_init(&lists_ida_mutex);
+ mutex_lock(&lists_ida_mutex);
+ /* ida_pre_get() should preallocate enough, and, due to lists_ida_mutex,
+ nobody else can use the preallocated data. Therefore the loop
+ recommended in idr_get_new() documentation is not necessary. */
+ if (ida_pre_get(&lists_ida, GFP_KERNEL) == 0 ||
+ ida_get_new(&lists_ida, &lst->id) != 0) {
+ mutex_unlock(&lists_ida_mutex);
+ kfree(lst);
+ return NULL;
+ }
+ mutex_unlock(&lists_ida_mutex);
+
+ mutex_init(&lst->key_idr_mutex);
+ idr_init(&lst->key_idr);
+
+ mutex_init(&lst->session_idr_mutex);
+ idr_init(&lst->session_idr);
+
+ return lst;
+}
+
+void ncr_deinit_lists(struct ncr_lists *lst)
+{
+ if(lst) {
+ ncr_key_list_deinit(lst);
+ ncr_sessions_list_deinit(lst);
+
+ mutex_lock(&lists_ida_mutex);
+ ida_remove(&lists_ida, lst->id);
+ mutex_unlock(&lists_ida_mutex);
+
+ kfree(lst);
+ }
+}
+
+void ncr_master_key_reset(void)
+{
+ memset(&master_key, 0, sizeof(master_key));
+}
+
+static int ncr_master_key_set(const struct ncr_master_key_set *st,
+ struct nlattr *tb[])
+{
+struct audit_buffer ...This includes:
- ncr_session_init
- ncr_session_update
- ncr_session_final
- ncr_session_once
The ncr_session_*_from_nla() functions are separate from the main
session code because they belong into ncr.c along with other code that
deals directly with user-space data structures and handles
CONFIG_COMPAT.
---
crypto/userspace/ncr-sessions.c | 953 +++++++++++++++++++++++++++++++++++++++
crypto/userspace/ncr.c | 86 ++++
2 files changed, 1039 insertions(+), 0 deletions(-)
diff --git a/crypto/userspace/ncr-sessions.c b/crypto/userspace/ncr-sessions.c
index e6fd995..b2adb8b 100644
--- a/crypto/userspace/ncr-sessions.c
+++ b/crypto/userspace/ncr-sessions.c
@@ -32,6 +32,104 @@
#include <linux/scatterlist.h>
#include <net/netlink.h>
+static int _ncr_session_update_key(struct ncr_lists *lists, ncr_session_t ses,
+ struct nlattr *tb[]);
+static void _ncr_session_remove(struct ncr_lists *lst, ncr_session_t desc);
+
+static int session_list_deinit_fn(int id, void *item, void *unused)
+{
+ (void)unused;
+ _ncr_sessions_item_put(item);
+ return 0;
+}
+
+void ncr_sessions_list_deinit(struct ncr_lists *lst)
+{
+ /* The mutex is not necessary, but doesn't hurt and makes it easier to
+ verify locking correctness. */
+ mutex_lock(&lst->session_idr_mutex);
+ idr_for_each(&lst->session_idr, session_list_deinit_fn, NULL);
+ idr_remove_all(&lst->session_idr);
+ idr_destroy(&lst->session_idr);
+ mutex_unlock(&lst->session_idr_mutex);
+}
+
+/* returns the data item corresponding to desc */
+struct session_item_st* ncr_sessions_item_get(struct ncr_lists *lst, ncr_session_t desc)
+{
+struct session_item_st* item;
+
+ mutex_lock(&lst->session_idr_mutex);
+ item = idr_find(&lst->session_idr, desc);
+ if (item != NULL) {
+ atomic_inc(&item->refcnt);
+ mutex_unlock(&lst->session_idr_mutex);
+ return item;
+ }
+ mutex_unlock(&lst->session_idr_mutex);
+
+ err();
+ return NULL;
+}
+
+void _ncr_sessions_item_put( struct session_item_st* ...Right now only key objects, not crypto sessions, are limited. --- crypto/userspace/Makefile | 2 +- crypto/userspace/ncr-limits.c | 247 +++++++++++++++++++++++++++++++++++++++++ 2 files changed, 248 insertions(+), 1 deletions(-) create mode 100644 crypto/userspace/ncr-limits.c diff --git a/crypto/userspace/Makefile b/crypto/userspace/Makefile index a37969b..3dfbc39 100644 --- a/crypto/userspace/Makefile +++ b/crypto/userspace/Makefile @@ -1,6 +1,6 @@ ccflags-y += -I$(src)/libtommath -I$(src)/libtomcrypt/headers -I$(src) -DLTC_SOURCE -cryptodev-objs := cryptodev_main.o cryptodev_cipher.o utils.o +cryptodev-objs := cryptodev_main.o cryptodev_cipher.o ncr-limits.o utils.o obj-$(CONFIG_CRYPTO_USERSPACE) += cryptodev.o diff --git a/crypto/userspace/ncr-limits.c b/crypto/userspace/ncr-limits.c new file mode 100644 index 0000000..345cca7 --- /dev/null +++ b/crypto/userspace/ncr-limits.c @@ -0,0 +1,247 @@ +/* + * New driver for /dev/crypto device (aka CryptoDev) + + * Copyright (c) 2010 Katholieke Universiteit Leuven + * + * Author: Nikos Mavrogiannopoulos <nmav@gnutls.org> + * + * This file is part of linux cryptodev. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version 2 + * of the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. + */ + +#include <linux/hash.h> +#include <linux/mutex.h> +#include <linux/types.h> +#include ...
--- crypto/userspace/cryptodev_main.c | 87 +++++++++++++++++++++++++++++++++++++ 1 files changed, 87 insertions(+), 0 deletions(-) diff --git a/crypto/userspace/cryptodev_main.c b/crypto/userspace/cryptodev_main.c index c6419f4..a6712db 100644 --- a/crypto/userspace/cryptodev_main.c +++ b/crypto/userspace/cryptodev_main.c @@ -1,3 +1,46 @@ +/* + * Driver for /dev/crypto device (aka CryptoDev) + * + * Copyright (c) 2004 Michal Ludvig <mludvig@logix.net.nz>, SuSE Labs + * Copyright (c) 2009,2010 Nikos Mavrogiannopoulos <nmav@gnutls.org> + * + * This file is part of linux cryptodev. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version 2 + * of the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. + */ + +/* + * Device /dev/crypto provides an interface for + * accessing kernel CryptoAPI algorithms (ciphers, + * hashes) from userspace programs. + * + * /dev/crypto interface was originally introduced in + * OpenBSD and this module attempts to keep the API. + * + */ + +#include <linux/audit.h> +#include <linux/crypto.h> +#include <linux/mm.h> +#include <linux/highmem.h> +#include <linux/ioctl.h> +#include <linux/random.h> +#include <linux/syscalls.h> +#include <linux/pagemap.h> +#include <linux/uaccess.h> +#include <linux/scatterlist.h> #include "cryptodev_int.h" #include "ncr-int.h" #include <linux/version.h> @@ -11,3 +54,47 @@ ...
This includes: - ncr_key_init - ncr_key_deinit - ncr_key_export (as plaintext) - ncr_key_import - ncr_key_generate - ncr_key_generate_pair - ncr_key_derive - ncr_key_get_info and supporting infrastructure. --- crypto/userspace/Makefile | 2 +- crypto/userspace/ncr-key.c | 689 ++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 690 insertions(+), 1 deletions(-) create mode 100644 crypto/userspace/ncr-key.c diff --git a/crypto/userspace/Makefile b/crypto/userspace/Makefile index fa4168d..454ed9d 100644 --- a/crypto/userspace/Makefile +++ b/crypto/userspace/Makefile @@ -63,7 +63,7 @@ TOMCRYPT_OBJECTS = libtomcrypt/misc/zeromem.o libtomcrypt/misc/crypt/crypt_argch libtomcrypt/misc/pk_get_oid.o libtomcrypt/pk/asn1/der/x509/der_encode_subject_public_key_info.o \ libtomcrypt/pk/asn1/der/x509/der_decode_subject_public_key_info.o -cryptodev-objs := cryptodev_main.o cryptodev_cipher.o ncr-limits.o \ +cryptodev-objs := cryptodev_main.o cryptodev_cipher.o ncr-key.o ncr-limits.o \ ncr-pk.o ncr-sessions.o ncr-dh.o utils.o $(TOMMATH_OBJECTS) \ $(TOMCRYPT_OBJECTS) diff --git a/crypto/userspace/ncr-key.c b/crypto/userspace/ncr-key.c new file mode 100644 index 0000000..b90a4fc --- /dev/null +++ b/crypto/userspace/ncr-key.c @@ -0,0 +1,689 @@ +/* + * New driver for /dev/crypto device (aka CryptoDev) + * + * Copyright (c) 2010 Katholieke Universiteit Leuven + * + * Author: Nikos Mavrogiannopoulos <nmav@gnutls.org> + * + * This file is part of linux cryptodev. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version 2 + * of the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License ...
Posted separately for review on linux-audit
---
include/linux/audit.h | 38 ++++++++++++++
kernel/auditfilter.c | 2 +
kernel/auditsc.c | 136 +++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 176 insertions(+), 0 deletions(-)
diff --git a/include/linux/audit.h b/include/linux/audit.h
index 3c7a358..8faa4e0 100644
--- a/include/linux/audit.h
+++ b/include/linux/audit.h
@@ -122,6 +122,9 @@
#define AUDIT_MAC_UNLBL_STCADD 1416 /* NetLabel: add a static label */
#define AUDIT_MAC_UNLBL_STCDEL 1417 /* NetLabel: del a static label */
+#define AUDIT_CRYPTO_STORAGE_KEY 1600 /* Key storage key configured */
+#define AUDIT_CRYPTO_USERSPACE_OP 1601 /* User-space crypto operation */
+
#define AUDIT_FIRST_KERN_ANOM_MSG 1700
#define AUDIT_LAST_KERN_ANOM_MSG 1799
#define AUDIT_ANOM_PROMISCUOUS 1700 /* Device changed promiscuous mode */
@@ -207,6 +210,7 @@
#define AUDIT_OBJ_TYPE 21
#define AUDIT_OBJ_LEV_LOW 22
#define AUDIT_OBJ_LEV_HIGH 23
+#define AUDIT_CRYPTO_OP 24
/* These are ONLY useful when checking
* at syscall exit time (AUDIT_AT_EXIT). */
@@ -314,6 +318,20 @@ enum {
#define AUDIT_PERM_READ 4
#define AUDIT_PERM_ATTR 8
+#define AUDIT_CRYPTO_OP_CONTEXT_NEW 1
+#define AUDIT_CRYPTO_OP_CONTEXT_DEL 2
+#define AUDIT_CRYPTO_OP_SESSION_INIT 3
+#define AUDIT_CRYPTO_OP_SESSION_OP 4
+#define AUDIT_CRYPTO_OP_SESSION_FINAL 5
+#define AUDIT_CRYPTO_OP_KEY_IMPORT 6
+#define AUDIT_CRYPTO_OP_KEY_EXPORT 7
+#define AUDIT_CRYPTO_OP_KEY_WRAP 8
+#define AUDIT_CRYPTO_OP_KEY_UNWRAP 9
+#define AUDIT_CRYPTO_OP_KEY_GEN 10
+#define AUDIT_CRYPTO_OP_KEY_DERIVE 11
+#define AUDIT_CRYPTO_OP_KEY_ZEROIZE 12
+#define AUDIT_CRYPTO_OP_KEY_GET_INFO 13
+
struct audit_status {
__u32 mask; /* Bit mask for valid entries */
__u32 enabled; /* 1 = enabled, 0 = disabled */
@@ -479,6 +497,10 @@ extern int __audit_log_bprm_fcaps(struct linux_binprm *bprm,
const struct cred *new,
const struct cred *old);
extern void ...This includes: - ncr_key_wrap - ncr_key_unwrap - ncr_key_storage_wrap - ncr_key_storage_unwrap --- crypto/userspace/Makefile | 5 +- crypto/userspace/ncr-key-storage.c | 136 +++++++ crypto/userspace/ncr-key-wrap.c | 763 ++++++++++++++++++++++++++++++++++++ crypto/userspace/ncr.c | 29 ++ 4 files changed, 931 insertions(+), 2 deletions(-) create mode 100644 crypto/userspace/ncr-key-storage.c create mode 100644 crypto/userspace/ncr-key-wrap.c create mode 100644 crypto/userspace/ncr.c diff --git a/crypto/userspace/Makefile b/crypto/userspace/Makefile index 454ed9d..689ee0d 100644 --- a/crypto/userspace/Makefile +++ b/crypto/userspace/Makefile @@ -63,8 +63,9 @@ TOMCRYPT_OBJECTS = libtomcrypt/misc/zeromem.o libtomcrypt/misc/crypt/crypt_argch libtomcrypt/misc/pk_get_oid.o libtomcrypt/pk/asn1/der/x509/der_encode_subject_public_key_info.o \ libtomcrypt/pk/asn1/der/x509/der_decode_subject_public_key_info.o -cryptodev-objs := cryptodev_main.o cryptodev_cipher.o ncr-key.o ncr-limits.o \ - ncr-pk.o ncr-sessions.o ncr-dh.o utils.o $(TOMMATH_OBJECTS) \ +cryptodev-objs := cryptodev_main.o cryptodev_cipher.o ncr.o \ + ncr-key.o ncr-limits.o ncr-pk.o ncr-sessions.o ncr-dh.o \ + ncr-key-wrap.o ncr-key-storage.o utils.o $(TOMMATH_OBJECTS) \ $(TOMCRYPT_OBJECTS) diff --git a/crypto/userspace/ncr-key-storage.c b/crypto/userspace/ncr-key-storage.c new file mode 100644 index 0000000..4d0cb87 --- /dev/null +++ b/crypto/userspace/ncr-key-storage.c @@ -0,0 +1,136 @@ +/* + * New driver for /dev/crypto device (aka CryptoDev) + + * Copyright (c) 2010 Katholieke Universiteit Leuven + * + * Author: Nikos Mavrogiannopoulos <nmav@gnutls.org> + * + * This file is part of linux cryptodev. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version 2 + * of the License, or (at your option) any later version. + ...
No use postponing it any more I'm afraid. (Reviewing this in detail is probably premature, we are considering replacing the implementation by something based on libgcrypt, which is more actively maintained and has been probably more thorouhgly examined for vulnerabilities.) --- crypto/userspace/Makefile | 38 ++- .../libtomcrypt/hashes/crypt_hash_is_valid.c | 30 ++ crypto/userspace/libtomcrypt/hashes/hash_get_oid.c | 78 ++++ crypto/userspace/libtomcrypt/hashes/hash_memory.c | 66 ++++ .../libtomcrypt/hashes/hash_memory_multi.c | 84 +++++ .../userspace/libtomcrypt/headers/tomcrypt_prng.h | 80 ++++ crypto/userspace/libtomcrypt/math/rand_prime.c | 80 ++++ .../libtomcrypt/misc/crypt/crypt_argchk.c | 28 ++ crypto/userspace/libtomcrypt/misc/pk_get_oid.c | 40 ++ crypto/userspace/libtomcrypt/misc/qsort.c | 247 ++++++++++++ crypto/userspace/libtomcrypt/misc/zeromem.c | 34 ++ .../pk/asn1/der/bit/der_decode_bit_string.c | 106 ++++++ .../pk/asn1/der/bit/der_encode_bit_string.c | 92 +++++ .../pk/asn1/der/bit/der_length_bit_string.c | 54 +++ .../pk/asn1/der/boolean/der_decode_boolean.c | 47 +++ .../pk/asn1/der/boolean/der_encode_boolean.c | 51 +++ .../pk/asn1/der/boolean/der_length_boolean.c | 35 ++ .../pk/asn1/der/choice/der_decode_choice.c | 182 +++++++++ .../pk/asn1/der/ia5/der_decode_ia5_string.c | 96 +++++ .../pk/asn1/der/ia5/der_encode_ia5_string.c | 85 +++++ .../pk/asn1/der/ia5/der_length_ia5_string.c | 194 ++++++++++ .../pk/asn1/der/integer/der_decode_integer.c | 110 ++++++ .../pk/asn1/der/integer/der_encode_integer.c | 130 +++++++ .../pk/asn1/der/integer/der_length_integer.c | 82 ++++ .../der_decode_object_identifier.c | 99 +++++ .../der_encode_object_identifier.c | 111 ++++++ .../der_length_object_identifier.c ...
Add basic Diffie-Hellman implementation, because it is not provided by libtomcrypt. Finally, add an algorithm-independent pubkey interface that encapsulates the separate pubkey algorithm implementations. --- crypto/userspace/Makefile | 2 +- crypto/userspace/ncr-dh.c | 282 +++++++++++++++++++ crypto/userspace/ncr-pk.c | 659 +++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 942 insertions(+), 1 deletions(-) create mode 100644 crypto/userspace/ncr-dh.c create mode 100644 crypto/userspace/ncr-pk.c diff --git a/crypto/userspace/Makefile b/crypto/userspace/Makefile index 0891c2b..fa4168d 100644 --- a/crypto/userspace/Makefile +++ b/crypto/userspace/Makefile @@ -64,7 +64,7 @@ TOMCRYPT_OBJECTS = libtomcrypt/misc/zeromem.o libtomcrypt/misc/crypt/crypt_argch libtomcrypt/pk/asn1/der/x509/der_decode_subject_public_key_info.o cryptodev-objs := cryptodev_main.o cryptodev_cipher.o ncr-limits.o \ - ncr-sessions.o utils.o $(TOMMATH_OBJECTS) \ + ncr-pk.o ncr-sessions.o ncr-dh.o utils.o $(TOMMATH_OBJECTS) \ $(TOMCRYPT_OBJECTS) diff --git a/crypto/userspace/ncr-dh.c b/crypto/userspace/ncr-dh.c new file mode 100644 index 0000000..3a00c0b --- /dev/null +++ b/crypto/userspace/ncr-dh.c @@ -0,0 +1,282 @@ +/* + * New driver for /dev/crypto device (aka CryptoDev) + + * Copyright (c) 2010 Katholieke Universiteit Leuven + * + * Author: Nikos Mavrogiannopoulos <nmav@gnutls.org> + * + * This file is part of linux cryptodev. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version 2 + * of the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have ...
No use postponing it any more I'm afraid. (Reviewing this in detail is probably premature, we are considering replacing the implementation by something based on libgcrypt, which is more actively maintained and has been probably more thorouhgly examined for vulnerabilities.) --- crypto/userspace/Makefile | 38 ++- .../libtomcrypt/hashes/crypt_hash_is_valid.c | 30 ++ crypto/userspace/libtomcrypt/hashes/hash_get_oid.c | 78 ++++ crypto/userspace/libtomcrypt/hashes/hash_memory.c | 66 ++++ .../libtomcrypt/hashes/hash_memory_multi.c | 84 +++++ .../userspace/libtomcrypt/headers/tomcrypt_prng.h | 80 ++++ crypto/userspace/libtomcrypt/math/rand_prime.c | 80 ++++ .../libtomcrypt/misc/crypt/crypt_argchk.c | 28 ++ crypto/userspace/libtomcrypt/misc/pk_get_oid.c | 40 ++ crypto/userspace/libtomcrypt/misc/qsort.c | 247 ++++++++++++ crypto/userspace/libtomcrypt/misc/zeromem.c | 34 ++ .../pk/asn1/der/bit/der_decode_bit_string.c | 106 ++++++ .../pk/asn1/der/bit/der_encode_bit_string.c | 92 +++++ .../pk/asn1/der/bit/der_length_bit_string.c | 54 +++ .../pk/asn1/der/boolean/der_decode_boolean.c | 47 +++ .../pk/asn1/der/boolean/der_encode_boolean.c | 51 +++ .../pk/asn1/der/boolean/der_length_boolean.c | 35 ++ .../pk/asn1/der/choice/der_decode_choice.c | 182 +++++++++ .../pk/asn1/der/ia5/der_decode_ia5_string.c | 96 +++++ .../pk/asn1/der/ia5/der_encode_ia5_string.c | 85 +++++ .../pk/asn1/der/ia5/der_length_ia5_string.c | 194 ++++++++++ .../pk/asn1/der/integer/der_decode_integer.c | 110 ++++++ .../pk/asn1/der/integer/der_encode_integer.c | 130 +++++++ .../pk/asn1/der/integer/der_length_integer.c | 82 ++++ .../der_decode_object_identifier.c | 99 +++++ .../der_encode_object_identifier.c | 111 ++++++ .../der_length_object_identifier.c ...
Pointers to this table are used to identify algorithms throughout the code. --- crypto/userspace/Makefile | 2 +- crypto/userspace/ncr-sessions.c | 150 +++++++++++++++++++++++++++++++++++++++ 2 files changed, 151 insertions(+), 1 deletions(-) create mode 100644 crypto/userspace/ncr-sessions.c diff --git a/crypto/userspace/Makefile b/crypto/userspace/Makefile index 81e4122..0891c2b 100644 --- a/crypto/userspace/Makefile +++ b/crypto/userspace/Makefile @@ -64,7 +64,7 @@ TOMCRYPT_OBJECTS = libtomcrypt/misc/zeromem.o libtomcrypt/misc/crypt/crypt_argch libtomcrypt/pk/asn1/der/x509/der_decode_subject_public_key_info.o cryptodev-objs := cryptodev_main.o cryptodev_cipher.o ncr-limits.o \ - utils.o $(TOMMATH_OBJECTS) \ + ncr-sessions.o utils.o $(TOMMATH_OBJECTS) \ $(TOMCRYPT_OBJECTS) diff --git a/crypto/userspace/ncr-sessions.c b/crypto/userspace/ncr-sessions.c new file mode 100644 index 0000000..e6fd995 --- /dev/null +++ b/crypto/userspace/ncr-sessions.c @@ -0,0 +1,150 @@ +/* + * New driver for /dev/crypto device (aka CryptoDev) + + * Copyright (c) 2010 Katholieke Universiteit Leuven + * Portions Copyright (c) 2010 Phil Sutter + * + * Author: Nikos Mavrogiannopoulos <nmav@gnutls.org> + * + * This file is part of linux cryptodev. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version 2 + * of the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA ...
No use postponing it any more I'm afraid. (Reviewing this in detail is probably premature, we are considering replacing the implementation by something based on libgcrypt, which is more actively maintained and has been probably more thorouhgly examined for vulnerabilities.) --- crypto/userspace/Makefile | 31 ++- crypto/userspace/libtommath/LICENSE | 4 + crypto/userspace/libtommath/bn_error.c | 47 +++ crypto/userspace/libtommath/bn_fast_mp_invmod.c | 148 ++++++++ .../libtommath/bn_fast_mp_montgomery_reduce.c | 172 +++++++++ .../userspace/libtommath/bn_fast_s_mp_mul_digs.c | 107 ++++++ .../libtommath/bn_fast_s_mp_mul_high_digs.c | 98 +++++ crypto/userspace/libtommath/bn_fast_s_mp_sqr.c | 114 ++++++ crypto/userspace/libtommath/bn_mp_2expt.c | 48 +++ crypto/userspace/libtommath/bn_mp_abs.c | 43 +++ crypto/userspace/libtommath/bn_mp_add.c | 53 +++ crypto/userspace/libtommath/bn_mp_add_d.c | 112 ++++++ crypto/userspace/libtommath/bn_mp_addmod.c | 41 ++ crypto/userspace/libtommath/bn_mp_and.c | 57 +++ crypto/userspace/libtommath/bn_mp_clamp.c | 44 +++ crypto/userspace/libtommath/bn_mp_clear.c | 45 +++ crypto/userspace/libtommath/bn_mp_clear_multi.c | 34 ++ crypto/userspace/libtommath/bn_mp_cmp.c | 43 +++ crypto/userspace/libtommath/bn_mp_cmp_d.c | 44 +++ crypto/userspace/libtommath/bn_mp_cmp_mag.c | 55 +++ crypto/userspace/libtommath/bn_mp_cnt_lsb.c | 53 +++ crypto/userspace/libtommath/bn_mp_copy.c | 68 ++++ crypto/userspace/libtommath/bn_mp_count_bits.c | 45 +++ crypto/userspace/libtommath/bn_mp_div.c | 292 ++++++++++++++ crypto/userspace/libtommath/bn_mp_div_2.c | 68 ++++ crypto/userspace/libtommath/bn_mp_div_2d.c | 97 +++++ crypto/userspace/libtommath/bn_mp_div_3.c | 79 ...
Not a good patch to start with, but the header file dependencies do not allow otherwise. (Reviewing this in detail is probably premature, we are considering replacing the implementation by something based on libgcrypt, which is more actively maintained and has been probably more thorouhgly examined for vulnerabilities.) --- crypto/userspace/libtommath/tommath.h | 555 ++++++++++++ crypto/userspace/libtommath/tommath_class.h | 999 ++++++++++++++++++++++ crypto/userspace/libtommath/tommath_superclass.h | 76 ++ 3 files changed, 1630 insertions(+), 0 deletions(-) create mode 100644 crypto/userspace/libtommath/tommath.h create mode 100644 crypto/userspace/libtommath/tommath_class.h create mode 100644 crypto/userspace/libtommath/tommath_superclass.h diff --git a/crypto/userspace/libtommath/tommath.h b/crypto/userspace/libtommath/tommath.h new file mode 100644 index 0000000..37fb23c --- /dev/null +++ b/crypto/userspace/libtommath/tommath.h @@ -0,0 +1,555 @@ +/* LibTomMath, multiple-precision integer library -- Tom St Denis + * + * LibTomMath is a library that provides multiple-precision + * integer arithmetic as well as number theoretic functionality. + * + * The library was designed directly after the MPI library by + * Michael Fromberger but has been written from scratch with + * additional optimizations in place. + * + * The library is free for all purposes without any express + * guarantee it works. + * + * Tom St Denis, tomstdenis@gmail.com, http://math.libtomcrypt.com + */ +#ifndef BN_H_ +#define BN_H_ + +#include <linux/kernel.h> +#include <linux/mm.h> +#include <linux/random.h> +#include <linux/ctype.h> + +#define CHAR_BIT sizeof(uint8_t)*8 + +inline static int rand(void) +{ + int res; + + get_random_bytes(&res, sizeof(int)); + + return res; +} + +#include <tommath_class.h> + +#ifndef MIN + #define MIN(x,y) ((x)<(y)?(x):(y)) +#endif + +#ifndef MAX + #define MAX(x,y) ((x)>(y)?(x):(y)) +#endif + +#ifdef ...
What's the goal of exporting the kernel crypto routines to userspace, as opposed to just simply doing the crypto in userspace? Is it to access hardware crypto accelerators? (1) I wasn't aware the kernel crypto routines actually used crypto accelerators, and (2) more often than not, by the time you take into account the time to move the crypto context as well as the data into kernel space and back out, and after you take into account price/performance, most hardware crypto accellerators have marginal performance benefits; in fact, more often than not, it's a lose. If the goal is access to hardware-escrowed keys, don't we have the TPM interface for that already? So I'm bit at a list what's the whole point of this patch series. Could you explain that in the documentation, please? Especially for crypto, explaining when something should be used, what the threat model is, etc., is often very important. Thanks, regards, - Ted --
This was the goal of the original cryptodev OpenBSD API and the subsequent linux port in http://home.gna.org/cryptodev-linux/. In typical PCs it might even be slower to use such an accelerator in kernel space, but in embedded systems where the hardware version of AES might be 100 times faster than the software it might make sense. However the design goal of this API is to separate cryptographic operations from the applications. That is applications in userspace can use keys, but the keys cannot be extracted from them, so for example code injection in the web server will not be able to extract the private key of the web service. (this approach is also required for certification of linux on certain fields as Miloslav described in the first post). The interface is designed in a way that it can be wrapped by a PKCS #11 module and used transparently by other crypto libraries (openssl/nss/gnutls). TPM is quite limited in this respect and cannot A detailed document describing this framework, threats and model is on its way. best regards, Nikos --
OK, but I hope that in that case, we don't go encouraging applications to use the /dev/crypto API directly. I know a number of distributions have been standardizing on NSS as the library that all of their applications will use, such that by simply configuring libnss differently, the crypto can either be done in userspace, or it can be done in hardware, either for crypto acceleration purposes or for when the key is locked inside hardware can only be used with appropriate authentication to encrypt or sign data passed to the hardware device. If you encourage applications to use /dev/crypto directly, then either (a) they will be much slower on PC's, or (b) the applications will need to be rewritten when they are moved between your embedded devices and standard PC's. - Ted --
Yes, this exactly is the plan. All the major crypto libraries - NSS,
OpenSSL, libgcrypt - are going to be patched to use the kernel API in
case they are configured to. By default they will still be using their
internal implementation of the cryptographic algorithms. Of course there
still might be some applications (for example glibc libcrypt password
hashing) that decide to use the kernel interface directly, but these
will be a very small minority I think.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
--
The API here looks overly complex resulting from the use of a combination of ioctl and netlink. If your interface cannot be easily expressed using simple (no indirect pointers or variable-length fields please) ioctl and read/write operations, why not go all the way and turn the interface New drivers should be written to *avoid* compat_ioctl calls, using only Again, wrong direction. If you think you need a version number, the interface is probably not ready for inclusion yet. Make sure it is simple enough that you don't run into the case where you have to make incompatible changes They actually seem to have made it to the list. However, the more signficant problem is the amount of code added to a security module. 20000 lines of code that is essentially a user-level library moved into kernel space can open up so many possible holes that you end up with a less secure As Kyle mentioned, we already have a key management API in the kernel. I think you should make a better effort of interfacing with that and adding features you need to it, like a way to prevent the kernel from I think you will have to back that statement by measurements. There are reasonably fast ways to do IPC and the interface you suggest to put in the We have kgdb, kdb, qemu gdbserver, tracing and more things that would very much make your code debuggable. OTOH, disabling ptrace with a root-only prctl should be an easy thing to I can see this as a good reason to put a proper interface for asymmetric crypto into the kernel. There are PCI cards and other things that are supported using ad-hoc interfaces right now. It would be wonderful if someone could clean that up and create a simple common interface that covers all the hardware variants. But that does not justify putting a software implementation into the kernel. For symmetric crypto and hashing hardware acceleration is typically implemented as CPU instructions anyway and available to user space If you are really worried about library load times, ...
I believe that this is the result of the discussion in the version 1 of There are cases where this cannot be easily done, when say pointers are involved. IMHO forcing pointers to be u64 or u32 is dirtier than using Note that the version number is not to the interface but to data that The same argument could apply to an other algorithm in the kernel such as deflate, lzma, AES etc. There are cases that the benefits outweigh Note that the NCR does not do key management. Integrating with the key management API could be nice, but it is not something critical and is This is an alternative design. There quite some reasons against that, such as the auditing features. For me the main reason was that there was no way to make it as fast (zero-copy) as this design, for the requirements we had (interface with existing crypto libraries through pkcs11). Zero-copy is important since crypto operations might involve You are right. Debugging by the administrator was not an issue. Only users should be prevented from that. It should have been mentioned. regards, Nikos --
Yes, but that only means you should avoid pointers in data structures that are passed to ioctl. Ideally, you would use ioctl to control The algorithms that are in the kernel already are there specifically because You mean using a shared memory segment would not be possible without changing the libpkcs11 interface? Arnd --
Indeed. The pkcs11 backend would have to copy the data to the shared segment, thus high-performance applications requiring zero-copy, would avoid to use this interface. Moreover if more than one applications are using the interface, the shared segment it is going to be a bottleneck. Having multiple shared segments might help, but I don't know how practical is something like that with the posix ipc. regards, Nikos --
Hmm, root daemon seems like a way to go. You already do the switch into the kernel... and "IPC is slow" is not good enough reason to put everything in kernel. Plus, you should be able to get better usage of multicore with daemon. Numbers? -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --
Actually not, and the arguments why multicore would not be really used
better anyway were stated here as well. If an application needs some
cryptography function in most of the cases it has to wait for the
operation to finish before it can proceed further. To use asynchronous
crypto interfaces efficiently would require serious redesign and rewrite
of the existing applications which is nowhere near to be accomplished.
In case of applications where the benefits of asynchronous crypto would
be obvious and easily utilized it is quite easier just to split the
threads for crypto processing and the rest of the application directly
inside the application process.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
--
| Greg KH | Og dreams of kernels |
| Jens Axboe | [PATCH 31/33] Fusion: sg chaining support |
| Arnd Bergmann | Re: finding your own dead "CONFIG_" variables |
| Mark Brown | [PATCH 2/2] Subject: natsemi: Allow users to disable workaround for DspCfg reset |
| Tony Breeds | [LGUEST] Look in object dir for .config |
git: | |
| Brian Downing | Re: Git in a Nutshell guide |
| John Benes | Re: master has some toys |
| Matthias Lederhofer | [PATCH 4/7] introduce GIT_WORK_TREE to specify the work tree |
| Alexander Sulfrian | [RFC/PATCH] RE: git calls SSH_ASKPASS even if DISPLAY is not set |
| Junio C Hamano | Re: Rss produced by git is not valid xml? |
| Linux Kernel Mailing List | iSeries: fix section mismatch in iseries_veth |
| Linux Kernel Mailing L |