Re: [PATCH v3 7/7] ima: Support module-style appended signatures for appraisal

[Thiago Jung Bauermann]

Mimi Zohar  writes:

> On Wed, 2017-08-02 at 18:52 -0400, Mimi Zohar wrote:
>> On Wed, 2017-08-02 at 14:42 -0300, Thiago Jung Bauermann wrote:
>> > Mimi Zohar  writes:
>
>> > >> @@ -229,8 +251,24 @@ int ima_appraise_measurement(enum ima_hooks func,
>> > >> goto out;
>> > >> }
>> > >> 
>> > >> -   status = evm_verifyxattr(dentry, XATTR_NAME_IMA, xattr_value, 
>> > >> rc, iint);
>> > >> -   if ((status != INTEGRITY_PASS) && (status != 
>> > >> INTEGRITY_UNKNOWN)) {
>> > >> +   /*
>> > >> +* Appended signatures aren't protected by EVM but we still call
>> > >> +* evm_verifyxattr to check other security xattrs, if they 
>> > >> exist.
>> > >> +*/
>> > >> +   if (appraising_modsig) {
>> > >> +   xattr_value_evm = NULL;
>> > >> +   xattr_len_evm = 0;
>> > >> +   } else {
>> > >> +   xattr_value_evm = xattr_value;
>> > >> +   xattr_len_evm = xattr_len;
>> > >> +   }
>> > >> +
>> > >> +   status = evm_verifyxattr(dentry, XATTR_NAME_IMA, 
>> > >> xattr_value_evm,
>> > >> +xattr_len_evm, iint);
>> > >> +   if (appraising_modsig && status == INTEGRITY_FAIL) {
>> > >> +   cause = "invalid-HMAC";
>> > >> +   goto out;
>> > >
>> > > "modsig" is special, because having any security xattrs is not
>> > > required. This test doesn't prevent status from being set to
>> > > "missing-HMAC". This test is redundant with the original tests below.
>> > 
>> > Indeed, that is wrong. I'm still a bit fuzzy about how EVM works and how
>> > it interacts with IMA. The only way I can think of singling out modsig
>> > without reintroduced the complex expression you didn't like in v2 is as
>> > below. What do you think?
>> 
>> The original code, without any extra tests, should be fine.
>
> There is one major difference.
>
> EVM verifies a file's metadata has not been modified based on either
> an HMAC or signature stored as security.evm. Prior to the appended
> signatures patch set, all files in policy required a security.evm
> xattr. With IMA enabled we could guarantee that at least one security
> xattr existed. The only exception were new files, which hadn't yet
> been labeled.
>
> With appended signatures, there is now no guarantee that at least one
> security xattr exists.
>
> Perhaps the code snippet below will help clarify the meaning of the
> integrity_status results.
>
> switch (status) {
> case INTEGRITY_PASS:
> case INTEGRITY_UNKNOWN:   
>break; 
> case INTEGRITY_NOXATTRS:/* no EVM protected xattrs */
> if (appraising_modsig)
> break;
> case INTEGRITY_NOLABEL:/* no security.evm xattr */
> cause = "missing-HMAC";
> fail = 1;
> break;
> case INTEGRITY_FAIL:/* invalid HMAC/signature */
> default:
> cause = "invalid-HMAC";
> fail = 1;
> break;
> }

Thanks! I'll use the switch above in the next version of the patch.

-- 
Thiago Jung Bauermann
IBM Linux Technology Center

[PATCH v6 0/7] make io{read|write}64 globally usable

[Logan Gunthorpe]

Changes since v5:
- Added a fix to the tilcdc driver to ensure it doesn't use the
  non-atomic operation. (This includes adding io{read|write}64[be]_is_nonatomic
  defines).

Changes since v4:
- Add functions so the powerpc implementation of iomap.c compiles. (As
  noticed by Horia)

Changes since v3:

- I noticed powerpc didn't use the appropriate functions seeing
  readq/writeq were not defined when iomap.h was included. Thus I've
  included a patch to adjust this
- Fixed some mistakes with a couple of the defines in io-64-nonatomic*
  headers
- Fixed a typo noticed by Horia.

(earlier versions were drastically different)

Horia Geantă (1):
  crypto: caam: cleanup CONFIG_64BIT ifdefs when using io{read|write}64

Logan Gunthorpe (6):
  drm/tilcdc: ensure nonatomic iowrite64 is not used
  powerpc: io.h: move iomap.h include so that it can use readq/writeq
defs
  powerpc: iomap.c: introduce io{read|write}64_{lo_hi|hi_lo}
  iomap: introduce io{read|write}64_{lo_hi|hi_lo}
  io-64-nonatomic: add io{read|write}64[be]{_lo_hi|_hi_lo} macros
  ntb: ntb_hw_intel: use io-64-nonatomic instead of in-driver hacks

 arch/powerpc/include/asm/io.h |   6 +-
 arch/powerpc/kernel/iomap.c   |  40 +++
 drivers/crypto/caam/regs.h|  35 ++---
 drivers/gpu/drm/tilcdc/tilcdc_regs.h  |   2 +-
 drivers/ntb/hw/intel/ntb_hw_intel.c   |  30 +---
 include/asm-generic/iomap.h   |  26 +--
 include/linux/io-64-nonatomic-hi-lo.h |  64 +
 include/linux/io-64-nonatomic-lo-hi.h |  64 +
 lib/iomap.c   | 132 ++
 9 files changed, 331 insertions(+), 68 deletions(-)

--
2.11.0

[PATCH v6 6/7] ntb: ntb_hw_intel: use io-64-nonatomic instead of in-driver hacks

[Logan Gunthorpe]

Now that ioread64 and iowrite64 are available in io-64-nonatomic,
we can remove the hack at the top of ntb_hw_intel.c and replace it
with an include.

Signed-off-by: Logan Gunthorpe 
Acked-by: Dave Jiang 
Acked-by: Allen Hubbe 
Acked-by: Jon Mason 
---
 drivers/ntb/hw/intel/ntb_hw_intel.c | 30 +-
 1 file changed, 1 insertion(+), 29 deletions(-)

diff --git a/drivers/ntb/hw/intel/ntb_hw_intel.c 
b/drivers/ntb/hw/intel/ntb_hw_intel.c
index 2557e2c05b90..606c90f59d4b 100644
--- a/drivers/ntb/hw/intel/ntb_hw_intel.c
+++ b/drivers/ntb/hw/intel/ntb_hw_intel.c
@@ -59,6 +59,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "ntb_hw_intel.h"
 
@@ -155,35 +156,6 @@ MODULE_PARM_DESC(xeon_b2b_dsd_bar5_addr32,
 static inline enum ntb_topo xeon_ppd_topo(struct intel_ntb_dev *ndev, u8 ppd);
 static int xeon_init_isr(struct intel_ntb_dev *ndev);
 
-#ifndef ioread64
-#ifdef readq
-#define ioread64 readq
-#else
-#define ioread64 _ioread64
-static inline u64 _ioread64(void __iomem *mmio)
-{
-   u64 low, high;
-
-   low = ioread32(mmio);
-   high = ioread32(mmio + sizeof(u32));
-   return low | (high << 32);
-}
-#endif
-#endif
-
-#ifndef iowrite64
-#ifdef writeq
-#define iowrite64 writeq
-#else
-#define iowrite64 _iowrite64
-static inline void _iowrite64(u64 val, void __iomem *mmio)
-{
-   iowrite32(val, mmio);
-   iowrite32(val >> 32, mmio + sizeof(u32));
-}
-#endif
-#endif
-
 static inline int pdev_is_atom(struct pci_dev *pdev)
 {
switch (pdev->device) {
-- 
2.11.0

[PATCH v6 3/7] powerpc: iomap.c: introduce io{read|write}64_{lo_hi|hi_lo}

[Logan Gunthorpe]

These functions will be introduced into the generic iomap.c so
they can deal with PIO accesses in hi-lo/lo-hi variants. Thus,
the powerpc version of iomap.c will need to provide the same
functions even though, in this arch, they are identical to the
regular io{read|write}64 functions.

Signed-off-by: Logan Gunthorpe 
Tested-by: Horia Geantă 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
---
 arch/powerpc/kernel/iomap.c | 40 
 1 file changed, 40 insertions(+)

diff --git a/arch/powerpc/kernel/iomap.c b/arch/powerpc/kernel/iomap.c
index a1854d1ded8b..b43dbadfd24f 100644
--- a/arch/powerpc/kernel/iomap.c
+++ b/arch/powerpc/kernel/iomap.c
@@ -44,12 +44,32 @@ u64 ioread64(void __iomem *addr)
 {
return readq(addr);
 }
+u64 ioread64_lo_hi(void __iomem *addr)
+{
+   return readq(addr);
+}
+u64 ioread64_hi_lo(void __iomem *addr)
+{
+   return readq(addr);
+}
 u64 ioread64be(void __iomem *addr)
 {
return readq_be(addr);
 }
+u64 ioread64be_lo_hi(void __iomem *addr)
+{
+   return readq_be(addr);
+}
+u64 ioread64be_hi_lo(void __iomem *addr)
+{
+   return readq_be(addr);
+}
 EXPORT_SYMBOL(ioread64);
+EXPORT_SYMBOL(ioread64_lo_hi);
+EXPORT_SYMBOL(ioread64_hi_lo);
 EXPORT_SYMBOL(ioread64be);
+EXPORT_SYMBOL(ioread64be_lo_hi);
+EXPORT_SYMBOL(ioread64be_hi_lo);
 #endif /* __powerpc64__ */
 
 void iowrite8(u8 val, void __iomem *addr)
@@ -82,12 +102,32 @@ void iowrite64(u64 val, void __iomem *addr)
 {
writeq(val, addr);
 }
+void iowrite64_lo_hi(u64 val, void __iomem *addr)
+{
+   writeq(val, addr);
+}
+void iowrite64_hi_lo(u64 val, void __iomem *addr)
+{
+   writeq(val, addr);
+}
 void iowrite64be(u64 val, void __iomem *addr)
 {
writeq_be(val, addr);
 }
+void iowrite64be_lo_hi(u64 val, void __iomem *addr)
+{
+   writeq_be(val, addr);
+}
+void iowrite64be_hi_lo(u64 val, void __iomem *addr)
+{
+   writeq_be(val, addr);
+}
 EXPORT_SYMBOL(iowrite64);
+EXPORT_SYMBOL(iowrite64_lo_hi);
+EXPORT_SYMBOL(iowrite64_hi_lo);
 EXPORT_SYMBOL(iowrite64be);
+EXPORT_SYMBOL(iowrite64be_lo_hi);
+EXPORT_SYMBOL(iowrite64be_hi_lo);
 #endif /* __powerpc64__ */
 
 /*
-- 
2.11.0

[PATCH v6 1/7] drm/tilcdc: ensure nonatomic iowrite64 is not used

[Logan Gunthorpe]

Add a check to ensure iowrite64 is only used if it is atomic.

It was decided in [1] that the tilcdc driver should not be using an
atomic operation (so it was left out of this patchset). However, it turns
out that through the drm code, a nonatomic header is actually included:

include/linux/io-64-nonatomic-lo-hi.h
is included from include/drm/drm_os_linux.h:9:0,
from include/drm/drmP.h:74,
from include/drm/drm_modeset_helper.h:26,
from include/drm/drm_atomic_helper.h:33,
from drivers/gpu/drm/tilcdc/tilcdc_crtc.c:19:

And thus, without this change, this patchset would inadvertantly
change the behaviour of the tilcdc driver.

[1] 
lkml.kernel.org/r/cak8p3a2hho_zcnstzq7hmwsz5la5thu19fwzpun16imnyyn...@mail.gmail.com

Signed-off-by: Logan Gunthorpe 
Cc: Jyri Sarha 
Cc: Arnd Bergmann 
Cc: Tomi Valkeinen 
Cc: David Airlie 
---
 drivers/gpu/drm/tilcdc/tilcdc_regs.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_regs.h 
b/drivers/gpu/drm/tilcdc/tilcdc_regs.h
index 9d528c0a67a4..5048ebb86835 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_regs.h
+++ b/drivers/gpu/drm/tilcdc/tilcdc_regs.h
@@ -133,7 +133,7 @@ static inline void tilcdc_write64(struct drm_device *dev, 
u32 reg, u64 data)
struct tilcdc_drm_private *priv = dev->dev_private;
volatile void __iomem *addr = priv->mmio + reg;
 
-#ifdef iowrite64
+#if defined(iowrite64) && !defined(iowrite64_is_nonatomic)
iowrite64(data, addr);
 #else
__iowmb();
-- 
2.11.0

[PATCH v6 5/7] io-64-nonatomic: add io{read|write}64[be]{_lo_hi|_hi_lo} macros

[Logan Gunthorpe]

This patch adds generic io{read|write}64[be]{_lo_hi|_hi_lo} macros if
they are not already defined by the architecture. (As they are provided
by the generic iomap library).

The patch also points io{read|write}64[be] to the variant specified by the
header name.

This is because new drivers are encouraged to use ioreadXX, et al instead
of readX[1], et al -- and mixing ioreadXX with readq is pretty ugly.

[1] ldd3: section 9.4.2

Signed-off-by: Logan Gunthorpe 
cc: Christoph Hellwig 
cc: Arnd Bergmann 
cc: Alan Cox 
cc: Greg Kroah-Hartman 
---
 include/linux/io-64-nonatomic-hi-lo.h | 64 +++
 include/linux/io-64-nonatomic-lo-hi.h | 64 +++
 2 files changed, 128 insertions(+)

diff --git a/include/linux/io-64-nonatomic-hi-lo.h 
b/include/linux/io-64-nonatomic-hi-lo.h
index defcc4644ce3..410c8b177080 100644
--- a/include/linux/io-64-nonatomic-hi-lo.h
+++ b/include/linux/io-64-nonatomic-hi-lo.h
@@ -54,4 +54,68 @@ static inline void hi_lo_writeq_relaxed(__u64 val, volatile 
void __iomem *addr)
 #define writeq_relaxed hi_lo_writeq_relaxed
 #endif
 
+#ifndef ioread64_hi_lo
+#define ioread64_hi_lo ioread64_hi_lo
+static inline u64 ioread64_hi_lo(void __iomem *addr)
+{
+   u32 low, high;
+
+   high = ioread32(addr + sizeof(u32));
+   low = ioread32(addr);
+
+   return low + ((u64)high << 32);
+}
+#endif
+
+#ifndef iowrite64_hi_lo
+#define iowrite64_hi_lo iowrite64_hi_lo
+static inline void iowrite64_hi_lo(u64 val, void __iomem *addr)
+{
+   iowrite32(val >> 32, addr + sizeof(u32));
+   iowrite32(val, addr);
+}
+#endif
+
+#ifndef ioread64be_hi_lo
+#define ioread64be_hi_lo ioread64be_hi_lo
+static inline u64 ioread64be_hi_lo(void __iomem *addr)
+{
+   u32 low, high;
+
+   high = ioread32be(addr);
+   low = ioread32be(addr + sizeof(u32));
+
+   return low + ((u64)high << 32);
+}
+#endif
+
+#ifndef iowrite64be_hi_lo
+#define iowrite64be_hi_lo iowrite64be_hi_lo
+static inline void iowrite64be_hi_lo(u64 val, void __iomem *addr)
+{
+   iowrite32be(val >> 32, addr);
+   iowrite32be(val, addr + sizeof(u32));
+}
+#endif
+
+#ifndef ioread64
+#define ioread64_is_nonatomic
+#define ioread64 ioread64_hi_lo
+#endif
+
+#ifndef iowrite64
+#define iowrite64_is_nonatomic
+#define iowrite64 iowrite64_hi_lo
+#endif
+
+#ifndef ioread64be
+#define ioread64be_is_nonatomic
+#define ioread64be ioread64be_hi_lo
+#endif
+
+#ifndef iowrite64be
+#define iowrite64be_is_nonatomic
+#define iowrite64be iowrite64be_hi_lo
+#endif
+
 #endif /* _LINUX_IO_64_NONATOMIC_HI_LO_H_ */
diff --git a/include/linux/io-64-nonatomic-lo-hi.h 
b/include/linux/io-64-nonatomic-lo-hi.h
index 084461a4e5ab..acba36812be8 100644
--- a/include/linux/io-64-nonatomic-lo-hi.h
+++ b/include/linux/io-64-nonatomic-lo-hi.h
@@ -54,4 +54,68 @@ static inline void lo_hi_writeq_relaxed(__u64 val, volatile 
void __iomem *addr)
 #define writeq_relaxed lo_hi_writeq_relaxed
 #endif
 
+#ifndef ioread64_lo_hi
+#define ioread64_lo_hi ioread64_lo_hi
+static inline u64 ioread64_lo_hi(void __iomem *addr)
+{
+   u32 low, high;
+
+   low = ioread32(addr);
+   high = ioread32(addr + sizeof(u32));
+
+   return low + ((u64)high << 32);
+}
+#endif
+
+#ifndef iowrite64_lo_hi
+#define iowrite64_lo_hi iowrite64_lo_hi
+static inline void iowrite64_lo_hi(u64 val, void __iomem *addr)
+{
+   iowrite32(val, addr);
+   iowrite32(val >> 32, addr + sizeof(u32));
+}
+#endif
+
+#ifndef ioread64be_lo_hi
+#define ioread64be_lo_hi ioread64be_lo_hi
+static inline u64 ioread64be_lo_hi(void __iomem *addr)
+{
+   u32 low, high;
+
+   low = ioread32be(addr + sizeof(u32));
+   high = ioread32be(addr);
+
+   return low + ((u64)high << 32);
+}
+#endif
+
+#ifndef iowrite64be_lo_hi
+#define iowrite64be_lo_hi iowrite64be_lo_hi
+static inline void iowrite64be_lo_hi(u64 val, void __iomem *addr)
+{
+   iowrite32be(val, addr + sizeof(u32));
+   iowrite32be(val >> 32, addr);
+}
+#endif
+
+#ifndef ioread64
+#define ioread64_is_nonatomic
+#define ioread64 ioread64_lo_hi
+#endif
+
+#ifndef iowrite64
+#define iowrite64_is_nonatomic
+#define iowrite64 iowrite64_lo_hi
+#endif
+
+#ifndef ioread64be
+#define ioread64be_is_nonatomic
+#define ioread64be ioread64be_lo_hi
+#endif
+
+#ifndef iowrite64be
+#define iowrite64be_is_nonatomic
+#define iowrite64be iowrite64be_lo_hi
+#endif
+
 #endif /* _LINUX_IO_64_NONATOMIC_LO_HI_H_ */
-- 
2.11.0

[PATCH v6 7/7] crypto: caam: cleanup CONFIG_64BIT ifdefs when using io{read|write}64

[Logan Gunthorpe]

From: Horia Geantă 

We can now make use of the io-64-nonatomic-lo-hi header to always
provide 64 bit IO operations. So this patch cleans up the extra
CONFIG_64BIT ifdefs.

To be consistent with CAAM engine HW spec: in case of 64-bit registers,
irrespective of device endianness, the lower address should be read from
/ written to first, followed by the upper address. Indeed the I/O
accessors in CAAM driver currently don't follow the spec, however this
is a good opportunity to fix the code.

Signed-off-by: Horia Geantă 
Signed-off-by: Logan Gunthorpe 
Cc: Horia Geantă 
Cc: Dan Douglass 
Cc: Herbert Xu 
Cc: "David S. Miller" 
---
 drivers/crypto/caam/regs.h | 35 +--
 1 file changed, 5 insertions(+), 30 deletions(-)

diff --git a/drivers/crypto/caam/regs.h b/drivers/crypto/caam/regs.h
index 84d2f838a063..0c45505458e7 100644
--- a/drivers/crypto/caam/regs.h
+++ b/drivers/crypto/caam/regs.h
@@ -9,7 +9,7 @@
 
 #include 
 #include 
-#include 
+#include 
 
 /*
  * Architecture-specific register access methods
@@ -134,50 +134,25 @@ static inline void clrsetbits_32(void __iomem *reg, u32 
clear, u32 set)
  *base + 0x : least-significant 32 bits
  *base + 0x0004 : most-significant 32 bits
  */
-#ifdef CONFIG_64BIT
 static inline void wr_reg64(void __iomem *reg, u64 data)
 {
+#ifndef CONFIG_CRYPTO_DEV_FSL_CAAM_IMX
if (caam_little_end)
iowrite64(data, reg);
else
-   iowrite64be(data, reg);
-}
-
-static inline u64 rd_reg64(void __iomem *reg)
-{
-   if (caam_little_end)
-   return ioread64(reg);
-   else
-   return ioread64be(reg);
-}
-
-#else /* CONFIG_64BIT */
-static inline void wr_reg64(void __iomem *reg, u64 data)
-{
-#ifndef CONFIG_CRYPTO_DEV_FSL_CAAM_IMX
-   if (caam_little_end) {
-   wr_reg32((u32 __iomem *)(reg) + 1, data >> 32);
-   wr_reg32((u32 __iomem *)(reg), data);
-   } else
 #endif
-   {
-   wr_reg32((u32 __iomem *)(reg), data >> 32);
-   wr_reg32((u32 __iomem *)(reg) + 1, data);
-   }
+   iowrite64be(data, reg);
 }
 
 static inline u64 rd_reg64(void __iomem *reg)
 {
 #ifndef CONFIG_CRYPTO_DEV_FSL_CAAM_IMX
if (caam_little_end)
-   return ((u64)rd_reg32((u32 __iomem *)(reg) + 1) << 32 |
-   (u64)rd_reg32((u32 __iomem *)(reg)));
+   return ioread64(reg);
else
 #endif
-   return ((u64)rd_reg32((u32 __iomem *)(reg)) << 32 |
-   (u64)rd_reg32((u32 __iomem *)(reg) + 1));
+   return ioread64be(reg);
 }
-#endif /* CONFIG_64BIT  */
 
 #ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
 #ifdef CONFIG_SOC_IMX7D
-- 
2.11.0

[PATCH v6 2/7] powerpc: io.h: move iomap.h include so that it can use readq/writeq defs

[Logan Gunthorpe]

Subsequent patches in this series makes use of the readq and writeq
defines in iomap.h. However, as is, they get missed on the powerpc
platform seeing the include comes before the define. This patch
moves the include down to fix this.

Signed-off-by: Logan Gunthorpe 
Acked-By: Michael Ellerman 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: Nicholas Piggin 
Cc: Suresh Warrier 
Cc: "Oliver O'Halloran" 
---
 arch/powerpc/include/asm/io.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/include/asm/io.h b/arch/powerpc/include/asm/io.h
index 422f99cf9924..af074923d598 100644
--- a/arch/powerpc/include/asm/io.h
+++ b/arch/powerpc/include/asm/io.h
@@ -33,8 +33,6 @@ extern struct pci_dev *isa_bridge_pcidev;
 #include 
 #include 
 
-#include 
-
 #ifdef CONFIG_PPC64
 #include 
 #endif
@@ -663,6 +661,8 @@ static inline void name at  
\
 #define writel_relaxed(v, addr)writel(v, addr)
 #define writeq_relaxed(v, addr)writeq(v, addr)
 
+#include 
+
 #ifdef CONFIG_PPC32
 #define mmiowb()
 #else
-- 
2.11.0

[PATCH v6 4/7] iomap: introduce io{read|write}64_{lo_hi|hi_lo}

[Logan Gunthorpe]

In order to provide non-atomic functions for io{read|write}64 that will
use readq and writeq when appropriate. We define a number of variants
of these functions in the generic iomap that will do non-atomic
operations on pio but atomic operations on mmio.

These functions are only defined if readq and writeq are defined. If
they are not, then the wrappers that always use non-atomic operations
from include/linux/io-64-nonatomic*.h will be used.

Signed-off-by: Logan Gunthorpe 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: Arnd Bergmann 
Cc: Suresh Warrier 
Cc: Nicholas Piggin 
---
 arch/powerpc/include/asm/io.h |   2 +
 include/asm-generic/iomap.h   |  26 +++--
 lib/iomap.c   | 132 ++
 3 files changed, 154 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/include/asm/io.h b/arch/powerpc/include/asm/io.h
index af074923d598..4cc420cfaa78 100644
--- a/arch/powerpc/include/asm/io.h
+++ b/arch/powerpc/include/asm/io.h
@@ -788,8 +788,10 @@ extern void __iounmap_at(void *ea, unsigned long size);
 
 #define mmio_read16be(addr)readw_be(addr)
 #define mmio_read32be(addr)readl_be(addr)
+#define mmio_read64be(addr)readq_be(addr)
 #define mmio_write16be(val, addr)  writew_be(val, addr)
 #define mmio_write32be(val, addr)  writel_be(val, addr)
+#define mmio_write64be(val, addr)  writeq_be(val, addr)
 #define mmio_insb(addr, dst, count)readsb(addr, dst, count)
 #define mmio_insw(addr, dst, count)readsw(addr, dst, count)
 #define mmio_insl(addr, dst, count)readsl(addr, dst, count)
diff --git a/include/asm-generic/iomap.h b/include/asm-generic/iomap.h
index 650fede33c25..30edebf627fe 100644
--- a/include/asm-generic/iomap.h
+++ b/include/asm-generic/iomap.h
@@ -30,9 +30,16 @@ extern unsigned int ioread16(void __iomem *);
 extern unsigned int ioread16be(void __iomem *);
 extern unsigned int ioread32(void __iomem *);
 extern unsigned int ioread32be(void __iomem *);
-#ifdef CONFIG_64BIT
-extern u64 ioread64(void __iomem *);
-extern u64 ioread64be(void __iomem *);
+
+#ifdef readq
+#define ioread64_lo_hi ioread64_lo_hi
+#define ioread64_hi_lo ioread64_hi_lo
+#define ioread64be_lo_hi ioread64be_lo_hi
+#define ioread64be_hi_lo ioread64be_hi_lo
+extern u64 ioread64_lo_hi(void __iomem *addr);
+extern u64 ioread64_hi_lo(void __iomem *addr);
+extern u64 ioread64be_lo_hi(void __iomem *addr);
+extern u64 ioread64be_hi_lo(void __iomem *addr);
 #endif
 
 extern void iowrite8(u8, void __iomem *);
@@ -40,9 +47,16 @@ extern void iowrite16(u16, void __iomem *);
 extern void iowrite16be(u16, void __iomem *);
 extern void iowrite32(u32, void __iomem *);
 extern void iowrite32be(u32, void __iomem *);
-#ifdef CONFIG_64BIT
-extern void iowrite64(u64, void __iomem *);
-extern void iowrite64be(u64, void __iomem *);
+
+#ifdef writeq
+#define iowrite64_lo_hi iowrite64_lo_hi
+#define iowrite64_hi_lo iowrite64_hi_lo
+#define iowrite64be_lo_hi iowrite64be_lo_hi
+#define iowrite64be_hi_lo iowrite64be_hi_lo
+extern void iowrite64_lo_hi(u64 val, void __iomem *addr);
+extern void iowrite64_hi_lo(u64 val, void __iomem *addr);
+extern void iowrite64be_lo_hi(u64 val, void __iomem *addr);
+extern void iowrite64be_hi_lo(u64 val, void __iomem *addr);
 #endif
 
 /*
diff --git a/lib/iomap.c b/lib/iomap.c
index fc3dcb4b238e..845b9c41082c 100644
--- a/lib/iomap.c
+++ b/lib/iomap.c
@@ -66,6 +66,7 @@ static void bad_io_access(unsigned long port, const char 
*access)
 #ifndef mmio_read16be
 #define mmio_read16be(addr) be16_to_cpu(__raw_readw(addr))
 #define mmio_read32be(addr) be32_to_cpu(__raw_readl(addr))
+#define mmio_read64be(addr) be64_to_cpu(__raw_readq(addr))
 #endif
 
 unsigned int ioread8(void __iomem *addr)
@@ -99,6 +100,80 @@ EXPORT_SYMBOL(ioread16be);
 EXPORT_SYMBOL(ioread32);
 EXPORT_SYMBOL(ioread32be);
 
+#ifdef readq
+static u64 pio_read64_lo_hi(unsigned long port)
+{
+   u64 lo, hi;
+
+   lo = inl(port);
+   hi = inl(port + sizeof(u32));
+
+   return lo | (hi << 32);
+}
+
+static u64 pio_read64_hi_lo(unsigned long port)
+{
+   u64 lo, hi;
+
+   hi = inl(port + sizeof(u32));
+   lo = inl(port);
+
+   return lo | (hi << 32);
+}
+
+static u64 pio_read64be_lo_hi(unsigned long port)
+{
+   u64 lo, hi;
+
+   lo = pio_read32be(port + sizeof(u32));
+   hi = pio_read32be(port);
+
+   return lo | (hi << 32);
+}
+
+static u64 pio_read64be_hi_lo(unsigned long port)
+{
+   u64 lo, hi;
+
+   hi = pio_read32be(port);
+   lo = pio_read32be(port + sizeof(u32));
+
+   return lo | (hi << 32);
+}
+
+u64 ioread64_lo_hi(void __iomem *addr)
+{
+   IO_COND(addr, return pio_read64_lo_hi(port), return readq(addr));
+   return 0xULL;
+}
+
+u64 ioread64_hi_lo(void __iomem *addr)
+{
+   

Re: [PATCH v2 1/4] dt-bindings: crypto: add ARTPEC crypto

[Rob Herring]

On Mon, Jul 24, 2017 at 09:07:29AM +0200, Lars Persson wrote:
> Document the device tree bindings for the ARTPEC crypto accelerator on
> ARTPEC-6 and ARTPEC-7 SoCs.
> 
> Signed-off-by: Lars Persson 
> ---
>  .../devicetree/bindings/crypto/artpec6-crypto.txt| 16 
> 
>  1 file changed, 16 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/crypto/artpec6-crypto.txt

Acked-by: Rob Herring 

Re: [PATCH v3 7/7] ima: Support module-style appended signatures for appraisal

[Mimi Zohar]

On Wed, 2017-08-02 at 18:52 -0400, Mimi Zohar wrote:
> On Wed, 2017-08-02 at 14:42 -0300, Thiago Jung Bauermann wrote:
> > Mimi Zohar  writes:

> > >> @@ -229,8 +251,24 @@ int ima_appraise_measurement(enum ima_hooks func,
> > >>  goto out;
> > >>  }
> > >> 
> > >> -status = evm_verifyxattr(dentry, XATTR_NAME_IMA, xattr_value, 
> > >> rc, iint);
> > >> -if ((status != INTEGRITY_PASS) && (status != 
> > >> INTEGRITY_UNKNOWN)) {
> > >> +/*
> > >> + * Appended signatures aren't protected by EVM but we still call
> > >> + * evm_verifyxattr to check other security xattrs, if they 
> > >> exist.
> > >> + */
> > >> +if (appraising_modsig) {
> > >> +xattr_value_evm = NULL;
> > >> +xattr_len_evm = 0;
> > >> +} else {
> > >> +xattr_value_evm = xattr_value;
> > >> +xattr_len_evm = xattr_len;
> > >> +}
> > >> +
> > >> +status = evm_verifyxattr(dentry, XATTR_NAME_IMA, 
> > >> xattr_value_evm,
> > >> + xattr_len_evm, iint);
> > >> +if (appraising_modsig && status == INTEGRITY_FAIL) {
> > >> +cause = "invalid-HMAC";
> > >> +goto out;
> > >
> > > "modsig" is special, because having any security xattrs is not
> > > required. This test doesn't prevent status from being set to
> > > "missing-HMAC". This test is redundant with the original tests below.
> > 
> > Indeed, that is wrong. I'm still a bit fuzzy about how EVM works and how
> > it interacts with IMA. The only way I can think of singling out modsig
> > without reintroduced the complex expression you didn't like in v2 is as
> > below. What do you think?
> 
> The original code, without any extra tests, should be fine.

There is one major difference.

EVM verifies a file's metadata has not been modified based on either
an HMAC or signature stored as security.evm.  Prior to the appended
signatures patch set, all files in policy required a security.evm
xattr. With IMA enabled we could guarantee that at least one security
xattr existed.  The only exception were new files, which hadn't yet
been labeled. 

With appended signatures, there is now no guarantee that at least one
security xattr exists.

Perhaps the code snippet below will help clarify the meaning of the
integrity_status results. 

        switch (status) {
case INTEGRITY_PASS:
case INTEGRITY_UNKNOWN:      
              break;
        case INTEGRITY_NOXATTRS:/* no EVM protected xattrs */
if (appraising_modsig)
break;
case INTEGRITY_NOLABEL: /* no security.evm xattr */
cause = "missing-HMAC";
fail = 1;
break;
case INTEGRITY_FAIL:/* invalid HMAC/signature */
default:
cause = "invalid-HMAC";
fail = 1;
break;
}

Mimi

Re: [PATCH V2] staging: ccree: Fix format/argument mismatches

[Joe Perches]

On Thu, 2017-08-03 at 17:09 +0800, kbuild test robot wrote:
> Hi Joe,
> 
> [auto build test WARNING on staging/staging-testing]
> [also build test WARNING on next-20170803]
> [cannot apply to v4.13-rc3]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improve the system]

Pretty odd that m32r has ioread32 as _readl and so unsigned long
Seems silly to have to cast it.

Gilad, is this actually a supported platform for ccree?

> url:
> https://github.com/0day-ci/linux/commits/Joe-Perches/staging-ccree-Fix-format-argument-mismatches/20170731-191055
> config: m32r-allmodconfig (attached as .config)
> compiler: m32r-linux-gcc (GCC) 6.2.0
> reproduce:
> wget 
> https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> make.cross ARCH=m32r 
> 
> All warnings (new ones prefixed by >>):
> 
>In file included from include/linux/kernel.h:13:0,
> from drivers/staging/ccree/ssi_driver.c:17:
>drivers/staging/ccree/ssi_driver.c: In function 'init_cc_regs':
> > > drivers/staging/ccree/ssi_driver.c:180:16: warning: format '%X' expects 
> > > argument of type 'unsigned int', but argument 2 has type 'long unsigned 
> > > int' [-Wformat=]
> 
>  SSI_LOG_DEBUG("AXIM_CFG=0x%08X\n", 
> CC_HAL_READ_REGISTER(CC_REG_OFFSET(CRY_KERNEL, AXIM_CFG)));

[PATCH] crypto: sahara - Remove leftover from previous used spinlock

[Mogens Lauridsen]

This driver previously used a spinlock. The spinlock is not
used any more, but the spinlock variable was still there
and also being initialized.

Signed-off-by: Mogens Lauridsen 
---
 drivers/crypto/sahara.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/crypto/sahara.c b/drivers/crypto/sahara.c
index 474da36bdd2c..03a8abad7e76 100644
--- a/drivers/crypto/sahara.c
+++ b/drivers/crypto/sahara.c
@@ -202,7 +202,6 @@ struct sahara_dev {
struct completion   dma_completion;
 
struct sahara_ctx   *ctx;
-   spinlock_t  lock;
struct crypto_queue queue;
unsigned long   flags;
 
@@ -1487,7 +1486,6 @@ static int sahara_probe(struct platform_device *pdev)
 
crypto_init_queue(>queue, SAHARA_QUEUE_LENGTH);
 
-   spin_lock_init(>lock);
mutex_init(>queue_mutex);
 
dev_ptr = dev;
-- 
2.13.4

[PATCH v5] crypto : stm32 - Add STM32F4 CRC32 support

[Cosar Dindar]

This patch adds CRC (CRC32 Crypto) support for STM32F4 series.

As an hardware limitation polynomial and key setting are not supported.
They are fixed as 0x4C11DB7 (poly) and 0x (key).
CRC32C Castagnoli algorithm is not used.

Signed-off-by: Cosar Dindar 
---
Changes in v5:
  - shash_alg struct definitons are defined seperately according to 
the platform type.
Changes in v4:
  - Edited patch summary.
Changes in v3:
  - Rearranged patch order to fix build test error.
Changes in v2:
  - Patchset created instead of one patch.

 drivers/crypto/stm32/stm32_crc32.c | 101 -
 1 file changed, 89 insertions(+), 12 deletions(-)

diff --git a/drivers/crypto/stm32/stm32_crc32.c 
b/drivers/crypto/stm32/stm32_crc32.c
index ec83b1e..39b28b8 100644
--- a/drivers/crypto/stm32/stm32_crc32.c
+++ b/drivers/crypto/stm32/stm32_crc32.c
@@ -1,12 +1,14 @@
 /*
  * Copyright (C) STMicroelectronics SA 2017
  * Author: Fabien Dessenne 
+ * Author: Cosar Dindar 
  * License terms:  GNU General Public License (GPL), version 2
  */
 
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -37,8 +39,12 @@ struct stm32_crc {
struct device*dev;
void __iomem *regs;
struct clk   *clk;
+   struct shash_alg *algs;
u8   pending_data[sizeof(u32)];
size_t   nb_pending_bytes;
+   bool key_support;
+   bool poly_support;
+   bool reverse_support;
 };
 
 struct stm32_crc_list {
@@ -106,13 +112,31 @@ static int stm32_crc_init(struct shash_desc *desc)
}
spin_unlock_bh(_list.lock);
 
-   /* Reset, set key, poly and configure in bit reverse mode */
-   writel(bitrev32(mctx->key), ctx->crc->regs + CRC_INIT);
-   writel(bitrev32(mctx->poly), ctx->crc->regs + CRC_POL);
-   writel(CRC_CR_RESET | CRC_CR_REVERSE, ctx->crc->regs + CRC_CR);
+   /* set key */
+   if (ctx->crc->key_support) {
+   writel(bitrev32(mctx->key), ctx->crc->regs + CRC_INIT);
+   } else if (mctx->key != CRC_INIT_DEFAULT) {
+   dev_err(ctx->crc->dev, "Unsupported key value! Should be: 
0x%x\n",
+   CRC_INIT_DEFAULT);
+   return -EINVAL;
+   }
+
+   /* set poly */
+   if (ctx->crc->poly_support)
+   writel(bitrev32(mctx->poly), ctx->crc->regs + CRC_POL);
+
+   /* reset and configure in bit reverse mode if supported */
+   if (ctx->crc->reverse_support)
+   writel(CRC_CR_RESET | CRC_CR_REVERSE, ctx->crc->regs + CRC_CR);
+   else
+   writel(CRC_CR_RESET, ctx->crc->regs + CRC_CR);
+
+   /* store partial result */
+   if (!ctx->crc->reverse_support)
+   ctx->partial = bitrev32(readl(crc->regs + CRC_DR));
+   else
+   ctx->partial = readl(ctx->crc->regs + CRC_DR);
 
-   /* Store partial result */
-   ctx->partial = readl(ctx->crc->regs + CRC_DR);
ctx->crc->nb_pending_bytes = 0;
 
return 0;
@@ -135,7 +159,12 @@ static int stm32_crc_update(struct shash_desc *desc, const 
u8 *d8,
 
if (crc->nb_pending_bytes == sizeof(u32)) {
/* Process completed pending data */
-   writel(*(u32 *)crc->pending_data, crc->regs + CRC_DR);
+   if (!ctx->crc->reverse_support)
+   writel(bitrev32(*(u32 *)crc->pending_data),
+  crc->regs + CRC_DR);
+   else
+   writel(*(u32 *)crc->pending_data,
+  crc->regs + CRC_DR);
crc->nb_pending_bytes = 0;
}
}
@@ -143,10 +172,16 @@ static int stm32_crc_update(struct shash_desc *desc, 
const u8 *d8,
d32 = (u32 *)d8;
for (i = 0; i < length >> 2; i++)
/* Process 32 bits data */
-   writel(*(d32++), crc->regs + CRC_DR);
+   if (!ctx->crc->reverse_support)
+   writel(bitrev32(*(d32++)), crc->regs + CRC_DR);
+   else
+   writel(*(d32++), crc->regs + CRC_DR);
 
/* Store partial result */
-   ctx->partial = readl(crc->regs + CRC_DR);
+   if (!ctx->crc->reverse_support)
+   ctx->partial = bitrev32(readl(crc->regs + CRC_DR));
+   else
+   ctx->partial = readl(crc->regs + CRC_DR);
 
/* Check for pending data (non 32 bits) */
length &= 3;
@@ -192,7 +227,7 @@ static int stm32_crc_digest(struct shash_desc *desc, const 
u8 *data,
return stm32_crc_init(desc) ?: stm32_crc_finup(desc, data, length, out);
 }
 
-static struct shash_alg algs[] = {
+static struct shash_alg algs_for_f7[] = {
/* CRC-32 */
{
.setkey = stm32_crc_setkey,
@@ -237,12 +272,37 @@ 

[PATCH] crypto: sahara - Fix dma unmap direction

[Mogens Lauridsen]

The direction used in dma_unmap_sg in aes calc is wrong.
This result in the cache not being invalidated correct when aes
calculation is done and result has been dma'ed to memory.
This is seen as sporadic wrong result from aes calc.

Signed-off-by: Mogens Lauridsen 
---
 drivers/crypto/sahara.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/crypto/sahara.c b/drivers/crypto/sahara.c
index c2174ec88e2a..474da36bdd2c 100644
--- a/drivers/crypto/sahara.c
+++ b/drivers/crypto/sahara.c
@@ -543,10 +543,10 @@ static int sahara_hw_descriptor_create(struct sahara_dev 
*dev)
 
 unmap_out:
dma_unmap_sg(dev->device, dev->out_sg, dev->nb_out_sg,
-   DMA_TO_DEVICE);
+   DMA_FROM_DEVICE);
 unmap_in:
dma_unmap_sg(dev->device, dev->in_sg, dev->nb_in_sg,
-   DMA_FROM_DEVICE);
+   DMA_TO_DEVICE);
 
return -EINVAL;
 }
@@ -594,9 +594,9 @@ static int sahara_aes_process(struct ablkcipher_request 
*req)
}
 
dma_unmap_sg(dev->device, dev->out_sg, dev->nb_out_sg,
-   DMA_TO_DEVICE);
-   dma_unmap_sg(dev->device, dev->in_sg, dev->nb_in_sg,
DMA_FROM_DEVICE);
+   dma_unmap_sg(dev->device, dev->in_sg, dev->nb_in_sg,
+   DMA_TO_DEVICE);
 
return 0;
 }
-- 
2.13.4

Re: [PATCH resend 00/18] crypto: ARM/arm64 roundup for v4.14

[Dave Martin]

On Thu, Aug 03, 2017 at 02:26:53PM +0800, Herbert Xu wrote:
> On Mon, Jul 24, 2017 at 11:28:02AM +0100, Ard Biesheuvel wrote:
> > This is a resend of all the patches I sent out recently that I would
> > like to be considered for v4.14. Their main purpose is to prepare the
> > arm64 crypto code to deal with situations where the SIMD register file
> > is unavailable, which never occurs at present, but this will change in
> > the future when support for SVE is added.
> > 
> > Patches #1 and #2 have been sent out last week as 'crypto/algapi - refactor
> > crypto_xor() to avoid memcpy()s' (v2). This version of #2 fixes an error
> > caught by kbuild. The non-SIMD fallback code added in the remaining patches
> > relies on crypto_xor() extensively, which is why these patches have been
> > included here.
> > 
> > Patches #3 - #13 implement the non-SIMD fallbacks for the various NEON
> > based drivers.
> > 
> > Patch #14 implements AES-GCM natively instead of relying on the generic
> > GCM module to wire accelerated AES-CTR and GHASH together, resulting in
> > a ~37% speedup.
> > 
> > Patches #15 and #16 implement an accelerated GHASH algorithm for ARM cores
> > that lack the 64x64 PMULL instruction.
> > 
> > Patches #17 and #18 update the scalar AES implementations to stop using
> > the expanded lookup tables for the final round. This reduces the Dcache
> > footprint, and thus the key correlated jitter.
> > 
> > This supersedes all other crypto patches I have outstanding, including the
> > AES refactor ones which I will rework later.
> > 
> > Ard Biesheuvel (18):
> >   crypto/algapi - use separate dst and src operands for __crypto_xor()
> >   crypto/algapi - make crypto_xor() take separate dst and src arguments
> >   crypto: arm64/ghash-ce - add non-SIMD scalar fallback
> >   crypto: arm64/crct10dif - add non-SIMD generic fallback
> >   crypto: arm64/crc32 - add non-SIMD scalar fallback
> >   crypto: arm64/sha1-ce - add non-SIMD generic fallback
> >   crypto: arm64/sha2-ce - add non-SIMD scalar fallback
> >   crypto: arm64/aes-ce-cipher - match round key endianness with generic
> > code
> >   crypto: arm64/aes-ce-cipher: add non-SIMD generic fallback
> >   crypto: arm64/aes-ce-ccm: add non-SIMD generic fallback
> >   crypto: arm64/aes-blk - add a non-SIMD fallback for synchronous CTR
> >   crypto: arm64/chacha20 - take may_use_simd() into account
> >   crypto: arm64/aes-bs - implement non-SIMD fallback for AES-CTR
> >   crypto: arm64/gcm - implement native driver using v8 Crypto Extensions
> >   crypto: arm/ghash - add NEON accelerated fallback for vmull.p64
> >   crypto: arm64/ghash - add NEON accelerated fallback for 64-bit PMULL
> >   crypto: arm/aes - avoid expanded lookup tables in the final round
> >   crypto: arm64/aes - avoid expanded lookup tables in the final round
> 
> All applied.  Thanks.

Awesome, thanks
---Dave

Re: [PATCH V3 2/6] crypto/nx: Create nx842_configure_crb function

[Herbert Xu]

On Thu, Aug 03, 2017 at 07:53:16PM +1000, Michael Ellerman wrote:
> Herbert Xu  writes:
> 
> > On Fri, Jul 21, 2017 at 09:57:39PM -0700, Haren Myneni wrote:
> >> 
> >> Configure CRB is moved to nx842_configure_crb() so that it can
> >> be used for icswx and VAS exec functions. VAS function will be
> >> added later with P9 support.
> >> 
> >> Signed-off-by: Haren Myneni 
> >
> > Your patch does not apply against cryptodev.  Please rebase.
> 
> It depends on another series that will go via my tree, so it might be
> better if this series goes via my tree too?

Sure, that's fine by me.

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

Re: [PATCH V3 2/6] crypto/nx: Create nx842_configure_crb function

[Michael Ellerman]

Herbert Xu  writes:

> On Fri, Jul 21, 2017 at 09:57:39PM -0700, Haren Myneni wrote:
>> 
>> Configure CRB is moved to nx842_configure_crb() so that it can
>> be used for icswx and VAS exec functions. VAS function will be
>> added later with P9 support.
>> 
>> Signed-off-by: Haren Myneni 
>
> Your patch does not apply against cryptodev.  Please rebase.

It depends on another series that will go via my tree, so it might be
better if this series goes via my tree too?

cheers

Re: [PATCH v1] crypto: caam - set hwrng quality level

[Oleksij Rempel]

On 03.08.2017 09:48, Horia Geantă wrote:

On 8/3/2017 6:17 AM, Herbert Xu wrote:

On Wed, Aug 02, 2017 at 02:03:14PM +, Horia Geantă wrote:


Take CAAM's engine HWRNG: it can work both as a TRNG and as a
TRNG-seeded DRBG (that's how it's currently configured).
IIUC, both setups are fit as source for the entropy pool.


So which is it? If it's a DRBG then it should not be exposed through
the hwrng interface.  Only TRNG should go through hwrng.  DRBGs
can use the crypto rng API.


Right now it's configured as a DRBG.
If I read correctly, it doesn't matter it's using the internal TRNG for
(automated) seeding, it still shouldn't use hwrng.
This means it's broken since the very beginning:
e24f7c9e87d4 crypto: caam - hwrng support


Hmmm..
- what is the security risk of this issue? For example system which use 
/dev/hwrng directly?

- And who will fix it?

Re: [PATCH V2] staging: ccree: Fix format/argument mismatches

[kbuild test robot]

Hi Joe,

[auto build test WARNING on staging/staging-testing]
[also build test WARNING on next-20170803]
[cannot apply to v4.13-rc3]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Joe-Perches/staging-ccree-Fix-format-argument-mismatches/20170731-191055
config: m32r-allmodconfig (attached as .config)
compiler: m32r-linux-gcc (GCC) 6.2.0
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=m32r 

All warnings (new ones prefixed by >>):

   In file included from include/linux/kernel.h:13:0,
from drivers/staging/ccree/ssi_driver.c:17:
   drivers/staging/ccree/ssi_driver.c: In function 'init_cc_regs':
>> drivers/staging/ccree/ssi_driver.c:180:16: warning: format '%X' expects 
>> argument of type 'unsigned int', but argument 2 has type 'long unsigned int' 
>> [-Wformat=]
 SSI_LOG_DEBUG("AXIM_CFG=0x%08X\n", 
CC_HAL_READ_REGISTER(CC_REG_OFFSET(CRY_KERNEL, AXIM_CFG)));
   ^
   include/linux/printk.h:136:11: note: in definition of macro 'no_printk'
   printk(fmt, ##__VA_ARGS__); \
  ^~~
>> drivers/staging/ccree/ssi_driver.c:180:2: note: in expansion of macro 
>> 'SSI_LOG_DEBUG'
 SSI_LOG_DEBUG("AXIM_CFG=0x%08X\n", 
CC_HAL_READ_REGISTER(CC_REG_OFFSET(CRY_KERNEL, AXIM_CFG)));
 ^
   In file included from drivers/staging/ccree/ssi_driver.c:64:0:
   drivers/staging/ccree/ssi_driver.c: In function 'init_cc_resources':
   include/linux/kern_levels.h:4:18: warning: format '%X' expects argument of 
type 'unsigned int', but argument 4 has type 'long unsigned int' [-Wformat=]
#define KERN_SOH "\001"  /* ASCII Start Of Header */
 ^
   drivers/staging/ccree/ssi_driver.h:95:9: note: in definition of macro 
'SSI_LOG'
 printk(level "cc715ree::%s: " format, __func__, ##__VA_ARGS__)
^
   include/linux/kern_levels.h:13:19: note: in expansion of macro 'KERN_SOH'
#define KERN_INFO KERN_SOH "6" /* informational */
  ^~~~
   drivers/staging/ccree/ssi_driver.c:319:10: note: in expansion of macro 
'KERN_INFO'
 SSI_LOG(KERN_INFO, "ARM CryptoCell %s Driver: HW version 0x%08X, Driver 
version %s\n", SSI_DEV_NAME_STR,
 ^

vim +180 drivers/staging/ccree/ssi_driver.c

abefd674 Gilad Ben-Yossef 2017-04-23  @17  #include 
abefd674 Gilad Ben-Yossef 2017-04-23   18  #include 
abefd674 Gilad Ben-Yossef 2017-04-23   19  
abefd674 Gilad Ben-Yossef 2017-04-23   20  #include 
abefd674 Gilad Ben-Yossef 2017-04-23   21  #include 
abefd674 Gilad Ben-Yossef 2017-04-23   22  #include 
abefd674 Gilad Ben-Yossef 2017-04-23   23  #include 
fe0a1951 Gilad Ben-Yossef 2017-04-23   24  #include 
abefd674 Gilad Ben-Yossef 2017-04-23   25  #include 
abefd674 Gilad Ben-Yossef 2017-04-23   26  #include 
302ef8eb Gilad Ben-Yossef 2017-04-23   27  #include 
abefd674 Gilad Ben-Yossef 2017-04-23   28  
abefd674 Gilad Ben-Yossef 2017-04-23   29  #include 
abefd674 Gilad Ben-Yossef 2017-04-23   30  #include 
abefd674 Gilad Ben-Yossef 2017-04-23   31  #include 
abefd674 Gilad Ben-Yossef 2017-04-23   32  #include 
abefd674 Gilad Ben-Yossef 2017-04-23   33  #include 
abefd674 Gilad Ben-Yossef 2017-04-23   34  #include 
abefd674 Gilad Ben-Yossef 2017-04-23   35  #include 
abefd674 Gilad Ben-Yossef 2017-04-23   36  #include 
abefd674 Gilad Ben-Yossef 2017-04-23   37  #include 
abefd674 Gilad Ben-Yossef 2017-04-23   38  #include 
abefd674 Gilad Ben-Yossef 2017-04-23   39  #include 
abefd674 Gilad Ben-Yossef 2017-04-23   40  #include 
abefd674 Gilad Ben-Yossef 2017-04-23   41  #include 
abefd674 Gilad Ben-Yossef 2017-04-23   42  #include 
abefd674 Gilad Ben-Yossef 2017-04-23   43  #include 
abefd674 Gilad Ben-Yossef 2017-04-23   44  #include 
abefd674 Gilad Ben-Yossef 2017-04-23   45  #include 
abefd674 Gilad Ben-Yossef 2017-04-23   46  #include 
abefd674 Gilad Ben-Yossef 2017-04-23   47  #include 
abefd674 Gilad Ben-Yossef 2017-04-23   48  #include 
abefd674 Gilad Ben-Yossef 2017-04-23   49  #include 
abefd674 Gilad Ben-Yossef 2017-04-23   50  #include 
abefd674 Gilad Ben-Yossef 2017-04-23   51  
abefd674 Gilad Ben-Yossef 2017-04-23   52  /* cache.h required for 
L1_CACHE_ALIGN() and cache_line_size() */
abefd674 Gilad Ben-Yossef 2017-04-23   53  #include 
abefd674 Gilad Ben-Yossef 2017-04-23   54  #include 
abefd674 Gilad Ben-Yossef 2017-04-23   55  #include 
abefd674 Gilad Ben-Yossef 2017-04-23   56  #include 
abefd674 Gilad Ben-Yossef 2017-04-23   57  #include 
abefd674 Gilad Ben-Yossef 2017-04-23   58  #include 
abefd674 Gilad Ben-Yossef 2017-04-23   59  #include 
675ef02f Gilad Ben-Yossef 2017-06-25   60  #include 
d255b343 Gilad Ben-

Re: [RESEND,PATCH v4 3/3] crypto : stm32 - Add STM32F4 CRC32 support

[Cosar Dindar]

On Thu, Aug 03, 2017 at 01:44:23PM +0800, Herbert Xu wrote:
> On Mon, Jul 17, 2017 at 11:27:36AM +0300, Cosar Dindar wrote:
> > This patch adds CRC (CRC32 Crypto) support for STM32F4 series.
> > 
> > As an hardware limitation polynomial and key setting are not supported.
> > They are fixed as 0x4C11DB7 (poly) and 0x (key).
> > CRC32C Castagnoli algorithm is not used.
> > 
> > Signed-off-by: Cosar Dindar 
> > Reviewed-by: Fabien Dessenne 
> 
> This patch doesn't apply anymore.  Please rebase.
> 
> Thanks,

OK, I'll rebase and send a new patch including new changes.

Thanks, 

Best Regards,
 
Cosar.

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

Re: KPP questions and confusion

[Marcel Holtmann]

Hi Tudor,

>>> I am confused about several things in the new key agreement code.
>>> 
>>> net/bluetooth/smp.c in two places generates random bytes for the
>>> private_key argument to
>>> net/bluetooth/ecdh_helper.c:generate_ecdh_keys, which suggests the
>>> private key is static within the function. However, there is a do ...
>>> while(true) loop within generate_ecdh_keys, with the following near
>>> the end:
>>> 
>>> /* Private key is not valid. Regenerate */
>>> if (err == -EINVAL)
>>>continue;
>>> 
>>> which suggests that it expects a different private key to be generated
>>> on each iteration of the loop. But it looks like it runs through the
>>> loop yet again with the same private key generated in the caller,
>>> which suggests it would infinitely loop on a bad private key value. Is
>>> this incorrect?
>> actually it seems that I screwed that up with commit 
>> 71653eb64bcca6110c42aadfd50b8d54d3a88079 where I moved the seeding of 
>> private_key outside of generate_ecdh_keys() function.
>>> Furthermore, since req->src == NULL via the call to
>>> kpp_request_set_input, ecc_make_pub_key will always be called in
>>> ecdh.c:ecdh_compute_value, in which case -EINVAL would be returned
>>> only by invalid input (!private_key or bad curve_id) that AFAICT
>>> cannot happen, or at least wouldn't be resolved by another run through
>>> the loop.
>>> 
>>> OTOH, -EAGAIN would be returned by ecc_make_pub_key if the public key
>>> turns out to be the zero point, which is at least one reason why you'd
>>> want to generate a new private key (if that loop were to do that.)
>>> 
>>> I'm a little confused about some other things:
>>> 
>>> * The bluetooth code doesn't seem to use ecc_gen_privkey, opting to
>>> instead just generate random bytes and hope for the best.
>>> * There doesn't appear to be any way for ecc_gen_privkey to get called
>>> from crypto/ecdh.c:ecdh_set_secret, as it starts with a call to
>>> crypto/ecdh_helper.c:crypto_ecdh_decode_key that returns -EINVAL if
>>> decoding fails, meaning that both params.key != NULL and (if I'm
>>> reading this correctly) params.key_size > 0. Is that dead code, or is
>>> there a way it is intended to be used?
>> I am fine switching to ecc_gen_privkey. Care to provide a patch for it?
> 
> Marcel, regarding the ecdh offload to hw from Bluetooth SMP code, this
> is not possible as of know because SMP code uses it's own private keys.
> atmel-ecc driver will fallback to the ecdh software implementation if
> user wants to use it's own private keys.
> 
> I can jump in the Bluetooth's ecdh handling, but at best effort, my
> primary goal is to add support for KPP in af_alg.

then we need a better abstraction inside KPP. Since even for Bluetooth SMP the 
keys are temporary. The only thing we have to check is against a well know 
public/private key pair that was designated as debug key for sniffer purposes.

Essentially we do what all other key exchange procedure do. Generate a 
private/public key pair, give the public key to the other side, run DH with the 
value from the other side. That Bluetooth SMP knows about the private key is 
really pointless. Since the detection of debug key usage is actually via the 
public key portion.

Regards

Marcel

Re: [PATCH 0/4] crypto: caam - add Job Ring support for DPAA2 parts

[Horia Geantă]

On 7/25/2017 4:50 PM, Shawn Guo wrote:
> On Tue, Jul 25, 2017 at 01:31:52PM +, Horia Geantă wrote:
>> On 7/25/2017 4:22 PM, Shawn Guo wrote:
>>> On Tue, Jul 18, 2017 at 06:30:46PM +0300, Horia Geantă wrote:
 This patch set adds support for CAAM's legacy Job Ring backend / interface
 on platforms having DPAA2 (Datapath Acceleration Architecture v2), like
 LS1088A or LS2088A.

 I would like to get the DT patches through the crypto list (to make sure
 they don't end up merged before driver support).
>>>
>>> Unless it's really urgent (usually critical bug fix), the DTS patches
>>> should go through arm-soc tree.  We usually take DTS patches after the
>>> driver counterpart has been accepted by subsystem maintainers, or in the
>>> best case, has landed on mainline.
>>
>> Thanks for the clarification.
>>
>> Do I have to re-post the DTS patches once the driver is accepted or a
>> ping should suffice or...?
> 
> A ping is sufficient.

Shawn,

Driver support (patch 1/4) has just been applied to the cryptodev-2.6 tree:
297b9cebd2fc crypto: caam/jr - add support for DPAA2 parts

Could you please pick up the DTS patches (2-4/4) in this series?

Thanks,
Horia

Re: [PATCH v1] crypto: caam - set hwrng quality level

[Horia Geantă]

On 8/3/2017 6:17 AM, Herbert Xu wrote:
> On Wed, Aug 02, 2017 at 02:03:14PM +, Horia Geantă wrote:
>>
>> Take CAAM's engine HWRNG: it can work both as a TRNG and as a
>> TRNG-seeded DRBG (that's how it's currently configured).
>> IIUC, both setups are fit as source for the entropy pool.
> 
> So which is it? If it's a DRBG then it should not be exposed through
> the hwrng interface.  Only TRNG should go through hwrng.  DRBGs
> can use the crypto rng API.

Right now it's configured as a DRBG.
If I read correctly, it doesn't matter it's using the internal TRNG for
(automated) seeding, it still shouldn't use hwrng.
This means it's broken since the very beginning:
e24f7c9e87d4 crypto: caam - hwrng support

Thanks,
Horia

Re: [PATCH v2 2/4] crypto: add crypto_(un)register_ahashes()

[Herbert Xu]

On Mon, Jul 24, 2017 at 09:07:30AM +0200, Lars Persson wrote:
> From: Rabin Vincent 
> 
> There are already helpers to (un)register multiple normal
> and AEAD algos.  Add one for ahashes too.
> 
> Signed-off-by: Lars Persson 

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

Re: [PATCH v6 1/3] Documentation: devicetree: add Freescale RNGC binding

[Herbert Xu]

On Sun, Jul 23, 2017 at 07:49:04PM +0200, Martin Kaiser wrote:
> From: Steffen Trumtrar 
> 
> Add binding documentation for the Freescale RNGC found on
> some i.MX2/3 SoCs.
> 
> Signed-off-by: Steffen Trumtrar 
> Signed-off-by: Martin Kaiser 

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

Re: [RESEND PATCH 0/2] crypto/rockchip: fix some issue which causes crypto failed

[Herbert Xu]

On Mon, Jul 24, 2017 at 09:23:12AM +0800, zain wang wrote:
> These patches fix some bugs on rockchip's crypto which would cause crypto 
> failed.
> 
> zain wang (2):
>   crypto: rockchip - move the crypto completion from interrupt context
>   crypto: rockchip - return the err code when unable dequeue the crypto
> request

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

Re: [PATCH v3 0/3] Update support for XTS-AES on AMD CCPs

[Herbert Xu]

On Tue, Jul 25, 2017 at 02:21:12PM -0500, Gary R Hook wrote:
> The following series adds support for XS-AES on version 5 CCPs, both
> 128- and 256-bit, and enhances/clarifies/simplifies some crypto layer
> code.
> 
> Changes since v2:
>  - Move a CCP v5 fix out of this patch series and submit independently
>  - In the unit-size check patch:
> - Edit comments
> - Remove unnecessary variable
> - Delay a change (that belongs in the CCP v5 patch)
> 
> Changes since v1:
>  - rework the validation of the unit-size; move to a separate patch
>  - expand the key buffer to accommodate 256-bit keys
>  - use xts_check_key() in the crypto layer
> 
> 
> ---
> 
> Gary R Hook (3):
>   crypto: ccp - Add a call to xts_check_key()
>   crypto: ccp - Rework the unit-size check for XTS-AES
>   crypto: ccp - Add XTS-AES-256 support for CCP version 5

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

Re: [PATCH v2 3/4] crypto: axis: add ARTPEC-6/7 crypto accelerator driver

[Herbert Xu]

On Mon, Jul 24, 2017 at 09:07:31AM +0200, Lars Persson wrote:
> This is an asynchronous crypto API driver for the accelerator present
> in the ARTPEC-6 and -7 SoCs from Axis Communications AB.
> 
> The driver supports AES in ECB/CTR/CBC/XTS/GCM modes and SHA1/2 hash
> standards.
> 
> Signed-off-by: Lars Persson 

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

Re: [PATCH] crypto: ccp - Fix XTS-AES-128 support on v5 CCPs

[Herbert Xu]

On Tue, Jul 25, 2017 at 02:12:11PM -0500, Gary R Hook wrote:
> Version 5 CCPs have some new requirements for XTS-AES: the type field
> must be specified, and the key requires 512 bits, with each part
> occupying 256 bits and padded with zeroes.
> 
> cc:  # 4.9.x+
> 
> Signed-off-by: Gary R Hook 

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

Re: [PATCH resend 00/18] crypto: ARM/arm64 roundup for v4.14

[Herbert Xu]

On Mon, Jul 24, 2017 at 11:28:02AM +0100, Ard Biesheuvel wrote:
> This is a resend of all the patches I sent out recently that I would
> like to be considered for v4.14. Their main purpose is to prepare the
> arm64 crypto code to deal with situations where the SIMD register file
> is unavailable, which never occurs at present, but this will change in
> the future when support for SVE is added.
> 
> Patches #1 and #2 have been sent out last week as 'crypto/algapi - refactor
> crypto_xor() to avoid memcpy()s' (v2). This version of #2 fixes an error
> caught by kbuild. The non-SIMD fallback code added in the remaining patches
> relies on crypto_xor() extensively, which is why these patches have been
> included here.
> 
> Patches #3 - #13 implement the non-SIMD fallbacks for the various NEON
> based drivers.
> 
> Patch #14 implements AES-GCM natively instead of relying on the generic
> GCM module to wire accelerated AES-CTR and GHASH together, resulting in
> a ~37% speedup.
> 
> Patches #15 and #16 implement an accelerated GHASH algorithm for ARM cores
> that lack the 64x64 PMULL instruction.
> 
> Patches #17 and #18 update the scalar AES implementations to stop using
> the expanded lookup tables for the final round. This reduces the Dcache
> footprint, and thus the key correlated jitter.
> 
> This supersedes all other crypto patches I have outstanding, including the
> AES refactor ones which I will rework later.
> 
> Ard Biesheuvel (18):
>   crypto/algapi - use separate dst and src operands for __crypto_xor()
>   crypto/algapi - make crypto_xor() take separate dst and src arguments
>   crypto: arm64/ghash-ce - add non-SIMD scalar fallback
>   crypto: arm64/crct10dif - add non-SIMD generic fallback
>   crypto: arm64/crc32 - add non-SIMD scalar fallback
>   crypto: arm64/sha1-ce - add non-SIMD generic fallback
>   crypto: arm64/sha2-ce - add non-SIMD scalar fallback
>   crypto: arm64/aes-ce-cipher - match round key endianness with generic
> code
>   crypto: arm64/aes-ce-cipher: add non-SIMD generic fallback
>   crypto: arm64/aes-ce-ccm: add non-SIMD generic fallback
>   crypto: arm64/aes-blk - add a non-SIMD fallback for synchronous CTR
>   crypto: arm64/chacha20 - take may_use_simd() into account
>   crypto: arm64/aes-bs - implement non-SIMD fallback for AES-CTR
>   crypto: arm64/gcm - implement native driver using v8 Crypto Extensions
>   crypto: arm/ghash - add NEON accelerated fallback for vmull.p64
>   crypto: arm64/ghash - add NEON accelerated fallback for 64-bit PMULL
>   crypto: arm/aes - avoid expanded lookup tables in the final round
>   crypto: arm64/aes - avoid expanded lookup tables in the final round

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

Re: [PATCH v2 4/4] MAINTAINERS: Add ARTPEC crypto maintainer

[Herbert Xu]

On Mon, Jul 24, 2017 at 09:07:32AM +0200, Lars Persson wrote:
> Assign the Axis kernel team as maintainer for crypto drivers under
> drivers/crypto/axis.
> 
> Signed-off-by: Lars Persson 

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

Re: [PATCH v6 3/3] hwrng: add a driver for Freescale RNGC

[Herbert Xu]

On Sun, Jul 23, 2017 at 07:49:06PM +0200, Martin Kaiser wrote:
> The driver is ported from Freescale's Linux git and can be
> found in the
> 
>   vendor/freescale/imx_2.6.35_maintain
> 
> branch.
> 
> The driver supports both RNG version C that's part of some Freescale
> i.MX3 SoCs and version B that is available on i.MX2x chipsets.
> 
> Signed-off-by: Steffen Trumtrar 
> Signed-off-by: Martin Kaiser 
> Reviewed-by: PrasannaKumar Muralidharan 

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

Re: [PATCH] crypto: Kconfig: Correct help text about feeding entropy pool

[Herbert Xu]

PrasannaKumar Muralidharan  wrote:
> Modify Kconfig help text to reflect the fact that random data from hwrng
> is fed into kernel random number generator's entropy pool.
> 
> Signed-off-by: PrasannaKumar Muralidharan 

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

Re: [PATCH v2 0/3] crypto: scompress - defer allocation of percpu scratch buffers

[Herbert Xu]

On Fri, Jul 21, 2017 at 04:42:35PM +0100, Ard Biesheuvel wrote:
> This is a followup to 'crypto: scompress - eliminate percpu scratch buffers',
> which attempted to replace the scompress per-CPU buffer entirely, but as
> Herbert pointed out, this is not going to fly in the targeted use cases.
> 
> Instead, move the alloc/free of the buffers into the tfm init/exit hooks,
> so that we only have the per-CPU buffers allocated if their are any
> acomp ciphers of the right kind (i.e, ones that encapsulate a synchronous
> implementation) in use (#3)
> 
> Patches #1 and #2 are fixes for issues I spotted when working on this code.
> 
> Ard Biesheuvel (3):
>   crypto: scompress - don't sleep with preemption disabled
>   crypto: scompress - free partially allocated scratch buffers on
> failure
>   crypto: scompress - defer allocation of scratch buffer to first use

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

Re: [PATCH v1] crypto: brcm - Support more FlexRM rings than SPU engines.

[Herbert Xu]

On Fri, Jul 21, 2017 at 11:17:39AM +0530, Raveendra Padasalagi wrote:
> Enhance code to generically support cases where DMA rings
> are greater than or equal to number of SPU engines.
> New hardware has underlying DMA engine-FlexRM with 32 rings
> which can be used to communicate to any of the available
> 10 SPU engines.
> 
> Fixes: 9d12ba86f818 ("crypto: brcm - Add Broadcom SPU driver")
> Signed-off-by: Raveendra Padasalagi 
> Reviewed-by: Scott Branden 
> Reviewed-by: Florian Fainelli 
> Cc: sta...@vger.kernel.org

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

Re: [PATCH] crypto: atmel-ecc: fix signed integer to u8 assignment

[Herbert Xu]

On Thu, Jul 20, 2017 at 04:35:49PM +0300, Tudor Ambarus wrote:
> static checker warning:
> drivers/crypto/atmel-ecc.c:281 atmel_ecdh_done()
> warn: assigning (-22) to unsigned variable 'status'
> 
> Similar warning can be raised in atmel_ecc_work_handler()
> when atmel_ecc_send_receive() returns an error. Fix this too.
> 
> Reported-by: Dan Carpenter 
> Signed-off-by: Tudor Ambarus 

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

Re: [PATCH] crypto: ccp: remove duplicate module version and author entry

[Herbert Xu]

On Wed, Jul 19, 2017 at 10:29:08PM -0500, Brijesh Singh wrote:
> commit 720419f01832 ("crypto: ccp - Introduce the AMD Secure Processor 
> device")
> moved the module registeration from ccp-dev.c to sp-dev.c but patch missed
> removing the module version and author entry from ccp-dev.c.
> 
> It causes the below warning during boot when CONFIG_CRYPTO_DEV_SP_CCP=y
> and CONFIG_CRYPTO_DEV_CCP_CRYPTO=y is set.
> 
> [ 0.187825] sysfs: cannot create duplicate filename '/module/ccp/version'
> [ 0.187825] sysfs: cannot create duplicate filename '/module/ccp/version'
> 
> Cc: Tom Lendacky 
> Cc: Gary R Hook 
> Cc: Herbert Xu 
> Cc: David S. Miller 
> Signed-off-by: Brijesh Singh 

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

Re: [PATCH] crypto: tcrypt - remove AES-XTS-192 speed tests

[Herbert Xu]

On Wed, Jul 19, 2017 at 07:40:32PM +0300, Horia Geantă wrote:
> Remove xts(aes) speed tests with 2 x 192-bit keys, since implementations
> adhering strictly to IEEE 1619-2007 standard cannot cope with key sizes
> other than 2 x 128, 2 x 256 bits - i.e. AES-XTS-{128,256}:
> [...]
> tcrypt: test 5 (384 bit key, 16 byte blocks):
> caam_jr 802.jr: key size mismatch
> tcrypt: setkey() failed flags=20
> [...]
> 
> Signed-off-by: Horia Geantă 

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

Re: [PATCH] crypto: ecdh: fix concurrency on shared secret and pubkey

[Herbert Xu]

On Thu, Jul 20, 2017 at 10:37:39AM +0300, Tudor Ambarus wrote:
> ecdh_ctx contained static allocated data for the shared secret
> and public key.
> 
> The shared secret and the public key were doomed to concurrency
> issues because they could be shared by multiple crypto requests.
> 
> The concurrency is fixed by replacing per-tfm shared secret and
> public key with per-request dynamically allocated shared secret
> and public key.
> 
> Signed-off-by: Tudor Ambarus 

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

Re: [PATCH] Crypto: atmel-ecc: Make a couple of local functions static

[Herbert Xu]

On Wed, Jul 19, 2017 at 10:24:15AM +0100, Colin King wrote:
> From: Colin Ian King 
> 
> Functions atmel_ecc_i2c_client_alloc and atmel_ecc_i2c_client_free are
> local to the source and no not need to be in the global scope. Make
> them static.
> 
> Cleans up sparse warnings:
> symbol 'atmel_ecc_i2c_client_alloc' was not declared. Should it be static?
> symbol 'atmel_ecc_i2c_client_free' was not declared. Should it be static?
> 
> Signed-off-by: Colin Ian King 

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

Re: [PATCH] crypto: atmel-tdes: remove unnecessary static in atmel_tdes_remove()

[Herbert Xu]

Gustavo A. R. Silva  wrote:
> Remove unnecessary static on local variable tdes_dd. Such variable
> is initialized before being used, on every execution path throughout
> the function. The static has no benefit and, removing it reduces the
> object file size.
> 
> This issue was detected using Coccinelle and the following semantic patch:
> https://github.com/GustavoARSilva/coccinelle/blob/master/static/static_unused.cocci
> 
> In the following log you can see a significant difference in the object
> file size. This log is the output of the size command, before and after
> the code change:
> 
> before:
>   textdata bss dec hex filename
>  170798704 128   259116537 drivers/crypto/atmel-tdes.o
> 
> after:
>   textdata bss dec hex filename
>  170398616  64   257196477 drivers/crypto/atmel-tdes.o
> 
> Signed-off-by: Gustavo A. R. Silva 

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

Re: [PATCH] crypto: atmel-sha: remove unnecessary static in atmel_sha_remove()

[Herbert Xu]

Gustavo A. R. Silva  wrote:
> Remove unnecessary static on local variable sha_dd. Such variable
> is initialized before being used, on every execution path throughout
> the function. The static has no benefit and, removing it reduces the
> object file size.
> 
> This issue was detected using Coccinelle and the following semantic patch:
> https://github.com/GustavoARSilva/coccinelle/blob/master/static/static_unused.cocci
> 
> In the following log you can see a significant difference in the object
> file size. This log is the output of the size command, before and after
> the code change:
> 
> before:
>   textdata bss dec hex filename
>  30005   10264 128   403979dcd drivers/crypto/atmel-sha.o
> 
> after:
>   textdata bss dec hex filename
>  29934   10208  64   402069d0e drivers/crypto/atmel-sha.o
> 
> Signed-off-by: Gustavo A. R. Silva 

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

Re: [PATCH] crypto: img-hash: remove unnecessary static in img_hash_remove()

[Herbert Xu]

Gustavo A. R. Silva  wrote:
> Remove unnecessary static on local variable hdev. Such variable
> is initialized before being used, on every execution path throughout
> the function. The static has no benefit and, removing it reduces the
> object file size.
> 
> This issue was detected using Coccinelle and the following semantic patch:
> https://github.com/GustavoARSilva/coccinelle/blob/master/static/static_unused.cocci
> 
> In the following log you can see a significant difference in the object
> file size. This log is the output of the size command, before and after
> the code change:
> 
> before:
>   textdata bss dec hex filename
>  148426464 128   2143453ba drivers/crypto/img-hash.o
> 
> after:
>   textdata bss dec hex filename
>  147896376  64   2122952ed drivers/crypto/img-hash.o
> 
> Signed-off-by: Gustavo A. R. Silva 

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

Re: [PATCH] crypto: omap-sham: remove unnecessary static in omap_sham_remove()

[Herbert Xu]

Gustavo A. R. Silva  wrote:
> Remove unnecessary static on local variable dd. Such variable
> is initialized before being used, on every execution path throughout
> the function. The static has no benefit and, removing it reduces the
> object file size.
> 
> This issue was detected using Coccinelle and the following semantic patch:
> https://github.com/GustavoARSilva/coccinelle/blob/master/static/static_unused.cocci
> 
> In the following log you can see a difference in the object file size.
> This log is the output of the size command, before and after the code
> change:
> 
> before:
>   textdata bss dec hex filename
>  26135   11944 128   38207953f drivers/crypto/omap-sham.o
> 
> after:
>   textdata bss dec hex filename
>  26084   11856  64   380049474 drivers/crypto/omap-sham.o
> 
> Signed-off-by: Gustavo A. R. Silva 

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

Re: [PATCH] crypto: n2_core: Convert to using %pOF instead of full_name

[Herbert Xu]

On Tue, Jul 18, 2017 at 04:42:56PM -0500, Rob Herring wrote:
> Now that we have a custom printf format specifier, convert users of
> full_name to use %pOF instead. This is preparation to remove storing
> of the full path string for each node.
> 
> Signed-off-by: Rob Herring 
> Cc: Herbert Xu 
> Cc: "David S. Miller" 
> Cc: linux-crypto@vger.kernel.org

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

Re: [PATCH v2 2/2] crypto: inside-secure - fix the sha state length in hmac_sha1_setkey

[Herbert Xu]

On Wed, Jul 19, 2017 at 11:02:31AM +0200, Antoine Tenart wrote:
> A check is performed on the ipad/opad in the safexcel_hmac_sha1_setkey
> function, but the index used by the loop doing it is wrong. It is
> currently the size of the state array while it should be the size of a
> sha1 state. This patch fixes it.
> 
> Fixes: 1b44c5a60c13 ("crypto: inside-secure - add SafeXcel EIP197 crypto 
> engine driver")
> Reported-by: Dan Carpenter 
> Signed-off-by: Antoine Tenart 

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

Re: [PATCH v2 1/2] crypto: inside-secure - fix invalidation check in hmac_sha1_setkey

[Herbert Xu]

On Wed, Jul 19, 2017 at 11:02:30AM +0200, Antoine Tenart wrote:
> The safexcel_hmac_sha1_setkey function checks if an invalidation command
> should be issued, i.e. when the context ipad/opad change. This checks is
> done after filling the ipad/opad which and it can't be true. The patch
> fixes this by moving the check before the ipad/opad memcpy operations.
> 
> Fixes: 1b44c5a60c13 ("crypto: inside-secure - add SafeXcel EIP197 crypto 
> engine driver")
> Signed-off-by: Antoine Tenart 

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

Re: [PATCH 1/4] crypto: caam/jr - add support for DPAA2 parts

[Herbert Xu]

On Tue, Jul 18, 2017 at 06:30:47PM +0300, Horia Geantă wrote:
> Add support for using the caam/jr backend on DPAA2-based SoCs.
> These have some particularities we have to account for:
> -HW S/G format is different
> -Management Complex (MC) firmware initializes / manages (partially)
> the CAAM block: MCFGR, QI enablement in QICTL, RNG
> 
> Signed-off-by: Horia Geantă 

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