Re: [PATCH resend 4.9] hw_random: Don't use a stack buffer in add_early_randomness()

[Herbert Xu]

On Mon, Oct 17, 2016 at 10:06:27AM -0700, Andy Lutomirski wrote:
> hw_random carefully avoids using a stack buffer except in
> add_early_randomness().  This causes a crash in virtio_rng if
> CONFIG_VMAP_STACK=y.
> 
> Reported-by: Matt Mullins 
> Tested-by: Matt Mullins 
> Fixes: d3cc7996473a ("hwrng: fetch randomness only after device init")
> Signed-off-by: Andy Lutomirski 

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 v2 0/8] crypto: ARM/arm64 - big endian fixes

[Herbert Xu]

On Tue, Oct 18, 2016 at 01:14:38PM +0100, Ard Biesheuvel wrote:
> On 18 October 2016 at 12:49, Catalin Marinas  wrote:
> > On Tue, Oct 11, 2016 at 07:15:12PM +0100, Ard Biesheuvel wrote:
> >> As it turns out, none of the accelerated crypto routines under 
> >> arch/arm64/crypto
> >> currently work, or have ever worked correctly when built for big endian. 
> >> So this
> >> series fixes all of them. This v2 now includes a similar fix for 32-bit 
> >> ARM as
> >> well, and an additional fix for XTS which escaped my attention before.
> >>
> >> Each of these patches carries a fixes tag, and could be backported to 
> >> stable.
> >> However, for patches #1 and #5, the fixes tag denotes the oldest commit 
> >> that the
> >> fix is compatible with, not the patch that introduced the algorithm.
> >
> > I think for future reference, the Fixes tag should denote the commit
> > that introduced the issue. An explicit Cc: stable tag would state how
> > far back it should be applied.
> >
> 
> OK, that sounds reasonable.
> 
> >> Ard Biesheuvel (8):
> >>   crypto: arm64/aes-ce - fix for big endian
> >>   crypto: arm64/ghash-ce - fix for big endian
> >>   crypto: arm64/sha1-ce - fix for big endian
> >>   crypto: arm64/sha2-ce - fix for big endian
> >>   crypto: arm64/aes-ccm-ce: fix for big endian
> >>   crypto: arm64/aes-neon - fix for big endian
> >>   crypto: arm64/aes-xts-ce: fix for big endian
> >>   crypto: arm/aes-ce - fix for big endian
> >
> > The changes look fine to me but I can't claim I fully understand these
> > algorithms. FWIW:
> >
> > Acked-by: Catalin Marinas 
> >
> > (Will may pick them up for 4.9-rcX)
> 
> Thanks, although I was kind of expecting Herbert to pick these up,
> given that #8 affects ARM not arm64.
> 
> But if you (or Will) can pick up #1 to #7, that is also fine, then I
> can drop #8 into rmk's patch database.

I was planning merging these for 4.10.  But I'm fine with them
going through the arm tree.  Let me know what you guys want to
do.

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

[PATCH] crypto: ccp - Clean up the LSB slot allocation code

[Gary R Hook]

Fix a few problems revealed by testing: verify consistent
units, especially in public slot allocation. Percolate
some common initialization code up to a common routine.
Add some comments.

Signed-off-by: Gary R Hook 
---
 drivers/crypto/ccp/ccp-dev-v3.c |4 
 drivers/crypto/ccp/ccp-dev-v5.c |   20 
 drivers/crypto/ccp/ccp-dev.c|4 
 3 files changed, 16 insertions(+), 12 deletions(-)

diff --git a/drivers/crypto/ccp/ccp-dev-v3.c b/drivers/crypto/ccp/ccp-dev-v3.c
index 8d2dbac..7bc0998 100644
--- a/drivers/crypto/ccp/ccp-dev-v3.c
+++ b/drivers/crypto/ccp/ccp-dev-v3.c
@@ -404,10 +404,6 @@ static int ccp_init(struct ccp_device *ccp)
goto e_pool;
}
 
