[PATCH 5/5] KEYS: DH: add __user annotations to keyctl_kdf_params

[Eric Biggers]

From: Eric Biggers 

Signed-off-by: Eric Biggers 
---
 include/uapi/linux/keyctl.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/uapi/linux/keyctl.h b/include/uapi/linux/keyctl.h
index 201c6644b237..ef16df06642a 100644
--- a/include/uapi/linux/keyctl.h
+++ b/include/uapi/linux/keyctl.h
@@ -70,8 +70,8 @@ struct keyctl_dh_params {
 };
 
 struct keyctl_kdf_params {
-   char *hashname;
-   char *otherinfo;
+   char __user *hashname;
+   char __user *otherinfo;
__u32 otherinfolen;
__u32 __spare[8];
 };
-- 
2.12.2

[PATCH 2/5] KEYS: DH: don't feed uninitialized "otherinfo" into KDF

[Eric Biggers]

From: Eric Biggers 

If userspace called KEYCTL_DH_COMPUTE with kdf_params containing NULL
otherinfo but nonzero otherinfolen, the kernel would allocate a buffer
for the otherinfo, then feed it into the KDF without initializing it.
Fix this by always doing the copy from userspace (which will fail with
EFAULT in this scenario).

Signed-off-by: Eric Biggers 
---
 security/keys/dh.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/security/keys/dh.c b/security/keys/dh.c
index 8abc70ebe22d..1c1cac677041 100644
--- a/security/keys/dh.c
+++ b/security/keys/dh.c
@@ -317,7 +317,7 @@ long __keyctl_dh_compute(struct keyctl_dh_params __user 
*params,
 * Concatenate SP800-56A otherinfo past DH shared secret -- the
 * input to the KDF is (DH shared secret || otherinfo)
 */
-   if (kdfcopy && kdfcopy->otherinfo &&
+   if (kdfcopy &&
copy_from_user(kbuf + resultlen, kdfcopy->otherinfo,
   kdfcopy->otherinfolen) != 0) {
ret = -EFAULT;
-- 
2.12.2

[PATCH 1/5] KEYS: DH: forbid using digest_null as the KDF hash

[Eric Biggers]

From: Eric Biggers 

Requesting "digest_null" in the keyctl_kdf_params caused an infinite
loop in kdf_ctr() because the "null" hash has a digest size of 0.  Fix
it by rejecting hash algorithms with a digest size of 0.

Signed-off-by: Eric Biggers 
---
 security/keys/dh.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/security/keys/dh.c b/security/keys/dh.c
index e603bd912e4c..8abc70ebe22d 100644
--- a/security/keys/dh.c
+++ b/security/keys/dh.c
@@ -89,6 +89,7 @@ static int kdf_alloc(struct kdf_sdesc **sdesc_ret, char 
*hashname)
struct crypto_shash *tfm;
struct kdf_sdesc *sdesc;
int size;
+   int err;
 
/* allocate synchronous hash */
tfm = crypto_alloc_shash(hashname, 0, 0);
@@ -97,16 +98,25 @@ static int kdf_alloc(struct kdf_sdesc **sdesc_ret, char 
*hashname)
return PTR_ERR(tfm);
}
 
+   err = -EINVAL;
+   if (crypto_shash_digestsize(tfm) == 0)
+   goto out_free_tfm;
+
+   err = -ENOMEM;
size = sizeof(struct shash_desc) + crypto_shash_descsize(tfm);
sdesc = kmalloc(size, GFP_KERNEL);
if (!sdesc)
-   return -ENOMEM;
+   goto out_free_tfm;
sdesc->shash.tfm = tfm;
sdesc->shash.flags = 0x0;
 
*sdesc_ret = sdesc;
 
return 0;
+
+out_free_tfm:
+   crypto_free_shash(tfm);
+   return err;
 }
 
 static void kdf_dealloc(struct kdf_sdesc *sdesc)
-- 
2.12.2

[PATCH 4/5] KEYS: DH: ensure the KDF counter is properly aligned

[Eric Biggers]

From: Eric Biggers 

Accessing a 'u8[4]' through a '__be32 *' violates alignment rules.  Just
make the counter a __be32 instead.

Signed-off-by: Eric Biggers 
---
 security/keys/dh.c | 16 +++-
 1 file changed, 3 insertions(+), 13 deletions(-)

diff --git a/security/keys/dh.c b/security/keys/dh.c
index a3a8607107f5..e6b757c33289 100644
--- a/security/keys/dh.c
+++ b/security/keys/dh.c
@@ -130,14 +130,6 @@ static void kdf_dealloc(struct kdf_sdesc *sdesc)
kzfree(sdesc);
 }
 
-/* convert 32 bit integer into its string representation */
-static inline void crypto_kw_cpu_to_be32(u32 val, u8 *buf)
-{
-   __be32 *a = (__be32 *)buf;
-
-   *a = cpu_to_be32(val);
-}
-
 /*
  * Implementation of the KDF in counter mode according to SP800-108 section 5.1
  * as well as SP800-56A section 5.8.1 (Single-step KDF).
@@ -154,16 +146,14 @@ static int kdf_ctr(struct kdf_sdesc *sdesc, const u8 
*src, unsigned int slen,
unsigned int h = crypto_shash_digestsize(desc->tfm);
int err = 0;
u8 *dst_orig = dst;
-   u32 i = 1;
-   u8 iteration[sizeof(u32)];
+   __be32 counter = cpu_to_be32(1);
 
while (dlen) {
err = crypto_shash_init(desc);
if (err)
goto err;
 
-   crypto_kw_cpu_to_be32(i, iteration);
-   err = crypto_shash_update(desc, iteration, sizeof(u32));
+   err = crypto_shash_update(desc, (u8 *), sizeof(__be32));
if (err)
goto err;
 
@@ -189,7 +179,7 @@ static int kdf_ctr(struct kdf_sdesc *sdesc, const u8 *src, 
unsigned int slen,
 
dlen -= h;
dst += h;
-   i++;
+   counter = cpu_to_be32(be32_to_cpu(counter) + 1);
}
}
 
-- 
2.12.2

[PATCH 0/5] KEYS: fixes for new keyctl_dh_compute() KDF extension

[Eric Biggers]

This patch series fixes several bugs in the KDF extension to
keyctl_dh_compute() currently sitting in keys-next: a way userspace could
cause an infinite loop, two ways userspace could cause the use of
uninitialized memory, a misalignment, and missing __user annotations.

Eric Biggers (5):
  KEYS: DH: forbid using digest_null as the KDF hash
  KEYS: DH: don't feed uninitialized "otherinfo" into KDF
  KEYS: DH: don't feed uninitialized result memory into KDF
  KEYS: DH: ensure the KDF counter is properly aligned
  KEYS: DH: add __user annotations to keyctl_kdf_params

 include/uapi/linux/keyctl.h |  4 ++--
 security/keys/dh.c  | 50 ++---
 2 files changed, 26 insertions(+), 28 deletions(-)

-- 
2.12.2

[PATCH 3/5] KEYS: DH: don't feed uninitialized result memory into KDF

[Eric Biggers]

From: Eric Biggers 

The result of the Diffie-Hellman computation may be shorter than the
input prime number.  Only calculate the KDF over the actual result;
don't include additional uninitialized memory.

Signed-off-by: Eric Biggers 
---
 security/keys/dh.c | 22 ++
 1 file changed, 10 insertions(+), 12 deletions(-)

diff --git a/security/keys/dh.c b/security/keys/dh.c
index 1c1cac677041..a3a8607107f5 100644
--- a/security/keys/dh.c
+++ b/security/keys/dh.c
@@ -313,17 +313,6 @@ long __keyctl_dh_compute(struct keyctl_dh_params __user 
*params,
goto error4;
}
 
-   /*
-* Concatenate SP800-56A otherinfo past DH shared secret -- the
-* input to the KDF is (DH shared secret || otherinfo)
-*/
-   if (kdfcopy &&
-   copy_from_user(kbuf + resultlen, kdfcopy->otherinfo,
-  kdfcopy->otherinfolen) != 0) {
-   ret = -EFAULT;
-   goto error5;
-   }
-
ret = do_dh(result, base, private, prime);
if (ret)
goto error5;
@@ -333,8 +322,17 @@ long __keyctl_dh_compute(struct keyctl_dh_params __user 
*params,
goto error5;
 
if (kdfcopy) {
+   /*
+* Concatenate SP800-56A otherinfo past DH shared secret -- the
+* input to the KDF is (DH shared secret || otherinfo)
+*/
+   if (copy_from_user(kbuf + nbytes, kdfcopy->otherinfo,
+  kdfcopy->otherinfolen) != 0) {
+   ret = -EFAULT;
+   goto error5;
+   }
ret = keyctl_dh_compute_kdf(sdesc, buffer, buflen, kbuf,
-   resultlen + kdfcopy->otherinfolen);
+   nbytes + kdfcopy->otherinfolen);
} else {
ret = nbytes;
if (copy_to_user(buffer, kbuf, nbytes) != 0)
-- 
2.12.2

[PATCH v2] powerpc/crypto/crct10dif-vpmsum: Fix missing preempt_disable()

[Michael Ellerman]

In crct10dif_vpmsum() we call enable_kernel_altivec() without first
disabling preemption, which is not allowed.

It used to be sufficient just to call pagefault_disable(), because that
also disabled preemption. But the two were decoupled in commit 8222dbe21e79
("sched/preempt, mm/fault: Decouple preemption from the page fault
logic") in mid 2015.

The crct10dif-vpmsum code inherited this bug from the crc32c-vpmsum code
on which it was modelled.

So add the missing preempt_disable/enable(). We should also call
disable_kernel_fp(), although it does nothing by default, there is a
debug switch to make it active and all enables should be paired with
disables.

Fixes: b01df1c16c9a ("crypto: powerpc - Add CRC-T10DIF acceleration")
Acked-by: Daniel Axtens 
Signed-off-by: Michael Ellerman 
---
 arch/powerpc/crypto/crct10dif-vpmsum_glue.c | 3 +++
 1 file changed, 3 insertions(+)

v2: No change to the patch. Add dja's ack. Add linux-crypto to Cc.

diff --git a/arch/powerpc/crypto/crct10dif-vpmsum_glue.c 
b/arch/powerpc/crypto/crct10dif-vpmsum_glue.c
index bebfc329f746..02ea277863d1 100644
--- a/arch/powerpc/crypto/crct10dif-vpmsum_glue.c
+++ b/arch/powerpc/crypto/crct10dif-vpmsum_glue.c
@@ -44,10 +44,13 @@ static u16 crct10dif_vpmsum(u16 crci, unsigned char const 
*p, size_t len)
 
if (len & ~VMX_ALIGN_MASK) {
crc <<= 16;
+   preempt_disable();
pagefault_disable();
enable_kernel_altivec();
crc = __crct10dif_vpmsum(crc, p, len & ~VMX_ALIGN_MASK);
+   disable_kernel_altivec();
pagefault_enable();
+   preempt_enable();
crc >>= 16;
}
 
-- 
2.7.4

Re: [PATCH 6/6] ima: Support appended signatures for appraisal

[kbuild test robot]

Hi Thiago,

[auto build test ERROR on security/next]
[also build test ERROR on v4.11-rc7 next-20170419]
[cannot apply to integrity/next]
[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/Thiago-Jung-Bauermann/Appended-signatures-support-for-IMA-appraisal/20170419-053422
base:   
https://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git next
config: i386-randconfig-h0-04201028 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   In file included from security/integrity/ima/ima_appraise.c:19:0:
   include/keys/asymmetric-type.h: In function 'asymmetric_key_ids':
>> include/keys/asymmetric-type.h:76:12: error: dereferencing pointer to 
>> incomplete type 'const struct key'
 return key->payload.data[asym_key_ids];
   ^~

vim +76 include/keys/asymmetric-type.h

7901c1a8 David Howells 2014-09-16  70   
size_t len_1,
7901c1a8 David Howells 2014-09-16  71   
const void *val_2,
7901c1a8 David Howells 2014-09-16  72   
size_t len_2);
146aa8b1 David Howells 2015-10-21  73  static inline
146aa8b1 David Howells 2015-10-21  74  const struct asymmetric_key_ids 
*asymmetric_key_ids(const struct key *key)
146aa8b1 David Howells 2015-10-21  75  {
146aa8b1 David Howells 2015-10-21 @76   return key->payload.data[asym_key_ids];
146aa8b1 David Howells 2015-10-21  77  }
7901c1a8 David Howells 2014-09-16  78  
9eb02989 David Howells 2016-04-06  79  extern struct key 
*find_asymmetric_key(struct key *keyring,

:: The code at line 76 was first introduced by commit
:: 146aa8b1453bd8f1ff2304ffb71b4ee0eb9acdcc KEYS: Merge the type-specific 
data with the payload data

:: TO: David Howells <dhowe...@redhat.com>
:: CC: David Howells <dhowe...@redhat.com>

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH 1/2] dt-bindings: hwrng: Add Mediatek hardware random generator bindings

[Rob Herring]

On Thu, Apr 13, 2017 at 03:05:07PM +0800, sean.w...@mediatek.com wrote:
> From: Sean Wang 
> 
> Document the devicetree bindings for Mediatek random number
> generator which could be found on MT7623 SoC or other similar
> Mediatek SoCs.
> 
> Signed-off-by: Sean Wang 
> ---
>  Documentation/devicetree/bindings/rng/mtk-rng.txt | 18 ++
>  1 file changed, 18 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/rng/mtk-rng.txt

Acked-by: Rob Herring 

Re: export pcie_flr and remove copies of it in drivers V2

[Leon Romanovsky]

On Wed, Apr 19, 2017 at 08:37:37AM +0300, Leon Romanovsky wrote:
> On Tue, Apr 18, 2017 at 01:36:12PM -0500, Bjorn Helgaas wrote:
> > On Fri, Apr 14, 2017 at 09:11:24PM +0200, Christoph Hellwig wrote:
> > > Hi all,
> > >
> > > this exports the PCI layer pcie_flr helper, and removes various opencoded
> > > copies of it.
> > >
> > > Changes since V1:
> > >  - rebase on top of the pci/virtualization branch
> > >  - fixed the probe case in __pci_dev_reset
> > >  - added ACKs from Bjorn
> >
> > Applied the first three patches:
> >
> >   bc13871ef35a PCI: Export pcie_flr()
> >   e641c375d414 PCI: Call pcie_flr() from reset_intel_82599_sfp_virtfn()
> >   40e0901ea4bf PCI: Call pcie_flr() from reset_chelsio_generic_dev()
> >
>
> Bjorn,
>
> How do you suggest to proceed with other patches? They should be applied
> to your tree either, because they depend on "bc13871ef35a PCI: Export
> pcie_flr()".

I finally caught the old emails and found the answer by myself.
http://marc.info/?l=linux-rdma=149218545228343=2

Thanks

>
> Thanks
>
>
> > to pci/virtualization for v4.12, thanks!




signature.asc
Description: PGP signature

Re: [PATCH 2/2] n2rng: Combine substrings for two messages in n2rng_probe()

[Shannon Nelson]

On 4/19/2017 2:11 AM, SF Markus Elfring wrote:

From: Markus Elfring 
Date: Wed, 19 Apr 2017 10:50:04 +0200

The script "checkpatch.pl" pointed information out like the following.

WARNING: quoted string split across lines

Thus fix the affected source code places.

Signed-off-by: Markus Elfring 


Thanks Markus.

Acked-by: Shannon Nelson 



---
 drivers/char/hw_random/n2-drv.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/char/hw_random/n2-drv.c b/drivers/char/hw_random/n2-drv.c
index 92dd4e925315..f3e67c768101 100644
--- a/drivers/char/hw_random/n2-drv.c
+++ b/drivers/char/hw_random/n2-drv.c
@@ -723,16 +723,16 @@ static int n2rng_probe(struct platform_device *op)
if (sun4v_hvapi_register(HV_GRP_RNG,
 np->hvapi_major,
 >hvapi_minor)) {
-   dev_err(>dev, "Cannot register suitable "
-   "HVAPI version.\n");
+   dev_err(>dev,
+   "Cannot register suitable HVAPI version.\n");
goto out;
}
}

if (np->flags & N2RNG_FLAG_MULTI) {
if (np->hvapi_major < 2) {
-   dev_err(>dev, "multi-unit-capable RNG requires "
-   "HVAPI major version 2 or later, got %lu\n",
+   dev_err(>dev,
+   "multi-unit-capable RNG requires HVAPI major version 
2 or later, got %lu\n",
np->hvapi_major);
goto out_hvapi_unregister;
}

Re: [PATCH 1/2] n2rng: Use devm_kcalloc() in n2rng_probe()

[Shannon Nelson]

On 4/19/2017 2:10 AM, SF Markus Elfring wrote:

From: Markus Elfring 
Date: Wed, 19 Apr 2017 10:30:47 +0200

* A multiplication for the size determination of a memory allocation
  indicated that an array data structure should be processed.
  Thus use the corresponding function "devm_kcalloc".

* Replace the specification of a data structure by a pointer dereference
  to make the corresponding size determination a bit safer according to
  the Linux coding style convention.

Signed-off-by: Markus Elfring 


Thanks Markus.

Acked-by: Shannon Nelson 


---
 drivers/char/hw_random/n2-drv.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/char/hw_random/n2-drv.c b/drivers/char/hw_random/n2-drv.c
index 31cbdbbaebfc..92dd4e925315 100644
--- a/drivers/char/hw_random/n2-drv.c
+++ b/drivers/char/hw_random/n2-drv.c
@@ -748,9 +748,7 @@ static int n2rng_probe(struct platform_device *op)

dev_info(>dev, "Registered RNG HVAPI major %lu minor %lu\n",
 np->hvapi_major, np->hvapi_minor);
-
-   np->units = devm_kzalloc(>dev,
-sizeof(struct n2rng_unit) * np->num_units,
+   np->units = devm_kcalloc(>dev, np->num_units, sizeof(*np->units),
 GFP_KERNEL);
err = -ENOMEM;
if (!np->units)

RE: [PATCH 4/8] crypto: KPP - add API crypto_kpp_set_params

[Benedetto, Salvatore]

Hi Stephan,

> -Original Message-
> From: keyrings-ow...@vger.kernel.org [mailto:keyrings-
> ow...@vger.kernel.org] On Behalf Of Stephan Müller
> Sent: Wednesday, April 19, 2017 12:06 AM
> To: linux-crypto@vger.kernel.org
> Cc: keyri...@vger.kernel.org
> Subject: [PATCH 4/8] crypto: KPP - add API crypto_kpp_set_params
> 
> KPP mechanisms like DH require a parameter set to be provided by the caller.
> That parameter set may be provided by the crypto_kpp_set_secret function.
> Yet, the parameters hare handled independently from the secret key which
> implies that they should be able to be set independently from the key.
> 
> The new API allows KPP mechanisms to register a callback allowing to set
> such parameters.
> 
> Signed-off-by: Stephan Mueller 
> ---
>  Documentation/crypto/api-kpp.rst |  2 +-
>  include/crypto/kpp.h | 28 
>  2 files changed, 29 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/crypto/api-kpp.rst b/Documentation/crypto/api-
> kpp.rst
> index 7d86ab9..7b2c0d4 100644
> --- a/Documentation/crypto/api-kpp.rst
> +++ b/Documentation/crypto/api-kpp.rst
> @@ -11,7 +11,7 @@ Key-agreement Protocol Primitives (KPP) Cipher API
> :doc: Generic Key-agreement Protocol Primitives API
> 
>  .. kernel-doc:: include/crypto/kpp.h
> -   :functions: crypto_alloc_kpp crypto_free_kpp crypto_kpp_set_secret
> crypto_kpp_generate_public_key crypto_kpp_compute_shared_secret
> crypto_kpp_maxsize
> +   :functions: crypto_alloc_kpp crypto_free_kpp crypto_kpp_set_params
> + crypto_kpp_set_secret crypto_kpp_generate_public_key
> + crypto_kpp_compute_shared_secret crypto_kpp_maxsize
> 
>  Key-agreement Protocol Primitives (KPP) Cipher Request Handle
>  -
> diff --git a/include/crypto/kpp.h b/include/crypto/kpp.h index
> ce8e1f7..5931364 100644
> --- a/include/crypto/kpp.h
> +++ b/include/crypto/kpp.h
> @@ -51,6 +51,9 @@ struct crypto_kpp {
>  /**
>   * struct kpp_alg - generic key-agreement protocol primitives
>   *
> + * @set_params:  Function allows the caller to set the parameters
> + *   separately from the key. The format of the
> parameters
> + *   is protocol specific.
>   * @set_secret:  Function invokes the protocol specific
> function to
>   *   store the secret private key along with parameters.
>   *   The implementation knows how to decode thie
> buffer
> @@ -74,6 +77,8 @@ struct crypto_kpp {
>   * @base:Common crypto API algorithm data structure
>   */
>  struct kpp_alg {
> + int (*set_params)(struct crypto_kpp *tfm, const void *buffer,
> +   unsigned int len);
>   int (*set_secret)(struct crypto_kpp *tfm, const void *buffer,
> unsigned int len);
>   int (*generate_public_key)(struct kpp_request *req); @@ -259,6
> +264,29 @@ struct kpp_secret {  };
> 
>  /**
> + * crypto_kpp_set_params() - Set parameters needed for kpp operation
> + *
> + * Function invokes the specific kpp operation for a given alg.
> + *
> + * @tfm: tfm handle
> + * @buffer:  Buffer holding the protocol specific representation of the
> + *   parameters (e.g. PKCS#3 DER for DH)
> + * @len: Length of the parameter buffer.
> + *
> + * Return: zero on success; error code in case of error  */ static
> +inline int crypto_kpp_set_params(struct crypto_kpp *tfm,
> + const void *buffer, unsigned int len) {
> + struct kpp_alg *alg = crypto_kpp_alg(tfm);
> +
> + if (alg->set_params)
> + return alg->set_params(tfm, buffer, len);
> + else
> + return -EOPNOTSUPP;
> +}
> +
> +/**
>   * crypto_kpp_set_secret() - Invoke kpp operation
>   *
>   * Function invokes the specific kpp operation for a given alg.
> --
> 2.9.3

I'm not really in favor of having two ways for setting the params.
As you are probably aware, PKCS3 and set_params was my intial
approach, but then Herbert suggested a lighter approach like rtnetlink
which I actually prefer.

Can't you expose that through AF_ALG?

Regards,
Salvatore

Re: [PATCH 0/4] staging: add ccree crypto driver

[Gilad Ben-Yossef]

On Tue, Apr 18, 2017 at 6:43 PM, Mark Rutland  wrote:
...
>> >>
>> >> The code still needs some cleanup before maturing to a proper
>> >> upstream driver, which I am in the process of doing. However,
>> >> as discussion of some of the capabilities of the hardware and
>> >> its application to some dm-crypt and dm-verity features recently
>> >> took place I though it is better to do this in the open via the
>> >> staging tree.
>> >>
>> >> A Git repository based off of Linux 4.11-rc7 is available at
>> >> https://github.com/gby/linux.git branch ccree.
>> >>
...
>> >>  .../devicetree/bindings/crypto/arm-cryptocell.txt  |   23 +
>> >
>> > I'm interested in looking at the DT binding, but for some reason I've
>> > only recevied the cover letter so far.
>> >
>> > Are my mail servers being particularly slow today, or has something gone
>> > wrong with the Cc list for the remaining patches?
>> >
>>
>> Thanks a bunch for the willingness to review this.
>>
>> My apologies for not communicating this clearly enough -  Since it is
>> an pre-existing driver it is rather big.
>> I did not want to inflict a 600K patch on the mailing list so opted to
>> provide a git repo instead, as stated in the
>> email.
>
> Should this have been a [GIT PULL], then?
>
> I was confused by the [PATCH 0/4].

Yes, it should have. Sorry about that.
>
>> The patch in question is here:
>> https://github.com/gby/linux/commit/12d92e0bc19aa9bbd891cdab765eaaeabe0b6967
>>
>> Do let me know if you prefer that I will send at least the smaller
>> patch file via email in the normal fashion.
>
> Sending patches is the usual way to have things reviewed. Linking to an
> external site doesn't fit with the workflows of everyone.
>
> If you wish to have patches reviewed, please send them as patches in the
> usual fashion.

Thanks for the feedback.
I will break the driver up and post patches in the normal fashion.

>
> I will note that on the patch you linked, the compatible string is far
> too vague, per common conventions. Per your description above, that
> should be something like "arm,cryptocell-712-ree" (and each variant
> should have its own string).

Got it. Will change.

Thanks for the review even in this unconventional form :-) !

>
> I don't have documentation to hand to attempt to review the rest.
>
> I would appreciate if you could ensure that the DT binding was reviewed
> as part of the staging TODOs. That needs to follow the usual DT review
> process of sending patches to the list. Until that has occurred, it
> shouldn't be in Documentation/devicetree/.

Of course, will do.

Thanks,
Gilad
>
> Thanks,
> Mark.



-- 
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 0/4] staging: add ccree crypto driver

[Gilad Ben-Yossef]

On Tue, Apr 18, 2017 at 6:39 PM, Greg Kroah-Hartman
 wrote:
> On Tue, Apr 18, 2017 at 05:07:50PM +0300, Gilad Ben-Yossef wrote:
>> Arm TrustZone CryptoCell 700 is a family of cryptographic hardware
>> accelerators. It is supported by a long lived series of out of tree
>> drivers, which I am now in the process of unifying and upstreaming.
>> This is the first drop, supporting the new CryptoCell 712 REE.
>>
>> The code still needs some cleanup before maturing to a proper
>> upstream driver, which I am in the process of doing. However,
>> as discussion of some of the capabilities of the hardware and
>> its application to some dm-crypt and dm-verity features recently
>> took place I though it is better to do this in the open via the
>> staging tree.
>>
>> A Git repository based off of Linux 4.11-rc7 is available at
>> https://github.com/gby/linux.git branch ccree.
>>
>> Signed-off-by: Gilad Ben-Yossef 
>> CC: Binoy Jayan 
>> CC: Ofir Drang 
>>
>> Gilad Ben-Yossef (4):
>>   staging: add ccree crypto driver
>>   staging: ccree: add TODO list
>>   staging: ccree: add devicetree bindings
>>   MAINTAINERS: add Gilad BY as maintainer for ccree
>
> We can't do much without a real patch, sorry.  Digging in random git
> trees doesn't work :(
>
> I can't take this as-is, I need patches.

Got it.

I'll break the driver to a series of patches and post them .
Thanks for the feedback.

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

[PATCH 1/2] crypto: scomp - allow registration of multiple scomps

[Giovanni Cabiddu]

Add crypto_register_scomps and crypto_unregister_scomps to allow
the registration of multiple implementations with one call.

Signed-off-by: Giovanni Cabiddu 
---
 crypto/scompress.c  | 29 +
 include/crypto/internal/scompress.h |  3 +++
 2 files changed, 32 insertions(+)

diff --git a/crypto/scompress.c b/crypto/scompress.c
index 6b048b3..ae1d3cf 100644
--- a/crypto/scompress.c
+++ b/crypto/scompress.c
@@ -353,5 +353,34 @@ int crypto_unregister_scomp(struct scomp_alg *alg)
 }
 EXPORT_SYMBOL_GPL(crypto_unregister_scomp);
 
+int crypto_register_scomps(struct scomp_alg *algs, int count)
+{
+   int i, ret;
+
+   for (i = 0; i < count; i++) {
+   ret = crypto_register_scomp([i]);
+   if (ret)
+   goto err;
+   }
+
+   return 0;
+
+err:
+   for (--i; i >= 0; --i)
+   crypto_unregister_scomp([i]);
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(crypto_register_scomps);
+
+void crypto_unregister_scomps(struct scomp_alg *algs, int count)
+{
+   int i;
+
+   for (i = count - 1; i >= 0; --i)
+   crypto_unregister_scomp([i]);
+}
+EXPORT_SYMBOL_GPL(crypto_unregister_scomps);
+
 MODULE_LICENSE("GPL");
 MODULE_DESCRIPTION("Synchronous compression type");
diff --git a/include/crypto/internal/scompress.h 
b/include/crypto/internal/scompress.h
index 3fda3c5..ccad9b2 100644
--- a/include/crypto/internal/scompress.h
+++ b/include/crypto/internal/scompress.h
@@ -133,4 +133,7 @@ int crypto_register_scomp(struct scomp_alg *alg);
  */
 int crypto_unregister_scomp(struct scomp_alg *alg);
 
+int crypto_register_scomps(struct scomp_alg *algs, int count);
+void crypto_unregister_scomps(struct scomp_alg *algs, int count);
+
 #endif
-- 
2.9.3

[PATCH 2/2] crypto: acomp - add support for deflate rfc1950 (zlib)

[Giovanni Cabiddu]

Add scomp backend for zlib-deflate compression algorithm.
This backend outputs data using the format defined in rfc1950
(raw deflate surrounded by zlib header and footer).

Signed-off-by: Giovanni Cabiddu 
---
 crypto/deflate.c | 61 -
 crypto/testmgr.c | 10 
 crypto/testmgr.h | 75 
 3 files changed, 129 insertions(+), 17 deletions(-)

diff --git a/crypto/deflate.c b/crypto/deflate.c
index f942cb3..647f2e5 100644
--- a/crypto/deflate.c
+++ b/crypto/deflate.c
@@ -43,20 +43,24 @@ struct deflate_ctx {
struct z_stream_s decomp_stream;
 };
 
-static int deflate_comp_init(struct deflate_ctx *ctx)
+static int deflate_comp_init(struct deflate_ctx *ctx, int format)
 {
int ret = 0;
struct z_stream_s *stream = >comp_stream;
 
stream->workspace = vzalloc(zlib_deflate_workspacesize(
-   -DEFLATE_DEF_WINBITS, DEFLATE_DEF_MEMLEVEL));
+   MAX_WBITS, MAX_MEM_LEVEL));
if (!stream->workspace) {
ret = -ENOMEM;
goto out;
}
-   ret = zlib_deflateInit2(stream, DEFLATE_DEF_LEVEL, Z_DEFLATED,
-   -DEFLATE_DEF_WINBITS, DEFLATE_DEF_MEMLEVEL,
-   Z_DEFAULT_STRATEGY);
+   if (format)
+   ret = zlib_deflateInit(stream, 3);
+   else
+   ret = zlib_deflateInit2(stream, DEFLATE_DEF_LEVEL, Z_DEFLATED,
+   -DEFLATE_DEF_WINBITS,
+   DEFLATE_DEF_MEMLEVEL,
+   Z_DEFAULT_STRATEGY);
if (ret != Z_OK) {
ret = -EINVAL;
goto out_free;
@@ -68,7 +72,7 @@ static int deflate_comp_init(struct deflate_ctx *ctx)
goto out;
 }
 
-static int deflate_decomp_init(struct deflate_ctx *ctx)
+static int deflate_decomp_init(struct deflate_ctx *ctx, int format)
 {
int ret = 0;
struct z_stream_s *stream = >decomp_stream;
@@ -78,7 +82,10 @@ static int deflate_decomp_init(struct deflate_ctx *ctx)
ret = -ENOMEM;
goto out;
}
-   ret = zlib_inflateInit2(stream, -DEFLATE_DEF_WINBITS);
+   if (format)
+   ret = zlib_inflateInit(stream);
+   else
+   ret = zlib_inflateInit2(stream, -DEFLATE_DEF_WINBITS);
if (ret != Z_OK) {
ret = -EINVAL;
goto out_free;
@@ -102,21 +109,21 @@ static void deflate_decomp_exit(struct deflate_ctx *ctx)
vfree(ctx->decomp_stream.workspace);
 }
 
-static int __deflate_init(void *ctx)
+static int __deflate_init(void *ctx, int format)
 {
int ret;
 
-   ret = deflate_comp_init(ctx);
+   ret = deflate_comp_init(ctx, format);
if (ret)
goto out;
-   ret = deflate_decomp_init(ctx);
+   ret = deflate_decomp_init(ctx, format);
if (ret)
deflate_comp_exit(ctx);
 out:
return ret;
 }
 
-static void *deflate_alloc_ctx(struct crypto_scomp *tfm)
+static void *gen_deflate_alloc_ctx(struct crypto_scomp *tfm, int format)
 {
struct deflate_ctx *ctx;
int ret;
@@ -125,7 +132,7 @@ static void *deflate_alloc_ctx(struct crypto_scomp *tfm)
if (!ctx)
return ERR_PTR(-ENOMEM);
 
-   ret = __deflate_init(ctx);
+   ret = __deflate_init(ctx, format);
if (ret) {
kfree(ctx);
return ERR_PTR(ret);
@@ -134,11 +141,21 @@ static void *deflate_alloc_ctx(struct crypto_scomp *tfm)
return ctx;
 }
 
+static void *deflate_alloc_ctx(struct crypto_scomp *tfm)
+{
+   return gen_deflate_alloc_ctx(tfm, 0);
+}
+
+static void *zlib_deflate_alloc_ctx(struct crypto_scomp *tfm)
+{
+   return gen_deflate_alloc_ctx(tfm, 1);
+}
+
 static int deflate_init(struct crypto_tfm *tfm)
 {
struct deflate_ctx *ctx = crypto_tfm_ctx(tfm);
 
-   return __deflate_init(ctx);
+   return __deflate_init(ctx, 0);
 }
 
 static void __deflate_exit(void *ctx)
@@ -272,7 +289,7 @@ static struct crypto_alg alg = {
.coa_decompress = deflate_decompress } }
 };
 
-static struct scomp_alg scomp = {
+static struct scomp_alg scomp[] = { {
.alloc_ctx  = deflate_alloc_ctx,
.free_ctx   = deflate_free_ctx,
.compress   = deflate_scompress,
@@ -282,7 +299,17 @@ static struct scomp_alg scomp = {
.cra_driver_name = "deflate-scomp",
.cra_module  = THIS_MODULE,
}
-};
+}, {
+   .alloc_ctx  = zlib_deflate_alloc_ctx,
+   .free_ctx   = deflate_free_ctx,
+   .compress   = deflate_scompress,
+   .decompress = deflate_sdecompress,
+   .base   = {
+   .cra_name   = "zlib(deflate)",
+   

[PATCH] crypto: acomp - replace compression known answer test

[Giovanni Cabiddu]

Compression implementations might return valid outputs that
do not match what specified in the test vectors.
For this reason, the testmgr might report that a compression
implementation failed the test even if the data produced
by the compressor is correct.
This implements a decompress-and-verify test for acomp
compression tests rather than a known answer test.

Signed-off-by: Giovanni Cabiddu 
---
 crypto/testmgr.c | 29 ++---
 1 file changed, 26 insertions(+), 3 deletions(-)

diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index cd075c7..8373c72 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -1458,7 +1458,7 @@ static int test_acomp(struct crypto_acomp *tfm,
 {
const char *algo = crypto_tfm_alg_driver_name(crypto_acomp_tfm(tfm));
unsigned int i;
-   char *output;
+   char *output, *decomp_out;
int ret;
struct scatterlist src, dst;
struct acomp_req *req;
@@ -1468,6 +1468,12 @@ static int test_acomp(struct crypto_acomp *tfm,
if (!output)
return -ENOMEM;
 
+   decomp_out = kmalloc(COMP_BUF_SIZE, GFP_KERNEL);
+   if (!decomp_out) {
+   kfree(output);
+   return -ENOMEM;
+   }
+
for (i = 0; i < ctcount; i++) {
unsigned int dlen = COMP_BUF_SIZE;
int ilen = ctemplate[i].inlen;
@@ -1506,7 +1512,23 @@ static int test_acomp(struct crypto_acomp *tfm,
goto out;
}
 
-   if (req->dlen != ctemplate[i].outlen) {
+   ilen = req->dlen;
+   dlen = COMP_BUF_SIZE;
+   sg_init_one(, output, ilen);
+   sg_init_one(, decomp_out, dlen);
+   init_completion();
+   acomp_request_set_params(req, , , ilen, dlen);
+
+   ret = wait_async_op(, crypto_acomp_decompress(req));
+   if (ret) {
+   pr_err("alg: acomp: compression failed on test %d for 
%s: ret=%d\n",
+  i + 1, algo, -ret);
+   kfree(input_vec);
+   acomp_request_free(req);
+   goto out;
+   }
+
+   if (req->dlen != ctemplate[i].inlen) {
pr_err("alg: acomp: Compression test %d failed for %s: 
output len = %d\n",
   i + 1, algo, req->dlen);
ret = -EINVAL;
@@ -1515,7 +1537,7 @@ static int test_acomp(struct crypto_acomp *tfm,
goto out;
}
 
-   if (memcmp(output, ctemplate[i].output, req->dlen)) {
+   if (memcmp(input_vec, decomp_out, req->dlen)) {
pr_err("alg: acomp: Compression test %d failed for 
%s\n",
   i + 1, algo);
hexdump(output, req->dlen);
@@ -1593,6 +1615,7 @@ static int test_acomp(struct crypto_acomp *tfm,
ret = 0;
 
 out:
+   kfree(decomp_out);
kfree(output);
return ret;
 }
-- 
2.9.3

[PATCH] crypto: acomp - report scomp implementations

[Giovanni Cabiddu]

Fix crypto_has_acomp to report scomp implementations.

Signed-off-by: Giovanni Cabiddu 
---
 include/crypto/acompress.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/crypto/acompress.h b/include/crypto/acompress.h
index e328b52..39871f9 100644
--- a/include/crypto/acompress.h
+++ b/include/crypto/acompress.h
@@ -162,6 +162,7 @@ static inline int crypto_has_acomp(const char *alg_name, 
u32 type, u32 mask)
 {
type &= ~CRYPTO_ALG_TYPE_MASK;
type |= CRYPTO_ALG_TYPE_ACOMPRESS;
+   type |= CRYPTO_ALG_TYPE_SCOMPRESS;
mask |= CRYPTO_ALG_TYPE_MASK;
 
return crypto_has_alg(alg_name, type, mask);
-- 
2.9.3

[PATCH] crypto: acomp - allow registration of multiple acomps

[Giovanni Cabiddu]

Add crypto_register_acomps and crypto_unregister_acomps to allow
the registration of multiple implementations with one call.

Signed-off-by: Giovanni Cabiddu 
---
 crypto/acompress.c  | 29 +
 include/crypto/internal/acompress.h |  3 +++
 2 files changed, 32 insertions(+)

diff --git a/crypto/acompress.c b/crypto/acompress.c
index 47d1162..1544b7c 100644
--- a/crypto/acompress.c
+++ b/crypto/acompress.c
@@ -166,5 +166,34 @@ int crypto_unregister_acomp(struct acomp_alg *alg)
 }
 EXPORT_SYMBOL_GPL(crypto_unregister_acomp);
 
+int crypto_register_acomps(struct acomp_alg *algs, int count)
+{
+   int i, ret;
+
+   for (i = 0; i < count; i++) {
+   ret = crypto_register_acomp([i]);
+   if (ret)
+   goto err;
+   }
+
+   return 0;
+
+err:
+   for (--i; i >= 0; --i)
+   crypto_unregister_acomp([i]);
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(crypto_register_acomps);
+
+void crypto_unregister_acomps(struct acomp_alg *algs, int count)
+{
+   int i;
+
+   for (i = count - 1; i >= 0; --i)
+   crypto_unregister_acomp([i]);
+}
+EXPORT_SYMBOL_GPL(crypto_unregister_acomps);
+
 MODULE_LICENSE("GPL");
 MODULE_DESCRIPTION("Asynchronous compression type");
diff --git a/include/crypto/internal/acompress.h 
b/include/crypto/internal/acompress.h
index 1de2b5a..51052f6 100644
--- a/include/crypto/internal/acompress.h
+++ b/include/crypto/internal/acompress.h
@@ -78,4 +78,7 @@ int crypto_register_acomp(struct acomp_alg *alg);
  */
 int crypto_unregister_acomp(struct acomp_alg *alg);
 
+int crypto_register_acomps(struct acomp_alg *algs, int count);
+void crypto_unregister_acomps(struct acomp_alg *algs, int count);
+
 #endif
-- 
2.9.3

Re: [RFC PATCH 0/8] crypto: AF_ALG support for KPP

[Stephan Müller]

Am Mittwoch, 19. April 2017, 14:03:35 CEST schrieb Tudor Ambarus:

Hi Tudor,

> Hi, Stephan, Herbert,
> 
> On 19.04.2017 02:03, Stephan Müller wrote:
> > The patch 8 describes the different operations that are supported by
> > AF_ALG
> > KPP. This support includes generation and retaining of the private key
> > inside the kernel. This private key would never be sent to user space.
> 
> There are crypto co-processors that are capable of generating and
> retaining the private key inside the device without revealing it to
> kernel. The private key will be further used to generate the public
> key and the shared secret. Should we extend the KPP API to support this?

The less software has access to secrets, the better. Thus, having such API 
would be good.

This of course assumes that the private key is generated with an appropriate 
RNG. As normal users cannot verify the RNG or the noise sources implemented in 
hardware, the choice of using such API to keep the private key inside the 
hardware should be left to the caller.

>From the AF_ALG KPP support side, I could imagine that that the algif_kpp code 
makes use of the hardware support unless the caller objects.

Ciao
Stephan

Re: [RFC PATCH 0/8] crypto: AF_ALG support for KPP

[Tudor Ambarus]

Hi, Stephan, Herbert,

On 19.04.2017 02:03, Stephan Müller wrote:

The patch 8 describes the different operations that are supported by AF_ALG
KPP. This support includes generation and retaining of the private key
inside the kernel. This private key would never be sent to user space.


There are crypto co-processors that are capable of generating and
retaining the private key inside the device without revealing it to
kernel. The private key will be further used to generate the public
key and the shared secret. Should we extend the KPP API to support this?

Thanks,
ta

[PATCH 2/2] n2rng: Combine substrings for two messages in n2rng_probe()

[SF Markus Elfring]

From: Markus Elfring 
Date: Wed, 19 Apr 2017 10:50:04 +0200

The script "checkpatch.pl" pointed information out like the following.

WARNING: quoted string split across lines

Thus fix the affected source code places.

Signed-off-by: Markus Elfring 
---
 drivers/char/hw_random/n2-drv.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/char/hw_random/n2-drv.c b/drivers/char/hw_random/n2-drv.c
index 92dd4e925315..f3e67c768101 100644
--- a/drivers/char/hw_random/n2-drv.c
+++ b/drivers/char/hw_random/n2-drv.c
@@ -723,16 +723,16 @@ static int n2rng_probe(struct platform_device *op)
if (sun4v_hvapi_register(HV_GRP_RNG,
 np->hvapi_major,
 >hvapi_minor)) {
-   dev_err(>dev, "Cannot register suitable "
-   "HVAPI version.\n");
+   dev_err(>dev,
+   "Cannot register suitable HVAPI version.\n");
goto out;
}
}
 
if (np->flags & N2RNG_FLAG_MULTI) {
if (np->hvapi_major < 2) {
-   dev_err(>dev, "multi-unit-capable RNG requires "
-   "HVAPI major version 2 or later, got %lu\n",
+   dev_err(>dev,
+   "multi-unit-capable RNG requires HVAPI major 
version 2 or later, got %lu\n",
np->hvapi_major);
goto out_hvapi_unregister;
}
-- 
2.12.2

[PATCH 1/2] n2rng: Use devm_kcalloc() in n2rng_probe()

[SF Markus Elfring]

From: Markus Elfring 
Date: Wed, 19 Apr 2017 10:30:47 +0200

* A multiplication for the size determination of a memory allocation
  indicated that an array data structure should be processed.
  Thus use the corresponding function "devm_kcalloc".

* Replace the specification of a data structure by a pointer dereference
  to make the corresponding size determination a bit safer according to
  the Linux coding style convention.

Signed-off-by: Markus Elfring 
---
 drivers/char/hw_random/n2-drv.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/char/hw_random/n2-drv.c b/drivers/char/hw_random/n2-drv.c
index 31cbdbbaebfc..92dd4e925315 100644
--- a/drivers/char/hw_random/n2-drv.c
+++ b/drivers/char/hw_random/n2-drv.c
@@ -748,9 +748,7 @@ static int n2rng_probe(struct platform_device *op)
 
dev_info(>dev, "Registered RNG HVAPI major %lu minor %lu\n",
 np->hvapi_major, np->hvapi_minor);
-
-   np->units = devm_kzalloc(>dev,
-sizeof(struct n2rng_unit) * np->num_units,
+   np->units = devm_kcalloc(>dev, np->num_units, sizeof(*np->units),
 GFP_KERNEL);
err = -ENOMEM;
if (!np->units)
-- 
2.12.2

[PATCH 0/2] n2rng: Fine-tuning for n2rng_probe()

[SF Markus Elfring]

From: Markus Elfring 
Date: Wed, 19 Apr 2017 11:00:11 +0200

Two update suggestions were taken into account
from static source code analysis.

Markus Elfring (2):
  Use devm_kcalloc()
  Combine substrings for two messages

 drivers/char/hw_random/n2-drv.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

-- 
2.12.2

[PATCH v2 2/3] crypto: inside-secure: add SafeXcel EIP197 crypto engine driver

[Antoine Tenart]

Add support for Inside Secure SafeXcel EIP197 cryptographic engine,
which can be found on Marvell Armada 7k and 8k boards. This driver
currently implements: ecb(aes), cbc(aes), sha1, sha224, sha256 and
hmac(sah1) algorithms.

Two firmwares are needed for this engine to work. Their are mostly used
for more advanced operations than the ones supported (as of now), but we
still need them to pass the data to the internal cryptographic engine.

Signed-off-by: Antoine Tenart 
---
 drivers/crypto/Kconfig |   17 +
 drivers/crypto/Makefile|1 +
 drivers/crypto/inside-secure/Makefile  |2 +
 drivers/crypto/inside-secure/safexcel.c|  940 +
 drivers/crypto/inside-secure/safexcel.h|  579 +
 drivers/crypto/inside-secure/safexcel_cipher.c |  555 +
 drivers/crypto/inside-secure/safexcel_hash.c   | 1060 
 drivers/crypto/inside-secure/safexcel_ring.c   |  157 
 8 files changed, 3311 insertions(+)
 create mode 100644 drivers/crypto/inside-secure/Makefile
 create mode 100644 drivers/crypto/inside-secure/safexcel.c
 create mode 100644 drivers/crypto/inside-secure/safexcel.h
 create mode 100644 drivers/crypto/inside-secure/safexcel_cipher.c
 create mode 100644 drivers/crypto/inside-secure/safexcel_hash.c
 create mode 100644 drivers/crypto/inside-secure/safexcel_ring.c

diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 473d31288ad8..d12a40450858 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -619,4 +619,21 @@ config CRYPTO_DEV_BCM_SPU
  Secure Processing Unit (SPU). The SPU driver registers ablkcipher,
  ahash, and aead algorithms with the kernel cryptographic API.
 
+config CRYPTO_DEV_SAFEXCEL
+   tristate "Inside Secure's SafeXcel cryptographic engine driver"
+   depends on HAS_DMA && OF
+   depends on (ARM64 && ARCH_MVEBU) || (COMPILE_TEST && 64BIT)
+   select CRYPTO_AES
+   select CRYPTO_BLKCIPHER
+   select CRYPTO_HASH
+   select CRYPTO_HMAC
+   select CRYPTO_SHA1
+   select CRYPTO_SHA256
+   select CRYPTO_SHA512
+   help
+ This driver interfaces with the SafeXcel EIP-197 cryptographic engine
+ designed by Inside Secure. Select this if you want to use CBC/ECB
+ chain mode, AES cipher mode and SHA1/SHA224/SHA256/SHA512 hash
+ algorithms.
+
 endif # CRYPTO_HW
diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
index 739609471169..7ed3e7940f76 100644
--- a/drivers/crypto/Makefile
+++ b/drivers/crypto/Makefile
@@ -36,3 +36,4 @@ obj-$(CONFIG_CRYPTO_DEV_UX500) += ux500/
 obj-$(CONFIG_CRYPTO_DEV_VIRTIO) += virtio/
 obj-$(CONFIG_CRYPTO_DEV_VMX) += vmx/
 obj-$(CONFIG_CRYPTO_DEV_BCM_SPU) += bcm/
+obj-$(CONFIG_CRYPTO_DEV_SAFEXCEL) += inside-secure/
diff --git a/drivers/crypto/inside-secure/Makefile 
b/drivers/crypto/inside-secure/Makefile
new file mode 100644
index ..302f07dde98c
--- /dev/null
+++ b/drivers/crypto/inside-secure/Makefile
@@ -0,0 +1,2 @@
+obj-$(CONFIG_CRYPTO_DEV_SAFEXCEL) += crypto_safexcel.o
+crypto_safexcel-objs := safexcel.o safexcel_ring.o safexcel_cipher.o 
safexcel_hash.o
diff --git a/drivers/crypto/inside-secure/safexcel.c 
b/drivers/crypto/inside-secure/safexcel.c
new file mode 100644
index ..050518be194c
--- /dev/null
+++ b/drivers/crypto/inside-secure/safexcel.c
@@ -0,0 +1,940 @@
+/*
+ * Copyright (C) 2017 Marvell
+ *
+ * Antoine Tenart 
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "safexcel.h"
+
+static u32 max_rings = EIP197_MAX_RINGS;
+module_param(max_rings, uint, 0644);
+MODULE_PARM_DESC(max_rings, "Maximum number of rings to use.");
+
+static void eip197_trc_cache_init(struct safexcel_crypto_priv *priv)
+{
+   u32 val, htable_offset;
+   int i;
+
+   /* Enable the record cache memory access */
+   val = readl(priv->base + EIP197_CS_RAM_CTRL);
+   val &= ~EIP197_TRC_ENABLE_MASK;
+   val |= EIP197_TRC_ENABLE_0;
+   writel(val, priv->base + EIP197_CS_RAM_CTRL);
+
+   /* Clear all ECC errors */
+   writel(0, priv->base + EIP197_TRC_ECCCTRL);
+
+   /*
+* Make sure the cache memory is accessible by taking record cache into
+* reset.
+*/
+   val = readl(priv->base + EIP197_TRC_PARAMS);
+   val |= EIP197_TRC_PARAMS_SW_RESET;
+   val &= ~EIP197_TRC_PARAMS_DATA_ACCESS;
+   writel(val, priv->base + EIP197_TRC_PARAMS);
+
+   /* Clear all records */
+   for (i = 0; i < EIP197_CS_RC_MAX; i++) {
+   u32 val, offset = EIP197_CLASSIFICATION_RAMS + i * 

[PATCH v2 1/3] Documentation/bindings: Document the SafeXel cryptographic engine driver

[Antoine Tenart]

The Inside Secure Safexcel cryptographic engine is found on some Marvell
SoCs (7k/8k). Document the bindings used by its driver.

Signed-off-by: Antoine Tenart 
---
 .../bindings/crypto/inside-secure-safexcel.txt | 27 ++
 1 file changed, 27 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/crypto/inside-secure-safexcel.txt

diff --git 
a/Documentation/devicetree/bindings/crypto/inside-secure-safexcel.txt 
b/Documentation/devicetree/bindings/crypto/inside-secure-safexcel.txt
new file mode 100644
index ..ff56b9384fcc
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/inside-secure-safexcel.txt
@@ -0,0 +1,27 @@
+Inside Secure SafeXcel cryptographic engine
+
+Required properties:
+- compatible: Should be "inside-secure,safexcel-eip197".
+- reg: Base physical address of the engine and length of memory mapped region.
+- interrupts: Interrupt numbers for the rings and engine.
+- interrupt-names: Should be "ring0", "ring1", "ring2", "ring3", "eip", "mem".
+
+Optional properties:
+- clocks: Reference to the crypto engine clock.
+
+Example:
+
+   crypto: crypto@80 {
+   compatible = "inside-secure,safexcel-eip197";
+   reg = <0x80 0x20>;
+   interrupts = ,
+,
+,
+,
+,
+;
+   interrupt-names = "mem", "ring0", "ring1", "ring2", "ring3",
+ "eip";
+   clocks = <_syscon0 1 26>;
+   status = "disabled";
+   };
-- 
2.11.0

[PATCH v2 3/3] MAINTAINERS: add a maintainer for the Inside Secure crypto driver

[Antoine Tenart]

A new cryptographic engine driver was added in
drivers/crypto/inside-secure. Add myself as a maintainer for this
driver.

Signed-off-by: Antoine Tenart 
---
 MAINTAINERS | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index c265a5fe4848..7240b9bca638 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6487,6 +6487,12 @@ F:   Documentation/input/multi-touch-protocol.txt
 F: drivers/input/input-mt.c
 K: \b(ABS|SYN)_MT_
 
+INSIDE SECURE CRYPTO DRIVER
+M: Antoine Tenart 
+F: drivers/crypto/inside-secure/
+S: Maintained
+L: linux-crypto@vger.kernel.org
+
 INTEL ASoC BDW/HSW DRIVERS
 M: Jie Yang 
 L: alsa-de...@alsa-project.org (moderated for non-subscribers)
-- 
2.11.0

[PATCH v2 0/3] arm64: marvell: add cryptographic engine support for 7k/8k

[Antoine Tenart]

Hi all,

This series adds support for the Inside Secure SafeXcel EIP197
cryptographic engine which can be found on Marvell Armada 7k and 8k
boards. A new cryptographic engine driver is added, as well as the
relevant device tree definition for the Armada 7040 DB and 8040 DB
boards.

This driver needs two firmwares to work correctly. These firmware are
usually used for more advanced operations than the ones supported (as of
now), but we still need them to pass the data to the internal
cryptographic engine.

This series was tested in various ways on both the Armada 7040 DB and
the Armada 8040 DB: using the crypto framework self tests, using tcrypt
and while performing various transfers with iperf on top of IPsec.

This series is based on top of v4.11-rc1, and is available on a branch
(which also contains the PPv2 support for 7k/8k, to ease the process of
testing IPsec): https://github.com/atenart/linux  v4.11-rc1/7k8k-crypto
I can rebase if needed. Patches adding device tree nodes and modifying
the arm64 defconfig have been applied to the mvebu tree already.

I'd like to thank Ofer Heifetz and Igal Liberman who helped me to do
this driver by adding functionalities, optimizing functions and testing
(a lot).

Thanks,
Antoine


Since v1:
  - Fixed two compilation issues reported by Kbuild.
  - Removed all dma_to_phys() calls and used the dma addresses instead.
  - Added a call to dma_set_mask_and_coherent() before calling any DMA
API helper.
  - Removed some DMA free functions to avoid double-freeing.
  - Do not rely on sg_nents_for_len() to get the number of sg anymore.
  - Added a dedicated kmalloc'ed cache to use for dma_map_single().


Antoine Tenart (3):
  Documentation/bindings: Document the SafeXel cryptographic engine
driver
  crypto: inside-secure: add SafeXcel EIP197 crypto engine driver
  MAINTAINERS: add a maintainer for the Inside Secure crypto driver

 .../bindings/crypto/inside-secure-safexcel.txt |   27 +
 MAINTAINERS|6 +
 drivers/crypto/Kconfig |   17 +
 drivers/crypto/Makefile|1 +
 drivers/crypto/inside-secure/Makefile  |2 +
 drivers/crypto/inside-secure/safexcel.c|  940 +
 drivers/crypto/inside-secure/safexcel.h|  579 +++
 drivers/crypto/inside-secure/safexcel_cipher.c |  555 ++
 drivers/crypto/inside-secure/safexcel_hash.c   | 1060 
 drivers/crypto/inside-secure/safexcel_ring.c   |  157 +++
 10 files changed, 3344 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/crypto/inside-secure-safexcel.txt
 create mode 100644 drivers/crypto/inside-secure/Makefile
 create mode 100644 drivers/crypto/inside-secure/safexcel.c
 create mode 100644 drivers/crypto/inside-secure/safexcel.h
 create mode 100644 drivers/crypto/inside-secure/safexcel_cipher.c
 create mode 100644 drivers/crypto/inside-secure/safexcel_hash.c
 create mode 100644 drivers/crypto/inside-secure/safexcel_ring.c

-- 
2.11.0