Re: [PATCH crypto-next] crypto: algif - add and use sock_kzfree_s() instead of memzero_explicit()
On Wed, Nov 19, 2014 at 05:13:11PM +0100, Daniel Borkmann wrote: Commit e1bd95bf7c25 (crypto: algif - zeroize IV buffer) and 2a6af25befd0 (crypto: algif - zeroize message digest buffer) added memzero_explicit() calls on buffers that are later on passed back to sock_kfree_s(). This is a discussed follow-up that, instead, extends the sock API and adds sock_kzfree_s(), which internally uses kzfree() instead of kfree() for passing the buffers back to slab. Having sock_kzfree_s() allows to keep the changes more minimal by just having a drop-in replacement instead of adding memzero_explicit() calls everywhere before sock_kfree_s(). In kzfree(), the compiler is not allowed to optimize the memset() away and thus there's no need for memzero_explicit(). Both, sock_kfree_s() and sock_kzfree_s() are wrappers for __sock_kfree_s() and call into kfree() resp. kzfree(); here, __sock_kfree_s() needs to be explicitly inlined as we want the compiler to optimize the call and condition away and thus it produces e.g. on x86_64 the _same_ assembler output for sock_kfree_s() before and after, and thus also allows for avoiding code duplication. Cc: David S. Miller da...@davemloft.net Signed-off-by: Daniel Borkmann dbork...@redhat.com Dave, any comment on this patch? Thanks, -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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 v3 1/7] crypto: AF_ALG: add user space interface for AEAD
On Fri, Nov 21, 2014 at 06:30:18AM +0100, Stephan Mueller wrote: @@ -421,6 +421,18 @@ int af_alg_cmsg_send(struct msghdr *msg, struct af_alg_control *con) con-op = *(u32 *)CMSG_DATA(cmsg); break; + case ALG_SET_AEAD_AUTHSIZE: + if (cmsg-cmsg_len CMSG_LEN(sizeof(u32))) + return -EINVAL; + con-aead_authsize = *(u32 *)CMSG_DATA(cmsg); + break; This is a tfm attribute so it should go into setsockopt. Cheers, -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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 1/2] crypto: Add Imagination Technologies hw hash accelerator
On Sat, Nov 15, 2014 at 08:55:58AM +0100, Corentin LABBE wrote: and then get it via struct crypto_priv *cp = req-base.tfm-__crt_alg-data; (a function will be better than that) So what is the recommended way to get driver structure inside the cryptoAPI function (init/udpate/final)? Have a look at talitos which deals with this by embedding crypto_alg within its own data structure. Cheers, -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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 v3 5/7] crypto: AF_ALG: add random number generator support
Am Montag, 24. November 2014, 22:31:50 schrieb Herbert Xu: Hi Herbert, On Fri, Nov 21, 2014 at 06:32:52AM +0100, Stephan Mueller wrote: This patch adds the random number generator support for AF_ALG. A random number generator's purpose is to generate data without requiring the caller to provide any data. Therefore, the AF_ALG interface handler for RNGs only implements a callback handler for recvmsg. The following parameters provided with a recvmsg are processed by the RNG callback handler: * sock - to resolve the RNG context data structure accessing the RNG instance private to the socket * len - this parameter allows userspace callers to specify how many random bytes the RNG shall produce and return. As the kernel context for the RNG allocates a buffer of 128 bytes to store random numbers before copying them to userspace, the len parameter is checked that it is not larger than 128. If a caller wants more random numbers, a new request for recvmsg shall be made. The size of 128 bytes is chose because of the following considerations: * to increase the memory footprint of the kernel too much (note, that would be 128 bytes per open socket) * 128 is divisible by any typical cryptographic block size an RNG may have * A request for random numbers typically only shall supply small amount of data like for keys or IVs that should only require one invocation of the recvmsg function. Note, during instantiation of the RNG, the code checks whether the RNG implementation requires seeding. If so, the RNG is seeded with output from get_random_bytes. A fully working example using all aspects of the RNG interface is provided at http://www.chronox.de/libkcapi.html Signed-off-by: Stephan Mueller smuel...@chronox.de Sorry but who is going to use this and for what purpose? Every other algif interface exports real hardware features that cannot otherwise be accessed from user-space. All crypto RNGs are by definition software-only, so what is the point of this? My idea is twofold: The software-RNGs currently available (X9.31 and DRBG) use other ciphers as backends. Therefore, they can be considered as transforms on top of these backend ciphers. Now, if these backend ciphers are available in kernel mode only, currently only these in- kernel RNGs can use the hardware. With the consideration of AEAD, all ciphers supported by the kernel crypto API are available to user space. That means, there is no need for an additional crypto library in user space in addition to provide hardware access. The RNG part is there to complement the case for not needing an additional crypto lib in user space. Ciao Stephan -- 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] crypto: drbg: use memzero_explicit() for clearing sensitive data
Compiler dead store optimization can sometimes remove final calls to memset() used to clear sensitive data at the end of a function. Replace trailing memset() calls with memzero_explicit() to preclude unwanted removal. Signed-off-by: Nickolaus Woodruff nickolauswoodr...@gmail.com --- crypto/drbg.c | 22 +++--- include/crypto/drbg.h | 1 + 2 files changed, 12 insertions(+), 11 deletions(-) diff --git a/crypto/drbg.c b/crypto/drbg.c index 54cfd48..c6258ca 100644 --- a/crypto/drbg.c +++ b/crypto/drbg.c @@ -522,9 +522,9 @@ static int drbg_ctr_df(struct drbg_state *drbg, ret = 0; out: - memset(iv, 0, drbg_blocklen(drbg)); - memset(temp, 0, drbg_statelen(drbg)); - memset(pad, 0, drbg_blocklen(drbg)); + memzero_explicit(iv, drbg_blocklen(drbg)); + memzero_explicit(temp, drbg_statelen(drbg)); + memzero_explicit(pad, drbg_blocklen(drbg)); return ret; } @@ -599,9 +599,9 @@ static int drbg_ctr_update(struct drbg_state *drbg, struct list_head *seed, ret = 0; out: - memset(temp, 0, drbg_statelen(drbg) + drbg_blocklen(drbg)); + memzero_explicit(temp, drbg_statelen(drbg) + drbg_blocklen(drbg)); if (2 != reseed) - memset(df_data, 0, drbg_statelen(drbg)); + memzero_explicit(df_data, drbg_statelen(drbg)); return ret; } @@ -660,7 +660,7 @@ static int drbg_ctr_generate(struct drbg_state *drbg, len = ret; out: - memset(drbg-scratchpad, 0, drbg_blocklen(drbg)); + memzero_explicit(drbg-scratchpad, drbg_blocklen(drbg)); return len; } @@ -848,7 +848,7 @@ static int drbg_hash_df(struct drbg_state *drbg, } out: - memset(tmp, 0, drbg_blocklen(drbg)); + memzero_explicit(tmp, drbg_blocklen(drbg)); return ret; } @@ -892,7 +892,7 @@ static int drbg_hash_update(struct drbg_state *drbg, struct list_head *seed, ret = drbg_hash_df(drbg, drbg-C, drbg_statelen(drbg), datalist2); out: - memset(drbg-scratchpad, 0, drbg_statelen(drbg)); + memzero_explicit(drbg-scratchpad, drbg_statelen(drbg)); return ret; } @@ -927,7 +927,7 @@ static int drbg_hash_process_addtl(struct drbg_state *drbg, drbg-scratchpad, drbg_blocklen(drbg)); out: - memset(drbg-scratchpad, 0, drbg_blocklen(drbg)); + memzero_explicit(drbg-scratchpad, drbg_blocklen(drbg)); return ret; } @@ -975,7 +975,7 @@ static int drbg_hash_hashgen(struct drbg_state *drbg, } out: - memset(drbg-scratchpad, 0, + memzero_explicit(drbg-scratchpad, (drbg_statelen(drbg) + drbg_blocklen(drbg))); return len; } @@ -1024,7 +1024,7 @@ static int drbg_hash_generate(struct drbg_state *drbg, drbg_add_buf(drbg-V, drbg_statelen(drbg), u.req, 8); out: - memset(drbg-scratchpad, 0, drbg_blocklen(drbg)); + memzero_explicit(drbg-scratchpad, drbg_blocklen(drbg)); return len; } diff --git a/include/crypto/drbg.h b/include/crypto/drbg.h index 5186f75..13471a2 100644 --- a/include/crypto/drbg.h +++ b/include/crypto/drbg.h @@ -45,6 +45,7 @@ #include crypto/hash.h #include linux/module.h #include linux/crypto.h +#include linux/string.h #include linux/slab.h #include crypto/internal/rng.h #include crypto/rng.h -- 1.9.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 V2 1/2] crypto: Add Imagination Technologies hw hash accelerator
Hi Herbert, thanks for the review.
-Original Message-
From: devicetree-ow...@vger.kernel.org [mailto:devicetree-
ow...@vger.kernel.org] On Behalf Of Herbert Xu
Sent: 20 November 2014 14:22
To: James Hartley
Cc: da...@davemloft.net; grant.lik...@linaro.org; robh...@kernel.org;
gre...@linuxfoundation.org; linux-crypto@vger.kernel.org;
devicet...@vger.kernel.org; pawel.m...@arm.com;
mark.rutl...@arm.com; ijc+devicet...@hellion.org.uk;
ga...@codeaurora.org; Ezequiel Garcia; abres...@chromium.org
Subject: Re: [PATCH V2 1/2] crypto: Add Imagination Technologies hw hash
accelerator
On Tue, Nov 18, 2014 at 08:48:46PM +, James Hartley wrote:
+struct img_hash_request_ctx {
+ struct img_hash_dev *hdev;
+ u8 digest[SHA256_DIGEST_SIZE] __aligned(sizeof(u32));
+ unsigned long flags;
+ size_t digsize;
+
+ dma_addr_t dma_addr;
+ size_t dma_ct;
+
+ /* sg root */
+ struct scatterlist *sgfirst;
+ /* walk state */
+ struct scatterlist *sg;
+ size_t nents;
+ size_t offset;
+ unsigned inttotal;
+ size_t sent;
+
+ unsigned long op;
+
+ size_t bufcnt;
+ u8 buffer[0] __aligned(sizeof(u32)); };
Unfortunately this is not consistent with our API since you're not storing the
non-final hash state in the request context.
It appears that you're finalising every request. That means you can only
implement finup and digest. With finup you'll also need to be able to import
a non-final hash state. If the hardware cannot do that then you can only
implement digest.
Everything else would have to be done by a fallback driver.
So the question is can you obtain the non-final hash state from the hardware
and then reinsert it for the next operation?
I've looked into this and unfortunately the hardware cannot do that. I'll
spend some
time looking into what this means (I'm not the author of the driver, so will
need to
become a bit more familiar with it).
Cheers,
--
Email: Herbert Xu herb...@gondor.apana.org.au Home Page:
http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line unsubscribe devicetree in the
body of a message to majord...@vger.kernel.org More majordomo info at
http://vger.kernel.org/majordomo-info.html
Thanks,
James.
--
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: sha-mb - remove a bogus NULL check
On Sat, 2014-11-22 at 21:36 +0300, Dan Carpenter wrote: This can't be NULL and we dereferenced it earlier. Smatch used to ignore these things where the pointer was obviously non-NULL but I've found that sometimes the intention was to check something else so we were maybe missing bugs. Signed-off-by: Dan Carpenter dan.carpen...@oracle.com diff --git a/arch/x86/crypto/sha-mb/sha1_mb.c b/arch/x86/crypto/sha-mb/sha1_mb.c index 99eefd8..a225a5ca 100644 --- a/arch/x86/crypto/sha-mb/sha1_mb.c +++ b/arch/x86/crypto/sha-mb/sha1_mb.c @@ -204,8 +204,7 @@ static struct sha1_hash_ctx *sha1_ctx_mgr_resubmit(struct sha1_ctx_mgr *mgr, str continue; } - if (ctx) - ctx-status = HASH_CTX_STS_IDLE; + ctx-status = HASH_CTX_STS_IDLE; return ctx; } Agree. This NULL pointer check is not necessary. Acked-by: Tim Chen tim.c.c...@linux.intel.com -- 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] crypto: include crypto- module prefix in template
This adds the module loading prefix crypto- to the template lookup
as well.
For example, attempting to load 'vfat(blowfish)' via AF_ALG now correctly
includes the crypto- prefix at every level, correctly rejecting vfat:
net-pf-38
algif-hash
crypto-vfat(blowfish)
crypto-vfat(blowfish)-all
crypto-vfat
Reported-by: Mathias Krause mini...@googlemail.com
Signed-off-by: Kees Cook keesc...@chromium.org
---
crypto/algapi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/crypto/algapi.c b/crypto/algapi.c
index e8d3a7dca8c4..71a8143e23b1 100644
--- a/crypto/algapi.c
+++ b/crypto/algapi.c
@@ -509,8 +509,8 @@ static struct crypto_template
*__crypto_lookup_template(const char *name)
struct crypto_template *crypto_lookup_template(const char *name)
{
- return try_then_request_module(__crypto_lookup_template(name), %s,
- name);
+ return try_then_request_module(__crypto_lookup_template(name),
+ crypto-%s, name);
}
EXPORT_SYMBOL_GPL(crypto_lookup_template);
--
1.9.1
--
Kees Cook
Chrome OS Security
--
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: include crypto- module prefix in template
On 24 November 2014 at 20:17, Kees Cook keesc...@chromium.org wrote: This adds the module loading prefix crypto- to the template lookup as well. For example, attempting to load 'vfat(blowfish)' via AF_ALG now correctly includes the crypto- prefix at every level, correctly rejecting vfat: net-pf-38 algif-hash crypto-vfat(blowfish) crypto-vfat(blowfish)-all crypto-vfat Reported-by: Mathias Krause mini...@googlemail.com Signed-off-by: Kees Cook keesc...@chromium.org --- crypto/algapi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) That commit will break the user API again as ciphers like 'cbc(aes)' won't work any more -- as the cbc module won't be loaded. You're missing the MODULE_ALIAS_CRYPTO() annotaions for all the crypto templates -- cbc, ctr, xts, hmac, ... Regards, Mathias -- 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] crypto: user - add MODULE_ALIAS
To allow automatic loading of the crypto_user kernel module, the netlink MODULE_ALIAS is added. Signed-off-by: Stephan Mueller smuel...@chronox.de --- crypto/crypto_user.c | 1 + 1 file changed, 1 insertion(+) diff --git a/crypto/crypto_user.c b/crypto/crypto_user.c index e2a34fe..255df95 100644 --- a/crypto/crypto_user.c +++ b/crypto/crypto_user.c @@ -537,3 +537,4 @@ module_exit(crypto_user_exit); MODULE_LICENSE(GPL); MODULE_AUTHOR(Steffen Klassert steffen.klass...@secunet.com); MODULE_DESCRIPTION(Crypto userspace configuration API); +MODULE_ALIAS(net-pf-16-proto-21); -- 2.1.0 -- 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 v3 4/7] crypto: AF_ALG: add AEAD support
Am Montag, 24. November 2014, 22:29:46 schrieb Herbert Xu: Hi Herbert, On Fri, Nov 21, 2014 at 06:32:16AM +0100, Stephan Mueller wrote: This patch adds the AEAD support for AF_ALG. The AEAD implementation uses the entire memory handling and infrastructure of the existing skcipher implementation. To use AEAD, the user space consumer has to use the salg_type named aead. The AEAD extension only uses the bind callback as the key differentiator. The previously added functions that select whether to use AEAD or ablkcipher crypto API functions depend on the TFM type allocated during the bind() call. The addition of AEAD brings a bit of overhead to calculate the size of the ciphertext, because the AEAD implementation of the kernel crypto API makes implied assumption on the location of the authentication tag. When performing an encryption, the tag will be added to the created ciphertext (note, the tag is placed adjacent to the ciphertext). For decryption, the caller must hand in the ciphertext with the tag appended to the ciphertext. Therefore, the selection of the used memory needs to add/subtract the tag size from the source/destination buffers depending on the encryption type. The code is provided with comments explainint when and how that operation is performed. Note: The AF_ALG interface does not support zero length input data. Such zero length input data may be used if one wants to access the hash implementation of an AEAD directly (e.g. the GHASH of GCM or CMAC for CCM). However, this is a use case that is not of interest. GHASH or CMAC is directly available via the hash AF_ALG interface and we therefore do not need to take precautions for this use case. A fully working example using all aspects of AEAD is provided at http://www.chronox.de/libkcapi.html Signed-off-by: Stephan Mueller smuel...@chronox.de I appreciate the effort to share code, but shoe-horning AEAD into algif_skcipher is just too ugly. How about let's just start with a separate algif_aead and then add helpers to merge common code as applicable? Instead of creating a separate algif_aead file, may I propose that the inline functions wrapping the kernel crypto API calls to keep them in a separate header file. That should remove code that distracts from the real functionality. The only AEAD code that is left is the memory handling in the recvmsg and setting the AD in sendmsg. Thanks Thanks, -- Ciao Stephan -- 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] crypto: include crypto- module prefix in template
This adds the module loading prefix crypto- to the template lookup
as well.
For example, attempting to load 'vfat(blowfish)' via AF_ALG now correctly
includes the crypto- prefix at every level, correctly rejecting vfat:
net-pf-38
algif-hash
crypto-vfat(blowfish)
crypto-vfat(blowfish)-all
crypto-vfat
Reported-by: Mathias Krause mini...@googlemail.com
Signed-off-by: Kees Cook keesc...@chromium.org
---
crypto/algapi.c | 4 ++--
crypto/authenc.c| 1 +
crypto/authencesn.c | 1 +
crypto/cbc.c| 1 +
crypto/chainiv.c| 1 +
crypto/cmac.c | 1 +
crypto/cts.c| 1 +
crypto/ecb.c| 1 +
crypto/eseqiv.c | 1 +
crypto/hmac.c | 1 +
crypto/lrw.c| 1 +
crypto/pcbc.c | 1 +
crypto/seqiv.c | 1 +
crypto/vmac.c | 1 +
crypto/xcbc.c | 1 +
crypto/xts.c| 1 +
16 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/crypto/algapi.c b/crypto/algapi.c
index e8d3a7dca8c4..71a8143e23b1 100644
--- a/crypto/algapi.c
+++ b/crypto/algapi.c
@@ -509,8 +509,8 @@ static struct crypto_template
*__crypto_lookup_template(const char *name)
struct crypto_template *crypto_lookup_template(const char *name)
{
- return try_then_request_module(__crypto_lookup_template(name), %s,
- name);
+ return try_then_request_module(__crypto_lookup_template(name),
+ crypto-%s, name);
}
EXPORT_SYMBOL_GPL(crypto_lookup_template);
diff --git a/crypto/authenc.c b/crypto/authenc.c
index e1223559d5df..78fb16cab13f 100644
--- a/crypto/authenc.c
+++ b/crypto/authenc.c
@@ -721,3 +721,4 @@ module_exit(crypto_authenc_module_exit);
MODULE_LICENSE(GPL);
MODULE_DESCRIPTION(Simple AEAD wrapper for IPsec);
+MODULE_ALIAS_CRYPTO(authenc);
diff --git a/crypto/authencesn.c b/crypto/authencesn.c
index 4be0dd4373a9..024bff2344fc 100644
--- a/crypto/authencesn.c
+++ b/crypto/authencesn.c
@@ -814,3 +814,4 @@ module_exit(crypto_authenc_esn_module_exit);
MODULE_LICENSE(GPL);
MODULE_AUTHOR(Steffen Klassert steffen.klass...@secunet.com);
MODULE_DESCRIPTION(AEAD wrapper for IPsec with extended sequence numbers);
+MODULE_ALIAS_CRYPTO(authencesn);
diff --git a/crypto/cbc.c b/crypto/cbc.c
index 61ac42e1e32b..780ee27b2d43 100644
--- a/crypto/cbc.c
+++ b/crypto/cbc.c
@@ -289,3 +289,4 @@ module_exit(crypto_cbc_module_exit);
MODULE_LICENSE(GPL);
MODULE_DESCRIPTION(CBC block cipher algorithm);
+MODULE_ALIAS_CRYPTO(cbc);
diff --git a/crypto/chainiv.c b/crypto/chainiv.c
index 9c294c8f9a07..63c17d5992f7 100644
--- a/crypto/chainiv.c
+++ b/crypto/chainiv.c
@@ -359,3 +359,4 @@ module_exit(chainiv_module_exit);
MODULE_LICENSE(GPL);
MODULE_DESCRIPTION(Chain IV Generator);
+MODULE_ALIAS_CRYPTO(chainiv);
diff --git a/crypto/cmac.c b/crypto/cmac.c
index 50880cf17fad..7a8bfbd548f6 100644
--- a/crypto/cmac.c
+++ b/crypto/cmac.c
@@ -313,3 +313,4 @@ module_exit(crypto_cmac_module_exit);
MODULE_LICENSE(GPL);
MODULE_DESCRIPTION(CMAC keyed hash algorithm);
+MODULE_ALIAS_CRYPTO(cmac);
diff --git a/crypto/cts.c b/crypto/cts.c
index 133f0874c95e..bd9405820e8a 100644
--- a/crypto/cts.c
+++ b/crypto/cts.c
@@ -351,3 +351,4 @@ module_exit(crypto_cts_module_exit);
MODULE_LICENSE(Dual BSD/GPL);
MODULE_DESCRIPTION(CTS-CBC CipherText Stealing for CBC);
+MODULE_ALIAS_CRYPTO(cts);
diff --git a/crypto/ecb.c b/crypto/ecb.c
index 935cfef4aa84..12011aff0971 100644
--- a/crypto/ecb.c
+++ b/crypto/ecb.c
@@ -185,3 +185,4 @@ module_exit(crypto_ecb_module_exit);
MODULE_LICENSE(GPL);
MODULE_DESCRIPTION(ECB block cipher algorithm);
+MODULE_ALIAS_CRYPTO(ecb);
diff --git a/crypto/eseqiv.c b/crypto/eseqiv.c
index bf7ab4a89493..f116fae766f8 100644
--- a/crypto/eseqiv.c
+++ b/crypto/eseqiv.c
@@ -267,3 +267,4 @@ module_exit(eseqiv_module_exit);
MODULE_LICENSE(GPL);
MODULE_DESCRIPTION(Encrypted Sequence Number IV Generator);
+MODULE_ALIAS_CRYPTO(eseqiv);
diff --git a/crypto/hmac.c b/crypto/hmac.c
index e392219ddc61..72e38c098bb3 100644
--- a/crypto/hmac.c
+++ b/crypto/hmac.c
@@ -268,3 +268,4 @@ module_exit(hmac_module_exit);
MODULE_LICENSE(GPL);
MODULE_DESCRIPTION(HMAC hash algorithm);
+MODULE_ALIAS_CRYPTO(hmac);
diff --git a/crypto/lrw.c b/crypto/lrw.c
index ba42acc4deba..6f9908a7ebcb 100644
--- a/crypto/lrw.c
+++ b/crypto/lrw.c
@@ -400,3 +400,4 @@ module_exit(crypto_module_exit);
MODULE_LICENSE(GPL);
MODULE_DESCRIPTION(LRW block cipher mode);
+MODULE_ALIAS_CRYPTO(lrw);
diff --git a/crypto/pcbc.c b/crypto/pcbc.c
index d1b8bdfb5855..f654965f0933 100644
--- a/crypto/pcbc.c
+++ b/crypto/pcbc.c
@@ -295,3 +295,4 @@ module_exit(crypto_pcbc_module_exit);
MODULE_LICENSE(GPL);
MODULE_DESCRIPTION(PCBC block cipher algorithm);
+MODULE_ALIAS_CRYPTO(pcbc);
diff --git a/crypto/seqiv.c b/crypto/seqiv.c
index ee190fcedcd2..9daa854cc485 100644
--- a/crypto/seqiv.c
+++ b/crypto/seqiv.c
@@ -362,3 +362,4 @@ module_exit(seqiv_module_exit);
MODULE_LICENSE(GPL);
[PATCH v3] crypto: include crypto- module prefix in template
This adds the module loading prefix crypto- to the template lookup
as well.
For example, attempting to load 'vfat(blowfish)' via AF_ALG now correctly
includes the crypto- prefix at every level, correctly rejecting vfat:
net-pf-38
algif-hash
crypto-vfat(blowfish)
crypto-vfat(blowfish)-all
crypto-vfat
Reported-by: Mathias Krause mini...@googlemail.com
Signed-off-by: Kees Cook keesc...@chromium.org
Acked-by: Mathias Krause mini...@googlemail.com
---
v3:
- added a few more missing aliases, minipli
v2:
- added missing aliases, minipli
---
arch/x86/crypto/fpu.c | 3 +++
crypto/algapi.c | 4 ++--
crypto/authenc.c | 1 +
crypto/authencesn.c | 1 +
crypto/cbc.c | 1 +
crypto/ccm.c | 1 +
crypto/chainiv.c | 1 +
crypto/cmac.c | 1 +
crypto/cryptd.c | 1 +
crypto/ctr.c | 1 +
crypto/cts.c | 1 +
crypto/ecb.c | 1 +
crypto/eseqiv.c | 1 +
crypto/gcm.c | 1 +
crypto/hmac.c | 1 +
crypto/lrw.c | 1 +
crypto/mcryptd.c | 1 +
crypto/pcbc.c | 1 +
crypto/pcrypt.c | 1 +
crypto/seqiv.c| 1 +
crypto/vmac.c | 1 +
crypto/xcbc.c | 1 +
crypto/xts.c | 1 +
23 files changed, 26 insertions(+), 2 deletions(-)
diff --git a/arch/x86/crypto/fpu.c b/arch/x86/crypto/fpu.c
index 98d7a188f46b..f368ba261739 100644
--- a/arch/x86/crypto/fpu.c
+++ b/arch/x86/crypto/fpu.c
@@ -17,6 +17,7 @@
#include linux/kernel.h
#include linux/module.h
#include linux/slab.h
+#include linux/crypto.h
#include asm/i387.h
struct crypto_fpu_ctx {
@@ -159,3 +160,5 @@ void __exit crypto_fpu_exit(void)
{
crypto_unregister_template(crypto_fpu_tmpl);
}
+
+MODULE_ALIAS_CRYPTO(fpu);
diff --git a/crypto/algapi.c b/crypto/algapi.c
index e8d3a7dca8c4..71a8143e23b1 100644
--- a/crypto/algapi.c
+++ b/crypto/algapi.c
@@ -509,8 +509,8 @@ static struct crypto_template
*__crypto_lookup_template(const char *name)
struct crypto_template *crypto_lookup_template(const char *name)
{
- return try_then_request_module(__crypto_lookup_template(name), %s,
- name);
+ return try_then_request_module(__crypto_lookup_template(name),
+ crypto-%s, name);
}
EXPORT_SYMBOL_GPL(crypto_lookup_template);
diff --git a/crypto/authenc.c b/crypto/authenc.c
index e1223559d5df..78fb16cab13f 100644
--- a/crypto/authenc.c
+++ b/crypto/authenc.c
@@ -721,3 +721,4 @@ module_exit(crypto_authenc_module_exit);
MODULE_LICENSE(GPL);
MODULE_DESCRIPTION(Simple AEAD wrapper for IPsec);
+MODULE_ALIAS_CRYPTO(authenc);
diff --git a/crypto/authencesn.c b/crypto/authencesn.c
index 4be0dd4373a9..024bff2344fc 100644
--- a/crypto/authencesn.c
+++ b/crypto/authencesn.c
@@ -814,3 +814,4 @@ module_exit(crypto_authenc_esn_module_exit);
MODULE_LICENSE(GPL);
MODULE_AUTHOR(Steffen Klassert steffen.klass...@secunet.com);
MODULE_DESCRIPTION(AEAD wrapper for IPsec with extended sequence numbers);
+MODULE_ALIAS_CRYPTO(authencesn);
diff --git a/crypto/cbc.c b/crypto/cbc.c
index 61ac42e1e32b..780ee27b2d43 100644
--- a/crypto/cbc.c
+++ b/crypto/cbc.c
@@ -289,3 +289,4 @@ module_exit(crypto_cbc_module_exit);
MODULE_LICENSE(GPL);
MODULE_DESCRIPTION(CBC block cipher algorithm);
+MODULE_ALIAS_CRYPTO(cbc);
diff --git a/crypto/ccm.c b/crypto/ccm.c
index 647575b41281..003bbbd21a2b 100644
--- a/crypto/ccm.c
+++ b/crypto/ccm.c
@@ -881,3 +881,4 @@ MODULE_LICENSE(GPL);
MODULE_DESCRIPTION(Counter with CBC MAC);
MODULE_ALIAS_CRYPTO(ccm_base);
MODULE_ALIAS_CRYPTO(rfc4309);
+MODULE_ALIAS_CRYPTO(ccm);
diff --git a/crypto/chainiv.c b/crypto/chainiv.c
index 9c294c8f9a07..63c17d5992f7 100644
--- a/crypto/chainiv.c
+++ b/crypto/chainiv.c
@@ -359,3 +359,4 @@ module_exit(chainiv_module_exit);
MODULE_LICENSE(GPL);
MODULE_DESCRIPTION(Chain IV Generator);
+MODULE_ALIAS_CRYPTO(chainiv);
diff --git a/crypto/cmac.c b/crypto/cmac.c
index 50880cf17fad..7a8bfbd548f6 100644
--- a/crypto/cmac.c
+++ b/crypto/cmac.c
@@ -313,3 +313,4 @@ module_exit(crypto_cmac_module_exit);
MODULE_LICENSE(GPL);
MODULE_DESCRIPTION(CMAC keyed hash algorithm);
+MODULE_ALIAS_CRYPTO(cmac);
diff --git a/crypto/cryptd.c b/crypto/cryptd.c
index e592c90abebb..650afac10fd7 100644
--- a/crypto/cryptd.c
+++ b/crypto/cryptd.c
@@ -955,3 +955,4 @@ module_exit(cryptd_exit);
MODULE_LICENSE(GPL);
MODULE_DESCRIPTION(Software async crypto daemon);
+MODULE_ALIAS_CRYPTO(cryptd);
diff --git a/crypto/ctr.c b/crypto/ctr.c
index 3d81ff7e6b48..2386f7313952 100644
--- a/crypto/ctr.c
+++ b/crypto/ctr.c
@@ -467,3 +467,4 @@ module_exit(crypto_ctr_module_exit);
MODULE_LICENSE(GPL);
MODULE_DESCRIPTION(CTR Counter block mode);
MODULE_ALIAS_CRYPTO(rfc3686);
+MODULE_ALIAS_CRYPTO(ctr);
diff --git a/crypto/cts.c b/crypto/cts.c
index 133f0874c95e..bd9405820e8a 100644
--- a/crypto/cts.c
+++ b/crypto/cts.c
@@ -351,3 +351,4 @@ module_exit(crypto_cts_module_exit);
MODULE_LICENSE(Dual