-   /* Initialize the queues used to wait for KSB space and suspend */
-   init_waitqueue_head(>sb_queue);
-   init_waitqueue_head(>suspend_queue);
-
dev_dbg(dev, "Starting threads...\n");
/* Create a kthread for each queue */
for (i = 0; i < ccp->cmd_q_count; i++) {
diff --git a/drivers/crypto/ccp/ccp-dev-v5.c b/drivers/crypto/ccp/ccp-dev-v5.c
index faf3cb3..ff7816a 100644
--- a/drivers/crypto/ccp/ccp-dev-v5.c
+++ b/drivers/crypto/ccp/ccp-dev-v5.c
@@ -21,6 +21,12 @@
 
 #include "ccp-dev.h"
 
+/* Allocate the requested number of contiguous LSB slots
+ * from the LSB bitmap. Look in the private range for this
+ * queue first; failing that, check the public area.
+ * If no space is available, wait around.
+ * Return: first slot number
+ */
 static u32 ccp_lsb_alloc(struct ccp_cmd_queue *cmd_q, unsigned int count)
 {
struct ccp_device *ccp;
@@ -50,7 +56,7 @@ static u32 ccp_lsb_alloc(struct ccp_cmd_queue *cmd_q, 
unsigned int count)
bitmap_set(ccp->lsbmap, start, count);
 
mutex_unlock(>sb_mutex);
-   return start * LSB_ITEM_SIZE;
+   return start;
}
 
ccp->sb_avail = 0;
@@ -63,17 +69,18 @@ static u32 ccp_lsb_alloc(struct ccp_cmd_queue *cmd_q, 
unsigned int count)
}
 }
 
+/* Free a number of LSB slots from the bitmap, starting at
+ * the indicated starting slot number.
+ */
 static void ccp_lsb_free(struct ccp_cmd_queue *cmd_q, unsigned int start,
 unsigned int count)
 {
-   int lsbno = start / LSB_SIZE;
-
if (!start)
return;
 
-   if (cmd_q->lsb == lsbno) {
+   if (cmd_q->lsb == start) {
/* An entry from the private LSB */
-   bitmap_clear(cmd_q->lsbmap, start % LSB_SIZE, count);
+   bitmap_clear(cmd_q->lsbmap, start, count);
} else {
/* From the shared LSBs */
struct ccp_device *ccp = cmd_q->ccp;
@@ -751,9 +758,6 @@ static int ccp5_init(struct ccp_device *ccp)
goto e_pool;
}
 
-   /* Initialize the queue used to suspend */
-   init_waitqueue_head(>suspend_queue);
-
dev_dbg(dev, "Loading LSB map...\n");
/* Copy the private LSB mask to the public registers */
status_lo = ioread32(ccp->io_regs + LSB_PRIVATE_MASK_LO_OFFSET);
diff --git a/drivers/crypto/ccp/ccp-dev.c b/drivers/crypto/ccp/ccp-dev.c
index d9885ce..653b5a5 100644
--- a/drivers/crypto/ccp/ccp-dev.c
+++ b/drivers/crypto/ccp/ccp-dev.c
@@ -478,6 +478,10 @@ struct ccp_device *ccp_alloc_struct(struct device *dev)
ccp->sb_count = KSB_COUNT;
ccp->sb_start = 0;
 
+   /* Initialize the wait queues */
+   init_waitqueue_head(>sb_queue);
+   init_waitqueue_head(>suspend_queue);
+
ccp->ord = ccp_increment_unit_ordinal();
snprintf(ccp->name, MAX_CCP_NAME_LEN, "ccp-%u", ccp->ord);
snprintf(ccp->rngname, MAX_CCP_NAME_LEN, "ccp-%u-rng", ccp->ord);

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] crypto: ccp - remove unneeded code

[Gary R Hook]

Clean up patch for an unneeded structure member.

Signed-off-by: Gary R Hook 
---
 drivers/crypto/ccp/ccp-dev.h |1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/crypto/ccp/ccp-dev.h b/drivers/crypto/ccp/ccp-dev.h
index 0d996fe..b96d788 100644
--- a/drivers/crypto/ccp/ccp-dev.h
+++ b/drivers/crypto/ccp/ccp-dev.h
@@ -515,7 +515,6 @@ struct ccp_op {
struct ccp_passthru_op passthru;
struct ccp_ecc_op ecc;
} u;
-   struct ccp_mem key;
 };
 
 static inline u32 ccp_addr_lo(struct ccp_dma_info *info)

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] crypto: ccp - change bitfield type to unsigned ints

