Re: AF_ALG broken?

2016-08-08 Thread Herbert Xu 
Russell King - ARM Linux  wrote:
> Testing that code on 4.8-rc (and 4.7 fwiw) gives:
> 
> socket(PF_ALG, SOCK_SEQPACKET, 0)   = 3
> bind(3, {sa_family=AF_ALG, sa_data="hash\0\0\0\0\0\0\0\0\0\0"}, 88) = 0
> accept(3, 0, NULL)  = 4
> write(4, "abc", 3)  = -1 ENOKEY (Required key not 
> available)
> read(4, 0xbec50508, 20) = -1 ENOKEY (Required key not 
> available)
> 
> IOW, the same problem - and it seems not to be a recent regression.
> 
> Since the last time I tested CESA or CAAM was back in 4.4 times,
> it's got to be something between 4.4 and 4.7.
> 
> Looking at the history, my guess would be the setkey changes -
> crypto: algif_skcipher - Require setkey before accept(2)
> crypto: af_alg - Disallow bind/setkey/... after accept(2)
> crypto: af_alg - Add nokey compatibility path
> crypto: hash - Add crypto_ahash_has_setkey
> crypto: algif_hash - Require setkey before accept(2)

This is definitely supposed to work.  Basically if the algorithm
requires a key (e.g., HMAC) then you must set it.  Otherwise it
should never return ENOKEY.

Which algorithm were you testing and what does /proc/crypto say?

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: AF_ALG broken?

2016-08-08 Thread David Miller 
From: Russell King - ARM Linux 
Date: Mon, 8 Aug 2016 23:58:51 +0100

> I don't know, but this seems to go completely against Linus' no
> userspace regressions, which seems to be an absolute requirement of
> all kernel development... Linus flames people for arguing against
> that rule!

Reading the explanation for the change given to you, it's impossible
for some hash algorithms to function properly without being given the
key first, and would crash.

Therefore the requirement is reasonable, even though it is unfortunate
that a critical piece of userspace infrastructure was coded this way.
--
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: powerpc - CRYPT_CRC32C_VPMSUM should depend on ALTIVEC

2016-08-08 Thread Michael Ellerman 
The optimised crc32c implementation depends on VMX (aka. Altivec)
instructions, so the kernel must be built with Altivec support in order
for the crc32c code to build.

Fixes: 6dd7a82cc54e ("crypto: powerpc - Add POWER8 optimised crc32c")
Acked-by: Anton Blanchard 
Signed-off-by: Michael Ellerman 
---
 crypto/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

v2: No change. Send to linux-crypto.

diff --git a/crypto/Kconfig b/crypto/Kconfig
index a9377bef25e3..84d71482bf08 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -439,7 +439,7 @@ config CRYPTO_CRC32C_INTEL
 
 config CRYPT_CRC32C_VPMSUM
tristate "CRC32c CRC algorithm (powerpc64)"
-   depends on PPC64
+   depends on PPC64 && ALTIVEC
select CRYPTO_HASH
select CRC32
help
-- 
2.7.4

--
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] RANDOM: ATH9K RNG delivers zero bits of entropy

2016-08-08 Thread Jason Cooper 
Hi Stephan,

On Mon, Aug 08, 2016 at 05:29:30PM +, Jason Cooper wrote:
> On Mon, Aug 08, 2016 at 08:41:36AM +0200, Stephan Mueller wrote:
...
> > If you think that this patch is a challenge because your driver starts to 
> > spin, please help and offer another solution.
> 
> Well, I don't buy the reasoning listed above for not using the hwrng
> framework.  Interrupt timings were never designed to be a source of entropy
> either.  We need to grab it where ever we can find it, especially on
> embedded systems.  Documentation/hw_random.txt even says:
> 
> """
> This data is NOT CHECKED by any fitness tests, and could potentially be
> bogus (if the hardware is faulty or has been tampered with).
> """
> 
> I really don't think there's a problem with adding these sorts of
> sources under char/hw_random/.  I think the only thing we would be
> concerned about, other than the already addressed entropy estimation,
> would be constraining the data rate.

Further research yields char/hw_random/timeriomem-rng.c

It could use an update to ->read() vice data_{present,read}(), but it's
functionally exactly what the ath9k rng is doing. :)

thx,

Jason.
--
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: AF_ALG broken?

2016-08-08 Thread Stephan Mueller 
Am Montag, 8. August 2016, 20:18:32 CEST schrieb Stephan Mueller:

Hi Stephan,

> Am Montag, 8. August 2016, 17:44:27 CEST schrieb Russell King - ARM Linux:
> 
> Hi Russell,
> 
> > Hi,
> > 
> > When trying to use the openssl AF_ALG module with 4.8-rc1 with imx
> > caam, I get this:
> > 
> > $ OPENSSL_CONF=/shared/crypto/openssl-imx.cnf strace openssl dgst -md5
> >  > socket(PF_ALG, SOCK_SEQPACKET, 0)   = 3
> > close(3)= 0
> > socket(PF_ALG, SOCK_SEQPACKET, 0)   = 3
> > bind(3, {sa_family=AF_ALG, sa_data="hash\0\0\0\0\0\0\0\0\0\0"}, 88) = 0
> > accept(3, 0, NULL)  = 4
> > fstat64(0, {st_mode=S_IFREG|0755, st_size=666864, ...}) = 0
> > mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
> > =
> > 0xb6fab000 read(0,
> > "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0(\0\1\0\0\0\21'\2\0004\0\0\0"...,
> > 8192)
> > = 8192 send(4,
> > "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0(\0\1\0\0\0\21'\2\0004\0\0\0"...,
> > 8192,
> > MSG_MORE) = -1 ENOKEY (Required key not available)
> > 
> > This used to work, so something in the kernel AF_ALG API has changed
> > which has broken userspace.  Any ideas what's up, or where to look?
> 
> This seems to be the the change added by Herbert to fix a security issue.
> This caused a similar stirr in the cryptsetup user space tool.
> 
> I guess you are affected by 6de62f15b581f920ade22d758f4c338311c2f0d4

Just to be clear: the settings on the tfmfd must be completed before an 
accept(). If make an operation on the tfmfd after the accept call, you get 
the ENOKEY.

This was my change to the issue:

https://github.com/smuellerDD/libkcapi/commit/
1d6c3b1b540caea784a95b1ca6e2cf38c174f585

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

Re: AF_ALG broken?

2016-08-08 Thread Stephan Mueller 
Am Montag, 8. August 2016, 17:44:27 CEST schrieb Russell King - ARM Linux:

Hi Russell,

> Hi,
> 
> When trying to use the openssl AF_ALG module with 4.8-rc1 with imx
> caam, I get this:
> 
> $ OPENSSL_CONF=/shared/crypto/openssl-imx.cnf strace openssl dgst -md5
>  socket(PF_ALG, SOCK_SEQPACKET, 0)   = 3
> close(3)= 0
> socket(PF_ALG, SOCK_SEQPACKET, 0)   = 3
> bind(3, {sa_family=AF_ALG, sa_data="hash\0\0\0\0\0\0\0\0\0\0"}, 88) = 0
> accept(3, 0, NULL)  = 4
> fstat64(0, {st_mode=S_IFREG|0755, st_size=666864, ...}) = 0
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
> 0xb6fab000 read(0,
> "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0(\0\1\0\0\0\21'\2\0004\0\0\0"..., 8192)
> = 8192 send(4,
> "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0(\0\1\0\0\0\21'\2\0004\0\0\0"..., 8192,
> MSG_MORE) = -1 ENOKEY (Required key not available)
> 
> This used to work, so something in the kernel AF_ALG API has changed
> which has broken userspace.  Any ideas what's up, or where to look?

This seems to be the the change added by Herbert to fix a security issue. This 
caused a similar stirr in the cryptsetup user space tool.

I guess you are affected by 6de62f15b581f920ade22d758f4c338311c2f0d4


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

Re: AF_ALG broken?

2016-08-08 Thread Russell King - ARM Linux 
On Mon, Aug 08, 2016 at 01:47:33PM -0400, Jeffrey Walton wrote:
> > When trying to use the openssl AF_ALG module with 4.8-rc1 with imx
> > caam, I get this:
> >
> > $ OPENSSL_CONF=/shared/crypto/openssl-imx.cnf strace openssl dgst -md5 
> >  > ...
> > socket(PF_ALG, SOCK_SEQPACKET, 0)   = 3
> > close(3)= 0
> > socket(PF_ALG, SOCK_SEQPACKET, 0)   = 3
> > bind(3, {sa_family=AF_ALG, sa_data="hash\0\0\0\0\0\0\0\0\0\0"}, 88) = 0
> > accept(3, 0, NULL)  = 4
> > fstat64(0, {st_mode=S_IFREG|0755, st_size=666864, ...}) = 0
> > mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
> > 0xb6fab000
> > read(0, 
> > "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0(\0\1\0\0\0\21'\2\0004\0\0\0"..., 8192) 
> > = 8192
> > send(4, 
> > "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0(\0\1\0\0\0\21'\2\0004\0\0\0"..., 8192, 
> > MSG_MORE) = -1 ENOKEY (Required key not available)
> 
> As far as I know from testing on x86, it has never worked as expected.
> I believe you have to use 'sendto' and 'recvfrom' because 'send' and
> 'recv' use default structures, and they configure the object
> incorrectly.

This used to work, because that's how I've tested my previous CAAM
and Marvell CESA patches.  So, this is not a case of "never worked"
but is definitely a regression caused by some kernel change.

There's also people's presentations that illustrate example code:

https://events.linuxfoundation.org/sites/events/files/slides/lcj-2014-crypto-user.pdf

which can also be found at:

https://lwn.net/Articles/410833/

and that example code comes from Herbert, so one would assume that
it's tested and was working.  Note that it doesn't use any send*,
but uses write().

Testing that code on 4.8-rc (and 4.7 fwiw) gives:

socket(PF_ALG, SOCK_SEQPACKET, 0)   = 3
bind(3, {sa_family=AF_ALG, sa_data="hash\0\0\0\0\0\0\0\0\0\0"}, 88) = 0
accept(3, 0, NULL)  = 4
write(4, "abc", 3)  = -1 ENOKEY (Required key not available)
read(4, 0xbec50508, 20) = -1 ENOKEY (Required key not available)

IOW, the same problem - and it seems not to be a recent regression.

Since the last time I tested CESA or CAAM was back in 4.4 times,
it's got to be something between 4.4 and 4.7.

Looking at the history, my guess would be the setkey changes -
crypto: algif_skcipher - Require setkey before accept(2)
crypto: af_alg - Disallow bind/setkey/... after accept(2)
crypto: af_alg - Add nokey compatibility path
crypto: hash - Add crypto_ahash_has_setkey
crypto: algif_hash - Require setkey before accept(2)

-- 
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 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: AF_ALG broken?

2016-08-08 Thread Jeffrey Walton 
> When trying to use the openssl AF_ALG module with 4.8-rc1 with imx
> caam, I get this:
>
> $ OPENSSL_CONF=/shared/crypto/openssl-imx.cnf strace openssl dgst -md5 
>  ...
> socket(PF_ALG, SOCK_SEQPACKET, 0)   = 3
> close(3)= 0
> socket(PF_ALG, SOCK_SEQPACKET, 0)   = 3
> bind(3, {sa_family=AF_ALG, sa_data="hash\0\0\0\0\0\0\0\0\0\0"}, 88) = 0
> accept(3, 0, NULL)  = 4
> fstat64(0, {st_mode=S_IFREG|0755, st_size=666864, ...}) = 0
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
> 0xb6fab000
> read(0, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0(\0\1\0\0\0\21'\2\0004\0\0\0"..., 
> 8192) = 8192
> send(4, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0(\0\1\0\0\0\21'\2\0004\0\0\0"..., 
> 8192, MSG_MORE) = -1 ENOKEY (Required key not available)

As far as I know from testing on x86, it has never worked as expected.
I believe you have to use 'sendto' and 'recvfrom' because 'send' and
'recv' use default structures, and they configure the object
incorrectly.

Jeff
--
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] RANDOM: ATH9K RNG delivers zero bits of entropy

2016-08-08 Thread Jason Cooper 
Hi Stephan, Miaoqing Pan,

On Mon, Aug 08, 2016 at 08:41:36AM +0200, Stephan Mueller wrote:
> Am Montag, 8. August 2016, 02:03:36 CEST schrieb Pan, Miaoqing:
> > The entropy was evaluated by crypto expert,  the analysis report show the
> > ADC with at least 10bits and up to 22 bits of min-entropy for a 32 bits
> > value, we conservatively assume the min-entropy is 10 bits out of 32 bits,
> > so that's why set entropy quality  to  320/1024 = 10/32.

Ok, so the relevant commit is:

  ed14dc0af7cce ath9k: feeding entropy in kernel from ADC capture

Which refers to a previous commit:

  6301566e0b2d ath9k: export HW random number generator

> > Also we have explained in the commit message why can't use the HW
> > RNG framework.

>From ed14dc0af7cce:

"""
Since ADC was not designed to be a dedicated HW RNG, we do not want to
bind it to /dev/hwrng framework directly.
"""

> Where is the description of the RNG, where is the test implementation? 
> > 
> > Otherwise, your patch will cause high CPU load,  as continuously read ADC
> > data if entropy bits under write_wakeup_threshold.
> 
> The issue is that although you may have analyzed it, others are unable to 
> measure the quality of the RNG and assess the design as well as the 
> implementation of the RNG. This RNG is the only implementation of a hardware 
> RNG that per default and without being able to change it at runtime injects 
> data into the input_pool where the noise source cannot be audited. Note, even 
> other respected RNG noise sources like the Intel RDRAND will not feed into /
> dev/random per default in a way that dominates all other noise sources.
> 
> I would like to be able to deactivate that noise source to the extent that it 
> does not cause /dev/random to unblock. The reason is that your noise source 
> starts to dominate all other noise sources.

I think the short-term problem here is the config logic:

config ATH9K_HWRNG
   bool "Random number generator support"
   depends on ATH9K && (HW_RANDOM = y || HW_RANDOM = ATH9K)
   default y

If you have *any* hwrngs you want to use and you have an ath9k card
(HW_RANDOM = y and ATH9K != n), you get the behavior Stephan is pointing
out.

Short term, we should just default no here.

> If you think that this patch is a challenge because your driver starts to 
> spin, please help and offer another solution.

Well, I don't buy the reasoning listed above for not using the hwrng
framework.  Interrupt timings were never designed to be a source of entropy
either.  We need to grab it where ever we can find it, especially on
embedded systems.  Documentation/hw_random.txt even says:

"""
This data is NOT CHECKED by any fitness tests, and could potentially be
bogus (if the hardware is faulty or has been tampered with).
"""

I really don't think there's a problem with adding these sorts of
sources under char/hw_random/.  I think the only thing we would be
concerned about, other than the already addressed entropy estimation,
would be constraining the data rate.

Is ath9k the only wireless card that exposes ADC registers?  What about
sound cards?

thx,

Jason.
--
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 09/11] crypto: caam: move job descriptor initialisation to ahash_edesc_alloc()

2016-08-08 Thread Russell King 
Signed-off-by: Russell King 
---
 drivers/crypto/caam/caamhash.c | 84 +-
 1 file changed, 34 insertions(+), 50 deletions(-)

diff --git a/drivers/crypto/caam/caamhash.c b/drivers/crypto/caam/caamhash.c
index 2c2c15b63059..9c3e74e4088e 100644
--- a/drivers/crypto/caam/caamhash.c
+++ b/drivers/crypto/caam/caamhash.c
@@ -770,7 +770,9 @@ static void ahash_done_ctx_dst(struct device *jrdev, u32 
*desc, u32 err,
  * and space for hardware scatter table containing sg_num entries.
  */
 static struct ahash_edesc *ahash_edesc_alloc(struct caam_hash_ctx *ctx,
-int sg_num, gfp_t flags)
+int sg_num, u32 *sh_desc,
+dma_addr_t sh_desc_dma,
+gfp_t flags)
 {
struct ahash_edesc *edesc;
unsigned int sg_size = sg_num * sizeof(struct sec4_sg_entry);
@@ -781,6 +783,9 @@ static struct ahash_edesc *ahash_edesc_alloc(struct 
caam_hash_ctx *ctx,
return NULL;
}
 
+   init_job_desc_shared(edesc->hw_desc, sh_desc_dma, desc_len(sh_desc),
+HDR_SHARE_DEFER | HDR_REVERSE);
+
return edesc;
 }
 
@@ -799,12 +804,10 @@ static int ahash_update_ctx(struct ahash_request *req)
int *next_buflen = state->current_buf ? >buflen_0 :
   >buflen_1, last_buflen;
int in_len = *buflen + req->nbytes, to_hash;
-   u32 *sh_desc = ctx->sh_desc_update, *desc;
-   dma_addr_t ptr = ctx->sh_desc_update_dma;
+   u32 *desc;
int src_nents, mapped_nents, sec4_sg_bytes, sec4_sg_src_index;
struct ahash_edesc *edesc;
int ret = 0;
-   int sh_len;
 
last_buflen = *next_buflen;
*next_buflen = in_len & (crypto_tfm_alg_blocksize(>base) - 1);
@@ -838,7 +841,8 @@ static int ahash_update_ctx(struct ahash_request *req)
 * link tables
 */
edesc = ahash_edesc_alloc(ctx, sec4_sg_src_index + mapped_nents,
- flags);
+ ctx->sh_desc_update,
+ ctx->sh_desc_update_dma, flags);
if (!edesc) {
dma_unmap_sg(jrdev, req->src, src_nents, DMA_TO_DEVICE);
return -ENOMEM;
@@ -872,10 +876,7 @@ static int ahash_update_ctx(struct ahash_request *req)
 
state->current_buf = !state->current_buf;
 
-   sh_len = desc_len(sh_desc);
desc = edesc->hw_desc;
-   init_job_desc_shared(desc, ptr, sh_len, HDR_SHARE_DEFER |
-HDR_REVERSE);
 
edesc->sec4_sg_dma = dma_map_single(jrdev, edesc->sec4_sg,
 sec4_sg_bytes,
@@ -936,25 +937,23 @@ static int ahash_final_ctx(struct ahash_request *req)
int buflen = state->current_buf ? state->buflen_1 : state->buflen_0;
int last_buflen = state->current_buf ? state->buflen_0 :
  state->buflen_1;
-   u32 *sh_desc = ctx->sh_desc_fin, *desc;
-   dma_addr_t ptr = ctx->sh_desc_fin_dma;
+   u32 *desc;
int sec4_sg_bytes, sec4_sg_src_index;
int digestsize = crypto_ahash_digestsize(ahash);
struct ahash_edesc *edesc;
int ret = 0;
-   int sh_len;
 
sec4_sg_src_index = 1 + (buflen ? 1 : 0);
sec4_sg_bytes = sec4_sg_src_index * sizeof(struct sec4_sg_entry);
 
/* allocate space for base edesc and hw desc commands, link tables */
-   edesc = ahash_edesc_alloc(ctx, sec4_sg_src_index, flags);
+   edesc = ahash_edesc_alloc(ctx, sec4_sg_src_index,
+ ctx->sh_desc_fin, ctx->sh_desc_fin_dma,
+ flags);
if (!edesc)
return -ENOMEM;
 
-   sh_len = desc_len(sh_desc);
desc = edesc->hw_desc;
-   init_job_desc_shared(desc, ptr, sh_len, HDR_SHARE_DEFER | HDR_REVERSE);
 
edesc->sec4_sg_bytes = sec4_sg_bytes;
edesc->src_nents = 0;
@@ -1018,14 +1017,12 @@ static int ahash_finup_ctx(struct ahash_request *req)
int buflen = state->current_buf ? state->buflen_1 : state->buflen_0;
int last_buflen = state->current_buf ? state->buflen_0 :
  state->buflen_1;
-   u32 *sh_desc = ctx->sh_desc_finup, *desc;
-   dma_addr_t ptr = ctx->sh_desc_finup_dma;
+   u32 *desc;
int sec4_sg_bytes, sec4_sg_src_index;
int src_nents, mapped_nents;
int digestsize = crypto_ahash_digestsize(ahash);
struct ahash_edesc *edesc;
int ret = 0;
-   int sh_len;
 
src_nents = sg_nents_for_len(req->src, req->nbytes);
if (src_nents < 0) {
@@ -1050,15 +1047,14 @@ static int ahash_finup_ctx(struct ahash_request

[PATCH 10/11] crypto: caam: add ahash_edesc_add_src()

2016-08-08 Thread Russell King 
Add a helper to map the source scatterlist into the descriptor.

Signed-off-by: Russell King 
---
 drivers/crypto/caam/caamhash.c | 137 +
 1 file changed, 57 insertions(+), 80 deletions(-)

diff --git a/drivers/crypto/caam/caamhash.c b/drivers/crypto/caam/caamhash.c
index 9c3e74e4088e..ea284e3909ef 100644
--- a/drivers/crypto/caam/caamhash.c
+++ b/drivers/crypto/caam/caamhash.c
@@ -789,6 +789,41 @@ static struct ahash_edesc *ahash_edesc_alloc(struct 
caam_hash_ctx *ctx,
return edesc;
 }
 
+static int ahash_edesc_add_src(struct caam_hash_ctx *ctx,
+  struct ahash_edesc *edesc,
+  struct ahash_request *req, int nents,
+  unsigned int first_sg,
+  unsigned int first_bytes, size_t to_hash)
+{
+   dma_addr_t src_dma;
+   u32 options;
+
+   if (nents > 1 || first_sg) {
+   struct sec4_sg_entry *sg = edesc->sec4_sg;
+   unsigned int sgsize = sizeof(*sg) * (first_sg + nents);
+
+   sg_to_sec4_sg_last(req->src, nents, sg + first_sg, 0);
+
+   src_dma = dma_map_single(ctx->jrdev, sg, sgsize, DMA_TO_DEVICE);
+   if (dma_mapping_error(ctx->jrdev, src_dma)) {
+   dev_err(ctx->jrdev, "unable to map S/G table\n");
+   return -ENOMEM;
+   }
+
+   edesc->sec4_sg_bytes = sgsize;
+   edesc->sec4_sg_dma = src_dma;
+   options = LDST_SGF;
+   } else {
+   src_dma = sg_dma_address(req->src);
+   options = 0;
+   }
+
+   append_seq_in_ptr(edesc->hw_desc, src_dma, first_bytes + to_hash,
+ options);
+
+   return 0;
+}
+
 /* submit update job descriptor */
 static int ahash_update_ctx(struct ahash_request *req)
 {
@@ -1018,7 +1053,7 @@ static int ahash_finup_ctx(struct ahash_request *req)
int last_buflen = state->current_buf ? state->buflen_0 :
  state->buflen_1;
u32 *desc;
-   int sec4_sg_bytes, sec4_sg_src_index;
+   int sec4_sg_src_index;
int src_nents, mapped_nents;
int digestsize = crypto_ahash_digestsize(ahash);
struct ahash_edesc *edesc;
@@ -1042,8 +1077,6 @@ static int ahash_finup_ctx(struct ahash_request *req)
}
 
sec4_sg_src_index = 1 + (buflen ? 1 : 0);
-   sec4_sg_bytes = (sec4_sg_src_index + mapped_nents) *
-sizeof(struct sec4_sg_entry);
 
/* allocate space for base edesc and hw desc commands, link tables */
edesc = ahash_edesc_alloc(ctx, sec4_sg_src_index + mapped_nents,
@@ -1057,7 +1090,6 @@ static int ahash_finup_ctx(struct ahash_request *req)
desc = edesc->hw_desc;
 
edesc->src_nents = src_nents;
-   edesc->sec4_sg_bytes = sec4_sg_bytes;
 
ret = ctx_map_to_sec4_sg(desc, jrdev, state, ctx->ctx_len,
 edesc->sec4_sg, DMA_TO_DEVICE);
@@ -1068,19 +1100,11 @@ static int ahash_finup_ctx(struct ahash_request *req)
buf, state->buf_dma, buflen,
last_buflen);
 
-   sg_to_sec4_sg_last(req->src, mapped_nents,
-  edesc->sec4_sg + sec4_sg_src_index, 0);
-
-   edesc->sec4_sg_dma = dma_map_single(jrdev, edesc->sec4_sg,
-   sec4_sg_bytes, DMA_TO_DEVICE);
-   if (dma_mapping_error(jrdev, edesc->sec4_sg_dma)) {
-   dev_err(jrdev, "unable to map S/G table\n");
-   ret = -ENOMEM;
+   ret = ahash_edesc_add_src(ctx, edesc, req, mapped_nents,
+ sec4_sg_src_index, ctx->ctx_len + buflen,
+ req->nbytes);
+   if (ret)
goto err;
-   }
-
-   append_seq_in_ptr(desc, edesc->sec4_sg_dma, ctx->ctx_len +
-  buflen + req->nbytes, LDST_SGF);
 
edesc->dst_dma = map_seq_out_ptr_result(desc, jrdev, req->result,
digestsize);
@@ -1116,11 +1140,9 @@ static int ahash_digest(struct ahash_request *req)
   CRYPTO_TFM_REQ_MAY_SLEEP)) ? GFP_KERNEL : GFP_ATOMIC;
u32 *desc;
int digestsize = crypto_ahash_digestsize(ahash);
-   int src_nents, mapped_nents, sec4_sg_bytes;
-   dma_addr_t src_dma;
+   int src_nents, mapped_nents;
struct ahash_edesc *edesc;
int ret = 0;
-   u32 options;
 
src_nents = sg_nents_for_len(req->src, req->nbytes);
if (src_nents < 0) {
@@ -1139,11 +1161,6 @@ static int ahash_digest(struct ahash_request *req)
mapped_nents = 0;
}
 
-   if (mapped_nents > 1)
-   sec4_sg_bytes = mapped_nents * sizeof(struct sec4_sg_entry);
-   else
-   sec4_sg_bytes

[PATCH 11/11] crypto: caam: get rid of tasklet

2016-08-08 Thread Russell King 
Threaded interrupts can perform the function of the tasklet, and much
more safely too - without races when trying to take the tasklet and
interrupt down on device removal.

With the old code, there is a window where we call tasklet_kill().  If
the interrupt handler happens to be running on a different CPU, and
subsequently calls tasklet_schedule(), the tasklet will be re-scheduled
for execution.

Switching to a hardirq/threadirq combination implementation avoids this,
and it also means generic code deals with the teardown sequencing of the
threaded and non-threaded parts.

Signed-off-by: Russell King 
---
 drivers/crypto/caam/intern.h |  1 -
 drivers/crypto/caam/jr.c | 25 +
 2 files changed, 9 insertions(+), 17 deletions(-)

diff --git a/drivers/crypto/caam/intern.h b/drivers/crypto/caam/intern.h
index e2bcacc1a921..5d4c05074a5c 100644
--- a/drivers/crypto/caam/intern.h
+++ b/drivers/crypto/caam/intern.h
@@ -41,7 +41,6 @@ struct caam_drv_private_jr {
struct device   *dev;
int ridx;
struct caam_job_ring __iomem *rregs;/* JobR's register space */
-   struct tasklet_struct irqtask;
int irq;/* One per queue */
 
/* Number of scatterlist crypt transforms active on the JobR */
diff --git a/drivers/crypto/caam/jr.c b/drivers/crypto/caam/jr.c
index a81f551ac222..320228875e9a 100644
--- a/drivers/crypto/caam/jr.c
+++ b/drivers/crypto/caam/jr.c
@@ -73,8 +73,6 @@ static int caam_jr_shutdown(struct device *dev)
 
ret = caam_reset_hw_jr(dev);
 
-   tasklet_kill(>irqtask);
-
/* Release interrupt */
free_irq(jrp->irq, dev);
 
@@ -130,7 +128,7 @@ static irqreturn_t caam_jr_interrupt(int irq, void *st_dev)
 
/*
 * Check the output ring for ready responses, kick
-* tasklet if jobs done.
+* the threaded irq if jobs done.
 */
irqstate = rd_reg32(>rregs->jrintstatus);
if (!irqstate)
@@ -152,18 +150,13 @@ static irqreturn_t caam_jr_interrupt(int irq, void 
*st_dev)
/* Have valid interrupt at this point, just ACK and trigger */
wr_reg32(>rregs->jrintstatus, irqstate);
 
-   preempt_disable();
-   tasklet_schedule(>irqtask);
-   preempt_enable();
-
-   return IRQ_HANDLED;
+   return IRQ_WAKE_THREAD;
 }
 
-/* Deferred service handler, run as interrupt-fired tasklet */
-static void caam_jr_dequeue(unsigned long devarg)
+static irqreturn_t caam_jr_threadirq(int irq, void *st_dev)
 {
int hw_idx, sw_idx, i, head, tail;
-   struct device *dev = (struct device *)devarg;
+   struct device *dev = st_dev;
struct caam_drv_private_jr *jrp = dev_get_drvdata(dev);
void (*usercall)(struct device *dev, u32 *desc, u32 status, void *arg);
u32 *userdesc, userstatus;
@@ -237,6 +230,8 @@ static void caam_jr_dequeue(unsigned long devarg)
 
/* reenable / unmask IRQs */
clrsetbits_32(>rregs->rconfig_lo, JRCFG_IMSK, 0);
+
+   return IRQ_HANDLED;
 }
 
 /**
@@ -394,11 +389,10 @@ static int caam_jr_init(struct device *dev)
 
jrp = dev_get_drvdata(dev);
 
-   tasklet_init(>irqtask, caam_jr_dequeue, (unsigned long)dev);
-
/* Connect job ring interrupt handler. */
-   error = request_irq(jrp->irq, caam_jr_interrupt, IRQF_SHARED,
-   dev_name(dev), dev);
+   error = request_threaded_irq(jrp->irq, caam_jr_interrupt,
+caam_jr_threadirq, IRQF_SHARED,
+dev_name(dev), dev);
if (error) {
dev_err(dev, "can't connect JobR %d interrupt (%d)\n",
jrp->ridx, jrp->irq);
@@ -460,7 +454,6 @@ static int caam_jr_init(struct device *dev)
 out_free_irq:
free_irq(jrp->irq, dev);
 out_kill_deq:
-   tasklet_kill(>irqtask);
return error;
 }
 
-- 
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

[PATCH 07/11] crypto: caam: check and use dma_map_sg() return code

2016-08-08 Thread Russell King 
Strictly, dma_map_sg() may coalesce SG entries, but in practise on iMX
hardware, this will never happen.  However, dma_map_sg() can fail, and
we completely fail to check its return value.  So, fix this properly.

Arrange the code to map the scatterlist early, so we know how many
scatter table entries to allocate, and then fill them in.  This allows
us to keep relatively simple error cleanup paths.

Signed-off-by: Russell King 
---
 drivers/crypto/caam/caamhash.c | 138 ++---
 1 file changed, 103 insertions(+), 35 deletions(-)

diff --git a/drivers/crypto/caam/caamhash.c b/drivers/crypto/caam/caamhash.c
index e1925bf3a7cc..a639183d0115 100644
--- a/drivers/crypto/caam/caamhash.c
+++ b/drivers/crypto/caam/caamhash.c
@@ -187,15 +187,6 @@ static inline dma_addr_t buf_map_to_sec4_sg(struct device 
*jrdev,
return buf_dma;
 }
 
-/* Map req->src and put it in link table */
-static inline void src_map_to_sec4_sg(struct device *jrdev,
- struct scatterlist *src, int src_nents,
- struct sec4_sg_entry *sec4_sg)
-{
-   dma_map_sg(jrdev, src, src_nents, DMA_TO_DEVICE);
-   sg_to_sec4_sg_last(src, src_nents, sec4_sg, 0);
-}
-
 /*
  * Only put buffer in link table if it contains data, which is possible,
  * since a buffer has previously been used, and needs to be unmapped,
@@ -791,7 +782,7 @@ static int ahash_update_ctx(struct ahash_request *req)
int in_len = *buflen + req->nbytes, to_hash;
u32 *sh_desc = ctx->sh_desc_update, *desc;
dma_addr_t ptr = ctx->sh_desc_update_dma;
-   int src_nents, sec4_sg_bytes, sec4_sg_src_index;
+   int src_nents, mapped_nents, sec4_sg_bytes, sec4_sg_src_index;
struct ahash_edesc *edesc;
int ret = 0;
int sh_len;
@@ -807,8 +798,20 @@ static int ahash_update_ctx(struct ahash_request *req)
dev_err(jrdev, "Invalid number of src SG.\n");
return src_nents;
}
+
+   if (src_nents) {
+   mapped_nents = dma_map_sg(jrdev, req->src, src_nents,
+ DMA_TO_DEVICE);
+   if (!mapped_nents) {
+   dev_err(jrdev, "unable to DMA map source\n");
+   return -ENOMEM;
+   }
+   } else {
+   mapped_nents = 0;
+   }
+
sec4_sg_src_index = 1 + (*buflen ? 1 : 0);
-   sec4_sg_bytes = (sec4_sg_src_index + src_nents) *
+   sec4_sg_bytes = (sec4_sg_src_index + mapped_nents) *
 sizeof(struct sec4_sg_entry);
 
/*
@@ -820,6 +823,7 @@ static int ahash_update_ctx(struct ahash_request *req)
if (!edesc) {
dev_err(jrdev,
"could not allocate extended descriptor\n");
+   dma_unmap_sg(jrdev, req->src, src_nents, DMA_TO_DEVICE);
return -ENOMEM;
}
 
@@ -836,9 +840,10 @@ static int ahash_update_ctx(struct ahash_request *req)
buf, state->buf_dma,
*buflen, last_buflen);
 
-   if (src_nents) {
-   src_map_to_sec4_sg(jrdev, req->src, src_nents,
-  edesc->sec4_sg + sec4_sg_src_index);
+   if (mapped_nents) {
+   sg_to_sec4_sg_last(req->src, mapped_nents,
+  edesc->sec4_sg + sec4_sg_src_index,
+  0);
if (*next_buflen)
scatterwalk_map_and_copy(next_buf, req->src,
 to_hash - *buflen,
@@ -1001,7 +1006,7 @@ static int ahash_finup_ctx(struct ahash_request *req)
u32 *sh_desc = ctx->sh_desc_finup, *desc;
dma_addr_t ptr = ctx->sh_desc_finup_dma;
int sec4_sg_bytes, sec4_sg_src_index;
-   int src_nents;
+   int src_nents, mapped_nents;
int digestsize = crypto_ahash_digestsize(ahash);
struct ahash_edesc *edesc;
int ret = 0;
@@ -1012,14 +1017,27 @@ static int ahash_finup_ctx(struct ahash_request *req)
dev_err(jrdev, "Invalid number of src SG.\n");
return src_nents;
}
+
+   if (src_nents) {
+   mapped_nents = dma_map_sg(jrdev, req->src, src_nents,
+ DMA_TO_DEVICE);
+   if (!mapped_nents) {
+   dev_err(jrdev, "unable to DMA map source\n");
+   return -ENOMEM;
+   }
+   } else {
+   mapped_nents = 0;
+   }
+

[PATCH 03/11] crypto: caam: incorporate job descriptor into struct ahash_edesc

2016-08-08 Thread Russell King 
Rather than giving the descriptor as hw_desc[0], give it's real size.
All places where we allocate an ahash_edesc incorporate DESC_JOB_IO_LEN
bytes of job descriptor.

Signed-off-by: Russell King 
---
 drivers/crypto/caam/caamhash.c | 49 --
 1 file changed, 19 insertions(+), 30 deletions(-)

diff --git a/drivers/crypto/caam/caamhash.c b/drivers/crypto/caam/caamhash.c
index 47ea7b428156..ce9c1bc23795 100644
--- a/drivers/crypto/caam/caamhash.c
+++ b/drivers/crypto/caam/caamhash.c
@@ -604,7 +604,7 @@ struct ahash_edesc {
int src_nents;
int sec4_sg_bytes;
struct sec4_sg_entry *sec4_sg;
-   u32 hw_desc[0];
+   u32 hw_desc[DESC_JOB_IO_LEN / sizeof(u32)];
 };
 
 static inline void ahash_unmap(struct device *dev,
@@ -815,8 +815,8 @@ static int ahash_update_ctx(struct ahash_request *req)
 * allocate space for base edesc and hw desc commands,
 * link tables
 */
-   edesc = kzalloc(sizeof(*edesc) + DESC_JOB_IO_LEN +
-   sec4_sg_bytes, GFP_DMA | flags);
+   edesc = kzalloc(sizeof(*edesc) + sec4_sg_bytes,
+   GFP_DMA | flags);
if (!edesc) {
dev_err(jrdev,
"could not allocate extended descriptor\n");
@@ -825,8 +825,7 @@ static int ahash_update_ctx(struct ahash_request *req)
 
edesc->src_nents = src_nents;
edesc->sec4_sg_bytes = sec4_sg_bytes;
-   edesc->sec4_sg = (void *)edesc + sizeof(struct ahash_edesc) +
-DESC_JOB_IO_LEN;
+   edesc->sec4_sg = (void *)(edesc + 1);
 
ret = ctx_map_to_sec4_sg(desc, jrdev, state, ctx->ctx_len,
 edesc->sec4_sg, DMA_BIDIRECTIONAL);
@@ -925,8 +924,7 @@ static int ahash_final_ctx(struct ahash_request *req)
sec4_sg_bytes = sec4_sg_src_index * sizeof(struct sec4_sg_entry);
 
/* allocate space for base edesc and hw desc commands, link tables */
-   edesc = kzalloc(sizeof(*edesc) + DESC_JOB_IO_LEN + sec4_sg_bytes,
-   GFP_DMA | flags);
+   edesc = kzalloc(sizeof(*edesc) + sec4_sg_bytes, GFP_DMA | flags);
if (!edesc) {
dev_err(jrdev, "could not allocate extended descriptor\n");
return -ENOMEM;
@@ -937,8 +935,7 @@ static int ahash_final_ctx(struct ahash_request *req)
init_job_desc_shared(desc, ptr, sh_len, HDR_SHARE_DEFER | HDR_REVERSE);
 
edesc->sec4_sg_bytes = sec4_sg_bytes;
-   edesc->sec4_sg = (void *)edesc + sizeof(struct ahash_edesc) +
-DESC_JOB_IO_LEN;
+   edesc->sec4_sg = (void *)(edesc + 1);
edesc->src_nents = 0;
 
ret = ctx_map_to_sec4_sg(desc, jrdev, state, ctx->ctx_len,
@@ -1016,8 +1013,7 @@ static int ahash_finup_ctx(struct ahash_request *req)
 sizeof(struct sec4_sg_entry);
 
/* allocate space for base edesc and hw desc commands, link tables */
-   edesc = kzalloc(sizeof(*edesc) + DESC_JOB_IO_LEN + sec4_sg_bytes,
-   GFP_DMA | flags);
+   edesc = kzalloc(sizeof(*edesc) + sec4_sg_bytes, GFP_DMA | flags);
if (!edesc) {
dev_err(jrdev, "could not allocate extended descriptor\n");
return -ENOMEM;
@@ -1029,8 +1025,7 @@ static int ahash_finup_ctx(struct ahash_request *req)
 
edesc->src_nents = src_nents;
edesc->sec4_sg_bytes = sec4_sg_bytes;
-   edesc->sec4_sg = (void *)edesc + sizeof(struct ahash_edesc) +
-DESC_JOB_IO_LEN;
+   edesc->sec4_sg = (void *)(edesc + 1);
 
ret = ctx_map_to_sec4_sg(desc, jrdev, state, ctx->ctx_len,
 edesc->sec4_sg, DMA_TO_DEVICE);
@@ -1106,14 +1101,12 @@ static int ahash_digest(struct ahash_request *req)
sec4_sg_bytes = 0;
 
/* allocate space for base edesc and hw desc commands, link tables */
-   edesc = kzalloc(sizeof(*edesc) + sec4_sg_bytes + DESC_JOB_IO_LEN,
-   GFP_DMA | flags);
+   edesc = kzalloc(sizeof(*edesc) + sec4_sg_bytes, GFP_DMA | flags);
if (!edesc) {
dev_err(jrdev, "could not allocate extended descriptor\n");
return -ENOMEM;
}
-   edesc->sec4_sg = (void *)edesc + sizeof(struct ahash_edesc) +
- DESC_JOB_IO_LEN;
+   edesc->sec4_sg = (void *)(edesc + 1);
edesc->sec4_sg_bytes = sec4_sg_bytes;
edesc->src_nents = src_nents;
 
@@ -1179,7 +1172,7 @@ static int ahash_final_no_ctx(struct ahash_request *req)
int sh_len;
 
/* allocate space for base edesc and hw desc commands, link tables */
-   edesc = kzalloc(sizeof(*edesc) + DESC_JOB_IO_LEN, GFP_DMA | flags);
+   edesc = kzalloc(sizeof(*edesc), GFP_DMA | flags);

[PATCH 05/11] crypto: caam: replace sec4_sg pointer with array

2016-08-08 Thread Russell King 
Since the extended descriptor includes the hardware descriptor, and the
sec4 scatterlist immediately follows this, we can declare it as a array
at the very end of the extended descriptor.  This allows us to get rid
of an initialiser for every site where we allocate an extended
descriptor.

Signed-off-by: Russell King 
---
 drivers/crypto/caam/caamhash.c | 12 +++-
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/drivers/crypto/caam/caamhash.c b/drivers/crypto/caam/caamhash.c
index e9c52cbf9a41..d2129be43bf1 100644
--- a/drivers/crypto/caam/caamhash.c
+++ b/drivers/crypto/caam/caamhash.c
@@ -595,16 +595,16 @@ static int ahash_setkey(struct crypto_ahash *ahash,
  * @sec4_sg_dma: physical mapped address of h/w link table
  * @src_nents: number of segments in input scatterlist
  * @sec4_sg_bytes: length of dma mapped sec4_sg space
- * @sec4_sg: pointer to h/w link table
  * @hw_desc: the h/w job descriptor followed by any referenced link tables
+ * @sec4_sg: h/w link table
  */
 struct ahash_edesc {
dma_addr_t dst_dma;
dma_addr_t sec4_sg_dma;
int src_nents;
int sec4_sg_bytes;
-   struct sec4_sg_entry *sec4_sg;
u32 hw_desc[DESC_JOB_IO_LEN / sizeof(u32)] cacheline_aligned;
+   struct sec4_sg_entry sec4_sg[0];
 };
 
 static inline void ahash_unmap(struct device *dev,
@@ -825,7 +825,6 @@ static int ahash_update_ctx(struct ahash_request *req)
 
edesc->src_nents = src_nents;
edesc->sec4_sg_bytes = sec4_sg_bytes;
-   edesc->sec4_sg = (void *)(edesc + 1);
 
ret = ctx_map_to_sec4_sg(desc, jrdev, state, ctx->ctx_len,
 edesc->sec4_sg, DMA_BIDIRECTIONAL);
@@ -935,7 +934,6 @@ static int ahash_final_ctx(struct ahash_request *req)
init_job_desc_shared(desc, ptr, sh_len, HDR_SHARE_DEFER | HDR_REVERSE);
 
edesc->sec4_sg_bytes = sec4_sg_bytes;
-   edesc->sec4_sg = (void *)(edesc + 1);
edesc->src_nents = 0;
 
ret = ctx_map_to_sec4_sg(desc, jrdev, state, ctx->ctx_len,
@@ -1025,7 +1023,6 @@ static int ahash_finup_ctx(struct ahash_request *req)
 
edesc->src_nents = src_nents;
edesc->sec4_sg_bytes = sec4_sg_bytes;
-   edesc->sec4_sg = (void *)(edesc + 1);
 
ret = ctx_map_to_sec4_sg(desc, jrdev, state, ctx->ctx_len,
 edesc->sec4_sg, DMA_TO_DEVICE);
@@ -1106,7 +1103,7 @@ static int ahash_digest(struct ahash_request *req)
dev_err(jrdev, "could not allocate extended descriptor\n");
return -ENOMEM;
}
-   edesc->sec4_sg = (void *)(edesc + 1);
+
edesc->sec4_sg_bytes = sec4_sg_bytes;
edesc->src_nents = src_nents;
 
@@ -1264,7 +1261,6 @@ static int ahash_update_no_ctx(struct ahash_request *req)
 
edesc->src_nents = src_nents;
edesc->sec4_sg_bytes = sec4_sg_bytes;
-   edesc->sec4_sg = (void *)(edesc + 1);
edesc->dst_dma = 0;
 
state->buf_dma = buf_map_to_sec4_sg(jrdev, edesc->sec4_sg,
@@ -1375,7 +1371,6 @@ static int ahash_finup_no_ctx(struct ahash_request *req)
 
edesc->src_nents = src_nents;
edesc->sec4_sg_bytes = sec4_sg_bytes;
-   edesc->sec4_sg = (void *)(edesc + 1);
 
state->buf_dma = try_buf_map_to_sec4_sg(jrdev, edesc->sec4_sg, buf,
state->buf_dma, buflen,
@@ -1470,7 +1465,6 @@ static int ahash_update_first(struct ahash_request *req)
 
edesc->src_nents = src_nents;
edesc->sec4_sg_bytes = sec4_sg_bytes;
-   edesc->sec4_sg = (void *)(edesc + 1);
edesc->dst_dma = 0;
 
if (src_nents > 1) {
-- 
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

[PATCH 04/11] crypto: caam: mark the hardware descriptor as cache line aligned

2016-08-08 Thread Russell King 
Mark the hardware descriptor as being cache line aligned; on DMA
incoherent architectures, the hardware descriptor should sit in a
separate cache line from the CPU accessed data to avoid polluting
the caches.

Signed-off-by: Russell King 
---
 drivers/crypto/caam/caamhash.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/crypto/caam/caamhash.c b/drivers/crypto/caam/caamhash.c
index ce9c1bc23795..e9c52cbf9a41 100644
--- a/drivers/crypto/caam/caamhash.c
+++ b/drivers/crypto/caam/caamhash.c
@@ -604,7 +604,7 @@ struct ahash_edesc {
int src_nents;
int sec4_sg_bytes;
struct sec4_sg_entry *sec4_sg;
-   u32 hw_desc[DESC_JOB_IO_LEN / sizeof(u32)];
+   u32 hw_desc[DESC_JOB_IO_LEN / sizeof(u32)] cacheline_aligned;
 };
 
 static inline void ahash_unmap(struct device *dev,
-- 
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

[PATCH 02/11] crypto: caam: ensure descriptor buffers are cacheline aligned

2016-08-08 Thread Russell King 
Signed-off-by: Russell King 
---
 drivers/crypto/caam/caamhash.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/crypto/caam/caamhash.c b/drivers/crypto/caam/caamhash.c
index 85c8b048bdc1..47ea7b428156 100644
--- a/drivers/crypto/caam/caamhash.c
+++ b/drivers/crypto/caam/caamhash.c
@@ -99,17 +99,17 @@ static struct list_head hash_list;
 
 /* ahash per-session context */
 struct caam_hash_ctx {
-   struct device *jrdev;
-   u32 sh_desc_update[DESC_HASH_MAX_USED_LEN];
-   u32 sh_desc_update_first[DESC_HASH_MAX_USED_LEN];
-   u32 sh_desc_fin[DESC_HASH_MAX_USED_LEN];
-   u32 sh_desc_digest[DESC_HASH_MAX_USED_LEN];
-   u32 sh_desc_finup[DESC_HASH_MAX_USED_LEN];
-   dma_addr_t sh_desc_update_dma;
+   u32 sh_desc_update[DESC_HASH_MAX_USED_LEN] cacheline_aligned;
+   u32 sh_desc_update_first[DESC_HASH_MAX_USED_LEN] cacheline_aligned;
+   u32 sh_desc_fin[DESC_HASH_MAX_USED_LEN] cacheline_aligned;
+   u32 sh_desc_digest[DESC_HASH_MAX_USED_LEN] cacheline_aligned;
+   u32 sh_desc_finup[DESC_HASH_MAX_USED_LEN] cacheline_aligned;
+   dma_addr_t sh_desc_update_dma cacheline_aligned;
dma_addr_t sh_desc_update_first_dma;
dma_addr_t sh_desc_fin_dma;
dma_addr_t sh_desc_digest_dma;
dma_addr_t sh_desc_finup_dma;
+   struct device *jrdev;
u32 alg_type;
u32 alg_op;
u8 key[CAAM_MAX_HASH_KEY_SIZE];
-- 
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

[PATCH 06/11] crypto: caam: ensure that we clean up after an error

2016-08-08 Thread Russell King 
Ensure that we clean up allocations and DMA mappings after encountering
an error rather than just giving up and leaking memory and resources.

Signed-off-by: Russell King 
---
 drivers/crypto/caam/caamhash.c | 132 -
 1 file changed, 79 insertions(+), 53 deletions(-)

diff --git a/drivers/crypto/caam/caamhash.c b/drivers/crypto/caam/caamhash.c
index d2129be43bf1..e1925bf3a7cc 100644
--- a/drivers/crypto/caam/caamhash.c
+++ b/drivers/crypto/caam/caamhash.c
@@ -829,7 +829,7 @@ static int ahash_update_ctx(struct ahash_request *req)
ret = ctx_map_to_sec4_sg(desc, jrdev, state, ctx->ctx_len,
 edesc->sec4_sg, DMA_BIDIRECTIONAL);
if (ret)
-   return ret;
+   goto err;
 
state->buf_dma = try_buf_map_to_sec4_sg(jrdev,
edesc->sec4_sg + 1,
@@ -860,7 +860,8 @@ static int ahash_update_ctx(struct ahash_request *req)
 DMA_TO_DEVICE);
if (dma_mapping_error(jrdev, edesc->sec4_sg_dma)) {
dev_err(jrdev, "unable to map S/G table\n");
-   return -ENOMEM;
+   ret = -ENOMEM;
+   goto err;
}
 
append_seq_in_ptr(desc, edesc->sec4_sg_dma, ctx->ctx_len +
@@ -875,13 +876,10 @@ static int ahash_update_ctx(struct ahash_request *req)
 #endif
 
ret = caam_jr_enqueue(jrdev, desc, ahash_done_bi, req);
-   if (!ret) {
-   ret = -EINPROGRESS;
-   } else {
-   ahash_unmap_ctx(jrdev, edesc, req, ctx->ctx_len,
-  DMA_BIDIRECTIONAL);
-   kfree(edesc);
-   }
+   if (ret)
+   goto err;
+
+   ret = -EINPROGRESS;
} else if (*next_buflen) {
scatterwalk_map_and_copy(buf + *buflen, req->src, 0,
 req->nbytes, 0);
@@ -897,6 +895,11 @@ static int ahash_update_ctx(struct ahash_request *req)
 #endif
 
return ret;
+
+ err:
+   ahash_unmap_ctx(jrdev, edesc, req, ctx->ctx_len, DMA_BIDIRECTIONAL);
+   kfree(edesc);
+   return ret;
 }
 
 static int ahash_final_ctx(struct ahash_request *req)
@@ -939,7 +942,7 @@ static int ahash_final_ctx(struct ahash_request *req)
ret = ctx_map_to_sec4_sg(desc, jrdev, state, ctx->ctx_len,
 edesc->sec4_sg, DMA_TO_DEVICE);
if (ret)
-   return ret;
+   goto err;
 
state->buf_dma = try_buf_map_to_sec4_sg(jrdev, edesc->sec4_sg + 1,
buf, state->buf_dma, buflen,
@@ -951,7 +954,8 @@ static int ahash_final_ctx(struct ahash_request *req)
sec4_sg_bytes, DMA_TO_DEVICE);
if (dma_mapping_error(jrdev, edesc->sec4_sg_dma)) {
dev_err(jrdev, "unable to map S/G table\n");
-   return -ENOMEM;
+   ret = -ENOMEM;
+   goto err;
}
 
append_seq_in_ptr(desc, edesc->sec4_sg_dma, ctx->ctx_len + buflen,
@@ -961,7 +965,8 @@ static int ahash_final_ctx(struct ahash_request *req)
digestsize);
if (dma_mapping_error(jrdev, edesc->dst_dma)) {
dev_err(jrdev, "unable to map dst\n");
-   return -ENOMEM;
+   ret = -ENOMEM;
+   goto err;
}
 
 #ifdef DEBUG
@@ -970,13 +975,14 @@ static int ahash_final_ctx(struct ahash_request *req)
 #endif
 
ret = caam_jr_enqueue(jrdev, desc, ahash_done_ctx_src, req);
-   if (!ret) {
-   ret = -EINPROGRESS;
-   } else {
-   ahash_unmap_ctx(jrdev, edesc, req, digestsize, DMA_FROM_DEVICE);
-   kfree(edesc);
-   }
+   if (ret)
+   goto err;
 
+   return -EINPROGRESS;
+
+err:
+   ahash_unmap_ctx(jrdev, edesc, req, digestsize, DMA_FROM_DEVICE);
+   kfree(edesc);
return ret;
 }
 
@@ -1027,7 +1033,7 @@ static int ahash_finup_ctx(struct ahash_request *req)
ret = ctx_map_to_sec4_sg(desc, jrdev, state, ctx->ctx_len,
 edesc->sec4_sg, DMA_TO_DEVICE);
if (ret)
-   return ret;
+   goto err;
 
state->buf_dma = try_buf_map_to_sec4_sg(jrdev, edesc->sec4_sg + 1,
buf, state->buf_dma, buflen,
@@ -1040,7 +1046,8 @@ static int ahash_finup_ctx(struct ahash_request *req)
sec4_sg_bytes, DMA_TO_DEVICE);
if (dma_mapping_error(jrdev, edesc->sec4_sg_dma)) {
dev_err(jrdev, "unable to map S/G table\n");
-   return

[PATCH 01/11] crypto: caam: fix DMA API mapping leak

2016-08-08 Thread Russell King 
caamhash contains this weird code:

src_nents = sg_count(req->src, req->nbytes);
dma_map_sg(jrdev, req->src, src_nents ? : 1, DMA_TO_DEVICE);
...
edesc->src_nents = src_nents;

sg_count() returns zero when sg_nents_for_len() returns zero or one.
This means we don't need to use a hardware scatterlist.  However,
setting src_nents to zero causes problems when we unmap:

if (edesc->src_nents)
dma_unmap_sg_chained(dev, req->src, edesc->src_nents,
 DMA_TO_DEVICE, edesc->chained);

as zero here means that we have no entries to unmap.  This causes us
to leak DMA mappings, where we map one scatterlist entry and then
fail to unmap it.

This can be fixed in two ways: either by writing the number of entries
that were requested of dma_map_sg(), or by reworking the "no SG
required" case.

We adopt the re-work solution here - we replace sg_count() with
sg_nents_for_len(), so src_nents now contains the real number of
scatterlist entries, and we then change the test for using the
hardware scatterlist to src_nents > 1 rather than just non-zero.

This change passes my sshd, openssl tests hashing /bin and tcrypt
tests.

Signed-off-by: Russell King 
---
 drivers/crypto/caam/caamhash.c | 26 +-
 1 file changed, 17 insertions(+), 9 deletions(-)

diff --git a/drivers/crypto/caam/caamhash.c b/drivers/crypto/caam/caamhash.c
index f1ecc8df8d41..85c8b048bdc1 100644
--- a/drivers/crypto/caam/caamhash.c
+++ b/drivers/crypto/caam/caamhash.c
@@ -1094,13 +1094,16 @@ static int ahash_digest(struct ahash_request *req)
u32 options;
int sh_len;
 
-   src_nents = sg_count(req->src, req->nbytes);
+   src_nents = sg_nents_for_len(req->src, req->nbytes);
if (src_nents < 0) {
dev_err(jrdev, "Invalid number of src SG.\n");
return src_nents;
}
-   dma_map_sg(jrdev, req->src, src_nents ? : 1, DMA_TO_DEVICE);
-   sec4_sg_bytes = src_nents * sizeof(struct sec4_sg_entry);
+   dma_map_sg(jrdev, req->src, src_nents, DMA_TO_DEVICE);
+   if (src_nents > 1)
+   sec4_sg_bytes = src_nents * sizeof(struct sec4_sg_entry);
+   else
+   sec4_sg_bytes = 0;
 
/* allocate space for base edesc and hw desc commands, link tables */
edesc = kzalloc(sizeof(*edesc) + sec4_sg_bytes + DESC_JOB_IO_LEN,
@@ -1118,7 +1121,7 @@ static int ahash_digest(struct ahash_request *req)
desc = edesc->hw_desc;
init_job_desc_shared(desc, ptr, sh_len, HDR_SHARE_DEFER | HDR_REVERSE);
 
-   if (src_nents) {
+   if (src_nents > 1) {
sg_to_sec4_sg_last(req->src, src_nents, edesc->sec4_sg, 0);
edesc->sec4_sg_dma = dma_map_single(jrdev, edesc->sec4_sg,
sec4_sg_bytes, DMA_TO_DEVICE);
@@ -1246,7 +1249,7 @@ static int ahash_update_no_ctx(struct ahash_request *req)
 
if (to_hash) {
src_nents = sg_nents_for_len(req->src,
-req->nbytes - (*next_buflen));
+req->nbytes - *next_buflen);
if (src_nents < 0) {
dev_err(jrdev, "Invalid number of src SG.\n");
return src_nents;
@@ -1450,13 +1453,18 @@ static int ahash_update_first(struct ahash_request *req)
to_hash = req->nbytes - *next_buflen;
 
if (to_hash) {
-   src_nents = sg_count(req->src, req->nbytes - (*next_buflen));
+   src_nents = sg_nents_for_len(req->src,
+req->nbytes - *next_buflen);
if (src_nents < 0) {
dev_err(jrdev, "Invalid number of src SG.\n");
return src_nents;
}
-   dma_map_sg(jrdev, req->src, src_nents ? : 1, DMA_TO_DEVICE);
-   sec4_sg_bytes = src_nents * sizeof(struct sec4_sg_entry);
+   dma_map_sg(jrdev, req->src, src_nents, DMA_TO_DEVICE);
+   if (src_nents > 1)
+   sec4_sg_bytes = src_nents *
+   sizeof(struct sec4_sg_entry);
+   else
+   sec4_sg_bytes = 0;
 
/*
 * allocate space for base edesc and hw desc commands,
@@ -1476,7 +1484,7 @@ static int ahash_update_first(struct ahash_request *req)
 DESC_JOB_IO_LEN;
edesc->dst_dma = 0;
 
-   if (src_nents) {
+   if (src_nents > 1) {
sg_to_sec4_sg_last(req->src, src_nents,
   edesc->sec4_sg, 0);
edesc->sec4_sg_dma = dma_map_single(jrdev,
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to

[PATCH 00/11] Further iMX CAAM updates

2016-08-08 Thread Russell King - ARM Linux 
This is a re-post (with hopefully bugs fixed from December's review).
Untested, because AF_ALG appears to be broken in 4.8-rc1.  Maybe
someone can provide some hints how to test using tcrypt please?

Here are further imx-caam updates that I've had since before the
previous merge window.  Please review and (I guess) if Freescale
folk can provide acks etc that would be nice.  Thanks.

 drivers/crypto/caam/caamhash.c | 540 ++---
 drivers/crypto/caam/intern.h   |   1 -
 drivers/crypto/caam/jr.c   |  25 +-
 3 files changed, 305 insertions(+), 261 deletions(-)

-- 
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 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 0/2] crypto: caam - authenc fixes

2016-08-08 Thread Herbert Xu 
On Thu, Aug 04, 2016 at 08:02:45PM +0300, Horia Geantă wrote:
> The first patch fixes a few typos in the encrypt shared descriptor
> used by echainiv(authenc) algorithms.
> 
> Second patch fixes the case when .setkey is called before .setauthsize,
> avoiding creating authenc descriptors with zero authsize.
> 
> Both patches are also being sent to -stable for v4.3+ kernels.

Both patches applied.  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: [PATCH] crypto: sha3 - Add missing ULL suffixes for 64-bit constants

2016-08-08 Thread Herbert Xu 
On Wed, Aug 03, 2016 at 07:37:03PM +0200, Geert Uytterhoeven wrote:
> On 32-bit (e.g. with m68k-linux-gnu-gcc-4.1):
> 
> crypto/sha3_generic.c:27: warning: integer constant is too large for 
> ‘long’ type
> crypto/sha3_generic.c:28: warning: integer constant is too large for 
> ‘long’ type
> crypto/sha3_generic.c:29: warning: integer constant is too large for 
> ‘long’ type
> crypto/sha3_generic.c:29: warning: integer constant is too large for 
> ‘long’ type
> crypto/sha3_generic.c:31: warning: integer constant is too large for 
> ‘long’ type
> crypto/sha3_generic.c:31: warning: integer constant is too large for 
> ‘long’ type
> crypto/sha3_generic.c:32: warning: integer constant is too large for 
> ‘long’ type
> crypto/sha3_generic.c:32: warning: integer constant is too large for 
> ‘long’ type
> crypto/sha3_generic.c:32: warning: integer constant is too large for 
> ‘long’ type
> crypto/sha3_generic.c:33: warning: integer constant is too large for 
> ‘long’ type
> crypto/sha3_generic.c:33: warning: integer constant is too large for 
> ‘long’ type
> crypto/sha3_generic.c:34: warning: integer constant is too large for 
> ‘long’ type
> crypto/sha3_generic.c:34: warning: integer constant is too large for 
> ‘long’ type
> 
> Fixes: 53964b9ee63b7075 ("crypto: sha3 - Add SHA-3 hash algorithm")
> Signed-off-by: Geert Uytterhoeven 

Patch applied.  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: [PATCH] crypto: crc32c-vpmsum - Convert to CPU feature based module autoloading

2016-08-08 Thread Herbert Xu 
Michael Ellerman  wrote:
>
> This is actually an arch/powerpc patch, so I'll merge it unless Herbert
> objects.

It's fine with me.

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

Re: [PATCH v2] RANDOM: ATH9K RNG delivers zero bits of entropy

2016-08-08 Thread Stephan Mueller 
Am Montag, 8. August 2016, 02:03:36 CEST schrieb Pan, Miaoqing:

Hi Miaoqing,

> The entropy was evaluated by crypto expert,  the analysis report show the
> ADC with at least 10bits and up to 22 bits of min-entropy for a 32 bits
> value, we conservatively assume the min-entropy is 10 bits out of 32 bits,
> so that's why set entropy quality  to  320/1024 = 10/32.  Also we have
> explained in the commit message why can't use the HW RNG framework.

Where is the description of the RNG, where is the test implementation? 
> 
> Otherwise, your patch will cause high CPU load,  as continuously read ADC
> data if entropy bits under write_wakeup_threshold.

The issue is that although you may have analyzed it, others are unable to 
measure the quality of the RNG and assess the design as well as the 
implementation of the RNG. This RNG is the only implementation of a hardware 
RNG that per default and without being able to change it at runtime injects 
data into the input_pool where the noise source cannot be audited. Note, even 
other respected RNG noise sources like the Intel RDRAND will not feed into /
dev/random per default in a way that dominates all other noise sources.

I would like to be able to deactivate that noise source to the extent that it 
does not cause /dev/random to unblock. The reason is that your noise source 
starts to dominate all other noise sources.

If you think that this patch is a challenge because your driver starts to 
spin, please help and offer another solution.
> 
> --
> Miaoqing
> 
> -Original Message-
> From: Stephan Mueller [mailto:smuel...@chronox.de]
> Sent: Sunday, August 07, 2016 5:36 PM
> To: Ted Tso 
> Cc: herb...@gondor.apana.org.au; linux-ker...@vger.kernel.org;
> linux-crypto@vger.kernel.org; ath9k-devel ;
> linux-wirel...@vger.kernel.org; ath9k-de...@lists.ath9k.org; Kalle Valo
> ; Jason Cooper  Subject: [PATCH
> v2] RANDOM: ATH9K RNG delivers zero bits of entropy
> 
> The ATH9K driver implements an RNG which is completely bypassing the
> standard Linux HW generator logic.
> 
> The RNG may or may not deliver entropy. Considering the conservative
> approach in treating entropy with respect to non-auditable sources, this
> patch changes the delivered entropy value to zero. The RNG still feeds data
> into the input_pool but it is assumed to have no entropy.
> 
> When the ATH9K RNG changes to use the HW RNG framework, it may re-enable 
the
> entropy estimation considering that a user can change that value at boot
> and runtime.
> 
> Reviewed-by: Jason Cooper 
> Signed-off-by: Stephan Mueller 
> ---
>  drivers/net/wireless/ath/ath9k/rng.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/net/wireless/ath/ath9k/rng.c
> b/drivers/net/wireless/ath/ath9k/rng.c index d38e50f..1ed8338 100644
> --- a/drivers/net/wireless/ath/ath9k/rng.c
> +++ b/drivers/net/wireless/ath/ath9k/rng.c
> @@ -22,7 +22,6 @@
>  #include "ar9003_phy.h"
> 
>  #define ATH9K_RNG_BUF_SIZE   320
> -#define ATH9K_RNG_ENTROPY(x) (((x) * 8 * 320) >> 10) /* quality: 320/1024
> */
> 
>  static int ath9k_rng_data_read(struct ath_softc *sc, u32 *buf, u32
> buf_size)  { @@ -92,8 +91,7 @@ static int ath9k_rng_kthread(void *data)
> fail_stats = 0;
> 
>   /* sleep until entropy bits under write_wakeup_threshold */
> - add_hwgenerator_randomness((void *)rng_buf, bytes_read,
> -ATH9K_RNG_ENTROPY(bytes_read));
> + add_hwgenerator_randomness((void *)rng_buf, bytes_read, 0);
>   }
> 
>   kfree(rng_buf);
> --
> 2.7.4



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