[PATCH v2 0/2] crypto: move ablk_helper out of arch/x86
v2: - whitespace fix - split into two patches so that the first one applies cleanly to the ARM/ARM64 trees as well - rebased onto cryptodev/master Ard Biesheuvel (2): crypto: create generic version of ablk_helper crypto: move x86 to the generic version of ablk_helper arch/x86/crypto/Makefile | 1 - arch/x86/crypto/ablk_helper.c | 149 arch/x86/crypto/aesni-intel_glue.c | 2 +- arch/x86/crypto/camellia_aesni_avx2_glue.c | 2 +- arch/x86/crypto/camellia_aesni_avx_glue.c | 2 +- arch/x86/crypto/cast5_avx_glue.c | 2 +- arch/x86/crypto/cast6_avx_glue.c | 2 +- arch/x86/crypto/serpent_avx2_glue.c| 2 +- arch/x86/crypto/serpent_avx_glue.c | 2 +- arch/x86/crypto/serpent_sse2_glue.c| 2 +- arch/x86/crypto/twofish_avx_glue.c | 2 +- arch/x86/include/asm/crypto/ablk_helper.h | 38 ++-- crypto/Kconfig | 23 +++-- crypto/Makefile| 1 + crypto/ablk_helper.c | 150 + include/asm-generic/crypto/ablk_helper.h | 13 +++ include/crypto/ablk_helper.h | 31 ++ 17 files changed, 224 insertions(+), 200 deletions(-) delete mode 100644 arch/x86/crypto/ablk_helper.c create mode 100644 crypto/ablk_helper.c create mode 100644 include/asm-generic/crypto/ablk_helper.h create mode 100644 include/crypto/ablk_helper.h -- 1.8.1.2 -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] crypto: move x86 to the generic version of ablk_helper
Move all users of ablk_helper under x86/ to the generic version
and delete the x86 specific version.
Acked-by: Jussi Kivilinna jussi.kivili...@iki.fi
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
arch/x86/crypto/Makefile | 1 -
arch/x86/crypto/ablk_helper.c | 149 -
arch/x86/crypto/aesni-intel_glue.c | 2 +-
arch/x86/crypto/camellia_aesni_avx2_glue.c | 2 +-
arch/x86/crypto/camellia_aesni_avx_glue.c | 2 +-
arch/x86/crypto/cast5_avx_glue.c | 2 +-
arch/x86/crypto/cast6_avx_glue.c | 2 +-
arch/x86/crypto/serpent_avx2_glue.c| 2 +-
arch/x86/crypto/serpent_avx_glue.c | 2 +-
arch/x86/crypto/serpent_sse2_glue.c| 2 +-
arch/x86/crypto/twofish_avx_glue.c | 2 +-
arch/x86/include/asm/crypto/ablk_helper.h | 38 ++--
crypto/Kconfig | 25 ++---
13 files changed, 28 insertions(+), 203 deletions(-)
delete mode 100644 arch/x86/crypto/ablk_helper.c
diff --git a/arch/x86/crypto/Makefile b/arch/x86/crypto/Makefile
index 75b08e1e..e0fc24d 100644
--- a/arch/x86/crypto/Makefile
+++ b/arch/x86/crypto/Makefile
@@ -6,7 +6,6 @@ avx_supported := $(call as-instr,vpxor
%xmm0$(comma)%xmm0$(comma)%xmm0,yes,no)
avx2_supported := $(call as-instr,vpgatherdd %ymm0$(comma)(%eax$(comma)%ymm1\
$(comma)4)$(comma)%ymm2,yes,no)
-obj-$(CONFIG_CRYPTO_ABLK_HELPER_X86) += ablk_helper.o
obj-$(CONFIG_CRYPTO_GLUE_HELPER_X86) += glue_helper.o
obj-$(CONFIG_CRYPTO_AES_586) += aes-i586.o
diff --git a/arch/x86/crypto/ablk_helper.c b/arch/x86/crypto/ablk_helper.c
deleted file mode 100644
index 43282fe..000
--- a/arch/x86/crypto/ablk_helper.c
+++ /dev/null
@@ -1,149 +0,0 @@
-/*
- * Shared async block cipher helpers
- *
- * Copyright (c) 2012 Jussi Kivilinna jussi.kivili...@mbnet.fi
- *
- * Based on aesni-intel_glue.c by:
- * Copyright (C) 2008, Intel Corp.
- *Author: Huang Ying ying.hu...@intel.com
- *
- * 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307
- * USA
- *
- */
-
-#include linux/kernel.h
-#include linux/crypto.h
-#include linux/init.h
-#include linux/module.h
-#include crypto/algapi.h
-#include crypto/cryptd.h
-#include asm/i387.h
-#include asm/crypto/ablk_helper.h
-
-int ablk_set_key(struct crypto_ablkcipher *tfm, const u8 *key,
-unsigned int key_len)
-{
- struct async_helper_ctx *ctx = crypto_ablkcipher_ctx(tfm);
- struct crypto_ablkcipher *child = ctx-cryptd_tfm-base;
- int err;
-
- crypto_ablkcipher_clear_flags(child, CRYPTO_TFM_REQ_MASK);
- crypto_ablkcipher_set_flags(child, crypto_ablkcipher_get_flags(tfm)
-CRYPTO_TFM_REQ_MASK);
- err = crypto_ablkcipher_setkey(child, key, key_len);
- crypto_ablkcipher_set_flags(tfm, crypto_ablkcipher_get_flags(child)
-CRYPTO_TFM_RES_MASK);
- return err;
-}
-EXPORT_SYMBOL_GPL(ablk_set_key);
-
-int __ablk_encrypt(struct ablkcipher_request *req)
-{
- struct crypto_ablkcipher *tfm = crypto_ablkcipher_reqtfm(req);
- struct async_helper_ctx *ctx = crypto_ablkcipher_ctx(tfm);
- struct blkcipher_desc desc;
-
- desc.tfm = cryptd_ablkcipher_child(ctx-cryptd_tfm);
- desc.info = req-info;
- desc.flags = 0;
-
- return crypto_blkcipher_crt(desc.tfm)-encrypt(
- desc, req-dst, req-src, req-nbytes);
-}
-EXPORT_SYMBOL_GPL(__ablk_encrypt);
-
-int ablk_encrypt(struct ablkcipher_request *req)
-{
- struct crypto_ablkcipher *tfm = crypto_ablkcipher_reqtfm(req);
- struct async_helper_ctx *ctx = crypto_ablkcipher_ctx(tfm);
-
- if (!irq_fpu_usable()) {
- struct ablkcipher_request *cryptd_req =
- ablkcipher_request_ctx(req);
-
- memcpy(cryptd_req, req, sizeof(*req));
- ablkcipher_request_set_tfm(cryptd_req, ctx-cryptd_tfm-base);
-
- return crypto_ablkcipher_encrypt(cryptd_req);
- } else {
- return __ablk_encrypt(req);
- }
-}
-EXPORT_SYMBOL_GPL(ablk_encrypt);
-
-int ablk_decrypt(struct ablkcipher_request *req)
-{
- struct crypto_ablkcipher *tfm = crypto_ablkcipher_reqtfm(req);
- struct async_helper_ctx *ctx =
[PATCH] ansi_cprng: Fix off by one error in non-block size request
Stephan Mueller reported to me recently a error in random number generation in
the ansi cprng. If several small requests are made that are less than the
instances block size, the remainder for loop code doesn't increment
rand_data_valid in the last iteration, meaning that the last bytes in the
rand_data buffer gets reused on the subsequent smaller-than-a-block request for
random data.
The fix is pretty easy, just re-code the for loop to make sure that
rand_data_valid gets incremented appropriately
Signed-off-by: Neil Horman nhor...@tuxdriver.com
Reported-by: Stephan Mueller stephan.muel...@atsec.com
CC: Stephan Mueller stephan.muel...@atsec.com
CC: Petr Matousek pmato...@redhat.com
CC: Herbert Xu herb...@gondor.apana.org.au
CC: David S. Miller da...@davemloft.net
---
crypto/ansi_cprng.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/crypto/ansi_cprng.c b/crypto/ansi_cprng.c
index c0bb377..666f196 100644
--- a/crypto/ansi_cprng.c
+++ b/crypto/ansi_cprng.c
@@ -230,11 +230,11 @@ remainder:
*/
if (byte_count DEFAULT_BLK_SZ) {
empty_rbuf:
- for (; ctx-rand_data_valid DEFAULT_BLK_SZ;
- ctx-rand_data_valid++) {
+ while (ctx-rand_data_valid DEFAULT_BLK_SZ) {
*ptr = ctx-rand_data[ctx-rand_data_valid];
ptr++;
byte_count--;
+ ctx-rand_data_valid++;
if (byte_count == 0)
goto done;
}
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] crypto_mem_not_equal: add constant-time equality testing of memory regions
On 09/16/2013 07:10 PM, James Yonan wrote:
On 16/09/2013 01:56, Daniel Borkmann wrote:
On 09/15/2013 06:59 PM, James Yonan wrote:
On 15/09/2013 09:45, Florian Weimer wrote:
* James Yonan:
+ * Constant-time equality testing of memory regions.
+ * Returns 0 when data is equal, non-zero otherwise.
+ * Fast path if size == 16.
+ */
+noinline unsigned long crypto_mem_not_equal(const void *a, const
void *b, size_t size)
I think this should really return unsigned or int, to reduce the risk
that the upper bytes are truncated because the caller uses an
inappropriate type, resulting in a bogus zero result. Reducing the
value to 0/1 probably doesn't hurt performance too much. It also
doesn't encode any information about the location of the difference in
the result value, which helps if that ever leaks.
The problem with returning 0/1 within the function body of
crypto_mem_not_equal is that it makes it easier for the compiler to
introduce a short-circuit optimization.
It might be better to move the test where the result is compared
against 0 into an inline function:
noinline unsigned long __crypto_mem_not_equal(const void *a, const
void *b, size_t size);
static inline int crypto_mem_not_equal(const void *a, const void *b,
size_t size) {
return __crypto_mem_not_equal(a, b, size) != 0UL ? 1 : 0;
}
This hides the fact that we are only interested in a boolean result
from the compiler when it's compiling crypto_mem_not_equal.c, but also
ensures type safety when users test the return value. It's also
likely to have little or no performance impact.
Well, the code snippet I've provided from NaCl [1] is not really
fast-path
as you say, but rather to prevent the compiler from doing such
optimizations
by having a transformation of the accumulated bits into 0 and 1 as an end
result (likely to prevent a short circuit), plus it has static size, so no
loops applied here that could screw up.
Variable size could be done under arch/ in asm, and if not available, that
just falls back to normal memcmp that is being transformed into a same
return
value. By that, all other archs could easily migrate afterwards. What do
you
think?
[1] http://www.spinics.net/lists/linux-crypto/msg09558.html
I'm not sure that the differentbits - 0/-1 transform in NaCl really buys us
anything because
we don't care very much about making the final test of differentbits != 0
constant-time. An
attacker already knows whether the test succeeded or failed -- we care more
about making the
failure cases constant-time.
To do this, we need to make sure that the compiler doesn't insert one or more
early instructions
to compare differentbits with 0xFF and then bypass the rest of the F(n) lines
because it knows
then that the value of differentbits cannot be changed by subsequent F(n)
lines. It seems that
all of the approaches that use |= to build up the differentbits value suffer
from this problem.
My proposed solution is rather than trying to outsmart the compiler with code
that resists
optimization, why not just turn optimization off directly with #pragma GCC
optimize. Or better
yet, use an optimization setting that provides reasonable speed without
introducing potential
short-circuit optimizations.
By optimizing for size (Os), the compiler will need to turn off optimizations
that add code
for a possible speed benefit, and the kind of short-circuit optimizations
that we are trying to
avoid fall precisely into this class -- they add an instruction to check if
the OR accumulator has
all of its bits set, then if so, do an early exit. So by using Os, we still
benefit from
optimizations that increase speed but don't increase code size.
While I was looking a bit further into this, I thought using an attribute like
this might be a
more clean variant ...
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 92669cd..2505b1b 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -351,6 +351,11 @@ void ftrace_likely_update(struct ftrace_branch_data *f,
int val, int expect);
*/
#define ACCESS_ONCE(x) (*(volatile typeof(x) *)(x))
+/* Tell GCC to turn off optimization for a particular function. */
+#ifndef __do_not_optimize
+#define __do_not_optimize __attribute__((optimize(O0)))
+#endif
+
/* Ignore/forbid kprobes attach on very low level functions marked by this
attribute: */
#ifdef CONFIG_KPROBES
# define __kprobes __attribute__((__section__(.kprobes.text)))
... however, then I found on the GCC developer mailing list [1]: That said, I
consider the
optimize attribute code seriously broken and unmaintained (but sometimes useful
for debugging -
and only that). [...] Does #pragma Gcc optimize work more reliably? No, it
uses the same
mechanism internally. [...] And if these options are so broken, should they be
marked as such
in the manual? [...] Probably yes.
Therefore, I still need to ask ... what about the option of an
arch/*/crypto/... asm
Re: [PATCH V4 02/15] asymmetric keys: implement EMSA_PKCS1-v1_5-ENCODE in rsa
Hello,
On Sat, Sep 14, 2013 at 7:56 PM, Lee, Chun-Yi joeyli.ker...@gmail.com wrote:
Implement EMSA_PKCS1-v1_5-ENCODE [RFC3447 sec 9.2] in rsa.c. It's the
first step of signature generation operation (RSASSA-PKCS1-v1_5-SIGN).
This patch is temporary set emLen to pks-k, and temporary set EM to
pks-S for debugging. We will replace the above values to real signature
after implement RSASP1.
The naming of EMSA_PKCS1_v1_5_ENCODE and the variables used in this function
accord PKCS#1 spec but not follow kernel naming convention, it useful when
look
at them with spec.
Reference: ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1v2/pkcs1ietffinal.txt
Reference:
http://www.emc.com/collateral/white-papers/h11300-pkcs-1v2-2-rsa-cryptography-standard-wp.pdf
V2:
- Clean up naming of variable: replace _EM by EM, replace EM by EM_tmp.
- Add comment to EMSA_PKCS1-v1_5-ENCODE function.
Cc: Pavel Machek pa...@ucw.cz
Reviewed-by: Jiri Kosina jkos...@suse.cz
Signed-off-by: Lee, Chun-Yi j...@suse.com
---
crypto/asymmetric_keys/rsa.c | 163
+-
include/crypto/public_key.h |2 +
2 files changed, 164 insertions(+), 1 deletions(-)
diff --git a/crypto/asymmetric_keys/rsa.c b/crypto/asymmetric_keys/rsa.c
index 47f3be4..352ba45 100644
--- a/crypto/asymmetric_keys/rsa.c
+++ b/crypto/asymmetric_keys/rsa.c
@@ -13,6 +13,7 @@
#include linux/module.h
#include linux/kernel.h
#include linux/slab.h
+#include crypto/hash.h
#include public_key.h
#include private_key.h
@@ -152,6 +153,132 @@ static int RSA_I2OSP(MPI x, size_t xLen, u8 **_X)
}
/*
+ * EMSA_PKCS1-v1_5-ENCODE [RFC3447 sec 9.2]
+ * @M: message to be signed, an octet string
+ * @emLen: intended length in octets of the encoded message
+ * @hash_algo: hash function (option)
+ * @hash: true means hash M, otherwise M is already a digest
+ * @EM: encoded message, an octet string of length emLen
+ *
+ * This function is a implementation of the EMSA-PKCS1-v1_5 encoding
operation
+ * in RSA PKCS#1 spec. It used by the signautre generation operation of
+ * RSASSA-PKCS1-v1_5 to encode message M to encoded message EM.
+ *
+ * The variables used in this function accord PKCS#1 spec but not follow
kernel
+ * naming convention, it useful when look at them with spec.
+ */
+static int EMSA_PKCS1_v1_5_ENCODE(const u8 *M, size_t emLen,
+ enum pkey_hash_algo hash_algo, const bool hash,
+ u8 **EM, struct public_key_signature *pks)
+{
+ u8 *digest;
+ struct crypto_shash *tfm;
+ struct shash_desc *desc;
+ size_t digest_size, desc_size;
+ size_t tLen;
+ u8 *T, *PS, *EM_tmp;
+ int i, ret;
+
+ pr_info(EMSA_PKCS1_v1_5_ENCODE start\n);
+
+ if (!RSA_ASN1_templates[hash_algo].data)
What about checking hash_algo against PKEY_HASH__LAST, or it relies on
the caller?
+ ret = -ENOTSUPP;
+ else
+ pks-pkey_hash_algo = hash_algo;
+
+ /* 1) Apply the hash function to the message M to produce a hash
value H */
+ tfm = crypto_alloc_shash(pkey_hash_algo[hash_algo], 0, 0);
+ if (IS_ERR(tfm))
+ return (PTR_ERR(tfm) == -ENOENT) ? -ENOPKG : PTR_ERR(tfm);
+
+ desc_size = crypto_shash_descsize(tfm) + sizeof(*desc);
+ digest_size = crypto_shash_digestsize(tfm);
+
+ ret = -ENOMEM;
+
+ digest = kzalloc(digest_size + desc_size, GFP_KERNEL);
+ if (!digest)
+ goto error_digest;
+ pks-digest = digest;
+ pks-digest_size = digest_size;
+
Ok. You allocated tfm to get hash size, right?
But why do you allocate descriptor even it might not be needed?
+ if (hash) {
+ desc = (void *) digest + digest_size;
+ desc-tfm = tfm;
+ desc-flags = CRYPTO_TFM_REQ_MAY_SLEEP;
+
+ ret = crypto_shash_init(desc);
+ if (ret 0)
+ goto error_shash;
+ ret = crypto_shash_finup(desc, M, sizeof(M), pks-digest);
This is I completely fail to understand... You expect sizeof(M) to be
the message length?
Have you ever tested it?
+ if (ret 0)
+ goto error_shash;
+ } else {
+ memcpy(pks-digest, M, pks-digest_size);
+ pks-digest_size = digest_size;
+ }
Does caller use pks-digest and pks-digest_size after return?
I think it needs encoded value, not the hash...
So why do you pass pks?
+ crypto_free_shash(tfm);
+
+ /* 2) Encode the algorithm ID for the hash function and the hash
value into
+* an ASN.1 value of type DigestInfo with the DER. Let T be the DER
encoding of
+* the DigestInfo value and let tLen be the length in octets of T.
+*/
+ tLen = RSA_ASN1_templates[hash_algo].size + pks-digest_size;
+ T = kmalloc(tLen, GFP_KERNEL);
+ if (!T)
+
Re: [PATCH] modules: add support for soft module dependencies
On Thu, Sep 12, 2013 at 9:07 PM, Rusty Russell ru...@rustcorp.com.au wrote: Lucas De Marchi lucas.de.mar...@gmail.com writes: On Wed, Jul 24, 2013 at 11:03 PM, Herbert Xu herb...@gondor.apana.org.au wrote: On Thu, Jul 25, 2013 at 09:32:02AM +0930, Rusty Russell wrote: Herbert Xu herb...@gondor.apana.org.au writes: Hi Rusty: I don't know why this patch never went into the kernel, even though the corresponding features have been added to modprobe in most if not all distros. Because Andreas never sent me the patch? This is the first I've *heard* of this feature. Looks like it didn't hit lkml either. And what was 2/2? 2/2 was the patch to actually use this in crc32c. It's not how I would have done this: post-deps are more flexibly done at runtime, because the module may have to do work to figure out what to pull in. But since it already exists, I'll apply this patch: it doesn't cost the kernel anything. But it did cause boot failures. The file modules.softdep file was supposed to be informational until now. That's why depmod put a comment saying to copy on user's discretion to /etc/modules.d instead of parsing it directly. I'm happy to change this macro to create a modinfo line like softdep:modname how is that solving the issue that this macro can be used to designate a mandatory or optional dependency (https://lkml.org/lkml/2013/9/10/371)? If we decide the dependency is mandatory we can very well let modprobe use that dependency during module load ie. tools like mkinitrd could pick it up and try to find a matching module, but depmod would ignore it. Some mkinitrd-like use whatever depmod/modprobe tells them it's needed. So kmod still needs to know about it. It's really up to Lucas, since this affects him. IMO saying this is an optional dependency and we can work without doesn't buy us much. Distros will end up putting the soft dep in /etc/modules.d, kmod will always use them anyway and failing to load the soft dep will fail the module load. I'd like to have no distro files in /etc/modules.d in future. Lucas De Marchi -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V4 02/15] asymmetric keys: implement EMSA_PKCS1-v1_5-ENCODE in rsa
On Sat, Sep 14, 2013 at 7:56 PM, Lee, Chun-Yi joeyli.ker...@gmail.com wrote:
Implement EMSA_PKCS1-v1_5-ENCODE [RFC3447 sec 9.2] in rsa.c. It's the
first step of signature generation operation (RSASSA-PKCS1-v1_5-SIGN).
This patch is temporary set emLen to pks-k, and temporary set EM to
pks-S for debugging. We will replace the above values to real signature
after implement RSASP1.
The naming of EMSA_PKCS1_v1_5_ENCODE and the variables used in this function
accord PKCS#1 spec but not follow kernel naming convention, it useful when
look
at them with spec.
Reference: ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1v2/pkcs1ietffinal.txt
Reference:
http://www.emc.com/collateral/white-papers/h11300-pkcs-1v2-2-rsa-cryptography-standard-wp.pdf
V2:
- Clean up naming of variable: replace _EM by EM, replace EM by EM_tmp.
- Add comment to EMSA_PKCS1-v1_5-ENCODE function.
Cc: Pavel Machek pa...@ucw.cz
Reviewed-by: Jiri Kosina jkos...@suse.cz
Signed-off-by: Lee, Chun-Yi j...@suse.com
---
crypto/asymmetric_keys/rsa.c | 163
+-
include/crypto/public_key.h |2 +
2 files changed, 164 insertions(+), 1 deletions(-)
diff --git a/crypto/asymmetric_keys/rsa.c b/crypto/asymmetric_keys/rsa.c
index 47f3be4..352ba45 100644
--- a/crypto/asymmetric_keys/rsa.c
+++ b/crypto/asymmetric_keys/rsa.c
@@ -13,6 +13,7 @@
#include linux/module.h
#include linux/kernel.h
#include linux/slab.h
+#include crypto/hash.h
#include public_key.h
#include private_key.h
@@ -152,6 +153,132 @@ static int RSA_I2OSP(MPI x, size_t xLen, u8 **_X)
}
/*
+ * EMSA_PKCS1-v1_5-ENCODE [RFC3447 sec 9.2]
+ * @M: message to be signed, an octet string
+ * @emLen: intended length in octets of the encoded message
+ * @hash_algo: hash function (option)
+ * @hash: true means hash M, otherwise M is already a digest
+ * @EM: encoded message, an octet string of length emLen
+ *
+ * This function is a implementation of the EMSA-PKCS1-v1_5 encoding
operation
+ * in RSA PKCS#1 spec. It used by the signautre generation operation of
+ * RSASSA-PKCS1-v1_5 to encode message M to encoded message EM.
+ *
+ * The variables used in this function accord PKCS#1 spec but not follow
kernel
+ * naming convention, it useful when look at them with spec.
+ */
+static int EMSA_PKCS1_v1_5_ENCODE(const u8 *M, size_t emLen,
+ enum pkey_hash_algo hash_algo, const bool hash,
+ u8 **EM, struct public_key_signature *pks)
+{
+ u8 *digest;
+ struct crypto_shash *tfm;
+ struct shash_desc *desc;
+ size_t digest_size, desc_size;
+ size_t tLen;
+ u8 *T, *PS, *EM_tmp;
+ int i, ret;
+
+ pr_info(EMSA_PKCS1_v1_5_ENCODE start\n);
+
+ if (!RSA_ASN1_templates[hash_algo].data)
+ ret = -ENOTSUPP;
+ else
+ pks-pkey_hash_algo = hash_algo;
+
+ /* 1) Apply the hash function to the message M to produce a hash
value H */
+ tfm = crypto_alloc_shash(pkey_hash_algo[hash_algo], 0, 0);
+ if (IS_ERR(tfm))
+ return (PTR_ERR(tfm) == -ENOENT) ? -ENOPKG : PTR_ERR(tfm);
+
+ desc_size = crypto_shash_descsize(tfm) + sizeof(*desc);
+ digest_size = crypto_shash_digestsize(tfm);
+
+ ret = -ENOMEM;
+
+ digest = kzalloc(digest_size + desc_size, GFP_KERNEL);
+ if (!digest)
+ goto error_digest;
+ pks-digest = digest;
+ pks-digest_size = digest_size;
+
+ if (hash) {
+ desc = (void *) digest + digest_size;
+ desc-tfm = tfm;
+ desc-flags = CRYPTO_TFM_REQ_MAY_SLEEP;
+
+ ret = crypto_shash_init(desc);
+ if (ret 0)
+ goto error_shash;
+ ret = crypto_shash_finup(desc, M, sizeof(M), pks-digest);
+ if (ret 0)
+ goto error_shash;
+ } else {
+ memcpy(pks-digest, M, pks-digest_size);
+ pks-digest_size = digest_size;
+ }
+ crypto_free_shash(tfm);
+
+ /* 2) Encode the algorithm ID for the hash function and the hash
value into
+* an ASN.1 value of type DigestInfo with the DER. Let T be the DER
encoding of
+* the DigestInfo value and let tLen be the length in octets of T.
+*/
+ tLen = RSA_ASN1_templates[hash_algo].size + pks-digest_size;
+ T = kmalloc(tLen, GFP_KERNEL);
+ if (!T)
+ goto error_T;
+
as I said, remove it... see bellow
+ memcpy(T, RSA_ASN1_templates[hash_algo].data,
RSA_ASN1_templates[hash_algo].size);
+ memcpy(T + RSA_ASN1_templates[hash_algo].size, pks-digest,
pks-digest_size);
+
+ /* 3) check If emLen tLen + 11, output intended encoded message
length too short */
+ if (emLen tLen + 11) {
+ ret = -EINVAL;
+ goto error_emLen;
+ }
+
+
Re: [PATCH] modules: add support for soft module dependencies
On Tue, Sep 17, 2013 at 11:10 PM, Rusty Russell ru...@rustcorp.com.au wrote: Lucas De Marchi lucas.de.mar...@gmail.com writes: On Thu, Sep 12, 2013 at 9:07 PM, Rusty Russell ru...@rustcorp.com.au wrote: Lucas De Marchi lucas.de.mar...@gmail.com writes: On Wed, Jul 24, 2013 at 11:03 PM, Herbert Xu herb...@gondor.apana.org.au wrote: On Thu, Jul 25, 2013 at 09:32:02AM +0930, Rusty Russell wrote: Herbert Xu herb...@gondor.apana.org.au writes: Hi Rusty: I don't know why this patch never went into the kernel, even though the corresponding features have been added to modprobe in most if not all distros. Because Andreas never sent me the patch? This is the first I've *heard* of this feature. Looks like it didn't hit lkml either. And what was 2/2? 2/2 was the patch to actually use this in crc32c. It's not how I would have done this: post-deps are more flexibly done at runtime, because the module may have to do work to figure out what to pull in. But since it already exists, I'll apply this patch: it doesn't cost the kernel anything. But it did cause boot failures. The file modules.softdep file was supposed to be informational until now. That's why depmod put a comment saying to copy on user's discretion to /etc/modules.d instead of parsing it directly. I'm happy to change this macro to create a modinfo line like softdep:modname how is that solving the issue that this macro can be used to designate a mandatory or optional dependency (https://lkml.org/lkml/2013/9/10/371)? If we decide the dependency is mandatory we can very well let modprobe use that dependency during module load I'm very close to sending Linus a revert commit at this point, since there's no consensus on what it's for. *Clearly* softdep shouldn't indicate a mandatory dependency. We already have a way (several) to make mandatory dependencies! And the pre: vs post: thing is just weird. If a module wants a post dependency, you can request_module() it from a workqueue. ie. tools like mkinitrd could pick it up and try to find a matching module, but depmod would ignore it. Some mkinitrd-like use whatever depmod/modprobe tells them it's needed. So kmod still needs to know about it. It sounds like we should create a separate tool, which takes a list of modules and spits out the full pathname of all dependencies. *That* tool should include soft dependencies. It's really up to Lucas, since this affects him. IMO saying this is an optional dependency and we can work without doesn't buy us much. Distros will end up putting the soft dep in /etc/modules.d, kmod will always use them anyway and failing to load the soft dep will fail the module load. I'd like to have no distro files in /etc/modules.d in future. I assumed modprobe would handle soft dependencies in modules and try to pull them in, but *not* fail if they don't work. Iff the module doesn't *exist*. If it failed to load or failed for any other reason then we will abort trying to load the other module. However this is one thing we can change in modprobe to make it consistent and more predictable. But we really need to reach a consensus. The previous way of doing this was: install foo modprobe foo_softdep 2/dev/null; modprobe --ignore-install foo $CMDLINE_OPTS I just hope this is in no way an incentive for people using install commands ;-) Lucas De Marchi -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