[Gary R Hook]

Bit fields are not sensitive to endianness, so use
a transparent standard data type

Signed-off-by: Gary R Hook 
---
 drivers/crypto/ccp/ccp-dev.h |   42 +-
 1 file changed, 21 insertions(+), 21 deletions(-)

diff --git a/drivers/crypto/ccp/ccp-dev.h b/drivers/crypto/ccp/ccp-dev.h
index da5f4a6..0d996fe 100644
--- a/drivers/crypto/ccp/ccp-dev.h
+++ b/drivers/crypto/ccp/ccp-dev.h
@@ -541,23 +541,23 @@ static inline u32 ccp_addr_hi(struct ccp_dma_info *info)
  * word 7: upper 16 bits of key pointer; key memory type
  */
 struct dword0 {
-   __le32 soc:1;
-   __le32 ioc:1;
-   __le32 rsvd1:1;
-   __le32 init:1;
-   __le32 eom:1;   /* AES/SHA only */
-   __le32 function:15;
-   __le32 engine:4;
-   __le32 prot:1;
-   __le32 rsvd2:7;
+   unsigned int soc:1;
+   unsigned int ioc:1;
+   unsigned int rsvd1:1;
+   unsigned int init:1;
+   unsigned int eom:1; /* AES/SHA only */
+   unsigned int function:15;
+   unsigned int engine:4;
+   unsigned int prot:1;
+   unsigned int rsvd2:7;
 };
 
 struct dword3 {
-   __le32 src_hi:16;
-   __le32 src_mem:2;
-   __le32 lsb_cxt_id:8;
-   __le32 rsvd1:5;
-   __le32 fixed:1;
+   unsigned int  src_hi:16;
+   unsigned int  src_mem:2;
+   unsigned int  lsb_cxt_id:8;
+   unsigned int  rsvd1:5;
+   unsigned int  fixed:1;
 };
 
 union dword4 {
@@ -567,18 +567,18 @@ union dword4 {
 
 union dword5 {
struct {
-   __le32 dst_hi:16;
-   __le32 dst_mem:2;
-   __le32 rsvd1:13;
-   __le32 fixed:1;
+   unsigned int  dst_hi:16;
+   unsigned int  dst_mem:2;
+   unsigned int  rsvd1:13;
+   unsigned int  fixed:1;
} fields;
__le32 sha_len_hi;
 };
 
 struct dword7 {
-   __le32 key_hi:16;
-   __le32 key_mem:2;
-   __le32 rsvd1:14;
+   unsigned int  key_hi:16;
+   unsigned int  key_mem:2;
+   unsigned int  rsvd1:14;
 };
 
 struct ccp5_desc {

--
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 -next] crypto: ccp - Fix non static symbol warning

[Hook, Gary]

On 10/17/2016 10:08 AM, Wei Yongjun wrote:
> From: Wei Yongjun 
>
> Fixes the following sparse warning:
>
> drivers/crypto/ccp/ccp-dev.c:44:6: warning:
>  symbol 'ccp_error_codes' was not declared. Should it be static?
>
> Signed-off-by: Wei Yongjun 
> ---
>  drivers/crypto/ccp/ccp-dev.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/crypto/ccp/ccp-dev.c b/drivers/crypto/ccp/ccp-dev.c
> index cafa633..c25515a 100644
> --- a/drivers/crypto/ccp/ccp-dev.c
> +++ b/drivers/crypto/ccp/ccp-dev.c
> @@ -41,7 +41,7 @@ struct ccp_tasklet_data {
>  };
>
>  /* Human-readable error strings */
> -char *ccp_error_codes[] = {
> +static char *ccp_error_codes[] = {
>   "",
>   "ERR 01: ILLEGAL_ENGINE",
>   "ERR 02: ILLEGAL_KEY_ID",
>

Yes, excellent. Thank you.

Acked-by: Gary R Hook 

-- 
This is my day job. Follow me at:
IG/Twitter/Facebook: @grhookphoto
IG/Twitter/Facebook: @grhphotographer
--
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 -next] crypto: ccp - Fix non static symbol warning

[Gary R Hook]

On 10/17/2016 10:08 AM, Wei Yongjun wrote:

From: Wei Yongjun 

Fixes the following sparse warning:

drivers/crypto/ccp/ccp-dev.c:44:6: warning:
 symbol 'ccp_error_codes' was not declared. Should it be static?

Signed-off-by: Wei Yongjun 


Excellent. Thank you.

Acked-by: Gary R Hook 

--
This is my day job. Follow me at:
IG/Twitter/Facebook: @grhookphoto
IG/Twitter/Facebook: @grhphotographer
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] crypto: sun4i-ss: support the Security System PRNG

[Corentin Labbe]

From: LABBE Corentin 

The Security System have a PRNG.
This patch add support for it as an hwrng.

Signed-off-by: Corentin Labbe 
---
 drivers/crypto/Kconfig   |  8 
 drivers/crypto/sunxi-ss/Makefile |  1 +
 drivers/crypto/sunxi-ss/sun4i-ss-core.c  | 14 +++
 drivers/crypto/sunxi-ss/sun4i-ss-hwrng.c | 70 
 drivers/crypto/sunxi-ss/sun4i-ss.h   |  8 
 5 files changed, 101 insertions(+)
 create mode 100644 drivers/crypto/sunxi-ss/sun4i-ss-hwrng.c

diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 4d2b81f..38f7aca 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -538,6 +538,14 @@ config CRYPTO_DEV_SUN4I_SS
  To compile this driver as a module, choose M here: the module
  will be called sun4i-ss.
 
+config CRYPTO_DEV_SUN4I_SS_PRNG
+   bool "Support for Allwinner Security System PRNG"
+   depends on CRYPTO_DEV_SUN4I_SS
+   select HW_RANDOM
+   help
+ This driver provides kernel-side support for the Pseudo-Random
+ Number Generator found in the Security System.
+
 config CRYPTO_DEV_ROCKCHIP
tristate "Rockchip's Cryptographic Engine driver"
depends on OF && ARCH_ROCKCHIP
diff --git a/drivers/crypto/sunxi-ss/Makefile b/drivers/crypto/sunxi-ss/Makefile
index 8f4c7a2..ca049ee 100644
--- a/drivers/crypto/sunxi-ss/Makefile
+++ b/drivers/crypto/sunxi-ss/Makefile
@@ -1,2 +1,3 @@
 obj-$(CONFIG_CRYPTO_DEV_SUN4I_SS) += sun4i-ss.o
 sun4i-ss-y += sun4i-ss-core.o sun4i-ss-hash.o sun4i-ss-cipher.o
+sun4i-ss-$(CONFIG_CRYPTO_DEV_SUN4I_SS_PRNG) += sun4i-ss-hwrng.o
diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-core.c 
b/drivers/crypto/sunxi-ss/sun4i-ss-core.c
index 3ac6c6c..fa739de 100644
--- a/drivers/crypto/sunxi-ss/sun4i-ss-core.c
+++ b/drivers/crypto/sunxi-ss/sun4i-ss-core.c
@@ -359,6 +359,16 @@ static int sun4i_ss_probe(struct platform_device *pdev)
}
}
platform_set_drvdata(pdev, ss);
+
+#ifdef CONFIG_CRYPTO_DEV_SUN4I_SS_PRNG
+   /* Voluntarily made the PRNG optional */
+   err = sun4i_ss_hwrng_register(>hwrng);
+   if (!err)
+   dev_info(ss->dev, "sun4i-ss PRNG loaded");
+   else
+   dev_err(ss->dev, "sun4i-ss PRNG failed");
+#endif
+
return 0;
 error_alg:
