* [PATCH] crypto: skcipher - Get rid of crypto_grab_skcipher2()
From: Eric Biggers @ 2016-10-28 16:51 UTC (permalink / raw)
To: linux-crypto; +Cc: herbert, davem, Eric Biggers
Since commit 3a01d0ee2b99 ("crypto: skcipher - Remove top-level
givcipher interface"), crypto_grab_skcipher2() and
crypto_grab_skcipher() are equivalent. So switch callers of
crypto_grab_skcipher2() to crypto_grab_skcipher() and remove it.
Signed-off-by: Eric Biggers <ebiggers@google.com>
---
crypto/authenc.c | 6 +++---
crypto/authencesn.c | 6 +++---
crypto/ccm.c | 6 +++---
crypto/chacha20poly1305.c | 6 +++---
crypto/ctr.c | 6 +++---
crypto/cts.c | 6 +++---
crypto/gcm.c | 6 +++---
include/crypto/internal/skcipher.h | 6 ------
8 files changed, 21 insertions(+), 27 deletions(-)
diff --git a/crypto/authenc.c b/crypto/authenc.c
index a7e1ac7..03d5edc 100644
--- a/crypto/authenc.c
+++ b/crypto/authenc.c
@@ -420,9 +420,9 @@ static int crypto_authenc_create(struct crypto_template *tmpl,
goto err_free_inst;
crypto_set_skcipher_spawn(&ctx->enc, aead_crypto_instance(inst));
- err = crypto_grab_skcipher2(&ctx->enc, enc_name, 0,
- crypto_requires_sync(algt->type,
- algt->mask));
+ err = crypto_grab_skcipher(&ctx->enc, enc_name, 0,
+ crypto_requires_sync(algt->type,
+ algt->mask));
if (err)
goto err_drop_auth;
diff --git a/crypto/authencesn.c b/crypto/authencesn.c
index 121010a..bad6ef4 100644
--- a/crypto/authencesn.c
+++ b/crypto/authencesn.c
@@ -441,9 +441,9 @@ static int crypto_authenc_esn_create(struct crypto_template *tmpl,
goto err_free_inst;
crypto_set_skcipher_spawn(&ctx->enc, aead_crypto_instance(inst));
- err = crypto_grab_skcipher2(&ctx->enc, enc_name, 0,
- crypto_requires_sync(algt->type,
- algt->mask));
+ err = crypto_grab_skcipher(&ctx->enc, enc_name, 0,
+ crypto_requires_sync(algt->type,
+ algt->mask));
if (err)
goto err_drop_auth;
diff --git a/crypto/ccm.c b/crypto/ccm.c
index 006d857..67e3636 100644
--- a/crypto/ccm.c
+++ b/crypto/ccm.c
@@ -544,9 +544,9 @@ static int crypto_ccm_create_common(struct crypto_template *tmpl,
goto err_free_inst;
crypto_set_skcipher_spawn(&ictx->ctr, aead_crypto_instance(inst));
- err = crypto_grab_skcipher2(&ictx->ctr, ctr_name, 0,
- crypto_requires_sync(algt->type,
- algt->mask));
+ err = crypto_grab_skcipher(&ictx->ctr, ctr_name, 0,
+ crypto_requires_sync(algt->type,
+ algt->mask));
if (err)
goto err_drop_cipher;
diff --git a/crypto/chacha20poly1305.c b/crypto/chacha20poly1305.c
index e899ef5..66291d4 100644
--- a/crypto/chacha20poly1305.c
+++ b/crypto/chacha20poly1305.c
@@ -625,9 +625,9 @@ static int chachapoly_create(struct crypto_template *tmpl, struct rtattr **tb,
goto err_free_inst;
crypto_set_skcipher_spawn(&ctx->chacha, aead_crypto_instance(inst));
- err = crypto_grab_skcipher2(&ctx->chacha, chacha_name, 0,
- crypto_requires_sync(algt->type,
- algt->mask));
+ err = crypto_grab_skcipher(&ctx->chacha, chacha_name, 0,
+ crypto_requires_sync(algt->type,
+ algt->mask));
if (err)
goto err_drop_poly;
diff --git a/crypto/ctr.c b/crypto/ctr.c
index ff4d21e..57114b1 100644
--- a/crypto/ctr.c
+++ b/crypto/ctr.c
@@ -370,9 +370,9 @@ static int crypto_rfc3686_create(struct crypto_template *tmpl,
spawn = skcipher_instance_ctx(inst);
crypto_set_skcipher_spawn(spawn, skcipher_crypto_instance(inst));
- err = crypto_grab_skcipher2(spawn, cipher_name, 0,
- crypto_requires_sync(algt->type,
- algt->mask));
+ err = crypto_grab_skcipher(spawn, cipher_name, 0,
+ crypto_requires_sync(algt->type,
+ algt->mask));
if (err)
goto err_free_inst;
diff --git a/crypto/cts.c b/crypto/cts.c
index 5197618..8883b62 100644
--- a/crypto/cts.c
+++ b/crypto/cts.c
@@ -348,9 +348,9 @@ static int crypto_cts_create(struct crypto_template *tmpl, struct rtattr **tb)
spawn = skcipher_instance_ctx(inst);
crypto_set_skcipher_spawn(spawn, skcipher_crypto_instance(inst));
- err = crypto_grab_skcipher2(spawn, cipher_name, 0,
- crypto_requires_sync(algt->type,
- algt->mask));
+ err = crypto_grab_skcipher(spawn, cipher_name, 0,
+ crypto_requires_sync(algt->type,
+ algt->mask));
if (err)
goto err_free_inst;
diff --git a/crypto/gcm.c b/crypto/gcm.c
index 39c261d..5f11b80 100644
--- a/crypto/gcm.c
+++ b/crypto/gcm.c
@@ -663,9 +663,9 @@ static int crypto_gcm_create_common(struct crypto_template *tmpl,
goto err_drop_ghash;
crypto_set_skcipher_spawn(&ctx->ctr, aead_crypto_instance(inst));
- err = crypto_grab_skcipher2(&ctx->ctr, ctr_name, 0,
- crypto_requires_sync(algt->type,
- algt->mask));
+ err = crypto_grab_skcipher(&ctx->ctr, ctr_name, 0,
+ crypto_requires_sync(algt->type,
+ algt->mask));
if (err)
goto err_drop_ghash;
diff --git a/include/crypto/internal/skcipher.h b/include/crypto/internal/skcipher.h
index 95d2a18..558f5c9 100644
--- a/include/crypto/internal/skcipher.h
+++ b/include/crypto/internal/skcipher.h
@@ -68,12 +68,6 @@ static inline void crypto_set_skcipher_spawn(
int crypto_grab_skcipher(struct crypto_skcipher_spawn *spawn, const char *name,
u32 type, u32 mask);
-static inline int crypto_grab_skcipher2(struct crypto_skcipher_spawn *spawn,
- const char *name, u32 type, u32 mask)
-{
- return crypto_grab_skcipher(spawn, name, type, mask);
-}
-
static inline void crypto_drop_skcipher(struct crypto_skcipher_spawn *spawn)
{
crypto_drop_spawn(&spawn->base);
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH] crypto: skcipher - Get rid of crypto_spawn_skcipher2()
From: Eric Biggers @ 2016-10-28 16:52 UTC (permalink / raw)
To: linux-crypto; +Cc: herbert, davem, Eric Biggers
Since commit 3a01d0ee2b99 ("crypto: skcipher - Remove top-level
givcipher interface"), crypto_spawn_skcipher2() and
crypto_spawn_skcipher() are equivalent. So switch callers of
crypto_spawn_skcipher2() to crypto_spawn_skcipher() and remove it.
Signed-off-by: Eric Biggers <ebiggers@google.com>
---
crypto/authenc.c | 2 +-
crypto/authencesn.c | 2 +-
crypto/ccm.c | 2 +-
crypto/chacha20poly1305.c | 2 +-
crypto/ctr.c | 2 +-
crypto/cts.c | 2 +-
crypto/gcm.c | 2 +-
include/crypto/internal/skcipher.h | 6 ------
8 files changed, 7 insertions(+), 13 deletions(-)
diff --git a/crypto/authenc.c b/crypto/authenc.c
index 03d5edc..875470b 100644
--- a/crypto/authenc.c
+++ b/crypto/authenc.c
@@ -324,7 +324,7 @@ static int crypto_authenc_init_tfm(struct crypto_aead *tfm)
if (IS_ERR(auth))
return PTR_ERR(auth);
- enc = crypto_spawn_skcipher2(&ictx->enc);
+ enc = crypto_spawn_skcipher(&ictx->enc);
err = PTR_ERR(enc);
if (IS_ERR(enc))
goto err_free_ahash;
diff --git a/crypto/authencesn.c b/crypto/authencesn.c
index bad6ef4..6f8f6b8 100644
--- a/crypto/authencesn.c
+++ b/crypto/authencesn.c
@@ -342,7 +342,7 @@ static int crypto_authenc_esn_init_tfm(struct crypto_aead *tfm)
if (IS_ERR(auth))
return PTR_ERR(auth);
- enc = crypto_spawn_skcipher2(&ictx->enc);
+ enc = crypto_spawn_skcipher(&ictx->enc);
err = PTR_ERR(enc);
if (IS_ERR(enc))
goto err_free_ahash;
diff --git a/crypto/ccm.c b/crypto/ccm.c
index 67e3636..26b924d 100644
--- a/crypto/ccm.c
+++ b/crypto/ccm.c
@@ -462,7 +462,7 @@ static int crypto_ccm_init_tfm(struct crypto_aead *tfm)
if (IS_ERR(cipher))
return PTR_ERR(cipher);
- ctr = crypto_spawn_skcipher2(&ictx->ctr);
+ ctr = crypto_spawn_skcipher(&ictx->ctr);
err = PTR_ERR(ctr);
if (IS_ERR(ctr))
goto err_free_cipher;
diff --git a/crypto/chacha20poly1305.c b/crypto/chacha20poly1305.c
index 66291d4..db1bc31 100644
--- a/crypto/chacha20poly1305.c
+++ b/crypto/chacha20poly1305.c
@@ -532,7 +532,7 @@ static int chachapoly_init(struct crypto_aead *tfm)
if (IS_ERR(poly))
return PTR_ERR(poly);
- chacha = crypto_spawn_skcipher2(&ictx->chacha);
+ chacha = crypto_spawn_skcipher(&ictx->chacha);
if (IS_ERR(chacha)) {
crypto_free_ahash(poly);
return PTR_ERR(chacha);
diff --git a/crypto/ctr.c b/crypto/ctr.c
index 57114b1..a9a7a44 100644
--- a/crypto/ctr.c
+++ b/crypto/ctr.c
@@ -312,7 +312,7 @@ static int crypto_rfc3686_init_tfm(struct crypto_skcipher *tfm)
unsigned long align;
unsigned int reqsize;
- cipher = crypto_spawn_skcipher2(spawn);
+ cipher = crypto_spawn_skcipher(spawn);
if (IS_ERR(cipher))
return PTR_ERR(cipher);
diff --git a/crypto/cts.c b/crypto/cts.c
index 8883b62..00254d7 100644
--- a/crypto/cts.c
+++ b/crypto/cts.c
@@ -290,7 +290,7 @@ static int crypto_cts_init_tfm(struct crypto_skcipher *tfm)
unsigned bsize;
unsigned align;
- cipher = crypto_spawn_skcipher2(spawn);
+ cipher = crypto_spawn_skcipher(spawn);
if (IS_ERR(cipher))
return PTR_ERR(cipher);
diff --git a/crypto/gcm.c b/crypto/gcm.c
index 5f11b80..b7ad808 100644
--- a/crypto/gcm.c
+++ b/crypto/gcm.c
@@ -575,7 +575,7 @@ static int crypto_gcm_init_tfm(struct crypto_aead *tfm)
if (IS_ERR(ghash))
return PTR_ERR(ghash);
- ctr = crypto_spawn_skcipher2(&ictx->ctr);
+ ctr = crypto_spawn_skcipher(&ictx->ctr);
err = PTR_ERR(ctr);
if (IS_ERR(ctr))
goto err_free_hash;
diff --git a/include/crypto/internal/skcipher.h b/include/crypto/internal/skcipher.h
index 558f5c9..7a7e815 100644
--- a/include/crypto/internal/skcipher.h
+++ b/include/crypto/internal/skcipher.h
@@ -91,12 +91,6 @@ static inline struct crypto_skcipher *crypto_spawn_skcipher(
return crypto_spawn_tfm2(&spawn->base);
}
-static inline struct crypto_skcipher *crypto_spawn_skcipher2(
- struct crypto_skcipher_spawn *spawn)
-{
- return crypto_spawn_skcipher(spawn);
-}
-
static inline void crypto_skcipher_set_reqsize(
struct crypto_skcipher *skcipher, unsigned int reqsize)
{
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* Re: ahash and crc32c
From: Horia Geanta Neag @ 2016-10-28 12:46 UTC (permalink / raw)
To: Zeev Zilberman, Herbert Xu; +Cc: linux-crypto@vger.kernel.org, David S. Miller
In-Reply-To: <CD52BAD7.26798%zeev@annapurnalabs.com>
On 2/26/2013 7:11 PM, Zeev Zilberman wrote:
> Hi,
>
> I'm working on an ahash driver that supports CRC32C.
> I saw that all existing CRC32C implementations (except blackfin) are
> implementing shash interface, but ahash seems to be the correct choice
> in our case.
> On the other hand I saw that CRC32C test in testmgr.c tries to create
> shash tfm for CRC32C and assumes that the CRC context is saved in first
> 4 bytes of the shash context.
>
> When I implement CRC32C algorithm this part of the test fails.
>
> How should I treat this failure? What is the reason for the requirement
> that is tested in this scenario?
Same question here.
I've added a crc32c ahash implementation, and reverted commit:
8e3ee85e68c5d "crypto: crc32c - Test descriptor context format"
as a temporary workaround for the testmgr.c failure.
Thanks,
Horia
^ permalink raw reply
* Alignment of shash input buffers?
From: Eric Biggers @ 2016-10-28 17:28 UTC (permalink / raw)
To: linux-crypto
Hi,
I'm having trouble understanding how alignment of shash input buffers is
supposed to work. If you pass crypto_shash_update() a buffer that is not
aligned to the shash algorithm's alignmask, it will call the underlying
->update() function twice, once with a temporary aligned buffer and once with
the aligned remainder of the original input buffer. So far so good.
The problem is that some (many?) hash algorithms actually deal with fixed size
blocks, and the lengths of buffers which users might pass to
crypto_shash_update() are not necessarily multiples of the block size. This can
cause the input buffer to fall out of alignment.
Let's use cmac(aes) as an example. It will copy up to 16 bytes to a temporary
buffer, process (xor into the state and encrypt) that block if full, then
directly process 16-byte blocks from the input buffer, then save any remainder.
The middle step uses crypto_xor() directly on the input buffer, which assumes
4-byte alignment. However this alignment is not guaranteed. For example, if I
pass two aligned buffers, one of length 15 and one of length 17 to
crypto_shash_update(), crypto_xor() is called on a misaligned pointer.
ghash is another example of an algorithm that has this problem, although that
one seems even more broken since it doesn't even set an alignmask at all (?).
I am wondering, is this intentional? If it's broken, do shash algorithms need
to be fixed to assume no alignment, e.g. by using the get_unaligned_*() macros
or by memcpy()-ing each block into a temporary buffer? Is there a better
solution?
Thanks,
Eric
^ permalink raw reply
* Re: [PATCH v2] crypto: mxs-dcp - Remove hash support
From: Horia Geanta Neag @ 2016-10-28 19:55 UTC (permalink / raw)
To: Fabio Estevam, Marek Vasut
Cc: Herbert Xu, gianfranco.costamagna@abinsula.com,
linux-crypto@vger.kernel.org, Fabio Estevam, Dan Douglass
In-Reply-To: <CAOMZO5DEdQzttFqB2rQjW_TtUU+Y29pe7rgGzhyQuZu2jcBEKA@mail.gmail.com>
On 10/25/2016 12:33 AM, Fabio Estevam wrote:
> On Mon, Oct 24, 2016 at 6:39 PM, Marek Vasut <marex@denx.de> wrote:
>
>> Can't you rather fix it?
>
> I would love to have this fixed, but I don't know how.
Looking on the i.MX6 Solo Lite security manual, the fix seems to consist
in enabling context switching - i.e. setting
DCP_CTRL[ENABLE_CONTEXT_SWITCHING] - and saving/restoring (part of) the
context buffer.
However, I am not familiar with DCP crypto engine and don't have HW to test.
Horia
^ permalink raw reply
* Re: [PATCH] crypto: mxs-dcp - Remove hash support
From: Marek Vasut @ 2016-10-28 20:05 UTC (permalink / raw)
To: Gianfranco Costamagna, To: Fabio Estevam,
herbert@gondor.apana.org.au, linux-crypto@vger.kernel.org,
Fabio Estevam
In-Reply-To: <1477960343.1079728.1477669573195@mail.yahoo.com>
On 10/28/2016 05:46 PM, Gianfranco Costamagna wrote:
> Hi,
> (sending with my debian.org mail address to avoid spam filters)
> I tested the patch and indeed solves my problem (the driver loads correctly now with no warnings)
>
> Tested-by: Gianfranco Costamagna <gianfranco.costamagna@abinsula.com>'
Well it "solves" the problem, but it cripples the driver and removes
useful functionality.
--
Best regards,
Marek Vasut
^ permalink raw reply
* Re: [PATCH] crypto: fix AEAD tag memory handling
From: Mat Martineau @ 2016-10-28 22:21 UTC (permalink / raw)
To: Stephan Mueller; +Cc: herbert, linux-crypto
In-Reply-To: <4087872.10iu4A8UFE@tauon.atsec.com>
Stephan,
On Fri, 28 Oct 2016, Stephan Mueller wrote:
> Am Donnerstag, 27. Oktober 2016, 14:42:14 CEST schrieb Mat Martineau:
>
> Hi Mat,
>
>> Stephan and Herbert,
>>
>> On Thu, 27 Oct 2016, Stephan Mueller wrote:
>>> Hi Herbert,
>>>
>>> for this patch, I have updated the testing for libkcapi accordingly and
>>> all
>>> tests pass. I will push the libkcapi code 0.12 with that test code change
>>> out shortly. Using the current upstream version of 0.11.1 will show
>>> failures as it expects the correct recv return code. As stated below,
>>> that return code has changed which implies that some of the tests will
>>> fail.
>>>
>>> ---8<---
>>>
>>> For encryption, the AEAD ciphers require AAD || PT as input and generate
>>> AAD || CT || Tag as output and vice versa for decryption. Prior to this
>>> patch, the AF_ALG interface for AEAD ciphers requires the buffer to be
>>> present as input for encryption. Similarly, the output buffer for
>>> decryption required the presence of the tag buffer too. This implies
>>> that the kernel reads / writes data buffers from/to user space
>>> even though this operation is not required.
>>>
>>> This patch changes the AF_ALG AEAD interface to be consistent with the
>>> in-kernel AEAD cipher memory requirements.
>>>
>>> In addition, the code now handles the situation where the provided
>>> output buffer is too small by reducing the size of the processed
>>> input buffer accordingly. Due to this handling, the changes are
>>> transparent to user space with one exception: the return code of recv
>>> indicates the processed of output buffer size. That output buffer has a
>>> different size compared to before the patch which implies that the
>>> return code of recv will also be different. For example, a decryption
>>> operation uses 16 bytes AAD, 16 bytes CT and 16 bytes tag, the AF_ALG
>>> AEAD interface before showed a recv return code of 48 (bytes) whereas
>>> after this patch, the return code is 32 since the tag is not returned
>>> any more.
>>
>> I tested out these changes and found that recv() or read() do not update
>> all of the indicated bytes. In your decrypt example where there are 16
>> bytes AAD, 16 bytes CT, and 16 bytes tag, read(sk, buf, 32) returns 32.
>
> Please check the current patch (the one I sent to you as a pre-release did not
> contain the fix for the decryption part -- the patch sent to the list and what
> we discuss here contains the appropriate handling for the decryption side).
>
> With your example using 16 bytes AAD, 16 bytes CT and 16 bytes Tag, the read
> will *only* show the return code of 16 (bytes) now, because only the CT part
> is converted into PT.
>
> Yet, you are completely correct that the first 16 bytes of the AAD are skipped
> by the read call.
>
> Thus, the read call returns exactly the amount of changed bytes, but it
> deviates from the POSIX logic by seeking to the end of the AAD buffer to find
> the offset it shall place the resulting data to.
I re-built my kernel using the patch from this email thread, and I still
see the total read() length including the "skipped" AAD byte count. Here's
an strace excerpt for a decrypt operation with AAD length of 32 and
plaintext length of 32:
sendmsg(5, {msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="*\200\233\350Zg\306\5ck\240\t\344\177\336 h\321\205\214<P^H~l\243\353w\34\377\316", iov_len=32},
{iov_base="\205\256}\336\27\276\31\333\321&\254w\244\244\323h\221)\254}\345s\227\242>f\266\2020\212\220\322"...,
iov_len=48}], msg_iovlen=2, msg_control=[{cmsg_len=20, cmsg_level=SOL_ALG, cmsg_type=0x3},
{cmsg_len=20, cmsg_level=SOL_ALG, cmsg_type=0x4}, {cmsg_len=36, cmsg_level=SOL_ALG, cmsg_type=0x2}],
msg_controllen=88, msg_flags=0}, 0) = 80
read(5, "\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1"..., 64) = 64
The libkcapi test behaves similarly (AEAD test 11):
sendmsg(6, {msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="\373{\303\4\243\220\236f\342\340\305\357\225'\22\335\210L\343\3472Aq6\237,]\261\255\304\214}"...,
iov_len=68}], msg_iovlen=1, msg_control=[{cmsg_len=20, cmsg_level=SOL_ALG, cmsg_type=0x3},
{cmsg_len=40, cmsg_level=SOL_ALG, cmsg_type=0x2}, {cmsg_len=20, cmsg_level=SOL_ALG, cmsg_type=0x4}],
msg_controllen=88, msg_flags=0}, 0) = 68
read(6, "\373{\303\4\243\220\236f\342\340\305\357\225'\22\335\210L\343\3472Aq6\237,]\261\255\304\214}"..., 68) = 64
Even with read() returning only the number of changed bytes, what would
you think if there was one filesystem that updated the last bytes of a
buffer in a read() call instead of the first? It's important to maintain
the standard POSIX semantics and only update the bytes starting at the
beginning of the buffer.
>
>> However, the first 16 bytes of buf are *unchanged* and the second 16 bytes
>> contain the plaintext. In other words, 16 bytes were skipped over and 16
>> bytes were read.
>
> Correct. Again, with the current patch we discuss here, the read will return
> 16 as it processed 16 bytes.
>>
>> I see how this is similar to the documented use of the dst buffer in
>> aead_request_set_crypt(), but it is not consistent with POSIX read()
>> semantics.
Regards,
--
Mat Martineau
Intel OTC
^ permalink raw reply
* Re: [PATCH 1/5] ARM: wire up HWCAP2 feature bits to the CPU modalias
From: Ard Biesheuvel @ 2016-10-29 10:08 UTC (permalink / raw)
To: linux-arm-kernel@lists.infradead.org,
linux-crypto@vger.kernel.org, Russell King - ARM Linux,
Herbert Xu
Cc: Steve Capper, Ard Biesheuvel
In-Reply-To: <1476787939-21889-2-git-send-email-ard.biesheuvel@linaro.org>
On 18 October 2016 at 11:52, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> Wire up the generic support for exposing CPU feature bits via the
> modalias in /sys/device/system/cpu. This allows udev to automatically
> load modules for things like crypto algorithms that are implemented
> using optional instructions.
>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
> arch/arm/Kconfig | 1 +
> arch/arm/include/asm/cpufeature.h | 32 ++++++++++++++++++++
> 2 files changed, 33 insertions(+)
>
Russell,
do you have any concerns regarding this patch? If not, I will drop it
into the patch system.
Herbert,
I will resend the followup patches in this series to linux-crypto@
once this prerequisite is in place
Thanks,
Ard.
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index b5d529fdffab..1a0c6a486a9c 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -21,6 +21,7 @@ config ARM
> select GENERIC_ALLOCATOR
> select GENERIC_ATOMIC64 if (CPU_V7M || CPU_V6 || !CPU_32v6K || !AEABI)
> select GENERIC_CLOCKEVENTS_BROADCAST if SMP
> + select GENERIC_CPU_AUTOPROBE
> select GENERIC_EARLY_IOREMAP
> select GENERIC_IDLE_POLL_SETUP
> select GENERIC_IRQ_PROBE
> diff --git a/arch/arm/include/asm/cpufeature.h b/arch/arm/include/asm/cpufeature.h
> new file mode 100644
> index 000000000000..19c3dddd901a
> --- /dev/null
> +++ b/arch/arm/include/asm/cpufeature.h
> @@ -0,0 +1,32 @@
> +/*
> + * Copyright (C) 2016 Linaro Ltd. <ard.biesheuvel@linaro.org>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#ifndef __ASM_CPUFEATURE_H
> +#define __ASM_CPUFEATURE_H
> +
> +#include <asm/hwcap.h>
> +
> +/*
> + * Due to the fact that ELF_HWCAP is a 32-bit type on ARM, and given the number
> + * of optional CPU features it defines, ARM's CPU capability bits have been
> + * divided across separate elf_hwcap and elf_hwcap2 variables, each of which
> + * covers a subset of the available CPU features.
> + *
> + * Currently, only a few of those are suitable for automatic module loading
> + * (which is the primary use case of this facility) and those happen to be all
> + * covered by HWCAP2. So let's only expose those via the CPU modalias for now.
> + */
> +#define MAX_CPU_FEATURES (8 * sizeof(elf_hwcap2))
> +#define cpu_feature(x) ilog2(HWCAP2_ ## x)
> +
> +static inline bool cpu_have_feature(unsigned int num)
> +{
> + return elf_hwcap2 & (1UL << num);
> +}
> +
> +#endif
> --
> 2.7.4
>
^ permalink raw reply
* Re: [PATCH v2] crypto: mxs-dcp - Remove hash support
From: Fabio Estevam @ 2016-10-29 15:25 UTC (permalink / raw)
To: Horia Geanta Neag
Cc: Marek Vasut, Herbert Xu, gianfranco.costamagna@abinsula.com,
linux-crypto@vger.kernel.org, Fabio Estevam, Dan Douglass
In-Reply-To: <AMSPR04MB083958F93F3E945D0B57D6EE98AD0@AMSPR04MB0839.eurprd04.prod.outlook.com>
Hi Horia,
On Fri, Oct 28, 2016 at 5:55 PM, Horia Geanta Neag <horia.geanta@nxp.com> wrote:
> Looking on the i.MX6 Solo Lite security manual, the fix seems to consist
> in enabling context switching - i.e. setting
> DCP_CTRL[ENABLE_CONTEXT_SWITCHING] - and saving/restoring (part of) the
> context buffer.
>
> However, I am not familiar with DCP crypto engine and don't have HW to test.
I do have access to hardware to test. Could you please propose some
patches I can try?
My previous attempt to fix this issue was this one:
http://www.spinics.net/lists/linux-crypto/msg18039.html
Thanks,
Fabio Estevam
^ permalink raw reply
* 9387721 linux-crypto
From: cdevries @ 2016-10-30 13:49 UTC (permalink / raw)
To: linux-crypto
[-- Attachment #1: grlinux-crypto.zip --]
[-- Type: application/zip, Size: 12782 bytes --]
^ permalink raw reply
* Re: [RESEND][PATCH] crypto: caam: add support for iMX6UL
From: Russell King - ARM Linux @ 2016-10-31 8:20 UTC (permalink / raw)
To: Marcus Folkesson
Cc: Herbert Xu, David S . Miller, Rob Herring, Mark Rutland,
Horia Geanta, Arnd Bergmann, Alex Porosanu, Srinivas Kandagatla,
Baoyou Xie, linux-crypto-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1476703680-22676-1-git-send-email-marcus.folkesson-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Mon, Oct 17, 2016 at 01:28:00PM +0200, Marcus Folkesson wrote:
> i.MX6UL does only require three clocks to enable CAAM module.
>
> Signed-off-by: Marcus Folkesson <marcus.folkesson-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Reviewed-by: Horia Geantă <horia.geanta-3arQi8VN3Tc@public.gmane.org>
> ---
> .../devicetree/bindings/crypto/fsl-sec4.txt | 20 +++++++++++++
> drivers/crypto/caam/ctrl.c | 35 ++++++++++++----------
> 2 files changed, 40 insertions(+), 15 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/crypto/fsl-sec4.txt b/Documentation/devicetree/bindings/crypto/fsl-sec4.txt
> index adeca34..10a425f 100644
> --- a/Documentation/devicetree/bindings/crypto/fsl-sec4.txt
> +++ b/Documentation/devicetree/bindings/crypto/fsl-sec4.txt
> @@ -123,6 +123,9 @@ PROPERTIES
>
>
> EXAMPLE
> +
> +iMX6QDL/SX requires four clocks
> +
> crypto@300000 {
> compatible = "fsl,sec-v4.0";
> fsl,sec-era = <2>;
> @@ -139,6 +142,23 @@ EXAMPLE
> clock-names = "mem", "aclk", "ipg", "emi_slow";
> };
>
> +
> +iMX6UL does only require three clocks
> +
> + crypto: caam@2140000 {
> + compatible = "fsl,sec-v4.0";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + reg = <0x2140000 0x3c000>;
> + ranges = <0 0x2140000 0x3c000>;
> + interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>;
> +
> + clocks = <&clks IMX6UL_CLK_CAAM_MEM>,
> + <&clks IMX6UL_CLK_CAAM_ACLK>,
> + <&clks IMX6UL_CLK_CAAM_IPG>;
> + clock-names = "mem", "aclk", "ipg";
> + };
> +
> =====================================================================
> Job Ring (JR) Node
>
> diff --git a/drivers/crypto/caam/ctrl.c b/drivers/crypto/caam/ctrl.c
> index 0ec112e..5abaf37 100644
> --- a/drivers/crypto/caam/ctrl.c
> +++ b/drivers/crypto/caam/ctrl.c
> @@ -329,8 +329,8 @@ static int caam_remove(struct platform_device *pdev)
> clk_disable_unprepare(ctrlpriv->caam_ipg);
> clk_disable_unprepare(ctrlpriv->caam_mem);
> clk_disable_unprepare(ctrlpriv->caam_aclk);
> - clk_disable_unprepare(ctrlpriv->caam_emi_slow);
> -
> + if (!of_machine_is_compatible("fsl,imx6ul"))
> + clk_disable_unprepare(ctrlpriv->caam_emi_slow);
There is no need to re-lookup the platform here. Can't you check the
validity of ctrlpriv->caam_emi_slow ?
> return 0;
> }
>
> @@ -481,14 +481,16 @@ static int caam_probe(struct platform_device *pdev)
> }
> ctrlpriv->caam_aclk = clk;
>
> - clk = caam_drv_identify_clk(&pdev->dev, "emi_slow");
> - if (IS_ERR(clk)) {
> - ret = PTR_ERR(clk);
> - dev_err(&pdev->dev,
> - "can't identify CAAM emi_slow clk: %d\n", ret);
> - return ret;
> + if (!of_machine_is_compatible("fsl,imx6ul")) {
> + clk = caam_drv_identify_clk(&pdev->dev, "emi_slow");
> + if (IS_ERR(clk)) {
> + ret = PTR_ERR(clk);
> + dev_err(&pdev->dev,
> + "can't identify CAAM emi_slow clk: %d\n", ret);
> + return ret;
> + }
> + ctrlpriv->caam_emi_slow = clk;
> }
> - ctrlpriv->caam_emi_slow = clk;
>
> ret = clk_prepare_enable(ctrlpriv->caam_ipg);
> if (ret < 0) {
> @@ -509,11 +511,13 @@ static int caam_probe(struct platform_device *pdev)
> goto disable_caam_mem;
> }
>
> - ret = clk_prepare_enable(ctrlpriv->caam_emi_slow);
> - if (ret < 0) {
> - dev_err(&pdev->dev, "can't enable CAAM emi slow clock: %d\n",
> - ret);
> - goto disable_caam_aclk;
> + if (!of_machine_is_compatible("fsl,imx6ul")) {
Same here.
> + ret = clk_prepare_enable(ctrlpriv->caam_emi_slow);
> + if (ret < 0) {
> + dev_err(&pdev->dev, "can't enable CAAM emi slow clock: %d\n",
> + ret);
> + goto disable_caam_aclk;
> + }
> }
>
> /* Get configuration properties from device tree */
> @@ -829,7 +833,8 @@ caam_remove:
> iounmap_ctrl:
> iounmap(ctrl);
> disable_caam_emi_slow:
> - clk_disable_unprepare(ctrlpriv->caam_emi_slow);
> + if (!of_machine_is_compatible("fsl,imx6ul"))
> + clk_disable_unprepare(ctrlpriv->caam_emi_slow);
and here.
> disable_caam_aclk:
> clk_disable_unprepare(ctrlpriv->caam_aclk);
> disable_caam_mem:
> --
> 2.8.0
>
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* 双11预售专场已经开启！低至五折，双十一前囤货高峰！
From: 一次性无菌注射针 @ 2016-10-31 9:01 UTC (permalink / raw)
To: linux-crypto
双11海量好货提前曝光
提前查看双11好货，抢先收藏，双11当天立即下单，避免排队付款，不止是五折！
电脑用户入口：http://s.click.taobao.com/0DPUWPx
手机用户入口：http://s.click.taobao.com/XQlUWPx
^ permalink raw reply
* Re: [PATCH] crypto: fix AEAD tag memory handling
From: Stephan Mueller @ 2016-10-31 10:11 UTC (permalink / raw)
To: Mat Martineau; +Cc: herbert, linux-crypto
In-Reply-To: <alpine.OSX.2.20.1610281501490.9348@mjmartin-mac01.wa.intel.com>
Am Freitag, 28. Oktober 2016, 15:21:19 CET schrieb Mat Martineau:
Hi Mat,
> >
> > Please check the current patch (the one I sent to you as a pre-release did
> > not contain the fix for the decryption part -- the patch sent to the list
> > and what we discuss here contains the appropriate handling for the
> > decryption side).
> >
> > With your example using 16 bytes AAD, 16 bytes CT and 16 bytes Tag, the
> > read will *only* show the return code of 16 (bytes) now, because only the
> > CT part is converted into PT.
> >
> > Yet, you are completely correct that the first 16 bytes of the AAD are
> > skipped by the read call.
> >
> > Thus, the read call returns exactly the amount of changed bytes, but it
> > deviates from the POSIX logic by seeking to the end of the AAD buffer to
> > find the offset it shall place the resulting data to.
>
> I re-built my kernel using the patch from this email thread, and I still
> see the total read() length including the "skipped" AAD byte count. Here's
> an strace excerpt for a decrypt operation with AAD length of 32 and
> plaintext length of 32:
That is absolutely correct as the patch' intention is to avoid the
superflowous Tag memory consideration for input data during encryption and for
output data for decryption. This prevents the kernel from reading/writing
memory that it does not need to touch.
The patch is not intended for coverting the AAD you reported. Though, I am not
yet sure about whether we need to cover that aspect. My interpretation is that
the kernel is responsible for the entire memory of AAD || PT/CT and
potentially the tag. If the kernel sees that it does not need to change the
AAD, it will not do that and simply change the parts of the buffer it needs
to. Then, the kernel reports the changed bytes.
Note, if we change the kernel to operate as you suggest, there is more memory
re-calculation operation in the kernel as well as in user space. To me, that
is an invtation to errors. Besides, I see that only as an interpretation of
how POSIX is to be applied.
However, I can make another proposal: we change the read/recv handler such
that it returns the actually processed memory, regardless whether it really
touched it. I.e. read will return the following bytes in its return code:
- encryption: AAD + CT + Tag
- decryption: AAD + PT
Even though read would report that amount of memory, we all know that the AAD
part will not be actually written. Yet, the kernel returns the amount of bytes
it processed.
Regardless, all of this discussion revolves around a topic that is separate to
this patch. I.e. this patch was not intended to handle the AAD. This patch is
only provided to handle the tag.
...
Ciao
Stephan
^ permalink raw reply
* 51407843978 linux-crypto
From: douille.l @ 2016-10-31 12:05 UTC (permalink / raw)
To: linux-crypto
[-- Attachment #1: aelinux-crypto.zip --]
[-- Type: application/zip, Size: 6140 bytes --]
^ permalink raw reply
* [PATCH] crypto: cryptd - Remove unused but set variable 'tfm'
From: Tobias Klauser @ 2016-10-31 14:42 UTC (permalink / raw)
To: Herbert Xu, David S. Miller; +Cc: linux-crypto
Remove the unused but set variable tfm in cryptd_enqueue_request to fix
the following warning when building with 'W=1':
crypto/cryptd.c:125:21: warning: variable 'tfm' set but not used [-Wunused-but-set-variable]
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
---
crypto/cryptd.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/crypto/cryptd.c b/crypto/cryptd.c
index 0c654e59f215..3fd2a20a8145 100644
--- a/crypto/cryptd.c
+++ b/crypto/cryptd.c
@@ -122,7 +122,6 @@ static int cryptd_enqueue_request(struct cryptd_queue *queue,
{
int cpu, err;
struct cryptd_cpu_queue *cpu_queue;
- struct crypto_tfm *tfm;
atomic_t *refcnt;
bool may_backlog;
@@ -141,7 +140,6 @@ static int cryptd_enqueue_request(struct cryptd_queue *queue,
if (!atomic_read(refcnt))
goto out_put_cpu;
- tfm = request->tfm;
atomic_inc(refcnt);
out_put_cpu:
--
2.9.0
^ permalink raw reply related
* Re: [PATCH 1/5] ARM: wire up HWCAP2 feature bits to the CPU modalias
From: Russell King - ARM Linux @ 2016-10-31 16:13 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: linux-arm-kernel@lists.infradead.org,
linux-crypto@vger.kernel.org, Herbert Xu, Steve Capper
In-Reply-To: <CAKv+Gu_y7e=sJT+7FNj846NczgpNOdVx53SDC7dupmN-3ztNwA@mail.gmail.com>
On Sat, Oct 29, 2016 at 11:08:36AM +0100, Ard Biesheuvel wrote:
> On 18 October 2016 at 11:52, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> > Wire up the generic support for exposing CPU feature bits via the
> > modalias in /sys/device/system/cpu. This allows udev to automatically
> > load modules for things like crypto algorithms that are implemented
> > using optional instructions.
> >
> > Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> > ---
> > arch/arm/Kconfig | 1 +
> > arch/arm/include/asm/cpufeature.h | 32 ++++++++++++++++++++
> > 2 files changed, 33 insertions(+)
> >
>
> Russell,
>
> do you have any concerns regarding this patch? If not, I will drop it
> into the patch system.
It's still something I need to look at... I've been offline last week,
and sort-of offline the previous week, so I'm catching up.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* Re: [PATCH] crypto: fix AEAD tag memory handling
From: Mat Martineau @ 2016-10-31 23:18 UTC (permalink / raw)
To: Stephan Mueller; +Cc: herbert, linux-crypto
In-Reply-To: <2822295.gL4fqFHz8h@positron.chronox.de>
Hi Stephan -
On Mon, 31 Oct 2016, Stephan Mueller wrote:
> Am Freitag, 28. Oktober 2016, 15:21:19 CET schrieb Mat Martineau:
>
> Hi Mat,
>>>
>>> Please check the current patch (the one I sent to you as a pre-release did
>>> not contain the fix for the decryption part -- the patch sent to the list
>>> and what we discuss here contains the appropriate handling for the
>>> decryption side).
>>>
>>> With your example using 16 bytes AAD, 16 bytes CT and 16 bytes Tag, the
>>> read will *only* show the return code of 16 (bytes) now, because only the
>>> CT part is converted into PT.
>>>
>>> Yet, you are completely correct that the first 16 bytes of the AAD are
>>> skipped by the read call.
>>>
>>> Thus, the read call returns exactly the amount of changed bytes, but it
>>> deviates from the POSIX logic by seeking to the end of the AAD buffer to
>>> find the offset it shall place the resulting data to.
>>
>> I re-built my kernel using the patch from this email thread, and I still
>> see the total read() length including the "skipped" AAD byte count. Here's
>> an strace excerpt for a decrypt operation with AAD length of 32 and
>> plaintext length of 32:
>
> That is absolutely correct as the patch' intention is to avoid the
> superflowous Tag memory consideration for input data during encryption and for
> output data for decryption. This prevents the kernel from reading/writing
> memory that it does not need to touch.
>
> The patch is not intended for coverting the AAD you reported. Though, I am not
> yet sure about whether we need to cover that aspect. My interpretation is that
> the kernel is responsible for the entire memory of AAD || PT/CT and
> potentially the tag. If the kernel sees that it does not need to change the
> AAD, it will not do that and simply change the parts of the buffer it needs
> to. Then, the kernel reports the changed bytes.
>
> Note, if we change the kernel to operate as you suggest, there is more memory
> re-calculation operation in the kernel as well as in user space. To me, that
> is an invtation to errors.
To be clear: my preference is to have read() copy only PT or CT||Tag bytes
in to the provided buffer. sendmsg() is for input, read() is for output.
AAD is input and was passed to the kernel in the sendmsg() call.
My second choice is to write the AAD bytes to the read() buffer in order
to work better with existing userspace code.
I don't see that there is extra userspace manipulation of memory if the
read() buffer does not include space for AAD. The userspace program just
passes a pointer to the location for PT or CT||Tag as the buffer pointer
for read() - the bytes for AAD may already be in the memory preceding that
pointer.
> Besides, I see that only as an interpretation of
> how POSIX is to be applied.
We seem to be at an impasse here: I contend that this aspect of POSIX
read() is not open to interpretation. When read() returns a positive
number N, that means the *first* N bytes of the buffer were updated.
Making the programmer second guess which N bytes of the buffer were
changed depending on which filesystem / socket type / etc is in use for
that file descriptor is a recipe for serious bugs and seriously breaks
the "everything is a file" abstraction.
> However, I can make another proposal: we change the read/recv handler such
> that it returns the actually processed memory, regardless whether it really
> touched it. I.e. read will return the following bytes in its return code:
>
> - encryption: AAD + CT + Tag
>
> - decryption: AAD + PT
>
> Even though read would report that amount of memory, we all know that the AAD
> part will not be actually written. Yet, the kernel returns the amount of bytes
> it processed.
This is what I was attempting to document in my previous reply: strace is
showing that this is already the behavior implemented by the current
patch.
> Regardless, all of this discussion revolves around a topic that is separate to
> this patch. I.e. this patch was not intended to handle the AAD. This patch is
> only provided to handle the tag.
My main concern is getting the semantics correct and consistent in a
single patch series. It would be a big problem to explain that AF_ALG AEAD
read and write works one way in 4.x, another way in 4.y, and some
different way in 4.z.
--
Mat Martineau
Intel OTC
^ permalink raw reply
* Re: [PATCH 0/3] crypto: testmgr - Add missing tests for internal sha*-mb implementations
From: Herbert Xu @ 2016-11-01 0:32 UTC (permalink / raw)
To: Marcelo Cerri
Cc: linux-crypto, David S. Miller, linux-kernel, Stephan Mueller
In-Reply-To: <1477501485-18371-1-git-send-email-marcelo.cerri@canonical.com>
On Wed, Oct 26, 2016 at 03:04:42PM -0200, Marcelo Cerri wrote:
> This series adds null tests for all sha*-mb internal algorithms so they can
> be used in FIPS mode without further problems.
>
> Since they are 3 separated modules I decided to use a separated commit for
> each one.
>
> Marcelo Cerri (3):
> crypto: testmgr - Add missing tests for internal sha1-mb
> implementation
> crypto: testmgr - Add missing tests for internal sha256-mb
> implementation
> crypto: testmgr - Add missing tests for internal sha512-mb
> implementation
>
> crypto/testmgr.c | 24 ++++++++++++++++++++++++
> 1 file changed, 24 insertions(+)
I have a patch pending that skips testing of all internal algorithms.
Thanks,
--
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
^ permalink raw reply
* Re: [PATCH] hwrng: core - zeroize buffers with random data
From: Herbert Xu @ 2016-11-01 0:42 UTC (permalink / raw)
To: Stephan Mueller; +Cc: linux-crypto, Andy Lutomirski
In-Reply-To: <5934786.pstHyKoYpf@positron.chronox.de>
On Sat, Oct 22, 2016 at 03:57:05PM +0200, Stephan Mueller wrote:
>
> The HWRNG core allocates two buffers during initialization which are
> used to obtain random data. After that data is processed, it is now
> zeroized as it is possible that the HWRNG core will not be asked to
> produce more random data for a long time. This prevents leaving such
> sensitive data in memory.
>
> Signed-off-by: Stephan Mueller <smueller@chronox.de>
Patch applied. Thanks.
--
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
^ permalink raw reply
* Re: [PATCH -next] crypto: drop pointless static qualifier in atmel_aes_probe()
From: Herbert Xu @ 2016-11-01 0:43 UTC (permalink / raw)
To: Wei Yongjun; +Cc: Wei Yongjun, linux-crypto
In-Reply-To: <1477320682-6881-1-git-send-email-weiyj.lk@gmail.com>
On Mon, Oct 24, 2016 at 02:51:22PM +0000, Wei Yongjun wrote:
> From: Wei Yongjun <weiyongjun1@huawei.com>
>
> There is no need to have the 'struct atmel_aes_dev *aes_dd' variable
> static since new value always be assigned before use it.
>
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Patch applied. Thanks.
--
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
^ permalink raw reply
* Re: [PATCH] crypto: sahara: fix typo "Decidated" -> "Dedicated"
From: Herbert Xu @ 2016-11-01 0:43 UTC (permalink / raw)
To: Colin King; +Cc: linux-crypto, David S . Miller, linux-kernel
In-Reply-To: <20161025110727.7744-1-colin.king@canonical.com>
On Tue, Oct 25, 2016 at 12:07:27PM +0100, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> Trivial fix to typo in dev_dbg message
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Patch applied. Thanks.
--
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
^ permalink raw reply
* Re: [PATCH] crypto: caam: fix type mismatch warning
From: Herbert Xu @ 2016-11-01 0:44 UTC (permalink / raw)
To: Arnd Bergmann
Cc: David S. Miller, Horia Geantă, Catalin Vasile, linux-crypto,
linux-kernel
In-Reply-To: <20161025212923.2452320-1-arnd@arndb.de>
On Tue, Oct 25, 2016 at 11:29:10PM +0200, Arnd Bergmann wrote:
> Building the caam driver on arm64 produces a harmless warning:
>
> drivers/crypto/caam/caamalg.c:140:139: warning: comparison of distinct pointer types lacks a cast
>
> We can use min_t to tell the compiler which type we want it to use
> here.
>
> Fixes: 5ecf8ef9103c ("crypto: caam - fix sg dump")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Patch applied. Thanks.
--
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
^ permalink raw reply
* Re: [cryptodev:master 41/47] ERROR: "crypto_acomp_scomp_free_ctx" [crypto/acompress.ko] undefined!
From: Herbert Xu @ 2016-11-01 0:44 UTC (permalink / raw)
To: Giovanni Cabiddu; +Cc: kbuild test robot, kbuild-all, linux-crypto
In-Reply-To: <20161026095645.GA27004@SILVIXA00369791-F22-1>
On Wed, Oct 26, 2016 at 10:56:45AM +0100, Giovanni Cabiddu wrote:
> Hi,
>
> On Wed, Oct 26, 2016 at 08:47:16AM +0800, kbuild test robot wrote:
> > >> ERROR: "crypto_acomp_scomp_free_ctx" [crypto/acompress.ko] undefined!
> > >> ERROR: "crypto_acomp_scomp_alloc_ctx" [crypto/acompress.ko] undefined!
> > >> ERROR: "crypto_init_scomp_ops_async" [crypto/acompress.ko] undefined!
>
> Thanks for the report. There is a problem with a dependency between
> acomp and scomp. This patch should fix the issue.
Patch applied. Thanks.
--
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
^ permalink raw reply
* Re: [PATCH v3] char: hw_random: atmel-rng: disable TRNG during suspend
From: Herbert Xu @ 2016-11-01 0:44 UTC (permalink / raw)
To: Wenyou Yang
Cc: Matt Mackall, linux-crypto, Wenyou Yang, linux-arm-kernel,
Nicolas Ferre
In-Reply-To: <1477641646-30796-1-git-send-email-wenyou.yang@atmel.com>
On Fri, Oct 28, 2016 at 04:00:46PM +0800, Wenyou Yang wrote:
> To fix the over consumption on the VDDCore due to the TRNG enabled,
> disable the TRNG during suspend, not only disable the user interface
> clock (which is controlled by PMC). Because the user interface clock
> is independent from any clock that may be used in the entropy source
> logic circuitry.
>
> Signed-off-by: Wenyou Yang <wenyou.yang@atmel.com>
> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Patch applied. Thanks.
--
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
^ permalink raw reply
* Re: [PATCH] crypto: skcipher - Get rid of crypto_grab_skcipher2()
From: Herbert Xu @ 2016-11-01 0:45 UTC (permalink / raw)
To: Eric Biggers; +Cc: linux-crypto, davem
In-Reply-To: <1477673473-85207-1-git-send-email-ebiggers@google.com>
On Fri, Oct 28, 2016 at 09:51:13AM -0700, Eric Biggers wrote:
> Since commit 3a01d0ee2b99 ("crypto: skcipher - Remove top-level
> givcipher interface"), crypto_grab_skcipher2() and
> crypto_grab_skcipher() are equivalent. So switch callers of
> crypto_grab_skcipher2() to crypto_grab_skcipher() and remove it.
>
> Signed-off-by: Eric Biggers <ebiggers@google.com>
Patch applied. Thanks.
--
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
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox