Re: [PATCH] crypto: ccp - Fix AES XTS error for request sizes above 4096
On Fri, May 20, 2016 at 05:33:03PM -0500, Tom Lendacky wrote: > The ccp-crypto module for AES XTS support has a bug that can allow requests > greater than 4096 bytes in size to be passed to the CCP hardware. The CCP > hardware does not support request sizes larger than 4096, resulting in > incorrect output. The request should actually be handled by the fallback > mechanism instantiated by the ccp-crypto module. > > Add a check to insure the request size is less than or equal to the maximum > supported size and use the fallback mechanism if it is not. > > Cc: # 3.14.x- > Signed-off-by: Tom Lendacky I'm OK with this patch but I think it doesn't always need to go into the fallback. I made a test vector split as 4064 bytes + 48 bytes and ccp handled it just fine. It appears that the bug is actually in the handling of a single SG entry that's longer than a page, presumably because sg_next is used unconditionally instead of checking whether there is more in the current SG entry. But I'll merge your fix as it fixes a real problem. Thanks, -- Email: Herbert Xu 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: IV generation in cryptographic driver in AEAD
On Fri, May 20, 2016 at 10:50:38AM -0500, Gary R Hook wrote: > > Why is (or should) setting geniv (be) required? > > crypto_givcipher_default() appears to call crypto_default_geniv() if > the geniv member > is NULL. That function returns "eseqiv" or "chainiv" (under certain > conditions). If an > implementation isn't generating its own IVs, shouldn't the default > happen anyway? Or is > this more a matter of populating the structure with known, > intentional values? > > Thank you for any illumination provided. In the upstream kernel AEAD geniv has been completely phased out and no longer exists. Denis is working on an old kernel that still has it. We haven't yet phased it out for skcipher but I'm working on it. Cheers, -- Email: Herbert Xu 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
[PATCH] crypto: ccp - Fix AES XTS error for request sizes above 4096
The ccp-crypto module for AES XTS support has a bug that can allow requests
greater than 4096 bytes in size to be passed to the CCP hardware. The CCP
hardware does not support request sizes larger than 4096, resulting in
incorrect output. The request should actually be handled by the fallback
mechanism instantiated by the ccp-crypto module.
Add a check to insure the request size is less than or equal to the maximum
supported size and use the fallback mechanism if it is not.
Cc: # 3.14.x-
Signed-off-by: Tom Lendacky
---
drivers/crypto/ccp/ccp-crypto-aes-xts.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/crypto/ccp/ccp-crypto-aes-xts.c
b/drivers/crypto/ccp/ccp-crypto-aes-xts.c
index 52c7395..0d0d452 100644
--- a/drivers/crypto/ccp/ccp-crypto-aes-xts.c
+++ b/drivers/crypto/ccp/ccp-crypto-aes-xts.c
@@ -122,6 +122,7 @@ static int ccp_aes_xts_crypt(struct ablkcipher_request *req,
struct ccp_ctx *ctx = crypto_tfm_ctx(req->base.tfm);
struct ccp_aes_req_ctx *rctx = ablkcipher_request_ctx(req);
unsigned int unit;
+ u32 unit_size;
int ret;
if (!ctx->u.aes.key_len)
@@ -133,11 +134,17 @@ static int ccp_aes_xts_crypt(struct ablkcipher_request
*req,
if (!req->info)
return -EINVAL;
- for (unit = 0; unit < ARRAY_SIZE(unit_size_map); unit++)
- if (!(req->nbytes & (unit_size_map[unit].size - 1)))
- break;
+ unit_size = CCP_XTS_AES_UNIT_SIZE__LAST;
+ if (req->nbytes <= unit_size_map[0].size) {
+ for (unit = 0; unit < ARRAY_SIZE(unit_size_map); unit++) {
+ if (!(req->nbytes & (unit_size_map[unit].size - 1))) {
+ unit_size = unit_size_map[unit].value;
+ break;
+ }
+ }
+ }
- if ((unit_size_map[unit].value == CCP_XTS_AES_UNIT_SIZE__LAST) ||
+ if ((unit_size == CCP_XTS_AES_UNIT_SIZE__LAST) ||
(ctx->u.aes.key_len != AES_KEYSIZE_128)) {
/* Use the fallback to process the request for any
* unsupported unit sizes or key sizes
@@ -158,7 +165,7 @@ static int ccp_aes_xts_crypt(struct ablkcipher_request *req,
rctx->cmd.engine = CCP_ENGINE_XTS_AES_128;
rctx->cmd.u.xts.action = (encrypt) ? CCP_AES_ACTION_ENCRYPT
: CCP_AES_ACTION_DECRYPT;
- rctx->cmd.u.xts.unit_size = unit_size_map[unit].value;
+ rctx->cmd.u.xts.unit_size = unit_size;
rctx->cmd.u.xts.key = &ctx->u.aes.key_sg;
rctx->cmd.u.xts.key_len = ctx->u.aes.key_len;
rctx->cmd.u.xts.iv = &rctx->iv_sg;
--
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: IV generation in cryptographic driver in AEAD
On 05/19/2016 11:19 PM, Herbert Xu wrote:
Denis B wrote:
My algs struct now looks like this:
static struct crypto_alg pp_crypto_algs[] = {
{
.cra_name = "authenc(hmac(sha256),cbc(aes))",
.cra_driver_name = "pp_crypto_cbc_hmac_sha256",
.cra_priority = 1, /**TODO set to highest values after
implementing encrypt decrypt functions */
.cra_flags = CRYPTO_ALG_TYPE_AEAD | CRYPTO_ALG_ASYNC,
.cra_blocksize = AES_BLOCK_SIZE,
.cra_ctxsize = sizeof(struct pp_crypto_aead_ctx),
.cra_type = &crypto_nivaead_type,
.cra_u = {
.aead = {
.setkey = pp_crypto_aead_setkey,
.setauthsize = pp_crypto_aead_setauthsize,
.decrypt = pp_crypto_aead_dec,
.encrypt = pp_crypto_aead_enc,
.givencrypt = NULL,
.givdecrypt = NULL,
.ivsize = AES_BLOCK_SIZE,
.maxauthsize = SHA256_DIGEST_SIZE,
You also need to set geniv to "eseqiv".
I just gotta ask. Forgive my ignorance.
Why is (or should) setting geniv (be) required?
crypto_givcipher_default() appears to call crypto_default_geniv() if the
geniv member
is NULL. That function returns "eseqiv" or "chainiv" (under certain
conditions). If an
implementation isn't generating its own IVs, shouldn't the default
happen anyway? Or is
this more a matter of populating the structure with known, intentional
values?
Thank you for any illumination provided.
Gary
--
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: HWCAP_CRYPTO define for ARMv8?
On 5/15/2016 1:13 PM, Jeffrey Walton wrote: > Hi Everyone, > > It appears defines like HWCAP_CRC32 fall under the purview of the > kernel. Confer, http://www.google.com/search?q="HWCAP_CRC32"; (my > apologies if this is not the case). > > We use getauxval(AT_HWCAP) and HWCAP_CRC32 for runtime detection of > processor support for CRC. However, I can't find a similar symbol in > the context of the crypto instructions. Confer, > http://www.google.com/search?q="HWCAP_CRYPTO";. > > My question is, what are the equivalent defines for Crypto features? > Take a look at arch/arm64/include/uapi/asm/hwcap.h #define HWCAP_AES (1 << 3) #define HWCAP_PMULL (1 << 4) #define HWCAP_SHA1 (1 << 5) #define HWCAP_SHA2 (1 << 6) Horia > Thanks in advance. > > * > > Below is from a 64-bit LeMaker HiKey > (http://www.lemaker.org/product-hikey-index.html). It responds to > getauxval(AT_HWCAP) and HWCAP_CRC32. > > $ cat /proc/cpuinfo > Processor: AArch64 Processor rev 3 (aarch64) > processor: 0 > ... > processor: 7 > Features: fp asimd evtstrm aes pmull sha1 sha2 crc32 > CPU implementer: 0x41 > CPU architecture: AArch64 > CPU variant: 0x0 > CPU part: 0xd03 > CPU revision: 3 > > Hardware: HiKey Development Board -- 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
Crypto Fixes for 4.7
Hi Linus: This push fixes a regression that causes sha-mb to crash. Please pull from git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git linus Josh Poimboeuf (1): crypto: sha1-mb - make sha1_x8_avx2() conform to C function ABI arch/x86/crypto/sha-mb/sha1_x8_avx2.S | 13 +++-- 1 file changed, 11 insertions(+), 2 deletions(-) Thanks, -- Email: Herbert Xu 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