i--;
@@ -386,6 +396,10 @@ static int sun4i_ss_remove(struct platform_device *pdev)
int i;
struct sun4i_ss_ctx *ss = platform_get_drvdata(pdev);
 
+#ifdef CONFIG_CRYPTO_DEV_SUN4I_SS_PRNG
+   sun4i_ss_hwrng_remove(>hwrng);
+#endif
+
for (i = 0; i < ARRAY_SIZE(ss_algs); i++) {
switch (ss_algs[i].type) {
case CRYPTO_ALG_TYPE_ABLKCIPHER:
diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-hwrng.c 
b/drivers/crypto/sunxi-ss/sun4i-ss-hwrng.c
new file mode 100644
index 000..95fadb7
--- /dev/null
+++ b/drivers/crypto/sunxi-ss/sun4i-ss-hwrng.c
@@ -0,0 +1,70 @@
+#include "sun4i-ss.h"
+
+static int sun4i_ss_hwrng_init(struct hwrng *hwrng)
+{
+   struct sun4i_ss_ctx *ss;
+
+   ss = container_of(hwrng, struct sun4i_ss_ctx, hwrng);
+   get_random_bytes(ss->seed, SS_SEED_LEN);
+
+   return 0;
+}
+
+static int sun4i_ss_hwrng_read(struct hwrng *hwrng, void *buf,
+  size_t max, bool wait)
+{
+   int i;
+   u32 v;
+   u32 *data = buf;
+   const u32 mode = SS_OP_PRNG | SS_PRNG_CONTINUE | SS_ENABLED;
+   size_t len;
+   struct sun4i_ss_ctx *ss;
+
+   ss = container_of(hwrng, struct sun4i_ss_ctx, hwrng);
+   len = min_t(size_t, SS_DATA_LEN, max);
+
+   spin_lock_bh(>slock);
+
+   writel(mode, ss->base + SS_CTL);
+
+   /* write the seed */
+   for (i = 0; i < SS_SEED_LEN / 4; i++)
+   writel(ss->seed[i], ss->base + SS_KEY0 + i * 4);
+   writel(mode | SS_PRNG_START, ss->base + SS_CTL);
+
+   /* Read the random data */
+   readsl(ss->base + SS_TXFIFO, data, len / 4);
+
+   if (len % 4 > 0) {
+   v = readl(ss->base + SS_TXFIFO);
+   memcpy(data + len / 4, , len % 4);
+   }
+
+   /* Update the seed */
+   for (i = 0; i < SS_SEED_LEN / 4; i++) {
+   v = readl(ss->base + SS_KEY0 + i * 4);
+   ss->seed[i] = v;
+   }
+
+   writel(0, ss->base + SS_CTL);
+   spin_unlock_bh(>slock);
+   return len;
+}
+
+int sun4i_ss_hwrng_register(struct hwrng *hwrng)
+{
+   hwrng->name = "sun4i Security System PRNG";
+   hwrng->init = sun4i_ss_hwrng_init;
+   hwrng->read = sun4i_ss_hwrng_read;
+   hwrng->quality = 1000;
+
+   /* Cannot use devm_hwrng_register() since we need to hwrng_unregister
+* before stopping clocks/regulator
+*/
+   return hwrng_register(hwrng);
+}
+
+void sun4i_ss_hwrng_remove(struct hwrng *hwrng)
+{
+   hwrng_unregister(hwrng);
+}
diff --git a/drivers/crypto/sunxi-ss/sun4i-ss.h 

Re: [PATCH v2 0/8] crypto: ARM/arm64 - big endian fixes

[Ard Biesheuvel]

On 18 October 2016 at 12:49, Catalin Marinas  wrote:
> On Tue, Oct 11, 2016 at 07:15:12PM +0100, Ard Biesheuvel wrote:
>> As it turns out, none of the accelerated crypto routines under 
>> arch/arm64/crypto
>> currently work, or have ever worked correctly when built for big endian. So 
>> this
>> series fixes all of them. This v2 now includes a similar fix for 32-bit ARM 
>> as
>> well, and an additional fix for XTS which escaped my attention before.
>>
>> Each of these patches carries a fixes tag, and could be backported to stable.
>> However, for patches #1 and #5, the fixes tag denotes the oldest commit that 
>> the
>> fix is compatible with, not the patch that introduced the algorithm.
>
> I think for future reference, the Fixes tag should denote the commit
> that introduced the issue. An explicit Cc: stable tag would state how
> far back it should be applied.
>

OK, that sounds reasonable.

>> Ard Biesheuvel (8):
>>   crypto: arm64/aes-ce - fix for big endian
>>   crypto: arm64/ghash-ce - fix for big endian
>>   crypto: arm64/sha1-ce - fix for big endian
>>   crypto: arm64/sha2-ce - fix for big endian
>>   crypto: arm64/aes-ccm-ce: fix for big endian
>>   crypto: arm64/aes-neon - fix for big endian
>>   crypto: arm64/aes-xts-ce: fix for big endian
>>   crypto: arm/aes-ce - fix for big endian
>
> The changes look fine to me but I can't claim I fully understand these
> algorithms. FWIW:
>
> Acked-by: Catalin Marinas 
>
> (Will may pick them up for 4.9-rcX)

Thanks, although I was kind of expecting Herbert to pick these up,
given that #8 affects ARM not arm64.

But if you (or Will) can pick up #1 to #7, that is also fine, then I
can drop #8 into rmk's patch database.

Thanks,
Ard,
--
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 0/8] crypto: ARM/arm64 - big endian fixes

[Catalin Marinas]

On Tue, Oct 11, 2016 at 07:15:12PM +0100, Ard Biesheuvel wrote:
> As it turns out, none of the accelerated crypto routines under 
> arch/arm64/crypto
> currently work, or have ever worked correctly when built for big endian. So 
> this
> series fixes all of them. This v2 now includes a similar fix for 32-bit ARM as
> well, and an additional fix for XTS which escaped my attention before.
> 
> Each of these patches carries a fixes tag, and could be backported to stable.
> However, for patches #1 and #5, the fixes tag denotes the oldest commit that 
> the
> fix is compatible with, not the patch that introduced the algorithm.

I think for future reference, the Fixes tag should denote the commit
that introduced the issue. An explicit Cc: stable tag would state how
far back it should be applied.

> Ard Biesheuvel (8):
>   crypto: arm64/aes-ce - fix for big endian
>   crypto: arm64/ghash-ce - fix for big endian
>   crypto: arm64/sha1-ce - fix for big endian
>   crypto: arm64/sha2-ce - fix for big endian
>   crypto: arm64/aes-ccm-ce: fix for big endian
>   crypto: arm64/aes-neon - fix for big endian
>   crypto: arm64/aes-xts-ce: fix for big endian
>   crypto: arm/aes-ce - fix for big endian

The changes look fine to me but I can't claim I fully understand these
algorithms. FWIW:

Acked-by: Catalin Marinas 

(Will may pick them up for 4.9-rcX)
--
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 0/8] crypto: ARM/arm64 - big endian fixes

