Re: [bug] sha1-avx2 and read beyond

2017-07-03 Thread Herbert Xu 
On Mon, Jul 03, 2017 at 08:33:44PM +0800, Herbert Xu wrote:
> On Sat, Jun 24, 2017 at 12:56:52AM +, Albrekht, Ilya wrote:
> > Hello all,
> > 
> > I'm sorry for late reply (I was out of office for a month).
> > 
> > It's been a while since we touched this code. We are going to do our best 
> > to support it. I'll be back to the office earlier next week and will figure 
> > out the fix ASAP.
> 
> Any update on this?

For the time being I'm going to disable this:

---8<---
Subject: crypto: sha1-ssse3 - Disable avx2

It has been reported that sha1-avx2 can cause page faults by reading
beyond the end of the input.  This patch disables it until it can be
fixed.

Cc: 
Fixes: 7c1da8d0d046 ("crypto: sha - SHA1 transform x86_64 AVX2")
Reported-by: Jan Stancek 
Signed-off-by: Herbert Xu 

diff --git a/arch/x86/crypto/sha1_ssse3_glue.c 
b/arch/x86/crypto/sha1_ssse3_glue.c
index fc61739..f960a04 100644
--- a/arch/x86/crypto/sha1_ssse3_glue.c
+++ b/arch/x86/crypto/sha1_ssse3_glue.c
@@ -201,7 +201,7 @@ asmlinkage void sha1_transform_avx2(u32 *digest, const char 
*data,
 
 static bool avx2_usable(void)
 {
-   if (avx_usable() && boot_cpu_has(X86_FEATURE_AVX2)
+   if (false && avx_usable() && boot_cpu_has(X86_FEATURE_AVX2)
&& boot_cpu_has(X86_FEATURE_BMI1)
&& boot_cpu_has(X86_FEATURE_BMI2))
return true;

-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

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

2017-07-03 Thread Corentin Labbe 
The Security System has a PRNG, this patch adds support for it via
crypto_rng.

Signed-off-by: Corentin Labbe 
---

Change since v4
- Fixed some spelling issue in Kconfig and patch description

Changes since v3 (note: the v3 miss changes and version tag sorry)
- Replaced all len values with bits / BITS_PER_LONG or BITS_PER_BYTE

Changes since v2
 - converted to crypto_rng

Changes since v1:
 - Replaced all spin_lock_bh by simple spin_lock
 - Removed handling of size not modulo 4 which will never happen
 - Added add_random_ready_callback()

 drivers/crypto/Kconfig  |  8 +
 drivers/crypto/sunxi-ss/Makefile|  1 +
 drivers/crypto/sunxi-ss/sun4i-ss-core.c | 30 ++
 drivers/crypto/sunxi-ss/sun4i-ss-prng.c | 56 +
 drivers/crypto/sunxi-ss/sun4i-ss.h  | 11 +++
 5 files changed, 106 insertions(+)
 create mode 100644 drivers/crypto/sunxi-ss/sun4i-ss-prng.c

diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index ab82536d64e2..99245f9c9d58 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -618,6 +618,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 CRYPTO_RNG
+   help
+ Select this option if you want to provide 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 8f4c7a273141..ccb893219079 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-prng.o
diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-core.c 
b/drivers/crypto/sunxi-ss/sun4i-ss-core.c
index 02ad8256e900..1547cbe13dc2 100644
--- a/drivers/crypto/sunxi-ss/sun4i-ss-core.c
+++ b/drivers/crypto/sunxi-ss/sun4i-ss-core.c
@@ -213,6 +213,23 @@ static struct sun4i_ss_alg_template ss_algs[] = {
}
}
 },
+#ifdef CONFIG_CRYPTO_DEV_SUN4I_SS_PRNG
+{
+   .type = CRYPTO_ALG_TYPE_RNG,
+   .alg.rng = {
+   .base = {
+   .cra_name   = "stdrng",
+   .cra_driver_name= "sun4i_ss_rng",
+   .cra_priority   = 300,
+   .cra_ctxsize= 0,
+   .cra_module = THIS_MODULE,
+   },
+   .generate   = sun4i_ss_prng_generate,
+   .seed   = sun4i_ss_prng_seed,
+   .seedsize   = SS_SEED_LEN / BITS_PER_BYTE,
+   }
+},
+#endif
 };
 
 static int sun4i_ss_probe(struct platform_device *pdev)
@@ -355,6 +372,13 @@ static int sun4i_ss_probe(struct platform_device *pdev)
goto error_alg;
}
break;
+   case CRYPTO_ALG_TYPE_RNG:
+   err = crypto_register_rng(_algs[i].alg.rng);
+   if (err) {
+   dev_err(ss->dev, "Fail to register %s\n",
+   ss_algs[i].alg.rng.base.cra_name);
+   }
+   break;
}
}
platform_set_drvdata(pdev, ss);
@@ -369,6 +393,9 @@ static int sun4i_ss_probe(struct platform_device *pdev)
case CRYPTO_ALG_TYPE_AHASH:
crypto_unregister_ahash(_algs[i].alg.hash);
break;
+   case CRYPTO_ALG_TYPE_RNG:
+   crypto_unregister_rng(_algs[i].alg.rng);
+   break;
}
}
if (ss->reset)
@@ -393,6 +420,9 @@ static int sun4i_ss_remove(struct platform_device *pdev)
case CRYPTO_ALG_TYPE_AHASH:
crypto_unregister_ahash(_algs[i].alg.hash);
break;
+   case CRYPTO_ALG_TYPE_RNG:
+   crypto_unregister_rng(_algs[i].alg.rng);
+   break;
}
}
 
diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-prng.c 
b/drivers/crypto/sunxi-ss/sun4i-ss-prng.c
new file mode 100644
index ..0d01d1624252
--- /dev/null
+++ b/drivers/crypto/sunxi-ss/sun4i-ss-prng.c
@@ -0,0 +1,56 @@
+#include "sun4i-ss.h"
+
+int sun4i_ss_prng_seed(struct crypto_rng *tfm, const u8 *seed,
+  unsigned int slen)
+{
+   struct sun4i_ss_alg_template *algt;
+

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

2017-07-03 Thread Corentin Labbe 
On Mon, Jun 26, 2017 at 02:36:43PM +0200, Frans Klaver wrote:
> Hi,
> 
> On Mon, Jun 26, 2017 at 2:20 PM, Corentin Labbe
>  wrote:
> > The Security System have a PRNG, this patch add support for it via
> > crypto_rng.
> 
> s,have,has,
> s,add,adds,
> 
> >
> > Signed-off-by: Corentin Labbe 
> > ---
> >
> > Changes since v3 (note: the v3 miss changes and version tag sorry)
> > - Replaced all len values with bits / BITS_PER_LONG or BITS_PER_BYTE
> >
> > Changes since v2
> >  - converted to crypto_rng
> >
> > Changes since v1:
> >  - Replaced all spin_lock_bh by simple spin_lock
> >  - Removed handling of size not modulo 4 which will never happen
> >  - Added add_random_ready_callback()
> >
> >  drivers/crypto/Kconfig  |  8 +
> >  drivers/crypto/sunxi-ss/Makefile|  1 +
> >  drivers/crypto/sunxi-ss/sun4i-ss-core.c | 30 ++
> >  drivers/crypto/sunxi-ss/sun4i-ss-prng.c | 56 
> > +
> >  drivers/crypto/sunxi-ss/sun4i-ss.h  | 11 +++
> >  5 files changed, 106 insertions(+)
> >  create mode 100644 drivers/crypto/sunxi-ss/sun4i-ss-prng.c
> >
> > diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
> > index ab82536d64e2..bde0b102eb70 100644
> > --- a/drivers/crypto/Kconfig
> > +++ b/drivers/crypto/Kconfig
> > @@ -618,6 +618,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 CRYPTO_RNG
> > +   help
> > + Select this option if you to provides kernel-side support for
> > + the Pseudo-Random Number Generator found in the Security System.
> 
> This sentence does not parse. "Select this option if you want to
> provide kernel-side for ...". Alternatively: "This option enables
> kernel-side support for ..."
> 
> Frans

Thanks, I will change it.

Re: [PATCH v3 RESEND 5/5] crypto: ccp - remove ccp_present() check from device initialize

2017-07-03 Thread Gary R Hook 

On 06/29/2017 11:54 AM, Singh, Brijesh wrote:

Since SP device driver supports multiples devices (e.g CCP, PSP), we
should not fail the driver init just because CCP device is not found.

Signed-off-by: Brijesh Singh 


Acked-by: Gary R Hook 


---
 drivers/crypto/ccp/sp-dev.c | 12 
 1 file changed, 12 deletions(-)

diff --git a/drivers/crypto/ccp/sp-dev.c b/drivers/crypto/ccp/sp-dev.c
index edbf1bd9..a017233 100644
--- a/drivers/crypto/ccp/sp-dev.c
+++ b/drivers/crypto/ccp/sp-dev.c
@@ -244,12 +244,6 @@ static int __init sp_mod_init(void)
 if (ret)
 return ret;

-   /* Don't leave the driver loaded if init failed */
-   if (ccp_present() != 0) {
-   sp_pci_exit();
-   return -ENODEV;
-   }
-
 return 0;
 #endif

@@ -260,12 +254,6 @@ static int __init sp_mod_init(void)
 if (ret)
 return ret;

-   /* Don't leave the driver loaded if init failed */
-   if (ccp_present() != 0) {
-   sp_platform_exit();
-   return -ENODEV;
-   }
-
 return 0;
 #endif

--
2.9.4

Re: [PATCH v3 RESEND 4/5] crypto: ccp - rename ccp driver initialize files as sp device

2017-07-03 Thread Gary R Hook 

On 06/29/2017 11:54 AM, Singh, Brijesh wrote:

CCP device initializes is now integerated into higher level SP device,
to avoid the confusion lets rename the ccp driver initialization files
(ccp-platform.c->sp-platform.c, ccp-pci.c->sp-pci.c). The patch does not
make any functional changes other than renaming file and structures

Signed-off-by: Brijesh Singh 


Acked-by: Gary R Hook 


---
 drivers/crypto/ccp/Makefile|  4 +-
 drivers/crypto/ccp/ccp-dev.h   |  6 --
 drivers/crypto/ccp/sp-dev.c| 12 ++--
 drivers/crypto/ccp/{ccp-pci.c => sp-pci.c} | 80
+++---
 .../crypto/ccp/{ccp-platform.c => sp-platform.c}   | 78
++---
 5 files changed, 87 insertions(+), 93 deletions(-)
 rename drivers/crypto/ccp/{ccp-pci.c => sp-pci.c} (71%)
 rename drivers/crypto/ccp/{ccp-platform.c => sp-platform.c} (66%)

diff --git a/drivers/crypto/ccp/Makefile b/drivers/crypto/ccp/Makefile
index d2f1b52..5f2adc5 100644
--- a/drivers/crypto/ccp/Makefile
+++ b/drivers/crypto/ccp/Makefile
@@ -1,12 +1,12 @@
 obj-$(CONFIG_CRYPTO_DEV_CCP_DD) += ccp.o
-ccp-objs  := sp-dev.o ccp-platform.o
+ccp-objs  := sp-dev.o sp-platform.o
 ccp-$(CONFIG_CRYPTO_DEV_SP_CCP) += ccp-dev.o \
 ccp-ops.o \
 ccp-dev-v3.o \
 ccp-dev-v5.o \
 ccp-dmaengine.o \
 ccp-debugfs.o
-ccp-$(CONFIG_PCI) += ccp-pci.o
+ccp-$(CONFIG_PCI) += sp-pci.o

 obj-$(CONFIG_CRYPTO_DEV_CCP_CRYPTO) += ccp-crypto.o
 ccp-crypto-objs := ccp-crypto-main.o \
diff --git a/drivers/crypto/ccp/ccp-dev.h b/drivers/crypto/ccp/ccp-dev.h
index 193f309..b959e24 100644
--- a/drivers/crypto/ccp/ccp-dev.h
+++ b/drivers/crypto/ccp/ccp-dev.h
@@ -626,12 +626,6 @@ struct ccp5_desc {
 struct dword7 dw7;
 };

-int ccp_pci_init(void);
-void ccp_pci_exit(void);
-
-int ccp_platform_init(void);
-void ccp_platform_exit(void);
-
 void ccp_add_device(struct ccp_device *ccp);
 void ccp_del_device(struct ccp_device *ccp);

diff --git a/drivers/crypto/ccp/sp-dev.c b/drivers/crypto/ccp/sp-dev.c
index 44e76e5..edbf1bd9 100644
--- a/drivers/crypto/ccp/sp-dev.c
+++ b/drivers/crypto/ccp/sp-dev.c
@@ -240,13 +240,13 @@ static int __init sp_mod_init(void)
 #ifdef CONFIG_X86
 int ret;

-   ret = ccp_pci_init();
+   ret = sp_pci_init();
 if (ret)
 return ret;

 /* Don't leave the driver loaded if init failed */
 if (ccp_present() != 0) {
-   ccp_pci_exit();
+   sp_pci_exit();
 return -ENODEV;
 }

@@ -256,13 +256,13 @@ static int __init sp_mod_init(void)
 #ifdef CONFIG_ARM64
 int ret;

-   ret = ccp_platform_init();
+   ret = sp_platform_init();
 if (ret)
 return ret;

 /* Don't leave the driver loaded if init failed */
 if (ccp_present() != 0) {
-   ccp_platform_exit();
+   sp_platform_exit();
 return -ENODEV;
 }

@@ -275,11 +275,11 @@ static int __init sp_mod_init(void)
 static void __exit sp_mod_exit(void)
 {
 #ifdef CONFIG_X86
-   ccp_pci_exit();
+   sp_pci_exit();
 #endif

 #ifdef CONFIG_ARM64
-   ccp_platform_exit();
+   sp_platform_exit();
 #endif
 }

diff --git a/drivers/crypto/ccp/ccp-pci.c b/drivers/crypto/ccp/sp-pci.c
similarity index 71%
rename from drivers/crypto/ccp/ccp-pci.c
rename to drivers/crypto/ccp/sp-pci.c
index b29a093..9859aa6 100644
--- a/drivers/crypto/ccp/ccp-pci.c
+++ b/drivers/crypto/ccp/sp-pci.c
@@ -1,5 +1,5 @@
 /*
- * AMD Cryptographic Coprocessor (CCP) driver
+ * AMD Secure Processor device driver
  *
  * Copyright (C) 2013,2016 Advanced Micro Devices, Inc.
  *
@@ -28,35 +28,35 @@

 #define MSIX_VECTORS2

-struct ccp_pci {
+struct sp_pci {
 int msix_count;
 struct msix_entry msix_entry[MSIX_VECTORS];
 };

-static int ccp_get_msix_irqs(struct sp_device *sp)
+static int sp_get_msix_irqs(struct sp_device *sp)
 {
-   struct ccp_pci *ccp_pci = sp->dev_specific;
+   struct sp_pci *sp_pci = sp->dev_specific;
 struct device *dev = sp->dev;
 struct pci_dev *pdev = to_pci_dev(dev);
 int v, ret;

-   for (v = 0; v < ARRAY_SIZE(ccp_pci->msix_entry); v++)
-   ccp_pci->msix_entry[v].entry = v;
+   for (v = 0; v < ARRAY_SIZE(sp_pci->msix_entry); v++)
+   sp_pci->msix_entry[v].entry = v;

-   ret = pci_enable_msix_range(pdev, ccp_pci->msix_entry, 1, v);
+   ret = pci_enable_msix_range(pdev, sp_pci->msix_entry, 1, v);
 if (ret < 0)
 return ret;

-   ccp_pci->msix_count = ret;
+   sp_pci->msix_count = ret;
 sp->use_tasklet = true;

-   sp->psp_irq = ccp_pci->msix_entry[0].vector;
-   sp->ccp_irq = (ccp_pci->msix_count > 1) ?
ccp_pci->msix_entry[1].vector
-  :
ccp_pci->msix_entry[0].vector;
+

Re: [PATCH v3 RESEND 2/5] crypto: ccp - Introduce the AMD Secure Processor device

2017-07-03 Thread Gary R Hook 

On 06/29/2017 11:54 AM, Singh, Brijesh wrote:

The CCP device is part of the AMD Secure Processor. In order to expand
the usage of the AMD Secure Processor, create a framework that allows
functional components of the AMD Secure Processor to be initialized and
handled appropriately.

Signed-off-by: Brijesh Singh 


Acked-by: Gary R Hook 


---
 drivers/crypto/Kconfig|   6 +-
 drivers/crypto/ccp/Kconfig|  21 +++--
 drivers/crypto/ccp/Makefile   |   4 +-
 drivers/crypto/ccp/ccp-dev-v3.c   |   4 +-
 drivers/crypto/ccp/ccp-dev-v5.c   |   5 +-
 drivers/crypto/ccp/ccp-dev.c  | 106 +-
 drivers/crypto/ccp/ccp-dev.h  |  21 +
 drivers/crypto/ccp/ccp-pci.c  |  81 +++--
 drivers/crypto/ccp/ccp-platform.c |  70 ---
 drivers/crypto/ccp/sp-dev.c   | 180
++
 drivers/crypto/ccp/sp-dev.h   | 120 +
 include/linux/ccp.h   |   7 +-
 12 files changed, 461 insertions(+), 164 deletions(-)
 create mode 100644 drivers/crypto/ccp/sp-dev.c
 create mode 100644 drivers/crypto/ccp/sp-dev.h

diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 0528a62..148b516 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -513,11 +513,11 @@ config CRYPTO_DEV_ATMEL_SHA
   will be called atmel-sha.

 config CRYPTO_DEV_CCP
-   bool "Support for AMD Cryptographic Coprocessor"
+   bool "Support for AMD Secure Processor"
 depends on ((X86 && PCI) || (ARM64 && (OF_ADDRESS || ACPI))) &&
HAS_IOMEM
 help
- The AMD Cryptographic Coprocessor provides hardware offload
support
- for encryption, hashing and related operations.
+ The AMD Secure Processor provides hardware offload support for
memory
+ encryption in virtualization and cryptographic hashing and
related operations.

 if CRYPTO_DEV_CCP
 source "drivers/crypto/ccp/Kconfig"
diff --git a/drivers/crypto/ccp/Kconfig b/drivers/crypto/ccp/Kconfig
index 2238f77..15b63fd 100644
--- a/drivers/crypto/ccp/Kconfig
+++ b/drivers/crypto/ccp/Kconfig
@@ -1,22 +1,29 @@
 config CRYPTO_DEV_CCP_DD
-   tristate "Cryptographic Coprocessor device driver"
-   depends on CRYPTO_DEV_CCP
+   tristate "Secure Processor device driver"
 default m
+   help
+ Provides AMD Secure Processor device driver.
+ If you choose 'M' here, this module will be called ccp.
+
+config CRYPTO_DEV_SP_CCP
+   bool "Cryptographic Coprocessor device"
+   default y
+   depends on CRYPTO_DEV_CCP_DD
 select HW_RANDOM
 select DMA_ENGINE
 select DMADEVICES
 select CRYPTO_SHA1
 select CRYPTO_SHA256
 help
- Provides the interface to use the AMD Cryptographic Coprocessor
- which can be used to offload encryption operations such as SHA,
- AES and more. If you choose 'M' here, this module will be called
- ccp.
+ Provides the support for AMD Cryptographic Coprocessor (CCP)
device
+ which can be used to offload encryption operations such as
SHA, AES
+ and more.

 config CRYPTO_DEV_CCP_CRYPTO
 tristate "Encryption and hashing offload support"
-   depends on CRYPTO_DEV_CCP_DD
 default m
+   depends on CRYPTO_DEV_CCP_DD
+   depends on CRYPTO_DEV_SP_CCP
 select CRYPTO_HASH
 select CRYPTO_BLKCIPHER
 select CRYPTO_AUTHENC
diff --git a/drivers/crypto/ccp/Makefile b/drivers/crypto/ccp/Makefile
index 59493fd..d2f1b52 100644
--- a/drivers/crypto/ccp/Makefile
+++ b/drivers/crypto/ccp/Makefile
@@ -1,9 +1,9 @@
 obj-$(CONFIG_CRYPTO_DEV_CCP_DD) += ccp.o
-ccp-objs := ccp-dev.o \
+ccp-objs  := sp-dev.o ccp-platform.o
+ccp-$(CONFIG_CRYPTO_DEV_SP_CCP) += ccp-dev.o \
 ccp-ops.o \
 ccp-dev-v3.o \
 ccp-dev-v5.o \
-   ccp-platform.o \
 ccp-dmaengine.o \
 ccp-debugfs.o
 ccp-$(CONFIG_PCI) += ccp-pci.o
diff --git a/drivers/crypto/ccp/ccp-dev-v3.c
b/drivers/crypto/ccp/ccp-dev-v3.c
index 52aa88b..57179034 100644
--- a/drivers/crypto/ccp/ccp-dev-v3.c
+++ b/drivers/crypto/ccp/ccp-dev-v3.c
@@ -359,8 +359,7 @@ static void ccp_irq_bh(unsigned long data)

 static irqreturn_t ccp_irq_handler(int irq, void *data)
 {
-   struct device *dev = data;
-   struct ccp_device *ccp = dev_get_drvdata(dev);
+   struct ccp_device *ccp = (struct ccp_device *)data;

 ccp_disable_queue_interrupts(ccp);
 if (ccp->use_tasklet)
@@ -597,6 +596,5 @@ const struct ccp_vdata ccpv3 = {
 .version = CCP_VERSION(3, 0),
 .setup = NULL,
 .perform = _actions,
-   .bar = 2,
 .offset = 0x2,
 };
diff --git a/drivers/crypto/ccp/ccp-dev-v5.c
b/drivers/crypto/ccp/ccp-dev-v5.c
index b10d2d2..8ed2b37 100644
--- a/drivers/crypto/ccp/ccp-dev-v5.c
+++ b/drivers/crypto/ccp/ccp-dev-v5.c
@@ -769,8 +769,7

Re: [PATCH v3 RESEND 3/5] crypto: cpp - Abstract interrupt registeration

2017-07-03 Thread Gary R Hook 

On 06/29/2017 11:54 AM, Singh, Brijesh wrote:

The CCP and PSP devices part of AMD Secure Procesor may share the same
interrupt. Hence we expand the SP device to register a common interrupt
handler and provide functions to CCP and PSP devices to register their
interrupt callback which will be invoked upon interrupt.

Signed-off-by: Brijesh Singh 


Acked-by: Gary R Hook 


---
 drivers/crypto/ccp/ccp-dev-v3.c   |   6 +--
 drivers/crypto/ccp/ccp-dev-v5.c   |   7 ++-
 drivers/crypto/ccp/ccp-dev.c  |   3 +-
 drivers/crypto/ccp/ccp-dev.h  |   2 -
 drivers/crypto/ccp/ccp-pci.c  | 103
+++-
 drivers/crypto/ccp/ccp-platform.c |  57 ++--
 drivers/crypto/ccp/sp-dev.c   | 107
++
 drivers/crypto/ccp/sp-dev.h   |  16 +-
 8 files changed, 186 insertions(+), 115 deletions(-)

diff --git a/drivers/crypto/ccp/ccp-dev-v3.c
b/drivers/crypto/ccp/ccp-dev-v3.c
index 57179034..695fde8 100644
--- a/drivers/crypto/ccp/ccp-dev-v3.c
+++ b/drivers/crypto/ccp/ccp-dev-v3.c
@@ -453,7 +453,7 @@ static int ccp_init(struct ccp_device *ccp)
 iowrite32(ccp->qim, ccp->io_regs + IRQ_STATUS_REG);

 /* Request an irq */
-   ret = ccp->get_irq(ccp);
+   ret = sp_request_ccp_irq(ccp->sp, ccp_irq_handler, ccp->name, ccp);
 if (ret) {
 dev_err(dev, "unable to allocate an IRQ\n");
 goto e_pool;
@@ -510,7 +510,7 @@ static int ccp_init(struct ccp_device *ccp)
 if (ccp->cmd_q[i].kthread)
 kthread_stop(ccp->cmd_q[i].kthread);

-   ccp->free_irq(ccp);
+   sp_free_ccp_irq(ccp->sp, ccp);

 e_pool:
 for (i = 0; i < ccp->cmd_q_count; i++)
@@ -549,7 +549,7 @@ static void ccp_destroy(struct ccp_device *ccp)
 if (ccp->cmd_q[i].kthread)
 kthread_stop(ccp->cmd_q[i].kthread);

-   ccp->free_irq(ccp);
+   sp_free_ccp_irq(ccp->sp, ccp);

 for (i = 0; i < ccp->cmd_q_count; i++)
 dma_pool_destroy(ccp->cmd_q[i].dma_pool);
diff --git a/drivers/crypto/ccp/ccp-dev-v5.c
b/drivers/crypto/ccp/ccp-dev-v5.c
index 8ed2b37..b0391f0 100644
--- a/drivers/crypto/ccp/ccp-dev-v5.c
+++ b/drivers/crypto/ccp/ccp-dev-v5.c
@@ -880,7 +880,7 @@ static int ccp5_init(struct ccp_device *ccp)

 dev_dbg(dev, "Requesting an IRQ...\n");
 /* Request an irq */
-   ret = ccp->get_irq(ccp);
+   ret = sp_request_ccp_irq(ccp->sp, ccp5_irq_handler, ccp->name, ccp);
 if (ret) {
 dev_err(dev, "unable to allocate an IRQ\n");
 goto e_pool;
@@ -986,7 +986,7 @@ static int ccp5_init(struct ccp_device *ccp)
 kthread_stop(ccp->cmd_q[i].kthread);

 e_irq:
-   ccp->free_irq(ccp);
+   sp_free_ccp_irq(ccp->sp, ccp);

 e_pool:
 for (i = 0; i < ccp->cmd_q_count; i++)
@@ -1036,7 +1036,7 @@ static void ccp5_destroy(struct ccp_device *ccp)
 if (ccp->cmd_q[i].kthread)
 kthread_stop(ccp->cmd_q[i].kthread);

-   ccp->free_irq(ccp);
+   sp_free_ccp_irq(ccp->sp, ccp);

 for (i = 0; i < ccp->cmd_q_count; i++) {
 cmd_q = >cmd_q[i];
@@ -1105,7 +1105,6 @@ static const struct ccp_actions ccp5_actions = {
 .init = ccp5_init,
 .destroy = ccp5_destroy,
 .get_free_slots = ccp5_get_free_slots,
-   .irqhandler = ccp5_irq_handler,
 };

 const struct ccp_vdata ccpv5a = {
diff --git a/drivers/crypto/ccp/ccp-dev.c b/drivers/crypto/ccp/ccp-dev.c
index 8a1674a..7c751bf 100644
--- a/drivers/crypto/ccp/ccp-dev.c
+++ b/drivers/crypto/ccp/ccp-dev.c
@@ -599,8 +599,7 @@ int ccp_dev_init(struct sp_device *sp)
 goto e_err;
 }

-   ccp->get_irq = sp->get_irq;
-   ccp->free_irq = sp->free_irq;
+   ccp->use_tasklet = sp->use_tasklet;

 ccp->io_regs = sp->io_map + ccp->vdata->offset;
 if (ccp->vdata->setup)
diff --git a/drivers/crypto/ccp/ccp-dev.h b/drivers/crypto/ccp/ccp-dev.h
index ca44821..193f309 100644
--- a/drivers/crypto/ccp/ccp-dev.h
+++ b/drivers/crypto/ccp/ccp-dev.h
@@ -351,8 +351,6 @@ struct ccp_device {
 /* Bus specific device information
  */
 void *dev_specific;
-   int (*get_irq)(struct ccp_device *ccp);
-   void (*free_irq)(struct ccp_device *ccp);
 unsigned int qim;
 unsigned int irq;
 bool use_tasklet;
diff --git a/drivers/crypto/ccp/ccp-pci.c b/drivers/crypto/ccp/ccp-pci.c
index ab2df96..b29a093 100644
--- a/drivers/crypto/ccp/ccp-pci.c
+++ b/drivers/crypto/ccp/ccp-pci.c
@@ -28,67 +28,37 @@

 #define MSIX_VECTORS2

-struct ccp_msix {
-   u32 vector;
-   char name[16];
-};
-
 struct ccp_pci {
 int msix_count;
-   struct ccp_msix msix[MSIX_VECTORS];
+   struct msix_entry msix_entry[MSIX_VECTORS];
 };

-static int ccp_get_msix_irqs(struct ccp_device

Re: [PATCH v3 RESEND 1/5] crypto: ccp - Use devres interface to allocate PCI/iomap and cleanup

2017-07-03 Thread Gary R Hook 

On 06/29/2017 11:54 AM, Singh, Brijesh wrote:

Update pci and platform files to use devres interface to allocate the PCI
and iomap resources. Also add helper functions to consolicate module init,
exit and power mangagement code duplication.

Signed-off-by: Brijesh Singh 


Acked-by: Gary R Hook 


---
 drivers/crypto/ccp/ccp-dev-v3.c   |   7 +++
 drivers/crypto/ccp/ccp-dev.c  |  61 
 drivers/crypto/ccp/ccp-dev.h  |   6 ++
 drivers/crypto/ccp/ccp-pci.c  | 114
+-
 drivers/crypto/ccp/ccp-platform.c |  56 ++-
 5 files changed, 106 insertions(+), 138 deletions(-)

diff --git a/drivers/crypto/ccp/ccp-dev-v3.c
b/drivers/crypto/ccp/ccp-dev-v3.c
index 367c2e3..52aa88b 100644
--- a/drivers/crypto/ccp/ccp-dev-v3.c
+++ b/drivers/crypto/ccp/ccp-dev-v3.c
@@ -586,6 +586,13 @@ static const struct ccp_actions ccp3_actions = {
 .irqhandler = ccp_irq_handler,
 };

+const struct ccp_vdata ccpv3_platform = {
+   .version = CCP_VERSION(3, 0),
+   .setup = NULL,
+   .perform = _actions,
+   .offset = 0,
+};
+
 const struct ccp_vdata ccpv3 = {
 .version = CCP_VERSION(3, 0),
 .setup = NULL,
diff --git a/drivers/crypto/ccp/ccp-dev.c b/drivers/crypto/ccp/ccp-dev.c
index 2506b50..abb3d68 100644
--- a/drivers/crypto/ccp/ccp-dev.c
+++ b/drivers/crypto/ccp/ccp-dev.c
@@ -538,8 +538,69 @@ bool ccp_queues_suspended(struct ccp_device *ccp)

 return ccp->cmd_q_count == suspended;
 }
+
+int ccp_dev_suspend(struct ccp_device *ccp, pm_message_t state)
+{
+   unsigned long flags;
+   unsigned int i;
+
+   spin_lock_irqsave(>cmd_lock, flags);
+
+   ccp->suspending = 1;
+
+   /* Wake all the queue kthreads to prepare for suspend */
+   for (i = 0; i < ccp->cmd_q_count; i++)
+   wake_up_process(ccp->cmd_q[i].kthread);
+
+   spin_unlock_irqrestore(>cmd_lock, flags);
+
+   /* Wait for all queue kthreads to say they're done */
+   while (!ccp_queues_suspended(ccp))
+   wait_event_interruptible(ccp->suspend_queue,
+ccp_queues_suspended(ccp));
+
+   return 0;
+}
+
+int ccp_dev_resume(struct ccp_device *ccp)
+{
+   unsigned long flags;
+   unsigned int i;
+
+   spin_lock_irqsave(>cmd_lock, flags);
+
+   ccp->suspending = 0;
+
+   /* Wake up all the kthreads */
+   for (i = 0; i < ccp->cmd_q_count; i++) {
+   ccp->cmd_q[i].suspended = 0;
+   wake_up_process(ccp->cmd_q[i].kthread);
+   }
+
+   spin_unlock_irqrestore(>cmd_lock, flags);
+
+   return 0;
+}
 #endif

+int ccp_dev_init(struct ccp_device *ccp)
+{
+   ccp->io_regs = ccp->io_map + ccp->vdata->offset;
+
+   if (ccp->vdata->setup)
+   ccp->vdata->setup(ccp);
+
+   return ccp->vdata->perform->init(ccp);
+}
+
+void ccp_dev_destroy(struct ccp_device *ccp)
+{
+   if (!ccp)
+   return;
+
+   ccp->vdata->perform->destroy(ccp);
+}
+
 static int __init ccp_mod_init(void)
 {
 #ifdef CONFIG_X86
diff --git a/drivers/crypto/ccp/ccp-dev.h b/drivers/crypto/ccp/ccp-dev.h
index a70154a..df2e76e 100644
--- a/drivers/crypto/ccp/ccp-dev.h
+++ b/drivers/crypto/ccp/ccp-dev.h
@@ -652,6 +652,11 @@ void ccp_dmaengine_unregister(struct ccp_device *ccp);
 void ccp5_debugfs_setup(struct ccp_device *ccp);
 void ccp5_debugfs_destroy(void);

+int ccp_dev_init(struct ccp_device *ccp);
+void ccp_dev_destroy(struct ccp_device *ccp);
+int ccp_dev_suspend(struct ccp_device *ccp, pm_message_t state);
+int ccp_dev_resume(struct ccp_device *ccp);
+
 /* Structure for computation functions that are device-specific */
 struct ccp_actions {
 int (*aes)(struct ccp_op *);
@@ -679,6 +684,7 @@ struct ccp_vdata {
 const unsigned int offset;
 };

+extern const struct ccp_vdata ccpv3_platform;
 extern const struct ccp_vdata ccpv3;
 extern const struct ccp_vdata ccpv5a;
 extern const struct ccp_vdata ccpv5b;
diff --git a/drivers/crypto/ccp/ccp-pci.c b/drivers/crypto/ccp/ccp-pci.c
index e880d4cf4..490ad0a 100644
--- a/drivers/crypto/ccp/ccp-pci.c
+++ b/drivers/crypto/ccp/ccp-pci.c
@@ -150,28 +150,13 @@ static void ccp_free_irqs(struct ccp_device *ccp)
 ccp->irq = 0;
 }

-static int ccp_find_mmio_area(struct ccp_device *ccp)
-{
-   struct device *dev = ccp->dev;
-   struct pci_dev *pdev = to_pci_dev(dev);
-   resource_size_t io_len;
-   unsigned long io_flags;
-
-   io_flags = pci_resource_flags(pdev, ccp->vdata->bar);
-   io_len = pci_resource_len(pdev, ccp->vdata->bar);
-   if ((io_flags & IORESOURCE_MEM) &&
-   (io_len >= (ccp->vdata->offset + 0x800)))
-   return ccp->vdata->bar;
-
-   return -EIO;
-}
-
 static int ccp_pci_probe(struct pci_dev *pdev, const struct
pci_device_id *id)
 {
 struct ccp_device *ccp;
 struct ccp_pci *ccp_pci;
 struct device *dev = >dev;
-

Re: [PATCH v3 01/28] crypto: change backlog return code to -EIOCBQUEUED

2017-07-03 Thread Gilad Ben-Yossef 
On Mon, Jul 3, 2017 at 3:35 PM, Herbert Xu  wrote:
> On Sun, Jul 02, 2017 at 05:41:43PM +0300, Gilad Ben-Yossef wrote:
>> The crypto API was using the -EBUSY return value to indicate
>> both a hard failure to submit a crypto operation into a
>> transformation provider when the latter was busy and the backlog
>> mechanism was not enabled as well as a notification that the operation
>> was queued into the backlog when the backlog mechanism was enabled.
>>
>> Having the same return code indicate two very different conditions
>> depending on a flag is both error prone and requires extra runtime
>> check like the following to discern between the cases:
>>
>>   if (err == -EINPROGRESS ||
>>   (err == -EBUSY && (ahash_request_flags(req) &
>>  CRYPTO_TFM_REQ_MAY_BACKLOG)))
>>
>> This patch changes the return code used to indicate a crypto op
>> was queued in the backlog to -EIOCBQUEUED, thus resolving both
>> issues.
>>
>> Signed-off-by: Gilad Ben-Yossef 
>
> So you're changing the success case from EBUSY to EIOCBQUEUED.
> This results in a lot of churn as you have to change every single
> driver and caller.
>
> How about changing the error case to use something other than
> EBUSY instead?

That was indeed my first thought - I wanted to change EBUSY to EAGAIN.
It might even be a more descriptive error message since the failure is
transient.

What stopped me was that I saw the algif interface passes this EBUSY value
to user space. I don't know of any software that depends on this value but
I'm really averse to changing user space API.

Of course, we can just plant a (ret != AGAIN : ? EBUSY) in the algif interface
return to user space code path but that felt like a kludge to me.

And it doesn't really save any churn, I think - I'd still have to
visit all the places that
use the flags value to distinguish between the two EBUSY use cases and  I need
to visit most places that check for EBUSY as backlog indication because I'm
replacing the check with the generic replacement, so it doesn't look
like in the end
it will be a smaller change.

Having said that, if you prefer me to replace the error case I'd
happily do that.

Thanks,
Gilad


-- 
Gilad Ben-Yossef
Chief Coffee Drinker

"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
 -- Jean-Baptiste Queru

Re: [PATCH v3 01/28] crypto: change backlog return code to -EIOCBQUEUED

2017-07-03 Thread Herbert Xu 
On Sun, Jul 02, 2017 at 05:41:43PM +0300, Gilad Ben-Yossef wrote:
> The crypto API was using the -EBUSY return value to indicate
> both a hard failure to submit a crypto operation into a
> transformation provider when the latter was busy and the backlog
> mechanism was not enabled as well as a notification that the operation
> was queued into the backlog when the backlog mechanism was enabled.
> 
> Having the same return code indicate two very different conditions
> depending on a flag is both error prone and requires extra runtime
> check like the following to discern between the cases:
> 
>   if (err == -EINPROGRESS ||
>   (err == -EBUSY && (ahash_request_flags(req) &
>  CRYPTO_TFM_REQ_MAY_BACKLOG)))
> 
> This patch changes the return code used to indicate a crypto op
> was queued in the backlog to -EIOCBQUEUED, thus resolving both
> issues.
> 
> Signed-off-by: Gilad Ben-Yossef 

So you're changing the success case from EBUSY to EIOCBQUEUED.
This results in a lot of churn as you have to change every single
driver and caller.

How about changing the error case to use something other than
EBUSY instead?

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [bug] sha1-avx2 and read beyond

2017-07-03 Thread Herbert Xu 
On Sat, Jun 24, 2017 at 12:56:52AM +, Albrekht, Ilya wrote:
> Hello all,
> 
> I'm sorry for late reply (I was out of office for a month).
> 
> It's been a while since we touched this code. We are going to do our best to 
> support it. I'll be back to the office earlier next week and will figure out 
> the fix ASAP.

Any update on this?

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH 00/10] Fix alignment issues in staging/ccree

2017-07-03 Thread Simon Sandström 
On Mon, Jul 03, 2017 at 10:19:31AM +0300, Gilad Ben-Yossef wrote:
> but for the few cases where its a complex expression that can be
> broken down like this one:
> 
> WARNING: line over 80 characters
> #93: FILE: drivers/staging/ccree/ssi_buffer_mgr.c:437:
> + (AES_BLOCK_SIZE + areq_ctx->ccm_hdr_size),
> 
> It would be great if you fix those.

Do you mean to fix them by just breaking the line after the ternary
operator? Is that OK according to the code style rules?

If not, then the two warnings in ssi_aead_handle_config_buf can be
fixed by simply having a local variable:

const unsigned int buflen = AES_BLOCK_SIZE + areq_ctx->ccm_hdr_size;

but I'm not sure if the same can be done in
ssi_buffer_mgr_map_hash_request_update for (update_data_len - *curr_buf_cnt)
as it's not always the case that update_data_len is greater than
*curr_buf_cnt. Even if it's safe to always calculate it I'm not
entierly sure what to call the variable.

Other then those two functions I don't think that there are any more
lines that can be fixed without renaming functions / variables or
by rewriting them to decrease the indentation depth, as you wrote.

-- Simon

[PATCH] crypto: change hwrng device default permissions to 0444

2017-07-03 Thread Harald Freudenberger 
Currently /dev/hwrng uses default device node permissions
which is 0600. So by default the device node is not accessible
by an ordinary user. Some distros do rewrite the device node
permissions via udev rule, others don't. This patch provides
0444 as the new mode value and so makes the device node
accessible for all users without the need to have udev rules
rewriting the access rights.

Signed-off-by: Harald Freudenberger 
---
 drivers/char/hw_random/core.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index 503a41d..4093db5 100644
--- a/drivers/char/hw_random/core.c
+++ b/drivers/char/hw_random/core.c
@@ -285,6 +285,7 @@ static struct miscdevice rng_miscdev = {
.minor  = HWRNG_MINOR,
.name   = RNG_MODULE_NAME,
.nodename   = "hwrng",
+   .mode   = 0444,
.fops   = _chrdev_ops,
.groups = rng_dev_groups,
 };
-- 
2.7.4

[RFT PATCH] crypto: arm64/ghash - add NEON accelerated fallback for 64-bit PMULL

2017-07-03 Thread Ard Biesheuvel 
Implement a NEON fallback for systems that do support NEON but have
no support for the optional 64x64->128 polynomial multiplication
instruction that is part of the ARMv8 Crypto Extensions. It is based
on the paper "Fast Software Polynomial Multiplication on ARM Processors
Using the NEON Engine" by Danilo Camara, Conrado Gouvea, Julio Lopez and
Ricardo Dahab (https://hal.inria.fr/hal-01506572)

On a low-end core such as the Cortex-A53 found in the Raspberry Pi3, the
NEON based implementation is ~2.8x faster than the table based one, and
is time invariant as well, making it less vulnerable to timing attacks.
When combined with the bit-sliced NEON implementation of AES-CTR, the
AES-GCM performance increases by 75% (from 58 to 33 cycles per byte).

Signed-off-by: Ard Biesheuvel 
---
Note that this is the arm64 counterpart of the patch
"crypto: arm/ghash - add NEON accelerated fallback for vmull.p64"

Raw numbers for a 1.2 Ghz Cortex-A53 (Raspberry Pi3) after the patch.

This patch applies onto the patch "crypto: arm64/gcm - implement native
driver using v8 Crypto Extensions" which can be found here:
http://www.mail-archive.com/linux-crypto@vger.kernel.org/msg26385.html

 arch/arm64/crypto/ghash-ce-core.S | 161 +---
 arch/arm64/crypto/ghash-ce-glue.c |  36 -
 2 files changed, 170 insertions(+), 27 deletions(-)

diff --git a/arch/arm64/crypto/ghash-ce-core.S 
b/arch/arm64/crypto/ghash-ce-core.S
index cb22459eba85..8a789f6154fc 100644
--- a/arch/arm64/crypto/ghash-ce-core.S
+++ b/arch/arm64/crypto/ghash-ce-core.S
@@ -1,7 +1,7 @@
 /*
  * Accelerated GHASH implementation with ARMv8 PMULL instructions.
  *
- * Copyright (C) 2014 Linaro Ltd. 
+ * Copyright (C) 2014 - 2017 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
@@ -11,24 +11,119 @@
 #include 
 #include 
 
-   SHASH   .reqv0
-   SHASH2  .reqv1
-   T1  .reqv2
-   T2  .reqv3
-   MASK.reqv4
-   XL  .reqv5
-   XM  .reqv6
-   XH  .reqv7
-   IN1 .reqv7
+   SHASH   .reqv0
+   SHASH2  .reqv1
+   T1  .reqv2
+   T2  .reqv3
+   MASK.reqv4
+   XL  .reqv5
+   XM  .reqv6
+   XH  .reqv7
+   IN1 .reqv7
+
+   k00_16  .reqv8
+   k32_48  .reqv9
+
+   t3  .reqv10
+   t4  .reqv11
+   t5  .reqv12
+   t6  .reqv13
+   t7  .reqv14
+   t8  .reqv15
+   t9  .reqv16
+
+   perm1   .reqv17
+   perm2   .reqv18
+   perm3   .reqv19
+   perm4   .reqv20
 
.text
.arch   armv8-a+crypto
 
-   /*
-* void pmull_ghash_update(int blocks, u64 dg[], const char *src,
-* struct ghash_key const *k, const char *head)
-*/
-ENTRY(pmull_ghash_update)
+   .macro  __pmull_p64, rd, rn, rm, i
+   .ifb\i
+   pmull   \rd\().1q, \rn\().1d, \rm\().1d
+   .else
+   pmull2  \rd\().1q, \rn\().2d, \rm\().2d
+   .endif
+   .endm
+
+   .macro  __pmull_p8, rq, ad, bd, i
+   .ifb\i
+   ext t4.8b, \ad\().8b, \ad\().8b, #1 // A1
+   ext t8.8b, \bd\().8b, \bd\().8b, #1 // B1
+   ext t5.8b, \ad\().8b, \ad\().8b, #2 // A2
+   ext t7.8b, \bd\().8b, \bd\().8b, #2 // B2
+   ext t6.8b, \ad\().8b, \ad\().8b, #3 // A3
+   ext t9.8b, \bd\().8b, \bd\().8b, #3 // B3
+   ext t3.8b, \bd\().8b, \bd\().8b, #4 // B4
+
+   pmull   t4.8h, t4.8b, \bd\().8b // F = A1*B
+   pmull   t8.8h, \ad\().8b, t8.8b // E = A*B1
+   pmull   t5.8h, t5.8b, \bd\().8b // H = A2*B
+   pmull   t7.8h, \ad\().8b, t7.8b // G = A*B2
+   pmull   t6.8h, t6.8b, \bd\().8b // J = A3*B
+   pmull   t9.8h, \ad\().8b, t9.8b // I = A*B3
+   pmull   t3.8h, \ad\().8b, t3.8b // K = A*B4
+   pmull   \rq\().8h, \ad\().8b, \bd\().8b // D = A*B
+   .else
+   tbl t4.16b, {\ad\().16b}, perm1.16b // A1
+   tbl t8.16b, {\bd\().16b}, perm1.16b // B1
+   tbl t5.16b, {\ad\().16b}, perm2.16b // A2
+   tbl t7.16b, {\bd\().16b}, perm2.16b

[PATCH 2/3] crypto: hwrng remember rng chosen by user

2017-07-03 Thread Harald Freudenberger 
When a user chooses a rng source via sysfs
attribute this rng should be sticky, even
when other sources with better quality to
register. This patch introduces a simple way
to remember the user's choise.

Signed-off-by: Harald Freudenberger 
---
 drivers/char/hw_random/core.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index e9dda16..ffd4e36 100644
--- a/drivers/char/hw_random/core.c
+++ b/drivers/char/hw_random/core.c
@@ -28,6 +28,8 @@
 #define RNG_MODULE_NAME"hw_random"
 
 static struct hwrng *current_rng;
+/* the current rng has been explicitly chosen by user via sysfs */
+static int cur_rng_set_by_user;
 static struct task_struct *hwrng_fill;
 /* list of registered rngs, sorted decending by quality */
 static LIST_HEAD(rng_list);
@@ -304,6 +306,7 @@ static ssize_t hwrng_attr_current_store(struct device *dev,
list_for_each_entry(rng, _list, list) {
if (sysfs_streq(rng->name, buf)) {
err = 0;
+   cur_rng_set_by_user = 1;
if (rng != current_rng)
err = set_current_rng(rng);
break;
@@ -444,10 +447,12 @@ int hwrng_register(struct hwrng *rng)
 
old_rng = current_rng;
err = 0;
-   if (!old_rng || (rng->quality > old_rng->quality)) {
+   if (!old_rng ||
+   (!cur_rng_set_by_user && rng->quality > old_rng->quality)) {
/*
 * Set new rng as current as the new rng source
-* provides better entropy quality.
+* provides better entropy quality and was not
+* chosen by userspace.
 */
err = set_current_rng(rng);
if (err)
@@ -479,6 +484,7 @@ void hwrng_unregister(struct hwrng *rng)
list_del(>list);
if (current_rng == rng) {
drop_current_rng();
+   cur_rng_set_by_user = 0;
/* rng_list is sorted by quality, use the best (=first) one */
if (!list_empty(_list)) {
struct hwrng *new_rng;
-- 
2.7.4

[PATCH 0/3] crypto hwrng consider quality value, remember user choice

2017-07-03 Thread Harald Freudenberger 
The hwrng core implementation currently doesn't consider the
quality field of the struct hwrng. So the first registered rng
is the winner and further rng sources even with much better
quality are ignored.

The behavior should be that always the best rng with the highest
quality rate should be used as current rng source. Only if the
user explicitly chooses a rng source (via writing a rng name
to /sys/class/misc/hw_random/rng_current) the decision for the
best quality should be suppressed.

This set of patches makes hwrng always hold a list of registered
rng sources sorted decreasing by quality. On registration of a new
hwrng source the list is updated and if the current rng source was
not chosen by user and the new rng provides better quality set as
new current rng source. Similar on unregistration of an rng, if it
was the current used rng source the one with the next highest quality
is used. If a rng source has been set via sysfs from userland as
long as this one doesn't unregister it is kept as current rng
regardless of registration of 'better' rng sources.

Patch 1 introduces the sorted list of registered rngs and the
always use the best quality behavior.

Patch 2 makes hwrng remember that the user has selected an
rng via echo to /sys/class/misc/hw_random/rng_current.

Patch 3 adds a new sysfs attribute file 'rng_selected' to the
rng core. This file shows the chosen rng name if a selection
from userspace took place otherwise 'none'.

Patch 3 is just a simple implementation of an possible improvement
and may act as a starting point for further discussions. For example,
the implementation could be reworked to accept also currently not
known rng sources and upon appearing instantly select this user
chosen rng. However, this would require to hold an string buffer
and this would introduce some string length limit on the rng name.
Another idea is that there should be a possibility to unselect
the user's choice. An echo 'none' to rng_current may be a way to
remove the selection and the hwrng may act by using the quality best
rng.

Harald Freudenberger (3):
  crypto: hwrng use rng source with best quality
  crypto: hwrng remember rng chosen by user
  crypto: hwrng add sysfs attribute to show user selected rng

 drivers/char/hw_random/core.c | 43 +--
 1 file changed, 37 insertions(+), 6 deletions(-)

-- 
2.7.4

[PATCH 3/3] crypto: hwrng add sysfs attribute to show user selected rng

2017-07-03 Thread Harald Freudenberger 
This patch introduces a new sysfs attribute file 'rng_selected'
which shows the the rng chosen by userspace.

If a rng source is chosen by user via echo some valid string
to rng_current there should be a way to signal this choice to
userspace. The new attribute file 'rng_selected' shows either
the name of the rng chosen or 'none'.

Signed-off-by: Harald Freudenberger 
---
 drivers/char/hw_random/core.c | 22 +-
 1 file changed, 17 insertions(+), 5 deletions(-)

diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index ffd4e36..6a6276a 100644
--- a/drivers/char/hw_random/core.c
+++ b/drivers/char/hw_random/core.c
@@ -28,8 +28,8 @@
 #define RNG_MODULE_NAME"hw_random"
 
 static struct hwrng *current_rng;
-/* the current rng has been explicitly chosen by user via sysfs */
-static int cur_rng_set_by_user;
+/* the rng explicitly selected by user via sysfs */
+static struct hwrng *selected_rng;
 static struct task_struct *hwrng_fill;
 /* list of registered rngs, sorted decending by quality */
 static LIST_HEAD(rng_list);
@@ -306,7 +306,7 @@ static ssize_t hwrng_attr_current_store(struct device *dev,
list_for_each_entry(rng, _list, list) {
if (sysfs_streq(rng->name, buf)) {
err = 0;
-   cur_rng_set_by_user = 1;
+   selected_rng = rng;
if (rng != current_rng)
err = set_current_rng(rng);
break;
@@ -355,16 +355,28 @@ static ssize_t hwrng_attr_available_show(struct device 
*dev,
return strlen(buf);
 }
 
+static ssize_t hwrng_attr_selected_show(struct device *dev,
+   struct device_attribute *attr,
+   char *buf)
+{
+   return snprintf(buf, PAGE_SIZE, "%s\n",
+   selected_rng ? selected_rng->name : "none");
+}
+
 static DEVICE_ATTR(rng_current, S_IRUGO | S_IWUSR,
   hwrng_attr_current_show,
   hwrng_attr_current_store);
 static DEVICE_ATTR(rng_available, S_IRUGO,
   hwrng_attr_available_show,
   NULL);
+static DEVICE_ATTR(rng_selected, S_IRUGO,
+  hwrng_attr_selected_show,
+  NULL);
 
 static struct attribute *rng_dev_attrs[] = {
_attr_rng_current.attr,
_attr_rng_available.attr,
+   _attr_rng_selected.attr,
NULL
 };
 
@@ -448,7 +460,7 @@ int hwrng_register(struct hwrng *rng)
old_rng = current_rng;
err = 0;
if (!old_rng ||
-   (!cur_rng_set_by_user && rng->quality > old_rng->quality)) {
+   (!selected_rng && rng->quality > old_rng->quality)) {
/*
 * Set new rng as current as the new rng source
 * provides better entropy quality and was not
@@ -484,7 +496,7 @@ void hwrng_unregister(struct hwrng *rng)
list_del(>list);
if (current_rng == rng) {
drop_current_rng();
-   cur_rng_set_by_user = 0;
+   selected_rng = NULL;
/* rng_list is sorted by quality, use the best (=first) one */
if (!list_empty(_list)) {
struct hwrng *new_rng;
-- 
2.7.4

[PATCH 1/3] crypto: hwrng use rng source with best quality

2017-07-03 Thread Harald Freudenberger 
This patch rewoks the hwrng to always use the
rng source with best entropy quality.

On registation and unregistration the hwrng now
tries to choose the best (= highest quality value)
rng source. The handling of the internal list
of registered rng sources is now always sorted
by quality and the top most rng chosen.

Signed-off-by: Harald Freudenberger 
---
 drivers/char/hw_random/core.c | 25 +++--
 1 file changed, 19 insertions(+), 6 deletions(-)

diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index 503a41d..e9dda16 100644
--- a/drivers/char/hw_random/core.c
+++ b/drivers/char/hw_random/core.c
@@ -29,6 +29,7 @@
 
 static struct hwrng *current_rng;
 static struct task_struct *hwrng_fill;
+/* list of registered rngs, sorted decending by quality */
 static LIST_HEAD(rng_list);
 /* Protects rng_list and current_rng */
 static DEFINE_MUTEX(rng_mutex);
@@ -417,6 +418,7 @@ int hwrng_register(struct hwrng *rng)
 {
int err = -EINVAL;
struct hwrng *old_rng, *tmp;
+   struct list_head *rng_list_ptr;
 
if (!rng->name || (!rng->data_read && !rng->read))
goto out;
@@ -432,14 +434,25 @@ int hwrng_register(struct hwrng *rng)
init_completion(>cleanup_done);
complete(>cleanup_done);
 
+   /* rng_list is sorted by decreasing quality */
+   list_for_each(rng_list_ptr, _list) {
+   tmp = list_entry(rng_list_ptr, struct hwrng, list);
+   if (tmp->quality < rng->quality)
+   break;
+   }
+   list_add_tail(>list, rng_list_ptr);
+
old_rng = current_rng;
err = 0;
-   if (!old_rng) {
+   if (!old_rng || (rng->quality > old_rng->quality)) {
+   /*
+* Set new rng as current as the new rng source
+* provides better entropy quality.
+*/
err = set_current_rng(rng);
if (err)
goto out_unlock;
}
-   list_add_tail(>list, _list);
 
if (old_rng && !rng->init) {
/*
@@ -466,12 +479,12 @@ void hwrng_unregister(struct hwrng *rng)
list_del(>list);
if (current_rng == rng) {
drop_current_rng();
+   /* rng_list is sorted by quality, use the best (=first) one */
if (!list_empty(_list)) {
-   struct hwrng *tail;
-
-   tail = list_entry(rng_list.prev, struct hwrng, list);
+   struct hwrng *new_rng;
 
-   set_current_rng(tail);
+   new_rng = list_entry(rng_list.next, struct hwrng, list);
+   set_current_rng(new_rng);
}
}
 
-- 
2.7.4

Re: [PATCH 00/10] Fix alignment issues in staging/ccree

2017-07-03 Thread Gilad Ben-Yossef 
Hi,

On Sun, Jul 2, 2017 at 2:25 AM, Simon Sandström  wrote:
> Fixes a total of 195 alignment issues in staging/ccree reported by
> checkpatch.pl. Adds a few "line over 80 characters" warnings as a
> result of the realignments, but I could try to get rid of them in the
> same patchset if needed.

For the large majority of warnings there is nothing you can due ti the
indentation depth,
but for the few cases where its a complex expression that can be
broken down like this one:

WARNING: line over 80 characters
#93: FILE: drivers/staging/ccree/ssi_buffer_mgr.c:437:
+ (AES_BLOCK_SIZE + areq_ctx->ccm_hdr_size),

It would be great if you fix those.

Otherwise it looks good to me.

Thanks for doing it!

Gilad



>
> -- Simon
>
> ---
>
> Simon Sandström (10):
>   staging: ccree: Fix alignment issues in ssi_aead.c
>   staging: ccree: Fix alignment issues in ssi_buffer_mgr.c
>   staging: ccree: Fix alignment issues in ssi_cipher.c
>   staging: ccree: Fix alignment issues in ssi_driver.c
>   staging: ccree: Fix alignment issues in ssi_fips_local.c
>   staging: ccree: Fix alignment issues in ssi_hash.c
>   staging: ccree: Fix alignment issues in ssi_ivgen.c
>   staging: ccree: Fix alignment issues in ssi_request_mgr.c
>   staging: ccree: Fix alignment issues in ssi_sram_mgr.c
>   staging: ccree: Fix alignment issues in ssi_sysfs.c
>
>  drivers/staging/ccree/ssi_aead.c|  67 
>  drivers/staging/ccree/ssi_buffer_mgr.c  | 295 
> ++--
>  drivers/staging/ccree/ssi_cipher.c  |  75 
>  drivers/staging/ccree/ssi_driver.c  |  40 ++---
>  drivers/staging/ccree/ssi_fips_local.c  |   3 +-
>  drivers/staging/ccree/ssi_hash.c| 116 +++--
>  drivers/staging/ccree/ssi_ivgen.c   |   3 +-
>  drivers/staging/ccree/ssi_request_mgr.c |  42 +++--
>  drivers/staging/ccree/ssi_sram_mgr.c|   6 +-
>  drivers/staging/ccree/ssi_sysfs.c   |  59 ---
>  10 files changed, 372 insertions(+), 334 deletions(-)
>
> --
> 2.11.0
>



-- 
Gilad Ben-Yossef
Chief Coffee Drinker

"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
 -- Jean-Baptiste Queru