From: Mimi Zohar <zohar@linux.vnet.ibm.com>
To: David Howells <dhowells@redhat.com>
Cc: keyrings@linux-nfs.org, linux-crypto@vger.kernel.org,
linux-security-module@vger.kernel.org,
linux-kernel@vger.kernel.org, dmitry.kasatkin@intel.com,
arjan.van.de.ven@intel.com, alan.cox@intel.com
Subject: Re: [PATCH 07/21] KEYS: Create a key type that can be used for general cryptographic operations [ver #3]
Date: Mon, 16 Jan 2012 07:53:13 -0500 [thread overview]
Message-ID: <1326718394.2276.1.camel@falcor> (raw)
In-Reply-To: <20111202184354.21874.57647.stgit@warthog.procyon.org.uk>
On Fri, 2011-12-02 at 18:43 +0000, David Howells wrote:
> Create a key type that can be used for general cryptographic operations, such
> as encryption, decryption, signature generation and signature verification.
>
> The key type is "crypto" and can provide access to a variety of cryptographic
> algorithms.
>
> Signed-off-by: David Howells <dhowells@redhat.com>
Nice! Basically the 'crypto' key type ties crypto/ with security/keys.
Other than the posted pgp key parser used for verifying kernel module
signatures, I assume another use case could be to expose kernel
cryptography to userspace. As there was a submission
https://lkml.org/lkml/2010/8/20/103 to do just this, there must be
userspace apps that would benefit. This architecture would address a
number of concerns raised with the prior submission. (Refer to
http://lwn.net/Articles/401548/.)
You'd probably want to move the 'crypto' key type to its own directory.
Acked-by: Mimi Zohar <zohar@us.ibm.com>
thanks,
Mimi
> ---
>
> Documentation/security/keys-crypto.txt | 181 +++++++++++++++++++++++++
> include/keys/crypto-subtype.h | 56 ++++++++
> include/keys/crypto-type.h | 25 +++
> security/keys/Kconfig | 8 +
> security/keys/Makefile | 3
> security/keys/crypto_keys.h | 28 ++++
> security/keys/crypto_type.c | 230 ++++++++++++++++++++++++++++++++
> 7 files changed, 531 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/security/keys-crypto.txt
> create mode 100644 include/keys/crypto-subtype.h
> create mode 100644 include/keys/crypto-type.h
> create mode 100644 security/keys/crypto_keys.h
> create mode 100644 security/keys/crypto_type.c
>
>
> diff --git a/Documentation/security/keys-crypto.txt b/Documentation/security/keys-crypto.txt
> new file mode 100644
> index 0000000..97dee80
> --- /dev/null
> +++ b/Documentation/security/keys-crypto.txt
> @@ -0,0 +1,181 @@
> + ======================
> + CRYPTOGRAPHIC KEY TYPE
> + ======================
> +
> +Contents:
> +
> + - Overview.
> + - Key identification.
> + - Accessing crypto keys.
> + - Implementing crypto parsers.
> + - Implementing crypto subtypes.
> +
> +
> +========
> +OVERVIEW
> +========
> +
> +The "crypto" key type is designed to be a container for cryptographic keys,
> +without imposing any particular restrictions on the form of the cryptography or
> +the key.
> +
> +The crypto key is given a subtype that defines what sort of data is associated
> +with the key and provides operations to describe and destroy it. However, no
> +requirement is made that the key data actually be loaded into the key.
> +
> +The crypto key also has a number of data parsers registered with it. The data
> +parsers are responsible for extracing information the blobs of data passed to
> +the instantiator function. The first data parser that recognises the blob gets
> +to set the subtype of the key and define the operations that can be done on
> +that key.
> +
> +Completely in-kernel key retention and operation subtypes and parsers can be
> +defined, but it would also be possible to provide access to cryptographic
> +hardware (such as a TPM) that might be used to both retain the relevant key and
> +perform operations using that key. In such a case, the crypto key would then
> +merely be an interface to the TPM driver.
> +
> +
> +==================
> +KEY IDENTIFICATION
> +==================
> +
> +Because the identity of a key is not necessarily known and may not be easily
> +calculated when a crypto key is allocated, it may not be a simple matter to set
> +a key description to something that's useful for determining whether this is
> +the key you're looking for. Furthermore, it may be necessary to perform a
> +partial match upon the key identity.
> +
> +To help with this, when a key is loaded, the parser calculates the key
> +fingerprint and stores a copy in the key structure.
> +
> +The crypto key type's key matching function then performs more checks than just
> +the straightforward comparison of the description with the criterion string:
> +
> + (1) If the criterion string is of the form "id:<hexdigits>" then the match
> + function will examine a key's fingerprint to see if the hex digits given
> + after the "id:" match the tail. For instance:
> +
> + keyctl search @s crypto id:5acc2142
> +
> + will match a key with fingerprint:
> +
> + 1A00 2040 7601 7889 DE11 882C 3823 04AD 5ACC 2142
> +
> + (2) If the criterion string is of the form "<subtype>:<hexdigits>" then the
> + match will match the ID as in (1), but with the added restriction that
> + only keys of the specified subtype (e.g. dsa or rsa) will be matched. For
> + instance:
> +
> + keyctl search @s crypto dsa:5acc2142
> +
> +Looking in /proc/keys, the last 8 hex digits of the key fingerprint are
> +displayed, along with the subtype:
> +
> + 1a39e171 I----- 1 perm 3f010000 0 0 crypto modsign.0: DSA 5acc2142 []
> +
> +
> +=====================
> +ACCESSING CRYPTO KEYS
> +=====================
> +
> +To access crypto keys from within the kernel, the following inclusion is
> +required:
> +
> + #include <keys/crypto-type.h>
> +
> +This gives access to the key type:
> +
> + struct key_type key_type_crypto;
> +
> +
> +===========================
> +IMPLEMENTING CRYPTO PARSERS
> +===========================
> +
> +The crypto key type keeps a list of registered data parsers. An example of
> +such a parser is one that parses OpenPGP packet formatted data [RFC 4880].
> +
> +During key instantiation each parser in the list is tried until one doesn't
> +return -EBADMSG.
> +
> +The parser definition structure looks like the following:
> +
> + struct crypto_key_parser {
> + struct module *owner;
> + const char *name;
> +
> + int (*instantiate)(struct key *key,
> + const void *data, size_t datalen);
> + };
> +
> +The owner and name fields should be set to the owning module and the name of
> +the parser.
> +
> +There are a number of operations defined by the parser. They are all optional,
> +but it is expected that at least one will be defined.
> +
> + (1) instantiate().
> +
> + The arguments are the same as for the instantiate function in the key
> + type. 'key' is the crypto key being instantiated; data and datalen are
> + the instantiation data, presumably containing cryptographic key data, and
> + the length of that data.
> +
> + If the data format is not recognised, -EBADMSG should be returned. If it
> + is recognised, but the key cannot for some reason be set up, some other
> + negative error code should be returned.
> +
> + If the key can be successfully set up, then key->payload should be set to
> + point to the retained data, key->type_data.p[0] should be set to point to
> + the subtype chosen and key->type_data.p[1] should be set to point to a
> + copy of the key's identity string and 0 should be returned.
> +
> + The key's identity string may be partially matched upon. For a public-key
> + algorithm such as RSA and DSA this will likely be a printable hex version
> + of the key's fingerprint.
> +
> +Functions are provided to register and unregister parsers:
> +
> + int register_crypto_key_parser(struct crypto_key_parser *parser);
> + void unregister_crypto_key_parser(struct crypto_key_parser *subtype);
> +
> +Parsers may not have the same name. The names are only used for displaying in
> +debugging messages.
> +
> +
> +============================
> +IMPLEMENTING CRYPTO SUBTYPES
> +============================
> +
> +The parser selects the appropriate subtype directly and sets it on the key; the
> +crypto key then retains a reference on the subtype module (which means the
> +parser can be removed thereafter).
> +
> +The subtype definition structure looks like the following:
> +
> + struct crypto_key_subtype {
> + struct module *owner;
> + const char *name;
> +
> + void (*describe)(const struct key *key, struct seq_file *m);
> + void (*destroy)(void *payload);
> + };
> +
> +The owner and name fields should be set to the owning module and the name of
> +the subtype.
> +
> +There are a number of operations defined by the subtype:
> +
> + (1) describe().
> +
> + Mandatory. This allows the subtype to display something in /proc/keys
> + against the key. For instance the name of the public key algorithm type
> + could be displayed. The key type will display the tail of the key
> + identity string after this.
> +
> + (2) destroy().
> +
> + Mandatory. This should free the memory associated with the key. The
> + crypto key will look after freeing the fingerprint and releasing the
> + reference on the subtype module.
> diff --git a/include/keys/crypto-subtype.h b/include/keys/crypto-subtype.h
> new file mode 100644
> index 0000000..fa87555
> --- /dev/null
> +++ b/include/keys/crypto-subtype.h
> @@ -0,0 +1,56 @@
> +/* Cryptographic key subtype
> + *
> + * Copyright (C) 2011 Red Hat, Inc. All Rights Reserved.
> + * Written by David Howells (dhowells@redhat.com)
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public Licence
> + * as published by the Free Software Foundation; either version
> + * 2 of the Licence, or (at your option) any later version.
> + *
> + * See Documentation/security/keys-crypto.txt
> + */
> +
> +#ifndef _KEYS_CRYPTO_SUBTYPE_H
> +#define _KEYS_CRYPTO_SUBTYPE_H
> +
> +#include <linux/seq_file.h>
> +#include <keys/crypto-type.h>
> +
> +extern struct key_type key_type_crypto;
> +
> +/*
> + * Keys of this type declare a subtype that indicates the handlers and
> + * capabilities.
> + */
> +struct crypto_key_subtype {
> + struct module *owner;
> + const char *name;
> + unsigned short name_len; /* length of name */
> +
> + void (*describe)(const struct key *key, struct seq_file *m);
> +
> + void (*destroy)(void *payload);
> +};
> +
> +/*
> + * Data parser. Called during instantiation and signature verification
> + * initiation.
> + */
> +struct crypto_key_parser {
> + struct list_head link;
> + struct module *owner;
> + const char *name;
> +
> + /* Attempt to instantiate a key from the data blob passed to add_key()
> + * or keyctl_instantiate().
> + *
> + * Return EBADMSG if not recognised.
> + */
> + int (*instantiate)(struct key *key, const void *data, size_t datalen);
> +};
> +
> +extern int register_crypto_key_parser(struct crypto_key_parser *);
> +extern void unregister_crypto_key_parser(struct crypto_key_parser *);
> +
> +#endif /* _KEYS_CRYPTO_SUBTYPE_H */
> diff --git a/include/keys/crypto-type.h b/include/keys/crypto-type.h
> new file mode 100644
> index 0000000..47c00c7
> --- /dev/null
> +++ b/include/keys/crypto-type.h
> @@ -0,0 +1,25 @@
> +/* Cryptographic key type interface
> + *
> + * Copyright (C) 2011 Red Hat, Inc. All Rights Reserved.
> + * Written by David Howells (dhowells@redhat.com)
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public Licence
> + * as published by the Free Software Foundation; either version
> + * 2 of the Licence, or (at your option) any later version.
> + *
> + * See Documentation/security/keys-crypto.txt
> + */
> +
> +#ifndef _KEYS_CRYPTO_TYPE_H
> +#define _KEYS_CRYPTO_TYPE_H
> +
> +#include <linux/key-type.h>
> +
> +extern struct key_type key_type_crypto;
> +
> +/*
> + * The payload is at the discretion of the subtype.
> + */
> +
> +#endif /* _KEYS_CRYPTO_TYPE_H */
> diff --git a/security/keys/Kconfig b/security/keys/Kconfig
> index a90d6d3..290c9d3 100644
> --- a/security/keys/Kconfig
> +++ b/security/keys/Kconfig
> @@ -69,3 +69,11 @@ config KEYS_DEBUG_PROC_KEYS
> the resulting table.
>
> If you are unsure as to whether this is required, answer N.
> +
> +config CRYPTO_KEY_TYPE
> + tristate "Cryptographic key type"
> + depends on KEYS
> + help
> + This option provides support for a type of key that holds the keys
> + required for cryptographic operations such as encryption, decryption,
> + signature generation and signature verification.
> diff --git a/security/keys/Makefile b/security/keys/Makefile
> index 504aaa0..67fceaa 100644
> --- a/security/keys/Makefile
> +++ b/security/keys/Makefile
> @@ -24,3 +24,6 @@ obj-$(CONFIG_SYSCTL) += sysctl.o
> #
> obj-$(CONFIG_TRUSTED_KEYS) += trusted.o
> obj-$(CONFIG_ENCRYPTED_KEYS) += encrypted-keys/
> +obj-$(CONFIG_CRYPTO_KEY_TYPE) += crypto_keys.o
> +
> +crypto_keys-y := crypto_type.o
> diff --git a/security/keys/crypto_keys.h b/security/keys/crypto_keys.h
> new file mode 100644
> index 0000000..a339ce0
> --- /dev/null
> +++ b/security/keys/crypto_keys.h
> @@ -0,0 +1,28 @@
> +/* Internal crypto type stuff
> + *
> + * Copyright (C) 2011 Red Hat, Inc. All Rights Reserved.
> + * Written by David Howells (dhowells@redhat.com)
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public Licence
> + * as published by the Free Software Foundation; either version
> + * 2 of the Licence, or (at your option) any later version.
> + */
> +
> +static inline
> +struct crypto_key_subtype *crypto_key_subtype(const struct key *key)
> +{
> + return key->type_data.p[0];
> +}
> +
> +static inline char *crypto_key_id(const struct key *key)
> +{
> + return key->type_data.p[1];
> +}
> +
> +
> +/*
> + * crypto_type.c
> + */
> +extern struct list_head crypto_key_parsers;
> +extern struct rw_semaphore crypto_key_parsers_sem;
> diff --git a/security/keys/crypto_type.c b/security/keys/crypto_type.c
> new file mode 100644
> index 0000000..a06413a
> --- /dev/null
> +++ b/security/keys/crypto_type.c
> @@ -0,0 +1,230 @@
> +/* Cryptographic key type
> + *
> + * Copyright (C) 2011 Red Hat, Inc. All Rights Reserved.
> + * Written by David Howells (dhowells@redhat.com)
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public Licence
> + * as published by the Free Software Foundation; either version
> + * 2 of the Licence, or (at your option) any later version.
> + *
> + * See Documentation/security/keys-crypto.txt
> + */
> +#include <keys/crypto-subtype.h>
> +#include <linux/seq_file.h>
> +#include <linux/module.h>
> +#include <linux/slab.h>
> +#include "crypto_keys.h"
> +
> +MODULE_LICENSE("GPL");
> +
> +LIST_HEAD(crypto_key_parsers);
> +DECLARE_RWSEM(crypto_key_parsers_sem);
> +
> +/*
> + * Match crypto_keys on (part of) their name
> + * We have some shorthand methods for matching keys. We allow:
> + *
> + * "<desc>" - request a key by description
> + * "id:<id>" - request a key matching the ID
> + * "<subtype>:<id>" - request a key of a subtype
> + */
> +static int crypto_key_match(const struct key *key, const void *description)
> +{
> + const struct crypto_key_subtype *subtype = crypto_key_subtype(key);
> + const char *spec = description;
> + const char *id, *kid;
> + ptrdiff_t speclen;
> + size_t idlen, kidlen;
> +
> + if (!subtype || !spec || !*spec)
> + return 0;
> +
> + /* See if the full key description matches as is */
> + if (key->description && strcmp(key->description, description) == 0)
> + return 1;
> +
> + /* All tests from here on break the criterion description into a
> + * specifier, a colon and then an identifier.
> + */
> + id = strchr(spec, ':');
> + if (!id)
> + return 0;
> +
> + speclen = id - spec;
> + id++;
> +
> + /* Anything after here requires a partial match on the ID string */
> + kid = crypto_key_id(key);
> + if (!kid)
> + return 0;
> +
> + idlen = strlen(id);
> + kidlen = strlen(kid);
> + if (idlen > kidlen)
> + return 0;
> +
> + kid += kidlen - idlen;
> + if (strcasecmp(id, kid) != 0)
> + return 0;
> +
> + if (speclen == 2 &&
> + memcmp(spec, "id", 2) == 0)
> + return 1;
> +
> + if (speclen == subtype->name_len &&
> + memcmp(spec, subtype->name, speclen) == 0)
> + return 1;
> +
> + return 0;
> +}
> +
> +/*
> + * Describe the crypto key
> + */
> +static void crypto_key_describe(const struct key *key, struct seq_file *m)
> +{
> + const struct crypto_key_subtype *subtype = crypto_key_subtype(key);
> + const char *kid = crypto_key_id(key);
> + size_t n;
> +
> + seq_puts(m, key->description);
> +
> + if (subtype) {
> + seq_puts(m, ": ");
> + subtype->describe(key, m);
> +
> + if (kid) {
> + seq_putc(m, ' ');
> + n = strlen(kid);
> + if (n <= 8)
> + seq_puts(m, kid);
> + else
> + seq_puts(m, kid + n - 8);
> + }
> +
> + seq_puts(m, " [");
> + /* put something here to indicate the key's capabilities */
> + seq_putc(m, ']');
> + }
> +}
> +
> +/*
> + * Instantiate a crypto_key defined key
> + */
> +static int crypto_key_instantiate(struct key *key,
> + const void *data, size_t datalen)
> +{
> + struct crypto_key_parser *parser;
> + int ret;
> +
> + pr_devel("==>%s()\n", __func__);
> +
> + if (datalen == 0)
> + return -EINVAL;
> +
> + down_read(&crypto_key_parsers_sem);
> +
> + ret = -EBADMSG;
> + list_for_each_entry(parser, &crypto_key_parsers, link) {
> + pr_debug("Trying parser '%s'\n", parser->name);
> +
> + ret = parser->instantiate(key, data, datalen);
> + if (ret != -EBADMSG) {
> + pr_debug("Parser recognised the format (ret %d)\n",
> + ret);
> + if (ret == 0)
> + module_get(crypto_key_subtype(key));
> + break;
> + }
> + }
> +
> + up_read(&crypto_key_parsers_sem);
> + pr_devel("<==%s() = %d\n", __func__, ret);
> + return ret;
> +}
> +
> +/*
> + * dispose of the data dangling from the corpse of a crypto key
> + */
> +static void crypto_key_destroy(struct key *key)
> +{
> + struct crypto_key_subtype *subtype = crypto_key_subtype(key);
> + if (subtype) {
> + subtype->destroy(key->payload.data);
> + module_put(subtype->owner);
> + key->type_data.p[0] = NULL;
> + }
> + kfree(key->type_data.p[1]);
> + key->type_data.p[1] = NULL;
> +}
> +
> +struct key_type key_type_crypto = {
> + .name = "crypto",
> + .instantiate = crypto_key_instantiate,
> + .match = crypto_key_match,
> + .destroy = crypto_key_destroy,
> + .describe = crypto_key_describe,
> +};
> +EXPORT_SYMBOL_GPL(key_type_crypto);
> +
> +/**
> + * register_crypto_key_parser - Register a crypto key blob parser
> + * @parser: The parser to register
> + */
> +int register_crypto_key_parser(struct crypto_key_parser *parser)
> +{
> + struct crypto_key_parser *cursor;
> + int ret;
> +
> + down_write(&crypto_key_parsers_sem);
> +
> + list_for_each_entry(cursor, &crypto_key_parsers, link) {
> + if (strcmp(cursor->name, parser->name) == 0) {
> + pr_err("Crypto key parser '%s' already registered\n",
> + parser->name);
> + ret = -EEXIST;
> + goto out;
> + }
> + }
> +
> + list_add_tail(&parser->link, &crypto_key_parsers);
> +
> + pr_notice("Crypto key parser '%s' registered\n", parser->name);
> + ret = 0;
> +
> +out:
> + up_write(&crypto_key_parsers_sem);
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(register_crypto_key_parser);
> +
> +/**
> + * unregister_crypto_key_parser - Unregister a crypto key blob parser
> + * @parser: The parser to unregister
> + */
> +void unregister_crypto_key_parser(struct crypto_key_parser *parser)
> +{
> + down_write(&crypto_key_parsers_sem);
> + list_del(&parser->link);
> + up_write(&crypto_key_parsers_sem);
> +
> + pr_notice("Crypto key parser '%s' unregistered\n", parser->name);
> +}
> +EXPORT_SYMBOL_GPL(unregister_crypto_key_parser);
> +
> +/*
> + * Module stuff
> + */
> +static int __init crypto_key_init(void)
> +{
> + return register_key_type(&key_type_crypto);
> +}
> +
> +static void __exit crypto_key_cleanup(void)
> +{
> + unregister_key_type(&key_type_crypto);
> +}
> +
> +module_init(crypto_key_init);
> +module_exit(crypto_key_cleanup);
>
next prev parent reply other threads:[~2012-01-16 12:56 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-02 18:42 [RFC][PATCH 00/21] Crypto keys and module signing [ver #3] David Howells
2011-12-02 18:42 ` [PATCH 01/21] MPILIB: Export some more symbols " David Howells
2011-12-02 18:42 ` [PATCH 02/21] MPILIB: Add a missing ENOMEM check " David Howells
2011-12-02 18:43 ` [PATCH 03/21] KEYS: Permit key_serial() to be called with a const key pointer " David Howells
2011-12-02 18:43 ` [PATCH 04/21] KEYS: Move the key config into security/keys/Kconfig " David Howells
2011-12-02 18:43 ` [PATCH 05/21] KEYS: Announce key type (un)registration " David Howells
2011-12-02 18:43 ` [PATCH 06/21] KEYS: Reorganise keys Makefile " David Howells
2011-12-02 18:43 ` [PATCH 07/21] KEYS: Create a key type that can be used for general cryptographic operations " David Howells
2012-01-16 12:53 ` Mimi Zohar [this message]
2012-01-17 15:32 ` David Howells
2012-01-18 10:56 ` Kasatkin, Dmitry
2011-12-02 18:44 ` [PATCH 08/21] KEYS: Add signature verification facility " David Howells
2012-01-18 11:20 ` Kasatkin, Dmitry
2012-01-18 12:26 ` David Howells
2012-01-18 13:26 ` Kasatkin, Dmitry
2012-01-18 15:13 ` David Howells
2012-01-18 15:20 ` Kasatkin, Dmitry
2012-01-18 19:59 ` David Howells
2012-01-20 1:52 ` Herbert Xu
2011-12-02 18:44 ` [PATCH 09/21] KEYS: Asymmetric public-key algorithm crypto key subtype " David Howells
2011-12-02 18:44 ` [PATCH 10/21] KEYS: DSA signature verification algorithm " David Howells
2011-12-02 18:44 ` [PATCH 11/21] KEYS: RSA " David Howells
2011-12-02 18:44 ` [PATCH 12/21] PGPLIB: PGP definitions (RFC 4880) " David Howells
2011-12-02 18:45 ` [PATCH 13/21] PGPLIB: Basic packet parser " David Howells
2011-12-02 18:45 ` [PATCH 14/21] PGPLIB: Signature " David Howells
2011-12-02 18:45 ` [PATCH 15/21] KEYS: PGP data " David Howells
2011-12-02 18:45 ` [PATCH 16/21] KEYS: PGP-based public key signature verification " David Howells
2012-01-18 11:36 ` Kasatkin, Dmitry
2012-01-18 12:49 ` David Howells
2012-01-18 13:34 ` Kasatkin, Dmitry
2011-12-02 18:46 ` [PATCH 17/21] KEYS: PGP format signature parser " David Howells
2011-12-02 18:46 ` [PATCH 18/21] KEYS: Provide a function to load keys from a PGP keyring blob " David Howells
2011-12-02 18:46 ` [PATCH 19/21] MODSIGN: Add indications of module ELF types " David Howells
2011-12-02 18:46 ` [PATCH 20/21] MODSIGN: Module ELF verifier " David Howells
2011-12-02 18:46 ` [PATCH 21/21] MODSIGN: Apply signature checking to modules on module load " David Howells
2011-12-09 11:18 ` Rusty Russell
2011-12-09 18:43 ` David Howells
2011-12-10 7:01 ` Rusty Russell
2011-12-10 18:37 ` Arjan van de Ven
2011-12-11 4:59 ` Rusty Russell
2011-12-10 14:08 ` David Howells
2011-12-11 4:57 ` Rusty Russell
2011-12-12 1:21 ` David Howells
2011-12-12 9:09 ` Rusty Russell
2011-12-12 16:11 ` David Howells
2011-12-13 2:15 ` Rusty Russell
2011-12-15 0:14 ` David Howells
2011-12-16 0:41 ` Rusty Russell
2012-01-08 22:02 ` [RFC][PATCH 00/21] Crypto keys and module signing " Mimi Zohar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1326718394.2276.1.camel@falcor \
--to=zohar@linux.vnet.ibm.com \
--cc=alan.cox@intel.com \
--cc=arjan.van.de.ven@intel.com \
--cc=dhowells@redhat.com \
--cc=dmitry.kasatkin@intel.com \
--cc=keyrings@linux-nfs.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).