[Ard Biesheuvel]

On 11 October 2016 at 19:15, Ard Biesheuvel  wrote:
> As it turns out, none of the accelerated crypto routines under 
> arch/arm64/crypto
> currently work, or have ever worked correctly when built for big endian. So 
> this
> series fixes all of them. This v2 now includes a similar fix for 32-bit ARM as
> well, and an additional fix for XTS which escaped my attention before.
>
> Each of these patches carries a fixes tag, and could be backported to stable.
> However, for patches #1 and #5, the fixes tag denotes the oldest commit that 
> the
> fix is compatible with, not the patch that introduced the algorithm. This is 
> due
> to the fact that the key schedules are incompatible between generic AES and 
> the
> arm64 Crypto Extensions implementation (but only when building for big endian)
> This is not a problem in practice, but it does mean that the AES-CCM and AES 
> in
> EBC/CBC/CTR/XTS mode implementations before v3.19 require a different fix, 
> i.e.,
> one that is compatible with the generic AES key schedule generation code 
> (which
> it currently no longer uses)
>
> In any case, please apply with cc to stable.
>

Ping?

> Ard Biesheuvel (8):
>   crypto: arm64/aes-ce - fix for big endian
>   crypto: arm64/ghash-ce - fix for big endian
>   crypto: arm64/sha1-ce - fix for big endian
>   crypto: arm64/sha2-ce - fix for big endian
>   crypto: arm64/aes-ccm-ce: fix for big endian
>   crypto: arm64/aes-neon - fix for big endian
>   crypto: arm64/aes-xts-ce: fix for big endian
>   crypto: arm/aes-ce - fix for big endian
>
>  arch/arm/crypto/aes-ce-glue.c   |  5 ++
>  arch/arm64/crypto/aes-ce-ccm-core.S | 53 ++--
>  arch/arm64/crypto/aes-ce-cipher.c   | 25 +
>  arch/arm64/crypto/aes-ce.S  |  1 +
>  arch/arm64/crypto/aes-modes.S   |  3 +-
>  arch/arm64/crypto/aes-neon.S| 25 +
>  arch/arm64/crypto/ghash-ce-core.S   |  6 +--
>  arch/arm64/crypto/sha1-ce-core.S|  4 +-
>  arch/arm64/crypto/sha2-ce-core.S|  4 +-
>  9 files changed, 72 insertions(+), 54 deletions(-)
>
> --
> 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

[PATCH 3/5] crypto: arm/ghash-ce - enable module autoloading based on CPU feature bits

[Ard Biesheuvel]

Make the module autoloadable by tying it to the CPU feature bit that
describes whether the optional instructions it relies on are implemented
by the current CPU.

Signed-off-by: Ard Biesheuvel 
---
 arch/arm/crypto/ghash-ce-glue.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/arch/arm/crypto/ghash-ce-glue.c b/arch/arm/crypto/ghash-ce-glue.c
index 7546b3c02466..6bac8bea9f1e 100644
--- a/arch/arm/crypto/ghash-ce-glue.c
+++ b/arch/arm/crypto/ghash-ce-glue.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -311,9 +312,6 @@ static int __init ghash_ce_mod_init(void)
 {
int err;
 
-   if (!(elf_hwcap2 & HWCAP2_PMULL))
-   return -ENODEV;
-
err = crypto_register_shash(_alg);
if (err)
return err;
@@ -334,5 +332,5 @@ static void __exit ghash_ce_mod_exit(void)
crypto_unregister_shash(_alg);
 }
 
-module_init(ghash_ce_mod_init);
+module_cpu_feature_match(PMULL, ghash_ce_mod_init);
 module_exit(ghash_ce_mod_exit);
-- 
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

[PATCH 0/5] ARM: add module autoloading support for crypto modules

[Ard Biesheuvel]

This series wires up the crypto modules that use the ARM 32-bit versions of
the ARMv8 Crypto Extensions to udev autoloading, by exposing the HWCAP2
feature bits via the CPU modalias. This is very similar to the arm64
implementation, with the notable exception that ARM has its CPU feature
definitions split across HWCAP and HWCAP2.

Given that the crypto feature bits are all exposed via HWCAP2, and considering
that there are currently no features exposed via HWCAP that are relevant to
udev module autoloading, exposing HWCAP2 only should be sufficient, at least
for now.

Note to Herbert: patches #2 - #5 all depend on #1, which requires an ack from
Russell, so please don't pull anything until #1 has been acked and/or merged.

Ard Biesheuvel (5):
  ARM: wire up HWCAP2 feature bits to the CPU modalias
  crypto: arm/aes-ce - enable module autoloading based on CPU feature
bits
  crypto: arm/ghash-ce - enable module autoloading based on CPU feature
bits
  crypto: arm/sha1-ce - enable module autoloading based on CPU feature
bits
  crypto: arm/sha2-ce - enable module autoloading based on CPU feature
bits

 arch/arm/Kconfig  |  1 +
 arch/arm/crypto/aes-ce-glue.c |  5 ++-
 arch/arm/crypto/ghash-ce-glue.c   |  6 ++--
 arch/arm/crypto/sha1-ce-glue.c|  5 ++-
 arch/arm/crypto/sha2-ce-glue.c|  5 ++-
 arch/arm/include/asm/cpufeature.h | 32 
 6 files changed, 41 insertions(+), 13 deletions(-)
 create mode 100644 arch/arm/include/asm/cpufeature.h

-- 
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

[PATCH 1/5] ARM: wire up HWCAP2 feature bits to the CPU modalias

[Ard Biesheuvel]

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 
---
 arch/arm/Kconfig  |  1 +
 arch/arm/include/asm/cpufeature.h | 32 
 2 files changed, 33 insertions(+)

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 ..19c3901a
--- /dev/null
+++ b/arch/arm/include/asm/cpufeature.h
@@ -0,0 +1,32 @@
+/*
+ * Copyright (C) 2016 Linaro Ltd. 
+ *
+ * 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 
+
+/*
+ * 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

--
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 2/5] crypto: arm/aes-ce - enable module autoloading based on CPU feature bits

[Ard Biesheuvel]

Make the module autoloadable by tying it to the CPU feature bit that
describes whether the optional instructions it relies on are implemented
by the current CPU.

Signed-off-by: Ard Biesheuvel 
---
 arch/arm/crypto/aes-ce-glue.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/arm/crypto/aes-ce-glue.c b/arch/arm/crypto/aes-ce-glue.c
index aef022a87c53..5b1af6f8b2b5 100644
--- a/arch/arm/crypto/aes-ce-glue.c
+++ b/arch/arm/crypto/aes-ce-glue.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -515,8 +516,6 @@ static struct crypto_alg aes_algs[] = { {
 
 static int __init aes_init(void)
 {
-   if (!(elf_hwcap2 & HWCAP2_AES))
-   return -ENODEV;
return crypto_register_algs(aes_algs, ARRAY_SIZE(aes_algs));
 }
 
@@ -525,5 +524,5 @@ static void __exit aes_exit(void)
crypto_unregister_algs(aes_algs, ARRAY_SIZE(aes_algs));
 }
 
-module_init(aes_init);
+module_cpu_feature_match(AES, aes_init);
 module_exit(aes_exit);
-- 
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

[PATCH 4/5] crypto: arm/sha1-ce - enable module autoloading based on CPU feature bits

[Ard Biesheuvel]

Make the module autoloadable by tying it to the CPU feature bit that
describes whether the optional instructions it relies on are implemented
by the current CPU.

Signed-off-by: Ard Biesheuvel 
---
 arch/arm/crypto/sha1-ce-glue.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/arm/crypto/sha1-ce-glue.c b/arch/arm/crypto/sha1-ce-glue.c
index 80bc2fcd241a..555f72b5e659 100644
--- a/arch/arm/crypto/sha1-ce-glue.c
+++ b/arch/arm/crypto/sha1-ce-glue.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -82,8 +83,6 @@ static struct shash_alg alg = {
 
 static int __init sha1_ce_mod_init(void)
 {
-   if (!(elf_hwcap2 & HWCAP2_SHA1))
-   return -ENODEV;
return crypto_register_shash();
 }
 
@@ -92,5 +91,5 @@ static void __exit sha1_ce_mod_fini(void)
crypto_unregister_shash();
 }
 
-module_init(sha1_ce_mod_init);
+module_cpu_feature_match(SHA1, sha1_ce_mod_init);
 module_exit(sha1_ce_mod_fini);
-- 
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

[PATCH 5/5] crypto: arm/sha2-ce - enable module autoloading based on CPU feature bits

[Ard Biesheuvel]

Make the module autoloadable by tying it to the CPU feature bit that
describes whether the optional instructions it relies on are implemented
by the current CPU.

Signed-off-by: Ard Biesheuvel 
---
 arch/arm/crypto/sha2-ce-glue.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/arm/crypto/sha2-ce-glue.c b/arch/arm/crypto/sha2-ce-glue.c
index 0755b2d657f3..df4dcef054ae 100644
--- a/arch/arm/crypto/sha2-ce-glue.c
+++ b/arch/arm/crypto/sha2-ce-glue.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -100,8 +101,6 @@ static struct shash_alg algs[] = { {
 
 static int __init sha2_ce_mod_init(void)
 {
-   if (!(elf_hwcap2 & HWCAP2_SHA2))
-   return -ENODEV;
return crypto_register_shashes(algs, ARRAY_SIZE(algs));
 }
 
@@ -110,5 +109,5 @@ static void __exit sha2_ce_mod_fini(void)
crypto_unregister_shashes(algs, ARRAY_SIZE(algs));
 }
 
-module_init(sha2_ce_mod_init);
+module_cpu_feature_match(SHA2, sha2_ce_mod_init);
 module_exit(sha2_ce_mod_fini);
-- 
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