Re: [v3 RFC PATCH 2/2] crypto: ecc: use caller's GFP flags

[Herbert Xu]

On Wed, Jun 28, 2017 at 05:08:36PM +0300, Tudor Ambarus wrote:
> Using GFP_KERNEL when allocating data and implicitly
> assuming that we can sleep was wrong because the caller
> could be in atomic context. Let the caller decide whether
> sleeping is possible or not.
> 
> The caller (ecdh) was updated in the same patch in order
> to not affect bissectability.
> 
> Signed-off-by: Tudor Ambarus 

Hmm, who wants to do asymmetric key crypto in interrupt context?

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

Re: [v3 RFC PATCH 1/2] crypto: ecdh: fix concurrency on ecdh_ctx

[Herbert Xu]

On Wed, Jun 28, 2017 at 05:08:35PM +0300, Tudor Ambarus wrote:
> ecdh_ctx contained static allocated data for the shared secret,
> for the public and private key.
> 
> When talking about shared secret and public key, they were
> doomed to concurrency issues because they could be shared by
> multiple crypto requests. The requests were generating specific
> data to the same zone of memory without any protection.
> 
> The private key was subject to concurrency problems because
> multiple setkey calls could fight to memcpy to the same zone
> of memory.
> 
> Shared secret and public key concurrency is fixed by allocating
> memory on heap for each request. In the end, the shared secret
> and public key are computed for each request, there is no reason
> to use shared memory.
> 
> Private key concurrency is fixed by allocating memory on heap
> for each setkey call, by memcopying the parsed/generated private
> key to the heap and by making the private key pointer from
> ecdh_ctx to point to the newly allocated data.
> 
> On all systems running Linux, loads from and stores to pointers
> are atomic, that is, if a store to a pointer occurs at the same
> time as a load from that same pointer, the load will return either
> the initial value or the value stored, never some bitwise mashup
> of the two.
> 
> With this, the private key will always point to a valid key,
> but to what setkey call it belongs, is the responsibility of the
> caller, as it is now in all crypto framework.

I don't get it.  You're replacing a per-tfm shared secret with
a per-tfm dynamically allocated shared secret.  As far as I can
see nothing has changed?

If the caller is making simultaneous setkey calls on the same tfm,
then it's their problem.

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

Re: [PATCH 3/3] hwrng: mxc-fsl - add support for Freescale RNGC

[PrasannaKumar Muralidharan]

Hi Martin,

On 18 July 2017 at 02:46, Martin Kaiser  wrote:
> From: Steffen Trumtrar 
>
> The driver is ported from Freescales Linux git and can be
> found in the
>
> vendor/freescale/imx_2.6.35_maintain
>
> branch.
>
> According to that code, the RNGC is found on Freescales i.MX3/5 SoCs.
> The i.MX2x actually has an RNGB, which has no driver implementation
> in Freescales kernel. However as it turns out, the driver for the RNGC
> works fine on the (at least) i.MX25. So, they seem to be somewhat
> compatible.
>
> Signed-off-by: Steffen Trumtrar 
> Signed-off-by: Martin Kaiser 
> ---
> Changes in v3:
>- use pdev->dev to request the irq, rngc->dev is not yet initialized
>- remove unused defines for registers and fields
>- use module_platform_driver_probe()
>- clean up the error handling in the probe function,
>  disable the clock if necessary
>- self-test must succeed in the first run
>- check for errors after seeding, exit for errors unrelated to
>  statistics
>- set a timeout when waiting for a completion
>
> Changes in v2:
>   - remove irq variable from private struct
>   - move devm_request_irq from mxc_rngc_init to probe
>   - return irq in case of error
>   - handle irq 0 as error
>
>  drivers/char/hw_random/Kconfig|  13 ++
>  drivers/char/hw_random/Makefile   |   1 +
>  drivers/char/hw_random/mxc-rngc.c | 351 
> ++
>  3 files changed, 365 insertions(+)
>  create mode 100644 drivers/char/hw_random/mxc-rngc.c
>
> diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
> index 1b223c3..ef057b7 100644
> --- a/drivers/char/hw_random/Kconfig
> +++ b/drivers/char/hw_random/Kconfig
> @@ -255,6 +255,19 @@ config HW_RANDOM_MXC_RNGA
>
>   If unsure, say Y.
>
> +config HW_RANDOM_MXC_RNGC
> +   tristate "Freescale i.MX RNGC Random Number Generator"
> +   depends on ARCH_MXC
> +   default HW_RANDOM
> +   ---help---
> + This driver provides kernel-side support for the Random Number
> + Generator hardware found on some Freescale i.MX processors.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called mxc-rngc.
> +
> + If unsure, say Y.
> +
>  config HW_RANDOM_NOMADIK
> tristate "ST-Ericsson Nomadik Random Number Generator support"
> depends on ARCH_NOMADIK
> diff --git a/drivers/char/hw_random/Makefile b/drivers/char/hw_random/Makefile
> index b085975..043b71d 100644
> --- a/drivers/char/hw_random/Makefile
> +++ b/drivers/char/hw_random/Makefile
> @@ -20,6 +20,7 @@ obj-$(CONFIG_HW_RANDOM_PASEMI) += pasemi-rng.o
>  obj-$(CONFIG_HW_RANDOM_VIRTIO) += virtio-rng.o
>  obj-$(CONFIG_HW_RANDOM_TX4939) += tx4939-rng.o
>  obj-$(CONFIG_HW_RANDOM_MXC_RNGA) += mxc-rnga.o
> +obj-$(CONFIG_HW_RANDOM_MXC_RNGC) += mxc-rngc.o
>  obj-$(CONFIG_HW_RANDOM_OCTEON) += octeon-rng.o
>  obj-$(CONFIG_HW_RANDOM_NOMADIK) += nomadik-rng.o
>  obj-$(CONFIG_HW_RANDOM_PSERIES) += pseries-rng.o
> diff --git a/drivers/char/hw_random/mxc-rngc.c 
> b/drivers/char/hw_random/mxc-rngc.c
> new file mode 100644
> index 000..56175b1
> --- /dev/null
> +++ b/drivers/char/hw_random/mxc-rngc.c
> @@ -0,0 +1,351 @@
> +/*
> + * RNG driver for Freescale RNGC
> + *
> + * Copyright (C) 2008-2012 Freescale Semiconductor, Inc.
> + */
> +
> +/*
> + * The code contained herein is licensed under the GNU General Public
> + * License. You may obtain a copy of the GNU General Public License
> + * Version 2 or later at the following locations:
> + *
> + * http://www.opensource.org/licenses/gpl-license.html
> + * http://www.gnu.org/copyleft/gpl.html
> + */

Please combine above 2 comments.

> +
> +/*
> + * Hardware driver for the Intel/AMD/VIA Random Number Generators (RNG)
> + * (c) Copyright 2003 Red Hat Inc 
> + *
> + * derived from
> + *
> + * Hardware driver for the AMD 768 Random Number Generator (RNG)
> + * (c) Copyright 2001 Red Hat Inc 
> + *
> + * derived from
> + *
> + * Hardware driver for Intel i810 Random Number Generator (RNG)
> + * Copyright 2000,2001 Jeff Garzik 
> + * Copyright 2000,2001 Philipp Rumpf 
> + *
> + * 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.
> + */

I feel this comment is because of copy paste. If that's the case please remove.

> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define RNGC_COMMAND   0x0004
> +#define RNGC_CONTROL   0x0008
> +#define RNGC_STATUS0x000C
> +#define RNGC_ERROR 0x0010
> +#define RNGC_FIFO   

Re: [PATCH V6 5/7] crypto: AES CBC multi-buffer glue code

[Herbert Xu]

On Tue, Jun 27, 2017 at 05:26:13PM -0700, Megha Dey wrote:
>
> +static void completion_callback(struct mcryptd_skcipher_request_ctx *rctx,
> + struct mcryptd_alg_cstate *cstate,
> + int err)
> +{
> + struct skcipher_request *req = cast_mcryptd_ctx_to_req(rctx);
> +
> +   /* remove from work list and invoke completion callback */
> + spin_lock(>work_lock);
> + list_del(>waiter);
> + spin_unlock(>work_lock);
> +
> + if (irqs_disabled())
> + rctx->complete(>base, err);
> + else {
> + local_bh_disable();
> + rctx->complete(>base, err);
> + local_bh_enable();
> + }
> +}

The fact that you need to do this check means that this design is
wrong.  You should always know what context you are in.

> +/*
> + * CRYPTO_ALG_ASYNC flag is passed to indicate we have an ablk
> + * scatter-gather walk.
> + */
> +static struct skcipher_alg aes_cbc_mb_alg = {
> + .base = {
> + .cra_name   = "cbc(aes)",
> + .cra_driver_name= "cbc-aes-aesni-mb",
> + .cra_priority   = 500,
> + .cra_flags  = CRYPTO_ALG_INTERNAL,
> + .cra_blocksize  = AES_BLOCK_SIZE,
> + .cra_ctxsize= CRYPTO_AES_CTX_SIZE,
> + .cra_module = THIS_MODULE,
> + },
> + .min_keysize= AES_MIN_KEY_SIZE,
> + .max_keysize= AES_MAX_KEY_SIZE,
> + .ivsize = AES_BLOCK_SIZE,
> + .setkey = aes_set_key,
> + .encrypt= mb_aes_cbc_encrypt,
> + .decrypt= mb_aes_cbc_decrypt
> +};

So this claims to be a sync algorithm.  Is this really the case?

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 0/7] crypto: aes - allow generic AES to be omitted

[Herbert Xu]

On Tue, Jun 20, 2017 at 11:28:53AM +0200, Ard Biesheuvel wrote:
> The generic AES driver uses 16 lookup tables of 1 KB each, and has
> encryption and decryption routines that are fully unrolled. Given how
> the dependencies between this code and other drivers are declared in
> Kconfig files, this code is always pulled into the core kernel, even
> if it is usually superseded at runtime by accelerated drivers that
> exist for many architectures.

Why can't we simply replace aes-generic with aes-ti?

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

Re: [PATCH 1/3] staging: ccree: Replace kzalloc with devm_kzalloc

[Suniel Mahesh]

On Monday 17 July 2017 06:03 PM, Greg KH wrote:
> On Sat, Jul 15, 2017 at 01:21:54PM +0530, suni...@techveda.org wrote:
>> From: Suniel Mahesh 
>>
>> It is recommended to use managed function devm_kzalloc, which
>> simplifies driver cleanup paths and driver code.
>> This patch does the following:
>> (a) replace kzalloc with devm_kzalloc.
>> (b) drop kfree(), because memory allocated with devm_kzalloc() is
>> automatically freed on driver detach, otherwise it leads to a double
>> free.
>> (c) remove unnecessary blank lines.
>>
>> Signed-off-by: Suniel Mahesh 
>> ---
>> Note:
>> - Patch was tested and built(ARCH=arm) on next-20170714.
>>   No build issues reported, however it was not tested on
>>   real hardware.
>> ---
>>  drivers/staging/ccree/ssi_driver.c | 10 --
>>  1 file changed, 4 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/staging/ccree/ssi_driver.c 
>> b/drivers/staging/ccree/ssi_driver.c
>> index 78709b92..f231ecf 100644
>> --- a/drivers/staging/ccree/ssi_driver.c
>> +++ b/drivers/staging/ccree/ssi_driver.c
>> @@ -224,13 +224,15 @@ static int init_cc_resources(struct platform_device 
>> *plat_dev)
>>  struct resource *req_mem_cc_regs = NULL;
>>  void __iomem *cc_base = NULL;
>>  bool irq_registered = false;
>> -struct ssi_drvdata *new_drvdata = kzalloc(sizeof(struct ssi_drvdata), 
>> GFP_KERNEL);
>> +struct ssi_drvdata *new_drvdata;
>>  struct device *dev = _dev->dev;
>>  struct device_node *np = dev->of_node;
>>  u32 signature_val;
>>  int rc = 0;
>>  
>> -if (unlikely(!new_drvdata)) {
>> +new_drvdata = devm_kzalloc(_dev->dev, sizeof(struct ssi_drvdata),
> 
> sizeof(*new_drvdata), right?
> 
Yes, sending v2 in a while. Thanks for the review
suniel
> thanks,
> 
> greg k-h
> 

Re: [PATCH V6 0/7] crypto: AES CBC multibuffer implementation

[Megha Dey]

Hi Herbert,

Do you want any other changes to be made to this patchset?

Thanks,
Megha

On Tue, 2017-06-27 at 17:26 -0700, Megha Dey wrote:
> In this patch series, we introduce AES CBC encryption that is parallelized on
> x86_64 cpu with XMM registers. The multi-buffer technique encrypt 8 data
> streams in parallel with SIMD instructions. Decryption is handled as in the
> existing AESNI Intel CBC implementation which can already parallelize 
> decryption
> even for a single data stream.
> 
> Please see the multi-buffer whitepaper for details of the technique:
> http://www.intel.com/content/www/us/en/communications/communications-ia-multi-buffer-paper.html
> 
> It is important that any driver uses this algorithm properly for scenarios
> where we have many data streams that can fill up the data lanes most of the
> time. It shouldn't be used when only a single data stream is expected mostly.
> Otherwise we may incur extra delays when we have frequent gaps in data lanes,
> causing us to wait till data come in to fill the data lanes before initiating
> encryption.  We may have to wait for flush operations to commence when no new
> data come in after some wait time. However we keep this extra delay to a
> minimum by opportunistically flushing the unfinished jobs if crypto daemon is
> the only active task running on a cpu.
> 
> By using this technique, we saw a throughput increase of up to 5.7x under
> optimal conditions when we have fully loaded encryption jobs filling up all
> the data lanes.
> 
> Change Log:
> 
> v6
> 1. Move away from the compat naming scheme and update the names of the inner
>and outer algorithm
> 2. Move wrapper code around synchronous internal algorithm from simd.c
>to mcryptd.c
> 
> v5
> 1. Use an async implementation of the inner algorithm instead of sync and use
>the latest skcipher interface instead of the older blkcipher interface.
>(we have picked up this work after a while)
> 
> v4
> 1. Make the decrypt path also use ablkcpher walk.
> http://lkml.iu.edu/hypermail/linux/kernel/1512.0/01807.html
> 
> v3
> 1. Use ablkcipher_walk helpers to walk the scatter gather list
> and eliminated needs to modify blkcipher_walk for multibuffer cipher
> 
> v2
> 1. Update cpu feature check to make sure SSE is supported
> 2. Fix up unloading of aes-cbc-mb module to properly free memory
> 
> Megha Dey (7):
>   crypto: Multi-buffer encryption infrastructure support
>   crypto: AES CBC multi-buffer data structures
>   crypto: AES CBC multi-buffer scheduler
>   crypto: AES CBC by8 encryption
>   crypto: AES CBC multi-buffer glue code
>   crypto: AES vectors for AES CBC multibuffer testing
>   crypto: AES CBC multi-buffer tcrypt
> 
>  arch/x86/crypto/Makefile   |1 +
>  arch/x86/crypto/aes-cbc-mb/Makefile|   22 +
>  arch/x86/crypto/aes-cbc-mb/aes_cbc_enc_x8.S|  775 ++
>  arch/x86/crypto/aes-cbc-mb/aes_cbc_mb.c|  727 ++
>  arch/x86/crypto/aes-cbc-mb/aes_cbc_mb_ctx.h|   97 ++
>  arch/x86/crypto/aes-cbc-mb/aes_cbc_mb_mgr.h|  132 ++
>  arch/x86/crypto/aes-cbc-mb/aes_mb_mgr_init.c   |  146 ++
>  arch/x86/crypto/aes-cbc-mb/mb_mgr_datastruct.S |  271 
>  arch/x86/crypto/aes-cbc-mb/mb_mgr_inorder_x8_asm.S |  223 +++
>  arch/x86/crypto/aes-cbc-mb/mb_mgr_ooo_x8_asm.S |  417 ++
>  arch/x86/crypto/aes-cbc-mb/reg_sizes.S |  126 ++
>  crypto/Kconfig |   15 +
>  crypto/mcryptd.c   |  474 +++
>  crypto/tcrypt.c|  259 +++-
>  crypto/testmgr.c   |  707 +
>  crypto/testmgr.h   | 1496 
> 
>  include/crypto/mcryptd.h   |   56 +
>  17 files changed, 5942 insertions(+), 2 deletions(-)
>  create mode 100644 arch/x86/crypto/aes-cbc-mb/Makefile
>  create mode 100644 arch/x86/crypto/aes-cbc-mb/aes_cbc_enc_x8.S
>  create mode 100644 arch/x86/crypto/aes-cbc-mb/aes_cbc_mb.c
>  create mode 100644 arch/x86/crypto/aes-cbc-mb/aes_cbc_mb_ctx.h
>  create mode 100644 arch/x86/crypto/aes-cbc-mb/aes_cbc_mb_mgr.h
>  create mode 100644 arch/x86/crypto/aes-cbc-mb/aes_mb_mgr_init.c
>  create mode 100644 arch/x86/crypto/aes-cbc-mb/mb_mgr_datastruct.S
>  create mode 100644 arch/x86/crypto/aes-cbc-mb/mb_mgr_inorder_x8_asm.S
>  create mode 100644 arch/x86/crypto/aes-cbc-mb/mb_mgr_ooo_x8_asm.S
>  create mode 100644 arch/x86/crypto/aes-cbc-mb/reg_sizes.S
> 

[PATCH V2 6/6] crypto/nx: Add P9 NX support for 842 compression engine

[Haren Myneni]

This patch adds P9 NX support for 842 compression engine. Virtual
Accelerator Switchboard (VAS) is used to access 842 engine on P9.

For each NX engine per chip, setup receive window using
vas_rx_win_open() which configures RxFIFo with FIFO address, lpid,
pid and tid values. This unique (lpid, pid, tid) combination will
be used to identify the target engine.

For crypto open request, open send window on the NX engine for
the corresponding chip / cpu where the open request is executed.
This send window will be closed upon crypto close request.

NX provides high and normal priority FIFOs. For compression /
decompression requests, we use only hight priority FIFOs in kernel.

Each NX request will be communicated to VAS using copy/paste
instructions with vas_copy_crb() / vas_paste_crb() functions.

Signed-off-by: Haren Myneni 
---
 drivers/crypto/nx/Kconfig  |   1 +
 drivers/crypto/nx/nx-842-powernv.c | 369 -
 drivers/crypto/nx/nx-842.c |   2 +-
 3 files changed, 365 insertions(+), 7 deletions(-)

diff --git a/drivers/crypto/nx/Kconfig b/drivers/crypto/nx/Kconfig
index ad7552a6998c..cd5dda9c48f4 100644
--- a/drivers/crypto/nx/Kconfig
+++ b/drivers/crypto/nx/Kconfig
@@ -38,6 +38,7 @@ config CRYPTO_DEV_NX_COMPRESS_PSERIES
 config CRYPTO_DEV_NX_COMPRESS_POWERNV
tristate "Compression acceleration support on PowerNV platform"
depends on PPC_POWERNV
+   depends on PPC_VAS
default y
help
  Support for PowerPC Nest (NX) compression acceleration. This
diff --git a/drivers/crypto/nx/nx-842-powernv.c 
b/drivers/crypto/nx/nx-842-powernv.c
index c0dd4c7e17d3..8d9d21420144 100644
--- a/drivers/crypto/nx/nx-842-powernv.c
+++ b/drivers/crypto/nx/nx-842-powernv.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 
 MODULE_LICENSE("GPL");
 MODULE_AUTHOR("Dan Streetman ");
@@ -32,6 +33,9 @@ MODULE_ALIAS_CRYPTO("842-nx");
 
 #define WORKMEM_ALIGN  (CRB_ALIGN)
 #define CSB_WAIT_MAX   (5000) /* ms */
+#define VAS_RETRIES(10)
+/* # of requests allowed per RxFIFO at a time. 0 for unlimited */
+#define MAX_CREDITS_PER_RXFIFO (64)
 
 struct nx842_workmem {
/* Below fields must be properly aligned */
@@ -42,16 +46,27 @@ struct nx842_workmem {
 
ktime_t start;
 
+   struct vas_window *txwin;   /* Used with VAS function */
char padding[WORKMEM_ALIGN]; /* unused, to allow alignment */
 } __packed __aligned(WORKMEM_ALIGN);
 
 struct nx842_coproc {
unsigned int chip_id;
unsigned int ct;
-   unsigned int ci;
+   unsigned int ci;/* Coprocessor instance, used with icswx */
+   struct {
+   struct vas_window *rxwin;
+   int id;
+   } vas;
struct list_head list;
 };
 
+/*
+ * Send the request to NX engine on the chip for the corresponding CPU
+ * where the process is executing. Use with VAS function.
+ */
+static DEFINE_PER_CPU(struct nx842_coproc *, coproc_inst);
+
 /* no cpu hotplug on powernv, so this list never changes after init */
 static LIST_HEAD(nx842_coprocs);
 static unsigned int nx842_ct;  /* used in icswx function */
@@ -513,6 +528,108 @@ static int nx842_exec_icswx(const unsigned char *in, 
unsigned int inlen,
 }
 
 /**
+ * nx842_exec_vas - compress/decompress data using the 842 algorithm
+ *
+ * (De)compression provided by the NX842 coprocessor on IBM PowerNV systems.
+ * This compresses or decompresses the provided input buffer into the provided
+ * output buffer.
+ *
+ * Upon return from this function @outlen contains the length of the
+ * output data.  If there is an error then @outlen will be 0 and an
+ * error will be specified by the return code from this function.
+ *
+ * The @workmem buffer should only be used by one function call at a time.
+ *
+ * @in: input buffer pointer
+ * @inlen: input buffer size
+ * @out: output buffer pointer
+ * @outlenp: output buffer size pointer
+ * @workmem: working memory buffer pointer, size determined by
+ *   nx842_powernv_driver.workmem_size
+ * @fc: function code, see CCW Function Codes in nx-842.h
+ *
+ * Returns:
+ *   0 Success, output of length @outlenp stored in the buffer
+ * at @out
+ *   -ENODEV   Hardware unavailable
+ *   -ENOSPC   Output buffer is to small
+ *   -EMSGSIZE Input buffer too large
+ *   -EINVAL   buffer constraints do not fix nx842_constraints
+ *   -EPROTO   hardware error during operation
+ *   -ETIMEDOUThardware did not complete operation in reasonable time
+ *   -EINTRoperation was aborted
+ */
+static int nx842_exec_vas(const unsigned char *in, unsigned int inlen,
+ unsigned char *out, unsigned int *outlenp,
+ void *workmem, int fc)
+{
+   struct coprocessor_request_block *crb;
+   struct coprocessor_status_block *csb;
+   struct nx842_workmem *wmem;
+   struct vas_window *txwin;
+   

[PATCH V2 5/6] crypto/nx: Add P9 NX specific error codes for 842 engine

[Haren Myneni]

This patch adds changes for checking P9 specific 842 engine
error codes. These errros are reported in coprocessor status
block (CSB) for failures.

Signed-off-by: Haren Myneni 
---
 arch/powerpc/include/asm/icswx.h   |  3 +++
 drivers/crypto/nx/nx-842-powernv.c | 18 ++
 drivers/crypto/nx/nx-842.h |  8 
 3 files changed, 29 insertions(+)

diff --git a/arch/powerpc/include/asm/icswx.h b/arch/powerpc/include/asm/icswx.h
index 27e588f6c72e..6a2c87577541 100644
--- a/arch/powerpc/include/asm/icswx.h
+++ b/arch/powerpc/include/asm/icswx.h
@@ -69,7 +69,10 @@ struct coprocessor_completion_block {
 #define CSB_CC_WR_PROTECTION   (16)
 #define CSB_CC_UNKNOWN_CODE(17)
 #define CSB_CC_ABORT   (18)
+#define CSB_CC_EXCEED_BYTE_COUNT   (19)/* P9 or later */
 #define CSB_CC_TRANSPORT   (20)
+#define CSB_CC_INVALID_CRB (21)/* P9 or later */
+#define CSB_CC_INVALID_DDE (30)/* P9 or later */
 #define CSB_CC_SEGMENTED_DDL   (31)
 #define CSB_CC_PROGRESS_POINT  (32)
 #define CSB_CC_DDE_OVERFLOW(33)
diff --git a/drivers/crypto/nx/nx-842-powernv.c 
b/drivers/crypto/nx/nx-842-powernv.c
index 829b5cad0043..c0dd4c7e17d3 100644
--- a/drivers/crypto/nx/nx-842-powernv.c
+++ b/drivers/crypto/nx/nx-842-powernv.c
@@ -243,6 +243,13 @@ static int wait_for_csb(struct nx842_workmem *wmem,
case CSB_CC_TEMPL_OVERFLOW:
CSB_ERR(csb, "Compressed data template shows data past end");
return -EINVAL;
+   case CSB_CC_EXCEED_BYTE_COUNT:  /* P9 or later */
+   /*
+* DDE byte count exceeds the limit specified in Maximum
+* byte count register.
+*/
+   CSB_ERR(csb, "DDE byte count exceeds the limit");
+   return -EINVAL;
 
/* these should not happen */
case CSB_CC_INVALID_ALIGN:
@@ -284,9 +291,17 @@ static int wait_for_csb(struct nx842_workmem *wmem,
CSB_ERR(csb, "Too many DDEs in DDL");
return -EINVAL;
case CSB_CC_TRANSPORT:
+   case CSB_CC_INVALID_CRB:/* P9 or later */
/* shouldn't happen, we setup CRB correctly */
CSB_ERR(csb, "Invalid CRB");
return -EINVAL;
+   case CSB_CC_INVALID_DDE:/* P9 or later */
+   /*
+* shouldn't happen, setup_direct/indirect_dde creates
+* DDE right
+*/
+   CSB_ERR(csb, "Invalid DDE");
+   return -EINVAL;
case CSB_CC_SEGMENTED_DDL:
/* shouldn't happen, setup_ddl creates DDL right */
CSB_ERR(csb, "Segmented DDL error");
@@ -330,6 +345,9 @@ static int wait_for_csb(struct nx842_workmem *wmem,
case CSB_CC_HW:
CSB_ERR(csb, "Correctable hardware error");
return -EPROTO;
+   case CSB_CC_HW_EXPIRED_TIMER:   /* P9 or later */
+   CSB_ERR(csb, "Job did not finish within allowed time");
+   return -EPROTO;
 
default:
CSB_ERR(csb, "Invalid CC %d", csb->cc);
diff --git a/drivers/crypto/nx/nx-842.h b/drivers/crypto/nx/nx-842.h
index 30929bd7d1a9..bb2f31792683 100644
--- a/drivers/crypto/nx/nx-842.h
+++ b/drivers/crypto/nx/nx-842.h
@@ -76,9 +76,17 @@
 #define CSB_CC_DECRYPT_OVERFLOW(64)
 /* asym crypt codes */
 #define CSB_CC_MINV_OVERFLOW   (128)
+/*
+ * HW error - Job did not finish in the maximum time allowed.
+ * Job terminated.
+ */
+#define CSB_CC_HW_EXPIRED_TIMER(224)
 /* These are reserved for hypervisor use */
 #define CSB_CC_HYP_RESERVE_START   (240)
 #define CSB_CC_HYP_RESERVE_END (253)
+#define CSB_CC_HYP_RESERVE_P9_END  (251)
+/* No valid interrupt server (P9 or later). */
+#define CSB_CC_HYP_RESERVE_NO_INTR_SERVER  (252)
 #define CSB_CC_HYP_NO_HW   (254)
 #define CSB_CC_HYP_HANG_ABORTED(255)
 
-- 
2.11.0

[PATCH V2 4/6] crypto/nx: Add nx842_add_coprocs_list function

[Haren Myneni]

Updating coprocessor list is moved to nx842_add_coprocs_list().
This function will be used for both icswx and VAS functions.

Signed-off-by: Haren Myneni 
---
 drivers/crypto/nx/nx-842-powernv.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/crypto/nx/nx-842-powernv.c 
b/drivers/crypto/nx/nx-842-powernv.c
index 67dc06f9b557..829b5cad0043 100644
--- a/drivers/crypto/nx/nx-842-powernv.c
+++ b/drivers/crypto/nx/nx-842-powernv.c
@@ -550,6 +550,14 @@ static int nx842_powernv_decompress(const unsigned char 
*in, unsigned int inlen,
  wmem, CCW_FC_842_DECOMP_CRC);
 }
 
+static inline void nx842_add_coprocs_list(struct nx842_coproc *coproc,
+   int chipid)
+{
+   coproc->chip_id = chipid;
+   INIT_LIST_HEAD(>list);
+   list_add(>list, _coprocs);
+}
+
 static int __init nx842_powernv_probe(struct device_node *dn)
 {
struct nx842_coproc *coproc;
@@ -576,11 +584,9 @@ static int __init nx842_powernv_probe(struct device_node 
*dn)
if (!coproc)
return -ENOMEM;
 
-   coproc->chip_id = chip_id;
coproc->ct = ct;
coproc->ci = ci;
-   INIT_LIST_HEAD(>list);
-   list_add(>list, _coprocs);
+   nx842_add_coprocs_list(coproc, chip_id);
 
pr_info("coprocessor found on chip %d, CT %d CI %d\n", chip_id, ct, ci);
 
-- 
2.11.0

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

[Haren Myneni]

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 
---
 drivers/crypto/nx/nx-842-powernv.c | 57 +-
 1 file changed, 38 insertions(+), 19 deletions(-)

diff --git a/drivers/crypto/nx/nx-842-powernv.c 
b/drivers/crypto/nx/nx-842-powernv.c
index 161987698bbc..1bd19e03eb7d 100644
--- a/drivers/crypto/nx/nx-842-powernv.c
+++ b/drivers/crypto/nx/nx-842-powernv.c
@@ -358,6 +358,40 @@ static int wait_for_csb(struct nx842_workmem *wmem,
return 0;
 }
 
+static int nx842_config_crb(const unsigned char *in, unsigned int inlen,
+   unsigned char *out, unsigned int outlen,
+   struct nx842_workmem *wmem)
+{
+   struct coprocessor_request_block *crb;
+   struct coprocessor_status_block *csb;
+   u64 csb_addr;
+   int ret;
+
+   crb = >crb;
+   csb = >csb;
+
+   /* Clear any previous values */
+   memset(crb, 0, sizeof(*crb));
+
+   /* set up DDLs */
+   ret = setup_ddl(>source, wmem->ddl_in,
+   (unsigned char *)in, inlen, true);
+   if (ret)
+   return ret;
+
+   ret = setup_ddl(>target, wmem->ddl_out,
+   out, outlen, false);
+   if (ret)
+   return ret;
+
+   /* set up CRB's CSB addr */
+   csb_addr = nx842_get_pa(csb) & CRB_CSB_ADDRESS;
+   csb_addr |= CRB_CSB_AT; /* Addrs are phys */
+   crb->csb_addr = cpu_to_be64(csb_addr);
+
+   return 0;
+}
+
 /**
  * nx842_exec_icswx - compress/decompress data using the 842 algorithm
  *
@@ -397,7 +431,6 @@ static int nx842_exec_icswx(const unsigned char *in, 
unsigned int inlen,
struct coprocessor_status_block *csb;
struct nx842_workmem *wmem;
int ret;
-   u64 csb_addr;
u32 ccw;
unsigned int outlen = *outlenp;
 
@@ -411,33 +444,19 @@ static int nx842_exec_icswx(const unsigned char *in, 
unsigned int inlen,
return -ENODEV;
}
 
-   crb = >crb;
-   csb = >csb;
-
-   /* Clear any previous values */
-   memset(crb, 0, sizeof(*crb));
-
-   /* set up DDLs */
-   ret = setup_ddl(>source, wmem->ddl_in,
-   (unsigned char *)in, inlen, true);
-   if (ret)
-   return ret;
-   ret = setup_ddl(>target, wmem->ddl_out,
-   out, outlen, false);
+   ret = nx842_config_crb(in, inlen, out, outlen, wmem);
if (ret)
return ret;
 
+   crb = >crb;
+   csb = >csb;
+
/* set up CCW */
ccw = 0;
ccw = SET_FIELD(CCW_CT, ccw, nx842_ct);
ccw = SET_FIELD(CCW_CI_842, ccw, 0); /* use 0 for hw auto-selection */
ccw = SET_FIELD(CCW_FC_842, ccw, fc);
 
-   /* set up CRB's CSB addr */
-   csb_addr = nx842_get_pa(csb) & CRB_CSB_ADDRESS;
-   csb_addr |= CRB_CSB_AT; /* Addrs are phys */
-   crb->csb_addr = cpu_to_be64(csb_addr);
-
wmem->start = ktime_get();
 
/* do ICSWX */
-- 
2.11.0

[PATCH V2 1/6] crypto/nx842: Rename nx842_powernv_function as icswx function

[Haren Myneni]

Rename nx842_powernv_function to nx842_powernv_exec.
nx842_powernv_exec points to nx842_exec_icswx and
will be point to VAS exec function which will be added later
for P9 NX support.

Signed-off-by: Haren Myneni 
---
 drivers/crypto/nx/nx-842-powernv.c | 20 +---
 1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/drivers/crypto/nx/nx-842-powernv.c 
b/drivers/crypto/nx/nx-842-powernv.c
index 3abb045cdba7..161987698bbc 100644
--- a/drivers/crypto/nx/nx-842-powernv.c
+++ b/drivers/crypto/nx/nx-842-powernv.c
@@ -54,7 +54,11 @@ struct nx842_coproc {
 
 /* no cpu hotplug on powernv, so this list never changes after init */
 static LIST_HEAD(nx842_coprocs);
-static unsigned int nx842_ct;
+static unsigned int nx842_ct;  /* used in icswx function */
+
+static int (*nx842_powernv_exec)(const unsigned char *in,
+   unsigned int inlen, unsigned char *out,
+   unsigned int *outlenp, void *workmem, int fc);
 
 /**
  * setup_indirect_dde - Setup an indirect DDE
@@ -355,7 +359,7 @@ static int wait_for_csb(struct nx842_workmem *wmem,
 }
 
 /**
- * nx842_powernv_function - compress/decompress data using the 842 algorithm
+ * nx842_exec_icswx - compress/decompress data using the 842 algorithm
  *
  * (De)compression provided by the NX842 coprocessor on IBM PowerNV systems.
  * This compresses or decompresses the provided input buffer into the provided
@@ -385,7 +389,7 @@ static int wait_for_csb(struct nx842_workmem *wmem,
  *   -ETIMEDOUThardware did not complete operation in reasonable time
  *   -EINTRoperation was aborted
  */
-static int nx842_powernv_function(const unsigned char *in, unsigned int inlen,
+static int nx842_exec_icswx(const unsigned char *in, unsigned int inlen,
  unsigned char *out, unsigned int *outlenp,
  void *workmem, int fc)
 {
@@ -489,13 +493,13 @@ static int nx842_powernv_function(const unsigned char 
*in, unsigned int inlen,
  * @workmem: working memory buffer pointer, size determined by
  *   nx842_powernv_driver.workmem_size
  *
- * Returns: see @nx842_powernv_function()
+ * Returns: see @nx842_powernv_exec()
  */
 static int nx842_powernv_compress(const unsigned char *in, unsigned int inlen,
  unsigned char *out, unsigned int *outlenp,
  void *wmem)
 {
-   return nx842_powernv_function(in, inlen, out, outlenp,
+   return nx842_powernv_exec(in, inlen, out, outlenp,
  wmem, CCW_FC_842_COMP_CRC);
 }
 
@@ -517,13 +521,13 @@ static int nx842_powernv_compress(const unsigned char 
*in, unsigned int inlen,
  * @workmem: working memory buffer pointer, size determined by
  *   nx842_powernv_driver.workmem_size
  *
- * Returns: see @nx842_powernv_function()
+ * Returns: see @nx842_powernv_exec()
  */
 static int nx842_powernv_decompress(const unsigned char *in, unsigned int 
inlen,
unsigned char *out, unsigned int *outlenp,
void *wmem)
 {
-   return nx842_powernv_function(in, inlen, out, outlenp,
+   return nx842_powernv_exec(in, inlen, out, outlenp,
  wmem, CCW_FC_842_DECOMP_CRC);
 }
 
@@ -625,6 +629,8 @@ static __init int nx842_powernv_init(void)
if (!nx842_ct)
return -ENODEV;
 
+   nx842_powernv_exec = nx842_exec_icswx;
+
ret = crypto_register_alg(_powernv_alg);
if (ret) {
struct nx842_coproc *coproc, *n;
-- 
2.11.0

[PATCH V2 0/6] Enable NX 842 compression engine on Power9

[Haren Myneni]

[PATCH V2 0/6] Enable NX 842 compression engine on Power9

P9 introduces Virtual Accelerator Switchboard (VAS) to communicate
with NX 842 engine. icswx function is used to access NX before.
On powerNV systems, NX-842 driver invokes VAS functions for
configuring RxFIFO (receive window) per each NX engine. VAS uses
this FIFO to communicate the request to NX. The kernel opens send
window which is used to transfer compression/decompression requests
to VAS. It maps the send window to the corresponding RxFIFO.
copy/paste instructions are used to pass the CRB to VAS.

This patch series adds P9 NX support for 842 compression engine.
First 4 patches reorganize the current code so that VAS function
can be added.
- nx842_powernv_function points to VAS function if VAS feature is
  available. Otherwise icswx function is used.
- Move configure CRB code nx842_cfg_crb() 
- In addition to freeing co-processor structs for initialization 
  failures and exit, both send and receive windows have to closed
  for VAS.
- Move updating coprocessor info list to nx842_add_coprocs_list().

The last 2 patches adds configuring and invoking VAS, and also
checking P9 NX specific errors that are provided in co-processor
status block (CSB) for failures.

Patches have been tested on P9 DD1 system using VAS changes and
on P8 HW to make sure no regression.

This patchset depends on VAS kernel changes:
https://lists.ozlabs.org/pipermail/linuxppc-dev/2017-May/158178.html

Thanks to Sukadev Bhattiprolu for his review, input and testing with
VAS changes. Also thanks to Michael Ellerman and Benjamin Herrenschmidt
for their valuable guidance and comments.

Changelog[v2]
- Open/close send windows in nx842_poernv_crypto_init/exit_vas().
- Changes for the new device-tree NX properties such as priority
  and compatible properties.
- Incorporate review comments from Michael Ellerman.
- Other minor issues found during HW testing.

Haren Myneni (6):
  crypto/nx842: Rename nx842_powernv_function as icswx function
  crypto/nx: Create nx842_configure_crb function
  crypto/nx: Create nx842_delete_coprocs function
  crypto/nx: Add nx842_add_coprocs_list function
  crypto/nx: Add P9 NX specific error codes for 842 engine
  crypto/nx: Add P9 NX support for 842 compression engine.

 arch/powerpc/include/asm/icswx.h   |   3 +
 drivers/crypto/nx/Kconfig  |   1 +
 drivers/crypto/nx/nx-842-powernv.c | 499 +
 drivers/crypto/nx/nx-842.c |   2 +-
 drivers/crypto/nx/nx-842.h |   8 +
 5 files changed, 465 insertions(+), 48 deletions(-)

-- 
2.11.0

Re: [PATCH] crypto: ccp - Fix XTS-AES support on a version 5 CCP

[Tom Lendacky]

On 7/17/2017 3:08 PM, Gary R Hook wrote:

Version 5 CCPs have differing requirements for XTS-AES: key components
are stored in a 512-bit vector. The context must be little-endian
justified. AES-256 is supported now, so propagate the cipher size to
the command descriptor.

Signed-off-by: Gary R Hook 
---
  drivers/crypto/ccp/ccp-crypto-aes-xts.c |   79 ---
  drivers/crypto/ccp/ccp-dev-v5.c |2 +
  drivers/crypto/ccp/ccp-dev.h|2 +
  drivers/crypto/ccp/ccp-ops.c|   56 ++
  4 files changed, 89 insertions(+), 50 deletions(-)

diff --git a/drivers/crypto/ccp/ccp-crypto-aes-xts.c 
b/drivers/crypto/ccp/ccp-crypto-aes-xts.c
index 58a4244b4752..8d248b198e22 100644
--- a/drivers/crypto/ccp/ccp-crypto-aes-xts.c
+++ b/drivers/crypto/ccp/ccp-crypto-aes-xts.c
@@ -1,7 +1,7 @@
  /*
   * AMD Cryptographic Coprocessor (CCP) AES XTS crypto API support
   *
- * Copyright (C) 2013 Advanced Micro Devices, Inc.
+ * Copyright (C) 2013,2017 Advanced Micro Devices, Inc.
   *
   * Author: Tom Lendacky 
   *
@@ -37,46 +37,26 @@ struct ccp_unit_size_map {
u32 value;
  };
  
-static struct ccp_unit_size_map unit_size_map[] = {

+static struct ccp_unit_size_map xts_unit_sizes[] = {
{
-   .size   = 4096,
-   .value  = CCP_XTS_AES_UNIT_SIZE_4096,
-   },
-   {
-   .size   = 2048,
-   .value  = CCP_XTS_AES_UNIT_SIZE_2048,
-   },
-   {
-   .size   = 1024,
-   .value  = CCP_XTS_AES_UNIT_SIZE_1024,
+   .size   = 16,
+   .value  = CCP_XTS_AES_UNIT_SIZE_16,
},
{
-   .size   = 512,
+   .size   = 512,
.value  = CCP_XTS_AES_UNIT_SIZE_512,
},
{
-   .size   = 256,
-   .value  = CCP_XTS_AES_UNIT_SIZE__LAST,
-   },
-   {
-   .size   = 128,
-   .value  = CCP_XTS_AES_UNIT_SIZE__LAST,
-   },
-   {
-   .size   = 64,
-   .value  = CCP_XTS_AES_UNIT_SIZE__LAST,
-   },
-   {
-   .size   = 32,
-   .value  = CCP_XTS_AES_UNIT_SIZE__LAST,
+   .size   = 1024,
+   .value  = CCP_XTS_AES_UNIT_SIZE_1024,
},
{
-   .size   = 16,
-   .value  = CCP_XTS_AES_UNIT_SIZE_16,
+   .size   = 2048,
+   .value  = CCP_XTS_AES_UNIT_SIZE_2048,
},
{
-   .size   = 1,
-   .value  = CCP_XTS_AES_UNIT_SIZE__LAST,
+   .size   = 4096,
+   .value  = CCP_XTS_AES_UNIT_SIZE_4096,
},
  };


Because of the way the unit size check is performed, you can't delete
the intermediate size checks.  Those must remain so that unit sizes
that aren't supported by the CCP are sent to the fallback mechanism.

Also, re-arranging the order should be a separate patch if that doesn't
really fix anything.

  
@@ -97,14 +77,20 @@ static int ccp_aes_xts_setkey(struct crypto_ablkcipher *tfm, const u8 *key,

  unsigned int key_len)
  {
struct ccp_ctx *ctx = crypto_tfm_ctx(crypto_ablkcipher_tfm(tfm));
+   unsigned int ccpversion = ccp_version();
  
  	/* Only support 128-bit AES key with a 128-bit Tweak key,

 * otherwise use the fallback
 */
+


Remove the addition of the blank line and update the above comment to
indicate the new supported key size added below.


switch (key_len) {
case AES_KEYSIZE_128 * 2:
memcpy(ctx->u.aes.key, key, key_len);
break;
+   case AES_KEYSIZE_256 * 2:
+   if (ccpversion > CCP_VERSION(3, 0))
+   memcpy(ctx->u.aes.key, key, key_len);
+   break;


Isn't u.aes.key defined with a maximum buffer size of AES_MAX_KEY_SIZE
(which is 32)?  I think this will cause a buffer overrun on memcpy.


}
ctx->u.aes.key_len = key_len / 2;
sg_init_one(>u.aes.key_sg, ctx->u.aes.key, key_len);
@@ -117,7 +103,10 @@ static int ccp_aes_xts_crypt(struct ablkcipher_request 
*req,
  {
struct ccp_ctx *ctx = crypto_tfm_ctx(req->base.tfm);
struct ccp_aes_req_ctx *rctx = ablkcipher_request_ctx(req);
+   unsigned int ccpversion = ccp_version();
+   unsigned int fallback = 0;
unsigned int unit;
+   u32 block_size = 0;
u32 unit_size;
int ret;
  
@@ -131,17 +120,29 @@ static int ccp_aes_xts_crypt(struct ablkcipher_request *req,

return -EINVAL;
  
  	unit_size = CCP_XTS_AES_UNIT_SIZE__LAST;

-   if (req->nbytes <= unit_size_map[0].size) {


This check can't be deleted.  It was added specifically to catch cases
where the size was greater than 4096.


-   for (unit = 0; unit < ARRAY_SIZE(unit_size_map); unit++) {
-   if (!(req->nbytes & 

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

[Martin Kaiser]

Hi,

I'd like to pick this up and get the rngc driver merged finally.

Thus wrote Rob Herring (r...@kernel.org):

> The MXC name is still not dead?

looks like no. There's still CONFIG_ARCH_MXC etc. The other similar rng
driver is called mxc-rnga.c so it makes sense to use mxc-rngc.

> >  1 file changed, 16 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/rng/mxc_rngc.txt

> > diff --git a/Documentation/devicetree/bindings/rng/mxc_rngc.txt 
> > b/Documentation/devicetree/bindings/rng/mxc_rngc.txt
> > new file mode 100644
> > index ..e147a6dde40a
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/rng/mxc_rngc.txt
> > @@ -0,0 +1,16 @@
> > +Freescale RNGC (Random Number Generator Version C)
> > +
> > +Required properties:
> > +- compatible : Should be "fsl,imx25-rng"

> What about i.MX3/5 compatible strings?

I couldn't find an imx5 chip that has this rng. I added a compatible
string for imx35.

Best regards,

   Martin

Re: [PATCH v2 3/3] hwrng: mxc-fsl - add support for Freescale RNGC

[Martin Kaiser]

Dear all,

looking for a Freescale RNGB/C driver, I came across this old mail
thread. It seems the review got stuck and the driver was never merged.
This mail is the latest conversation I could find.

I would like to pick up this work and prepare the RNGC driver for
merging into the mailine kernel.

Thus wrote Vladimir Zapolskiy (vladimir_zapols...@mentor.com):

> > +#define RNGC_VERID_VERSION_MAJOR_MASK  0xff00
> > +#define RNGC_VERID_VERSION_MAJOR_SHIFT 8
> > +#define RNGC_VERID_VERSION_MINOR_MASK  0x00ff
> > +#define RNGC_VERID_VERSION_MINOR_SHIFT 0

> All RNGC_VERID_* are not used. And actually quite many other
> defined values are not used, e.g. all *_ZEROS_MASK etc.

I removed unused defines.

> > +   struct mxc_rngc *rngc = (struct mxc_rngc *)priv;
> > +   int handled = IRQ_NONE;
> > +
> > +   /* is the seed creation done? */
> > +   if (__raw_readl(rngc->base + RNGC_STATUS) & RNGC_STATUS_SEED_DONE) {
> > +   complete(>rng_seed_done);
> > +   __raw_writel(RNGC_CMD_CLR_INT | RNGC_CMD_CLR_ERR,
> > +rngc->base + RNGC_COMMAND);
> > +   handled = IRQ_HANDLED;
> > +   }
> > +
> > +   /* is the self test done? */
> > +   if (__raw_readl(rngc->base + RNGC_STATUS) & RNGC_STATUS_ST_DONE) {
> > +   complete(>rng_self_testing);
> > +   __raw_writel(RNGC_CMD_CLR_INT | RNGC_CMD_CLR_ERR,
> > +rngc->base + RNGC_COMMAND);
> > +   handled = IRQ_HANDLED;
> > +   }
> > +
> > +   /* is there any error? */
> > +   if (__raw_readl(rngc->base + RNGC_STATUS) & RNGC_STATUS_ERROR) {
> > +   /* clear interrupt */
> > +   __raw_writel(RNGC_CMD_CLR_INT | RNGC_CMD_CLR_ERR,
> > +rngc->base + RNGC_COMMAND);
> > +   handled = IRQ_HANDLED;

> For the code errors seem to be harmless, is it so? Does it make
> sense to inform a user about errors?

Either one of the completions is triggered or we time out when we wait
on a wait queue, see below. In any case, we read the error register and
abort the operation if there's an error.

> > +   wait_for_completion(>rng_self_testing);

> I would suggest to use wait_for_completion_timeout().

I fixed this.

> > +
> > +   } while (__raw_readl(rngc->base + RNGC_ERROR) &
> > +RNGC_ERROR_STATUS_ST_ERR);

> Logic of running a self test until error condition is gone looks strange.

Agreed. I don't see why the self test should fail in the first run and
complete successfully when we retry without a reset. I changed the code
to run the self test only once.

> > +
> > +   /* clear interrupt. Is it really necessary here? */
> > +   __raw_writel(RNGC_CMD_CLR_INT | RNGC_CMD_CLR_ERR,
> > +rngc->base + RNGC_COMMAND);

> Answering the question above I believe it is not needed here.

True. The irq handler clears the error status and interrupt bits.

> > +   wait_for_completion(>rng_seed_done);

> I would suggest to use wait_for_completion_timeout().

Done.

> > +
> > +   } while (__raw_readl(rngc->base + RNGC_ERROR) &
> > +RNGC_ERROR_STATUS_STAT_ERR);

> Any chance to loop forever?

I exit the loop now for all errors except the "statistical error". This
+ the timeout on the wait queue should prevent us from looping forever.

> > +   if (ret) {
> > +   dev_err(rngc->dev, "Can't get interrupt working.\n");
> > +   return -EIO;

> Leaked enabled rngc->clk clock on error path.

I restructured the probe function such that the clock is disabled when
there's an error after it was enabled.


Best regards,

   Martin

Re: [PATCH v2 2/3] ARM: i.MX25: add RNGC node to dtsi

[Martin Kaiser]

Dear all,

I'd like to pick this up and get the rgnc driver merged.

Thus wrote Shawn Guo (shawn...@kernel.org):

> > +   rng: rng@53fb {
> > +   compatible = "fsl,imx25-rng";
> > +   reg = <0x53fb 0x4000>;
> > +   clocks = < 109>;
> > +   clock-names = "ipg";

> I think clock-names can be dropped too.

done. I'll upload a new version shortly.

Best regards,
Martin

[PATCH v3 2/3] ARM: i.MX25: add RNGC node to dtsi

[Martin Kaiser]

From: Steffen Trumtrar 

Add a devicetree entry for the Random Number Generator Version C (RNGC).

Signed-off-by: Steffen Trumtrar 
Signed-off-by: Martin Kaiser 
---
Changes in v3:
  - remove clock-names from dtsi

Changes in v2:
  - remove interrupt-names from dtsi

 arch/arm/boot/dts/imx25.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/imx25.dtsi b/arch/arm/boot/dts/imx25.dtsi
index dfcc8e0..0d2f3a1 100644
--- a/arch/arm/boot/dts/imx25.dtsi
+++ b/arch/arm/boot/dts/imx25.dtsi
@@ -451,6 +451,13 @@
interrupt-names = "scm", "smn";
};
 
+   rng: rng@53fb {
+   compatible = "fsl,imx25-rng";
+   reg = <0x53fb 0x4000>;
+   clocks = < 109>;
+   interrupts = <22>;
+   };
+
esdhc1: esdhc@53fb4000 {
compatible = "fsl,imx25-esdhc";
reg = <0x53fb4000 0x4000>;
-- 
2.1.4

[PATCH 3/3] hwrng: mxc-fsl - add support for Freescale RNGC

[Martin Kaiser]

From: Steffen Trumtrar 

The driver is ported from Freescales Linux git and can be
found in the

vendor/freescale/imx_2.6.35_maintain

branch.

According to that code, the RNGC is found on Freescales i.MX3/5 SoCs.
The i.MX2x actually has an RNGB, which has no driver implementation
in Freescales kernel. However as it turns out, the driver for the RNGC
works fine on the (at least) i.MX25. So, they seem to be somewhat
compatible.

Signed-off-by: Steffen Trumtrar 
Signed-off-by: Martin Kaiser 
---
Changes in v3:
   - use pdev->dev to request the irq, rngc->dev is not yet initialized
   - remove unused defines for registers and fields
   - use module_platform_driver_probe()
   - clean up the error handling in the probe function,
 disable the clock if necessary
   - self-test must succeed in the first run
   - check for errors after seeding, exit for errors unrelated to
 statistics
   - set a timeout when waiting for a completion

Changes in v2:
  - remove irq variable from private struct
  - move devm_request_irq from mxc_rngc_init to probe
  - return irq in case of error
  - handle irq 0 as error

 drivers/char/hw_random/Kconfig|  13 ++
 drivers/char/hw_random/Makefile   |   1 +
 drivers/char/hw_random/mxc-rngc.c | 351 ++
 3 files changed, 365 insertions(+)
 create mode 100644 drivers/char/hw_random/mxc-rngc.c

diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
index 1b223c3..ef057b7 100644
--- a/drivers/char/hw_random/Kconfig
+++ b/drivers/char/hw_random/Kconfig
@@ -255,6 +255,19 @@ config HW_RANDOM_MXC_RNGA
 
  If unsure, say Y.
 
+config HW_RANDOM_MXC_RNGC
+   tristate "Freescale i.MX RNGC Random Number Generator"
+   depends on ARCH_MXC
+   default HW_RANDOM
+   ---help---
+ This driver provides kernel-side support for the Random Number
+ Generator hardware found on some Freescale i.MX processors.
+
+ To compile this driver as a module, choose M here: the
+ module will be called mxc-rngc.
+
+ If unsure, say Y.
+
 config HW_RANDOM_NOMADIK
tristate "ST-Ericsson Nomadik Random Number Generator support"
depends on ARCH_NOMADIK
diff --git a/drivers/char/hw_random/Makefile b/drivers/char/hw_random/Makefile
index b085975..043b71d 100644
--- a/drivers/char/hw_random/Makefile
+++ b/drivers/char/hw_random/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_HW_RANDOM_PASEMI) += pasemi-rng.o
 obj-$(CONFIG_HW_RANDOM_VIRTIO) += virtio-rng.o
 obj-$(CONFIG_HW_RANDOM_TX4939) += tx4939-rng.o
 obj-$(CONFIG_HW_RANDOM_MXC_RNGA) += mxc-rnga.o
+obj-$(CONFIG_HW_RANDOM_MXC_RNGC) += mxc-rngc.o
 obj-$(CONFIG_HW_RANDOM_OCTEON) += octeon-rng.o
 obj-$(CONFIG_HW_RANDOM_NOMADIK) += nomadik-rng.o
 obj-$(CONFIG_HW_RANDOM_PSERIES) += pseries-rng.o
diff --git a/drivers/char/hw_random/mxc-rngc.c 
b/drivers/char/hw_random/mxc-rngc.c
new file mode 100644
index 000..56175b1
--- /dev/null
+++ b/drivers/char/hw_random/mxc-rngc.c
@@ -0,0 +1,351 @@
+/*
+ * RNG driver for Freescale RNGC
+ *
+ * Copyright (C) 2008-2012 Freescale Semiconductor, Inc.
+ */
+
+/*
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+/*
+ * Hardware driver for the Intel/AMD/VIA Random Number Generators (RNG)
+ * (c) Copyright 2003 Red Hat Inc 
+ *
+ * derived from
+ *
+ * Hardware driver for the AMD 768 Random Number Generator (RNG)
+ * (c) Copyright 2001 Red Hat Inc 
+ *
+ * derived from
+ *
+ * Hardware driver for Intel i810 Random Number Generator (RNG)
+ * Copyright 2000,2001 Jeff Garzik 
+ * Copyright 2000,2001 Philipp Rumpf 
+ *
+ * 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 
+
+#define RNGC_COMMAND   0x0004
+#define RNGC_CONTROL   0x0008
+#define RNGC_STATUS0x000C
+#define RNGC_ERROR 0x0010
+#define RNGC_FIFO  0x0014
+#define RNGC_VERIF_CTRL0x0020
+#define RNGC_OSC_CTRL_COUNT0x0028
+#define RNGC_OSC_COUNT 0x002C
+#define RNGC_OSC_COUNT_STATUS  0x0030
+
+#define RNGC_CMD_CLR_ERR   0x0020
+#define RNGC_CMD_CLR_INT   0x0010
+#define RNGC_CMD_SEED  0x0002
+#define RNGC_CMD_SELF_TEST 0x0001
+
+#define 

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

[Martin Kaiser]

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 
---
Changes in v3:
  - add compatible string for imx35
  - remove imx5 from the commit message,
I couldn't find an i.MX5 soc that has an RNGC

Changes in v2:
  none

 Documentation/devicetree/bindings/rng/mxc_rngc.txt | 16 
 1 file changed, 16 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/rng/mxc_rngc.txt

diff --git a/Documentation/devicetree/bindings/rng/mxc_rngc.txt 
b/Documentation/devicetree/bindings/rng/mxc_rngc.txt
new file mode 100644
index 000..5a12ada
--- /dev/null
+++ b/Documentation/devicetree/bindings/rng/mxc_rngc.txt
@@ -0,0 +1,16 @@
+Freescale RNGC (Random Number Generator Version C)
+
+Required properties:
+- compatible : Should be "fsl,imx25-rng" or "fsl,imx35-rng"
+- reg : Offset and length of the register set of this block
+- interrupts : the interrupt number for the RNG block
+- clocks: should contain the RNG clk source
+
+Example:
+
+rng@53fb {
+   compatible = "fsl,imx25-rng";
+   reg = <0x53fb 0x4000>;
+   interrupts = <22>;
+   clocks = <_clk>;
+};
-- 
2.1.4

[PATCH 4/4] csrypto: ccp - Expand RSA support for a v5 ccp

[Gary R Hook]

A version 5 CCP can handle an RSA modulus up to 16k bits.

Signed-off-by: Gary R Hook 
---
 drivers/crypto/ccp/ccp-crypto-rsa.c |5 -
 drivers/crypto/ccp/ccp-crypto.h |1 +
 drivers/crypto/ccp/ccp-dev-v3.c |1 +
 drivers/crypto/ccp/ccp-dev-v5.c |2 ++
 drivers/crypto/ccp/ccp-dev.h|1 +
 drivers/crypto/ccp/ccp-ops.c|3 ++-
 drivers/crypto/ccp/sp-dev.h |1 +
 7 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/crypto/ccp/ccp-crypto-rsa.c 
b/drivers/crypto/ccp/ccp-crypto-rsa.c
index d5544943f5f0..e6db8672d89c 100644
--- a/drivers/crypto/ccp/ccp-crypto-rsa.c
+++ b/drivers/crypto/ccp/ccp-crypto-rsa.c
@@ -60,7 +60,10 @@ static int ccp_rsa_complete(struct crypto_async_request 
*async_req, int ret)
 
 static unsigned int ccp_rsa_maxsize(struct crypto_akcipher *tfm)
 {
-   return CCP_RSA_MAXMOD;
+   if (ccp_version() > CCP_VERSION(3, 0))
+   return CCP5_RSA_MAXMOD;
+   else
+   return CCP_RSA_MAXMOD;
 }
 
 static int ccp_rsa_crypt(struct akcipher_request *req, bool encrypt)
diff --git a/drivers/crypto/ccp/ccp-crypto.h b/drivers/crypto/ccp/ccp-crypto.h
index aa53b97f6f00..67c7620029e3 100644
--- a/drivers/crypto/ccp/ccp-crypto.h
+++ b/drivers/crypto/ccp/ccp-crypto.h
@@ -255,6 +255,7 @@ struct ccp_rsa_req_ctx {
 };
 
 #defineCCP_RSA_MAXMOD  (4 * 1024 / 8)
+#defineCCP5_RSA_MAXMOD (16 * 1024 / 8)
 
 /* Common Context Structure */
 struct ccp_ctx {
diff --git a/drivers/crypto/ccp/ccp-dev-v3.c b/drivers/crypto/ccp/ccp-dev-v3.c
index c2861749e2ad..240bebbcb8ac 100644
--- a/drivers/crypto/ccp/ccp-dev-v3.c
+++ b/drivers/crypto/ccp/ccp-dev-v3.c
@@ -597,4 +597,5 @@ const struct ccp_vdata ccpv3 = {
.setup = NULL,
.perform = _actions,
.offset = 0x2,
+   .rsamax = CCP_RSA_MAX_WIDTH,
 };
diff --git a/drivers/crypto/ccp/ccp-dev-v5.c b/drivers/crypto/ccp/ccp-dev-v5.c
index b77ac0a638d5..3f574d50c0f8 100644
--- a/drivers/crypto/ccp/ccp-dev-v5.c
+++ b/drivers/crypto/ccp/ccp-dev-v5.c
@@ -1114,6 +1114,7 @@ const struct ccp_vdata ccpv5a = {
.setup = ccp5_config,
.perform = _actions,
.offset = 0x0,
+   .rsamax = CCP5_RSA_MAX_WIDTH,
 };
 
 const struct ccp_vdata ccpv5b = {
@@ -1122,4 +1123,5 @@ const struct ccp_vdata ccpv5b = {
.setup = ccp5other_config,
.perform = _actions,
.offset = 0x0,
+   .rsamax = CCP5_RSA_MAX_WIDTH,
 };
diff --git a/drivers/crypto/ccp/ccp-dev.h b/drivers/crypto/ccp/ccp-dev.h
index 3d51180199ac..6810b65c1939 100644
--- a/drivers/crypto/ccp/ccp-dev.h
+++ b/drivers/crypto/ccp/ccp-dev.h
@@ -203,6 +203,7 @@
 #define CCP_SHA_SB_COUNT   1
 
 #define CCP_RSA_MAX_WIDTH  4096
+#define CCP5_RSA_MAX_WIDTH 16384
 
 #define CCP_PASSTHRU_BLOCKSIZE 256
 #define CCP_PASSTHRU_MASKSIZE  32
diff --git a/drivers/crypto/ccp/ccp-ops.c b/drivers/crypto/ccp/ccp-ops.c
index 72c0f938abd7..c269f41e0526 100644
--- a/drivers/crypto/ccp/ccp-ops.c
+++ b/drivers/crypto/ccp/ccp-ops.c
@@ -1770,7 +1770,8 @@ static int ccp_run_rsa_cmd(struct ccp_cmd_queue *cmd_q, 
struct ccp_cmd *cmd)
unsigned int sb_count, i_len, o_len;
int ret;
 
-   if (rsa->key_size > CCP_RSA_MAX_WIDTH)
+   /* Check against the maximum allowable size, in bits */
+   if (rsa->key_size > cmd_q->ccp->vdata->rsamax)
return -EINVAL;
 
if (!rsa->exp || !rsa->mod || !rsa->src || !rsa->dst)
diff --git a/drivers/crypto/ccp/sp-dev.h b/drivers/crypto/ccp/sp-dev.h
index 3520da4e20cf..5ab486ade1ad 100644
--- a/drivers/crypto/ccp/sp-dev.h
+++ b/drivers/crypto/ccp/sp-dev.h
@@ -40,6 +40,7 @@ struct ccp_vdata {
void (*setup)(struct ccp_device *);
const struct ccp_actions *perform;
const unsigned int offset;
+   const unsigned int rsamax;
 };
 /* Structure to hold SP device data */
 struct sp_dev_vdata {

[PATCH 3/4] crypto: ccp - Add support for RSA on the CCP

[Gary R Hook]

Wire up the CCP as an RSA cipher provider.

Signed-off-by: Gary R Hook 
---
 drivers/crypto/ccp/Makefile  |1 
 drivers/crypto/ccp/ccp-crypto-main.c |   19 ++
 drivers/crypto/ccp/ccp-crypto-rsa.c  |  296 ++
 drivers/crypto/ccp/ccp-crypto.h  |   31 
 4 files changed, 347 insertions(+)
 create mode 100644 drivers/crypto/ccp/ccp-crypto-rsa.c

diff --git a/drivers/crypto/ccp/Makefile b/drivers/crypto/ccp/Makefile
index 5f2adc5facfe..57f8debfcfb3 100644
--- a/drivers/crypto/ccp/Makefile
+++ b/drivers/crypto/ccp/Makefile
@@ -15,4 +15,5 @@ ccp-crypto-objs := ccp-crypto-main.o \
   ccp-crypto-aes-xts.o \
   ccp-crypto-aes-galois.o \
   ccp-crypto-des3.o \
+  ccp-crypto-rsa.o \
   ccp-crypto-sha.o
diff --git a/drivers/crypto/ccp/ccp-crypto-main.c 
b/drivers/crypto/ccp/ccp-crypto-main.c
index 78b9d26a381f..35a9de7fd475 100644
--- a/drivers/crypto/ccp/ccp-crypto-main.c
+++ b/drivers/crypto/ccp/ccp-crypto-main.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "ccp-crypto.h"
 
@@ -37,10 +38,15 @@ static unsigned int des3_disable;
 module_param(des3_disable, uint, 0444);
 MODULE_PARM_DESC(des3_disable, "Disable use of 3DES - any non-zero value");
 
+static unsigned int rsa_disable;
+module_param(rsa_disable, uint, 0444);
+MODULE_PARM_DESC(rsa_disable, "Disable use of RSA - any non-zero value");
+
 /* List heads for the supported algorithms */
 static LIST_HEAD(hash_algs);
 static LIST_HEAD(cipher_algs);
 static LIST_HEAD(aead_algs);
+static LIST_HEAD(akcipher_algs);
 
 /* For any tfm, requests for that tfm must be returned on the order
  * received.  With multiple queues available, the CCP can process more
@@ -358,6 +364,12 @@ static int ccp_register_algs(void)
return ret;
}
 
+   if (!rsa_disable) {
+   ret = ccp_register_rsa_algs(_algs);
+   if (ret)
+   return ret;
+   }
+
return 0;
 }
 
@@ -366,6 +378,7 @@ static void ccp_unregister_algs(void)
struct ccp_crypto_ahash_alg *ahash_alg, *ahash_tmp;
struct ccp_crypto_ablkcipher_alg *ablk_alg, *ablk_tmp;
struct ccp_crypto_aead *aead_alg, *aead_tmp;
+   struct ccp_crypto_akcipher_alg *akc_alg, *akc_tmp;
 
list_for_each_entry_safe(ahash_alg, ahash_tmp, _algs, entry) {
crypto_unregister_ahash(_alg->alg);
@@ -384,6 +397,12 @@ static void ccp_unregister_algs(void)
list_del(_alg->entry);
kfree(aead_alg);
}
+
+   list_for_each_entry_safe(akc_alg, akc_tmp, _algs, entry) {
+   crypto_unregister_akcipher(_alg->alg);
+   list_del(_alg->entry);
+   kfree(akc_alg);
+   }
 }
 
 static int ccp_crypto_init(void)
diff --git a/drivers/crypto/ccp/ccp-crypto-rsa.c 
b/drivers/crypto/ccp/ccp-crypto-rsa.c
new file mode 100644
index ..d5544943f5f0
--- /dev/null
+++ b/drivers/crypto/ccp/ccp-crypto-rsa.c
@@ -0,0 +1,296 @@
+/*
+ * AMD Cryptographic Coprocessor (CCP) RSA crypto API support
+ *
+ * Copyright (C) 2017 Advanced Micro Devices, Inc.
+ *
+ * Author: Gary R Hook 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "ccp-crypto.h"
+
+static inline struct akcipher_request *akcipher_request_cast(
+   struct crypto_async_request *req)
+{
+   return container_of(req, struct akcipher_request, base);
+}
+
+static inline int ccp_copy_and_save_keypart(u8 **kpbuf, unsigned int *kplen,
+   const u8 *buf, size_t sz)
+{
+   int nskip;
+
+   for (nskip = 0; nskip < sz; nskip++)
+   if (buf[nskip])
+   break;
+   *kplen = sz - nskip;
+   *kpbuf = kzalloc(*kplen, GFP_KERNEL);
+   if (!*kpbuf)
+   return -ENOMEM;
+   memcpy(*kpbuf, buf + nskip, *kplen);
+
+   return 0;
+}
+
+static int ccp_rsa_complete(struct crypto_async_request *async_req, int ret)
+{
+   struct akcipher_request *req = akcipher_request_cast(async_req);
+   struct ccp_rsa_req_ctx *rctx = akcipher_request_ctx(req);
+
+   if (ret)
+   return ret;
+
+   req->dst_len = rctx->cmd.u.rsa.key_size >> 3;
+
+   return 0;
+}
+
+static unsigned int ccp_rsa_maxsize(struct crypto_akcipher *tfm)
+{
+   return CCP_RSA_MAXMOD;
+}
+
+static int ccp_rsa_crypt(struct akcipher_request *req, bool encrypt)
+{
+   struct crypto_akcipher *tfm = crypto_akcipher_reqtfm(req);
+   struct ccp_ctx *ctx = akcipher_tfm_ctx(tfm);
+   struct ccp_rsa_req_ctx *rctx = akcipher_request_ctx(req);
+   int ret = 0;
+
+   

[PATCH 1/4] crypto: ccp - Fix base RSA function for version 5 CCPs

[Gary R Hook]

Version 5 devices have requirements for buffer lengths, as well as
parameter format (e.g. bits vs. bytes). Fix the base CCP driver
code to meet requirements all supported versions.

Signed-off-by: Gary R Hook 
---
 drivers/crypto/ccp/ccp-dev-v5.c |   10 +++--
 drivers/crypto/ccp/ccp-ops.c|   78 +--
 2 files changed, 54 insertions(+), 34 deletions(-)

diff --git a/drivers/crypto/ccp/ccp-dev-v5.c b/drivers/crypto/ccp/ccp-dev-v5.c
index 11febe2bd07c..b77ac0a638d5 100644
--- a/drivers/crypto/ccp/ccp-dev-v5.c
+++ b/drivers/crypto/ccp/ccp-dev-v5.c
@@ -471,7 +471,7 @@ static int ccp5_perform_rsa(struct ccp_op *op)
CCP5_CMD_PROT() = 0;
 
function.raw = 0;
-   CCP_RSA_SIZE() = op->u.rsa.mod_size >> 3;
+   CCP_RSA_SIZE() = (op->u.rsa.mod_size + 7) >> 3;
CCP5_CMD_FUNCTION() = function.raw;
 
CCP5_CMD_LEN() = op->u.rsa.input_len;
@@ -486,10 +486,10 @@ static int ccp5_perform_rsa(struct ccp_op *op)
CCP5_CMD_DST_HI() = ccp_addr_hi(>dst.u.dma);
CCP5_CMD_DST_MEM() = CCP_MEMTYPE_SYSTEM;
 
-   /* Exponent is in LSB memory */
-   CCP5_CMD_KEY_LO() = op->sb_key * LSB_ITEM_SIZE;
-   CCP5_CMD_KEY_HI() = 0;
-   CCP5_CMD_KEY_MEM() = CCP_MEMTYPE_SB;
+   /* Key (Exponent) is in external memory */
+   CCP5_CMD_KEY_LO() = ccp_addr_lo(>exp.u.dma);
+   CCP5_CMD_KEY_HI() = ccp_addr_hi(>exp.u.dma);
+   CCP5_CMD_KEY_MEM() = CCP_MEMTYPE_SYSTEM;
 
return ccp5_do_cmd(, op->cmd_q);
 }
diff --git a/drivers/crypto/ccp/ccp-ops.c b/drivers/crypto/ccp/ccp-ops.c
index d1be07884a9b..72c0f938abd7 100644
--- a/drivers/crypto/ccp/ccp-ops.c
+++ b/drivers/crypto/ccp/ccp-ops.c
@@ -1765,8 +1765,7 @@ static int ccp_run_sha_cmd(struct ccp_cmd_queue *cmd_q, 
struct ccp_cmd *cmd)
 static int ccp_run_rsa_cmd(struct ccp_cmd_queue *cmd_q, struct ccp_cmd *cmd)
 {
struct ccp_rsa_engine *rsa = >u.rsa;
-   struct ccp_dm_workarea exp, src;
-   struct ccp_data dst;
+   struct ccp_dm_workarea exp, src, dst;
struct ccp_op op;
unsigned int sb_count, i_len, o_len;
int ret;
@@ -1777,30 +1776,40 @@ static int ccp_run_rsa_cmd(struct ccp_cmd_queue *cmd_q, 
struct ccp_cmd *cmd)
if (!rsa->exp || !rsa->mod || !rsa->src || !rsa->dst)
return -EINVAL;
 
+   memset(, 0, sizeof(op));
+   op.cmd_q = cmd_q;
+   op.jobid = CCP_NEW_JOBID(cmd_q->ccp);
+
/* The RSA modulus must precede the message being acted upon, so
 * it must be copied to a DMA area where the message and the
 * modulus can be concatenated.  Therefore the input buffer
 * length required is twice the output buffer length (which
-* must be a multiple of 256-bits).
+* must be a multiple of 256-bits).  Compute o_len, i_len in bytes.
+* Buffer sizes must be a multiple of 32 bytes; rounding up may be
+* required.
 */
-   o_len = ((rsa->key_size + 255) / 256) * 32;
+   o_len = 32 * ((rsa->key_size + 255) / 256);
i_len = o_len * 2;
 
-   sb_count = o_len / CCP_SB_BYTES;
-
-   memset(, 0, sizeof(op));
-   op.cmd_q = cmd_q;
-   op.jobid = CCP_NEW_JOBID(cmd_q->ccp);
-   op.sb_key = cmd_q->ccp->vdata->perform->sballoc(cmd_q, sb_count);
-
-   if (!op.sb_key)
-   return -EIO;
+   if (cmd_q->ccp->vdata->version < CCP_VERSION(5, 0)) {
+   /* sb_count is the number of storage block slots required
+* for the modulus.
+*/
+   sb_count = o_len / CCP_SB_BYTES;
+   op.sb_key = cmd_q->ccp->vdata->perform->sballoc(cmd_q,
+   sb_count);
+   if (!op.sb_key)
+   return -EIO;
+   } else {
+   /* A version 5 device allows a modulus size that will not fit
+* in the LSB, so the command will transfer it from memory.
+* Set the sb key to the default, even though it's not used.
+*/
+   op.sb_key = cmd_q->sb_key;
+   }
 
-   /* The RSA exponent may span multiple (32-byte) SB entries and must
-* be in little endian format. Reverse copy each 32-byte chunk
-* of the exponent (En chunk to E0 chunk, E(n-1) chunk to E1 chunk)
-* and each byte within that chunk and do not perform any byte swap
-* operations on the passthru operation.
+   /* The RSA exponent must be in little endian format. Reverse its
+* byte order.
 */
ret = ccp_init_dm_workarea(, cmd_q, o_len, DMA_TO_DEVICE);
if (ret)
@@ -1809,11 +1818,22 @@ static int ccp_run_rsa_cmd(struct ccp_cmd_queue *cmd_q, 
struct ccp_cmd *cmd)
ret = ccp_reverse_set_dm_area(, 0, rsa->exp, 0, rsa->exp_len);
if (ret)
goto e_exp;
-   ret = ccp_copy_to_sb(cmd_q, , op.jobid, op.sb_key,
-

[PATCH 2/4] crypto: Add akcipher_set_reqsize() function

[Gary R Hook]

Signed-off-by: Gary R Hook 
---
 0 files changed

diff --git a/include/crypto/internal/akcipher.h 
b/include/crypto/internal/akcipher.h
index 479a0078f0f7..805686ba2be4 100644
--- a/include/crypto/internal/akcipher.h
+++ b/include/crypto/internal/akcipher.h
@@ -38,6 +38,12 @@ static inline void *akcipher_request_ctx(struct 
akcipher_request *req)
return req->__ctx;
 }
 
+static inline void akcipher_set_reqsize(struct crypto_akcipher *akcipher,
+   unsigned int reqsize)
+{
+   crypto_akcipher_alg(akcipher)->reqsize = reqsize;
+}
+
 static inline void *akcipher_tfm_ctx(struct crypto_akcipher *tfm)
 {
return tfm->base.__crt_ctx;

[PATCH 0/4] Enable RSA Support on the CCP

[Gary R Hook]

This series accomplishes the following:

 - Fix RSA support in the base CCP driver
 - Add the akcipher_set_reqsize() function
 - Enable RSA support in the crypto layer
 - Allow for a larger RSA modulus in a version 5 CCP

---

Gary R Hook (4):
  crypto: ccp - Fix base RSA function for version 5 CCPs
  crypto: Add akcipher_set_reqsize() function
  crypto: ccp - Add support for RSA on the CCP
  csrypto: ccp - Expand RSA support for a v5 ccp


 drivers/crypto/ccp/Makefile  |1 
 drivers/crypto/ccp/ccp-crypto-main.c |   19 ++
 drivers/crypto/ccp/ccp-crypto-rsa.c  |  299 ++
 drivers/crypto/ccp/ccp-crypto.h  |   32 
 drivers/crypto/ccp/ccp-dev-v3.c  |1 
 drivers/crypto/ccp/ccp-dev-v5.c  |   12 +
 drivers/crypto/ccp/ccp-dev.h |1 
 drivers/crypto/ccp/ccp-ops.c |   81 ++---
 drivers/crypto/ccp/sp-dev.h  |1 
 9 files changed, 412 insertions(+), 35 deletions(-)
 create mode 100644 drivers/crypto/ccp/ccp-crypto-rsa.c

--

[PATCH] crypto: ccp - Fix XTS-AES support on a version 5 CCP

[Gary R Hook]

Version 5 CCPs have differing requirements for XTS-AES: key components
are stored in a 512-bit vector. The context must be little-endian
justified. AES-256 is supported now, so propagate the cipher size to
the command descriptor.

Signed-off-by: Gary R Hook 
---
 drivers/crypto/ccp/ccp-crypto-aes-xts.c |   79 ---
 drivers/crypto/ccp/ccp-dev-v5.c |2 +
 drivers/crypto/ccp/ccp-dev.h|2 +
 drivers/crypto/ccp/ccp-ops.c|   56 ++
 4 files changed, 89 insertions(+), 50 deletions(-)

diff --git a/drivers/crypto/ccp/ccp-crypto-aes-xts.c 
b/drivers/crypto/ccp/ccp-crypto-aes-xts.c
index 58a4244b4752..8d248b198e22 100644
--- a/drivers/crypto/ccp/ccp-crypto-aes-xts.c
+++ b/drivers/crypto/ccp/ccp-crypto-aes-xts.c
@@ -1,7 +1,7 @@
 /*
  * AMD Cryptographic Coprocessor (CCP) AES XTS crypto API support
  *
- * Copyright (C) 2013 Advanced Micro Devices, Inc.
+ * Copyright (C) 2013,2017 Advanced Micro Devices, Inc.
  *
  * Author: Tom Lendacky 
  *
@@ -37,46 +37,26 @@ struct ccp_unit_size_map {
u32 value;
 };
 
-static struct ccp_unit_size_map unit_size_map[] = {
+static struct ccp_unit_size_map xts_unit_sizes[] = {
{
-   .size   = 4096,
-   .value  = CCP_XTS_AES_UNIT_SIZE_4096,
-   },
-   {
-   .size   = 2048,
-   .value  = CCP_XTS_AES_UNIT_SIZE_2048,
-   },
-   {
-   .size   = 1024,
-   .value  = CCP_XTS_AES_UNIT_SIZE_1024,
+   .size   = 16,
+   .value  = CCP_XTS_AES_UNIT_SIZE_16,
},
{
-   .size   = 512,
+   .size   = 512,
.value  = CCP_XTS_AES_UNIT_SIZE_512,
},
{
-   .size   = 256,
-   .value  = CCP_XTS_AES_UNIT_SIZE__LAST,
-   },
-   {
-   .size   = 128,
-   .value  = CCP_XTS_AES_UNIT_SIZE__LAST,
-   },
-   {
-   .size   = 64,
-   .value  = CCP_XTS_AES_UNIT_SIZE__LAST,
-   },
-   {
-   .size   = 32,
-   .value  = CCP_XTS_AES_UNIT_SIZE__LAST,
+   .size   = 1024,
+   .value  = CCP_XTS_AES_UNIT_SIZE_1024,
},
{
-   .size   = 16,
-   .value  = CCP_XTS_AES_UNIT_SIZE_16,
+   .size   = 2048,
+   .value  = CCP_XTS_AES_UNIT_SIZE_2048,
},
{
-   .size   = 1,
-   .value  = CCP_XTS_AES_UNIT_SIZE__LAST,
+   .size   = 4096,
+   .value  = CCP_XTS_AES_UNIT_SIZE_4096,
},
 };
 
@@ -97,14 +77,20 @@ static int ccp_aes_xts_setkey(struct crypto_ablkcipher 
*tfm, const u8 *key,
  unsigned int key_len)
 {
struct ccp_ctx *ctx = crypto_tfm_ctx(crypto_ablkcipher_tfm(tfm));
+   unsigned int ccpversion = ccp_version();
 
/* Only support 128-bit AES key with a 128-bit Tweak key,
 * otherwise use the fallback
 */
+
switch (key_len) {
case AES_KEYSIZE_128 * 2:
memcpy(ctx->u.aes.key, key, key_len);
break;
+   case AES_KEYSIZE_256 * 2:
+   if (ccpversion > CCP_VERSION(3, 0))
+   memcpy(ctx->u.aes.key, key, key_len);
+   break;
}
ctx->u.aes.key_len = key_len / 2;
sg_init_one(>u.aes.key_sg, ctx->u.aes.key, key_len);
@@ -117,7 +103,10 @@ static int ccp_aes_xts_crypt(struct ablkcipher_request 
*req,
 {
struct ccp_ctx *ctx = crypto_tfm_ctx(req->base.tfm);
struct ccp_aes_req_ctx *rctx = ablkcipher_request_ctx(req);
+   unsigned int ccpversion = ccp_version();
+   unsigned int fallback = 0;
unsigned int unit;
+   u32 block_size = 0;
u32 unit_size;
int ret;
 
@@ -131,17 +120,29 @@ static int ccp_aes_xts_crypt(struct ablkcipher_request 
*req,
return -EINVAL;
 
unit_size = CCP_XTS_AES_UNIT_SIZE__LAST;
-   if (req->nbytes <= unit_size_map[0].size) {
-   for (unit = 0; unit < ARRAY_SIZE(unit_size_map); unit++) {
-   if (!(req->nbytes & (unit_size_map[unit].size - 1))) {
-   unit_size = unit_size_map[unit].value;
-   break;
-   }
+   for (unit = ARRAY_SIZE(xts_unit_sizes); unit-- > 0; ) {
+   if (!(req->nbytes & (xts_unit_sizes[unit].size - 1))) {
+   unit_size = unit;
+   block_size = xts_unit_sizes[unit].size;
+   break;
}
}
 
-   if ((unit_size == CCP_XTS_AES_UNIT_SIZE__LAST) ||
-   (ctx->u.aes.key_len != AES_KEYSIZE_128)) {
+   /* The CCP has restrictions on block sizes. Also, a version 3 device
+* only supports AES-128 operations; version 5 CCPs support both
+* AES-128 

[PATCH] crypto: ccp - Update copyright dates for 2017.

[Gary R Hook]

Some updates this year have not had copyright dates changed in modified
files. Correct this for 2017.

Signed-off-by: Gary R Hook 
---
 drivers/crypto/ccp/ccp-crypto-aes-galois.c |2 +-
 drivers/crypto/ccp/ccp-crypto-des3.c   |2 +-
 drivers/crypto/ccp/ccp-crypto-main.c   |2 +-
 drivers/crypto/ccp/ccp-crypto-sha.c|2 +-
 drivers/crypto/ccp/ccp-crypto.h|2 +-
 drivers/crypto/ccp/ccp-dev-v3.c|2 +-
 drivers/crypto/ccp/ccp-dev-v5.c|2 +-
 drivers/crypto/ccp/ccp-dev.c   |2 +-
 drivers/crypto/ccp/ccp-dev.h   |2 +-
 drivers/crypto/ccp/ccp-dmaengine.c |2 +-
 drivers/crypto/ccp/ccp-ops.c   |2 +-
 11 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/crypto/ccp/ccp-crypto-aes-galois.c 
b/drivers/crypto/ccp/ccp-crypto-aes-galois.c
index 38ee6f348ea9..52313524a4dd 100644
--- a/drivers/crypto/ccp/ccp-crypto-aes-galois.c
+++ b/drivers/crypto/ccp/ccp-crypto-aes-galois.c
@@ -1,7 +1,7 @@
 /*
  * AMD Cryptographic Coprocessor (CCP) AES GCM crypto API support
  *
- * Copyright (C) 2016 Advanced Micro Devices, Inc.
+ * Copyright (C) 2016,2017 Advanced Micro Devices, Inc.
  *
  * Author: Gary R Hook 
  *
diff --git a/drivers/crypto/ccp/ccp-crypto-des3.c 
b/drivers/crypto/ccp/ccp-crypto-des3.c
index 5af7347ae03c..ae87b741f9d5 100644
--- a/drivers/crypto/ccp/ccp-crypto-des3.c
+++ b/drivers/crypto/ccp/ccp-crypto-des3.c
@@ -1,7 +1,7 @@
 /*
  * AMD Cryptographic Coprocessor (CCP) DES3 crypto API support
  *
- * Copyright (C) 2016 Advanced Micro Devices, Inc.
+ * Copyright (C) 2016,2017 Advanced Micro Devices, Inc.
  *
  * Author: Gary R Hook 
  *
diff --git a/drivers/crypto/ccp/ccp-crypto-main.c 
b/drivers/crypto/ccp/ccp-crypto-main.c
index 8dccbddabef1..78b9d26a381f 100644
--- a/drivers/crypto/ccp/ccp-crypto-main.c
+++ b/drivers/crypto/ccp/ccp-crypto-main.c
@@ -1,7 +1,7 @@
 /*
  * AMD Cryptographic Coprocessor (CCP) crypto API support
  *
- * Copyright (C) 2013 Advanced Micro Devices, Inc.
+ * Copyright (C) 2013,2017 Advanced Micro Devices, Inc.
  *
  * Author: Tom Lendacky 
  *
diff --git a/drivers/crypto/ccp/ccp-crypto-sha.c 
b/drivers/crypto/ccp/ccp-crypto-sha.c
index ce97b3868f4a..8b9b16d433f7 100644
--- a/drivers/crypto/ccp/ccp-crypto-sha.c
+++ b/drivers/crypto/ccp/ccp-crypto-sha.c
@@ -1,7 +1,7 @@
 /*
  * AMD Cryptographic Coprocessor (CCP) SHA crypto API support
  *
- * Copyright (C) 2013,2016 Advanced Micro Devices, Inc.
+ * Copyright (C) 2013,2017 Advanced Micro Devices, Inc.
  *
  * Author: Tom Lendacky 
  * Author: Gary R Hook 
diff --git a/drivers/crypto/ccp/ccp-crypto.h b/drivers/crypto/ccp/ccp-crypto.h
index dd5bf15f06e5..156b8233853f 100644
--- a/drivers/crypto/ccp/ccp-crypto.h
+++ b/drivers/crypto/ccp/ccp-crypto.h
@@ -1,7 +1,7 @@
 /*
  * AMD Cryptographic Coprocessor (CCP) crypto API support
  *
- * Copyright (C) 2013 Advanced Micro Devices, Inc.
+ * Copyright (C) 2013,2017 Advanced Micro Devices, Inc.
  *
  * Author: Tom Lendacky 
  *
diff --git a/drivers/crypto/ccp/ccp-dev-v3.c b/drivers/crypto/ccp/ccp-dev-v3.c
index 695fde887c11..c2861749e2ad 100644
--- a/drivers/crypto/ccp/ccp-dev-v3.c
+++ b/drivers/crypto/ccp/ccp-dev-v3.c
@@ -1,7 +1,7 @@
 /*
  * AMD Cryptographic Coprocessor (CCP) driver
  *
- * Copyright (C) 2013,2016 Advanced Micro Devices, Inc.
+ * Copyright (C) 2013,2017 Advanced Micro Devices, Inc.
  *
  * Author: Tom Lendacky 
  * Author: Gary R Hook 
diff --git a/drivers/crypto/ccp/ccp-dev-v5.c b/drivers/crypto/ccp/ccp-dev-v5.c
index b0391f03b0fe..b3526336d608 100644
--- a/drivers/crypto/ccp/ccp-dev-v5.c
+++ b/drivers/crypto/ccp/ccp-dev-v5.c
@@ -1,7 +1,7 @@
 /*
  * AMD Cryptographic Coprocessor (CCP) driver
  *
- * Copyright (C) 2016 Advanced Micro Devices, Inc.
+ * Copyright (C) 2016,2017 Advanced Micro Devices, Inc.
  *
  * Author: Gary R Hook 
  *
diff --git a/drivers/crypto/ccp/ccp-dev.c b/drivers/crypto/ccp/ccp-dev.c
index b2d176164402..52eb3ed25a26 100644
--- a/drivers/crypto/ccp/ccp-dev.c
+++ b/drivers/crypto/ccp/ccp-dev.c
@@ -1,7 +1,7 @@
 /*
  * AMD Cryptographic Coprocessor (CCP) driver
  *
- * Copyright (C) 2013,2016 Advanced Micro Devices, Inc.
+ * Copyright (C) 2013,2017 Advanced Micro Devices, Inc.
  *
  * Author: Tom Lendacky 
  * Author: Gary R Hook 
diff --git a/drivers/crypto/ccp/ccp-dev.h b/drivers/crypto/ccp/ccp-dev.h
index b959e2402aa2..9320931d89da 100644
--- a/drivers/crypto/ccp/ccp-dev.h
+++ b/drivers/crypto/ccp/ccp-dev.h
@@ -1,7 +1,7 @@
 /*
  * AMD Cryptographic Coprocessor (CCP) driver
  *
- * Copyright (C) 2013,2016 Advanced Micro Devices, Inc.
+ * Copyright (C) 2013,2017 Advanced Micro Devices, Inc.
  *
  * Author: Tom Lendacky 
  * Author: Gary R 

Re: [PATCH 1/2] dt-bindings: Document STM32 HASH bindings

[Rob Herring]

On Thu, Jul 13, 2017 at 03:32:26PM +0200, Lionel Debieve wrote:
> This adds documentation of device tree bindings for the STM32
> HASH controller.
> 
> Signed-off-by: Lionel Debieve 
> ---
>  .../devicetree/bindings/crypto/st,stm32-hash.txt   | 30 
> ++
>  1 file changed, 30 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/crypto/st,stm32-hash.txt

Acked-by: Rob Herring 

Re: KPP questions and confusion

[Marcel Holtmann]

Hi Kyle,

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

> The context for this email is that I have need for the same basic
> functionality in net/bluetooth/ecdh_helper.c for a non-BT purpose, so
> it seems like this should be part of crypto/ecdh_helper.c (abstracted
> to work for any curve). Basically, I need to do basic ECDH key
> agreement:
> 
> * Generate a new (valid) ephemeral private key, or potentially re-use
> an existing one
> * Compute the corresponding public key for the curve
> * Compute the shared secret based on my private and peer's public
> 
> Is KPP intended to be an abstract interface to all of the above, e.g.,
> for both ECDH and FFDH? Right now it seems like layer violations are
> required as there doesn't appear to be any way to (for example)
> generate a fresh private key via kpp_*.

I think the whole goal is to abstract this. Mainly so that ECDH can also be 
offload to hardware.

Regards

Marcel

Re: [PATCH 6/6] fscrypt: for v2 policies, support "fscrypt:" key prefix only

[Michael Halcrow]

On Wed, Jul 12, 2017 at 02:00:35PM -0700, Eric Biggers wrote:
> From: Eric Biggers 
> 
> Since v2 encryption policies are opt-in, take the opportunity to also
> drop support for the legacy filesystem-specific key description prefixes
> "ext4:", "f2fs:", and "ubifs:", instead requiring the generic prefix
> "fscrypt:".  The generic prefix is preferred since it works for all
> filesystems.  Also there is a performance benefit from not having to
> search the keyrings twice.
> 
> The old prefixes remain supported for v1 encryption policies.
> 
> Signed-off-by: Eric Biggers 

Reviewed-by: Michael Halcrow 

> ---
>  fs/crypto/fscrypt_private.h |  3 +--
>  fs/crypto/keyinfo.c | 16 
>  fs/crypto/policy.c  |  2 +-
>  3 files changed, 6 insertions(+), 15 deletions(-)
> 
> diff --git a/fs/crypto/fscrypt_private.h b/fs/crypto/fscrypt_private.h
> index 4b158717a8c3..201906ff7033 100644
> --- a/fs/crypto/fscrypt_private.h
> +++ b/fs/crypto/fscrypt_private.h
> @@ -167,8 +167,7 @@ extern struct page *fscrypt_alloc_bounce_page(struct 
> fscrypt_ctx *ctx,
> gfp_t gfp_flags);
>  
>  /* keyinfo.c */
> -extern int fscrypt_compute_key_hash(const struct inode *inode,
> - const struct fscrypt_policy *policy,
> +extern int fscrypt_compute_key_hash(const struct fscrypt_policy *policy,
>   u8 hash[FSCRYPT_KEY_HASH_SIZE]);
>  extern void __exit fscrypt_essiv_cleanup(void);
>  
> diff --git a/fs/crypto/keyinfo.c b/fs/crypto/keyinfo.c
> index bf60e76f9599..e20b5e85c1b3 100644
> --- a/fs/crypto/keyinfo.c
> +++ b/fs/crypto/keyinfo.c
> @@ -385,8 +385,7 @@ find_and_lock_keyring_key(const char *prefix,
>  }
>  
>  static struct fscrypt_master_key *
> -load_master_key_from_keyring(const struct inode *inode,
> -  const u8 descriptor[FS_KEY_DESCRIPTOR_SIZE],
> +load_master_key_from_keyring(const u8 descriptor[FS_KEY_DESCRIPTOR_SIZE],
>unsigned int min_keysize)
>  {
>   struct key *keyring_key;
> @@ -395,11 +394,6 @@ load_master_key_from_keyring(const struct inode *inode,
>  
>   keyring_key = find_and_lock_keyring_key(FS_KEY_DESC_PREFIX, descriptor,
>   min_keysize, );
> - if (keyring_key == ERR_PTR(-ENOKEY) && inode->i_sb->s_cop->key_prefix) {
> - keyring_key = find_and_lock_keyring_key(
> - inode->i_sb->s_cop->key_prefix,
> - descriptor, min_keysize, );
> - }
>   if (IS_ERR(keyring_key))
>   return ERR_CAST(keyring_key);
>  
> @@ -441,8 +435,7 @@ find_or_create_master_key(const struct inode *inode,
>   /*
>* The needed master key isn't in memory yet.  Load it from the keyring.
>*/
> - master_key = load_master_key_from_keyring(inode,
> -   ctx->master_key_descriptor,
> + master_key = load_master_key_from_keyring(ctx->master_key_descriptor,
> min_keysize);
>   if (IS_ERR(master_key))
>   return master_key;
> @@ -676,8 +669,7 @@ void __exit fscrypt_essiv_cleanup(void)
>   crypto_free_shash(essiv_hash_tfm);
>  }
>  
> -int fscrypt_compute_key_hash(const struct inode *inode,
> -  const struct fscrypt_policy *policy,
> +int fscrypt_compute_key_hash(const struct fscrypt_policy *policy,
>u8 hash[FSCRYPT_KEY_HASH_SIZE])
>  {
>   struct fscrypt_master_key *k;
> @@ -691,7 +683,7 @@ int fscrypt_compute_key_hash(const struct inode *inode,
>   max(available_modes[policy->contents_encryption_mode].keysize,
>   available_modes[policy->filenames_encryption_mode].keysize);
>  
> - k = load_master_key_from_keyring(inode, policy->master_key_descriptor,
> + k = load_master_key_from_keyring(policy->master_key_descriptor,
>min_keysize);
>   if (IS_ERR(k))
>   return PTR_ERR(k);
> diff --git a/fs/crypto/policy.c b/fs/crypto/policy.c
> index 7661c66a3533..cd8c9c7cc9a9 100644
> --- a/fs/crypto/policy.c
> +++ b/fs/crypto/policy.c
> @@ -117,7 +117,7 @@ int fscrypt_ioctl_set_policy(struct file *filp, const 
> void __user *arg)
>   pr_warn_once("%s (pid %d) is setting less secure v0 encryption 
> policy; recommend upgrading to v2.\n",
>current->comm, current->pid);
>   } else {
> - ret = fscrypt_compute_key_hash(inode, , key_hash);
> + ret = fscrypt_compute_key_hash(, key_hash);
>   if (ret)
>   return ret;
>   }
> -- 
> 2.13.2.932.g7449e964c-goog
> 

Re: [PATCH 2/3] dt-bindings: Document STM32 CRYP bindings

[Rob Herring]

On Thu, Jul 13, 2017 at 11:59:38AM +0200, Fabien Dessenne wrote:
> Document device tree bindings for the STM32 CRYP.
> 
> Signed-off-by: Fabien Dessenne 
> ---
>  .../devicetree/bindings/crypto/st,stm32-cryp.txt | 20 
> 
>  1 file changed, 20 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/crypto/st,stm32-cryp.txt
> 
> diff --git a/Documentation/devicetree/bindings/crypto/st,stm32-cryp.txt 
> b/Documentation/devicetree/bindings/crypto/st,stm32-cryp.txt
> new file mode 100644
> index 000..f631c37
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/crypto/st,stm32-cryp.txt
> @@ -0,0 +1,20 @@
> +* STMicroelectronics STM32 CRYP
> +
> +Required properties:
> +- compatible: Should be "st,stm32f756-cryp".
> +- reg: The address and length of the peripheral registers space
> +- clocks: The input clock of the CRYP instance
> +- interrupts: The CRYP interrupts

More than 1? How many?

> +
> +Optional properties:
> +- resets: The input reset of the CRYP instance
> +
> +Example:
> +cryp1: cryp@5006 {
> + compatible = "st,stm32f756-cryp";
> + reg = <0x5006 0x400>;
> + interrupts = <79>;
> + clocks = < 0 STM32F7_AHB2_CLOCK(CRYP)>;
> + resets = < STM32F7_AHB2_RESET(CRYP)>;
> + status = "disabled";
> +};
> -- 
> 2.7.4
> 

Re: [PATCH 5/6] fscrypt: cache the HMAC transform for each master key

[Michael Halcrow]

On Wed, Jul 12, 2017 at 02:00:34PM -0700, Eric Biggers wrote:
> From: Eric Biggers 
> 
> Now that we have a key_hash field which securely identifies a master key
> payload, introduce a cache of the HMAC transforms for the master keys
> currently in use for inodes using v2+ encryption policies.  The entries
> in this cache are called 'struct fscrypt_master_key' and are identified
> by key_hash.  The cache is per-superblock.  (It could be global, but
> making it per-superblock should reduce the lock contention a bit, and we
> may need to keep track of keys on a per-superblock basis for other
> reasons later, e.g. to implement an ioctl for evicting keys.)
> 
> This results in a large efficiency gain: we now only have to allocate
> and key an "hmac(sha512)" transformation, execute HKDF-Extract, and
> compute key_hash once per master key rather than once per inode.  Note
> that this optimization can't easily be applied to the original AES-based
> KDF because that uses a different AES key for each KDF execution.  In
> practice, this difference makes the HKDF per-inode encryption key
> derivation performance comparable to or even faster than the old KDF,
> which typically spends more time allocating an "ecb(aes)" transformation
> from the crypto API than doing actual crypto work.
> 
> Note that it would have been possible to make the mapping be from
> raw_key => fscrypt_master_key (where raw_key denotes the actual bytes of
> the master key) rather than from key_hash => fscrypt_master_key.
> However, an advantage of doing lookups by key_hash is that it replaces
> the keyring lookup in most cases, which opens up the future
> possibilities of not even having the master key in memory following an
> initial provisioning step (if the HMAC-SHA512 implementation is
> hardware-backed), or of introducing an ioctl to provision a key to the
> filesystem directly, avoiding keyrings and their visibility problems
> entirely.  Also, because key_hash is public information while raw_key is
> secret information, it would have been very difficult to use raw_key as
> a map key in a way that would prevent timing attacks while still being
> scalable to a large number of entries.
> 
> Signed-off-by: Eric Biggers 

Reviewed-by: Michael Halcrow 

> ---
>  fs/crypto/fscrypt_private.h |  11 
>  fs/crypto/keyinfo.c | 134 
> +++-
>  fs/crypto/policy.c  |   5 +-
>  fs/super.c  |   4 ++
>  include/linux/fs.h  |   5 ++
>  5 files changed, 152 insertions(+), 7 deletions(-)
> 
> diff --git a/fs/crypto/fscrypt_private.h b/fs/crypto/fscrypt_private.h
> index a7baeac92575..4b158717a8c3 100644
> --- a/fs/crypto/fscrypt_private.h
> +++ b/fs/crypto/fscrypt_private.h
> @@ -88,11 +88,22 @@ fscrypt_valid_context_format(const struct fscrypt_context 
> *ctx, int size)
>  
>  /*
>   * fscrypt_master_key - an in-use master key
> + *
> + * This is referenced from each in-core inode that has been "unlocked" using 
> a
> + * particular master key.  It's primarily used to cache the HMAC transform so
> + * that the per-inode encryption keys can be derived efficiently with HKDF.  
> It
> + * is securely erased once all inodes referencing it have been evicted.
> + *
> + * If the same master key is used on different filesystems (unusual, but
> + * possible), we'll create one of these structs for each filesystem.
>   */
>  struct fscrypt_master_key {
>   struct crypto_shash *mk_hmac;
>   unsigned intmk_size;
>   u8  mk_hash[FSCRYPT_KEY_HASH_SIZE];
> + refcount_t  mk_refcount;
> + struct rb_node  mk_node;
> + struct super_block  *mk_sb;
>  };
>  
>  /*
> diff --git a/fs/crypto/keyinfo.c b/fs/crypto/keyinfo.c
> index 12a60eacf819..bf60e76f9599 100644
> --- a/fs/crypto/keyinfo.c
> +++ b/fs/crypto/keyinfo.c
> @@ -176,6 +176,14 @@ static void put_master_key(struct fscrypt_master_key *k)
>   if (!k)
>   return;
>  
> + if (refcount_read(>mk_refcount) != 0) { /* in ->s_master_keys? */
> + if (!refcount_dec_and_lock(>mk_refcount,
> +>mk_sb->s_master_keys_lock))
> + return;
> + rb_erase(>mk_node, >mk_sb->s_master_keys);
> + spin_unlock(>mk_sb->s_master_keys_lock);
> + }
> +
>   crypto_free_shash(k->mk_hmac);
>   kzfree(k);
>  }
> @@ -231,6 +239,87 @@ alloc_master_key(const struct fscrypt_key *payload)
>   goto out;
>  }
>  
> +/*
> + * ->s_master_keys is a map of master keys currently in use by in-core 
> inodes on
> + * a given filesystem, identified by key_hash which is a cryptographically
> + * secure identifier for an actual key payload.
> + *
> + * Note that master_key_descriptor cannot be used to identify the keys 
> because
> + * master_key_descriptor only identifies the "location" of a key in the 
> keyring,
> + 

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

[Cosar Dindar]

On Mon, Jul 17, 2017 at 02:23:44PM +, Lionel DEBIEVE wrote:
> Hi Cosar,
> 
> - ret = crypto_register_shashes(algs, ARRAY_SIZE(algs));
> + /* For F4 series only CRC32 algorithm will be used */
> + if (of_device_is_compatible(crc->dev->of_node, "st,stm32f4-crc"))
> + algs_size = 1;
> + else
> + algs_size = ARRAY_SIZE(algs);
> +
> + ret = crypto_register_shashes(algs, algs_size);
> 
> Should it be better to have a dedicated array per platform data instead? 
> Could be new platform update?
> 
> BR,
> 
> Lionel
>

Hi Lionel,

Thanks for the comment.

It might be better to seperate shash_alg array according to the platform, one 
alg array for F7 and one for M4.
Adding a new array definition for M4 platform with only CRC-32 algorithm might 
be enough.
This action would be necessary since it might cause problem while unregistering 
with your last patch.

BR,

Cosar
 
> 
> On 07/17/2017 10:27 AM, 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 
> > ---
> >   drivers/crypto/stm32/stm32_crc32.c | 68 
> > --
> >   1 file changed, 58 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/crypto/stm32/stm32_crc32.c 
> > b/drivers/crypto/stm32/stm32_crc32.c
> > index ec83b1e..12fbd98 100644
> > --- a/drivers/crypto/stm32/stm32_crc32.c
> > +++ b/drivers/crypto/stm32/stm32_crc32.c
> > @@ -7,6 +7,7 @@
> >   #include 
> >   #include 
> >   #include 
> > +#include 
> >   #include 
> >   
> >   #include 
> > @@ -39,6 +40,9 @@ struct stm32_crc {
> > struct clk   *clk;
> > 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 +110,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 +157,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 +170,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 + 

KPP questions and confusion

[Kyle Rose]

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?

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?

The context for this email is that I have need for the same basic
functionality in net/bluetooth/ecdh_helper.c for a non-BT purpose, so
it seems like this should be part of crypto/ecdh_helper.c (abstracted
to work for any curve). Basically, I need to do basic ECDH key
agreement:

* Generate a new (valid) ephemeral private key, or potentially re-use
an existing one
* Compute the corresponding public key for the curve
* Compute the shared secret based on my private and peer's public

Is KPP intended to be an abstract interface to all of the above, e.g.,
for both ECDH and FFDH? Right now it seems like layer violations are
required as there doesn't appear to be any way to (for example)
generate a fresh private key via kpp_*.

Thanks,
Kyle

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

[Lionel DEBIEVE]

Hi Cosar,

-   ret = crypto_register_shashes(algs, ARRAY_SIZE(algs));
+   /* For F4 series only CRC32 algorithm will be used */
+   if (of_device_is_compatible(crc->dev->of_node, "st,stm32f4-crc"))
+   algs_size = 1;
+   else
+   algs_size = ARRAY_SIZE(algs);
+
+   ret = crypto_register_shashes(algs, algs_size);

Should it be better to have a dedicated array per platform data instead? Could 
be new platform update?

BR,

Lionel


On 07/17/2017 10:27 AM, 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 
> ---
>   drivers/crypto/stm32/stm32_crc32.c | 68 
> --
>   1 file changed, 58 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/crypto/stm32/stm32_crc32.c 
> b/drivers/crypto/stm32/stm32_crc32.c
> index ec83b1e..12fbd98 100644
> --- a/drivers/crypto/stm32/stm32_crc32.c
> +++ b/drivers/crypto/stm32/stm32_crc32.c
> @@ -7,6 +7,7 @@
>   #include 
>   #include 
>   #include 
> +#include 
>   #include 
>   
>   #include 
> @@ -39,6 +40,9 @@ struct stm32_crc {
>   struct clk   *clk;
>   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 +110,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 +157,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 +170,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;
> @@ -243,6 +276,7 @@ static int stm32_crc_probe(struct platform_device *pdev)
>   struct stm32_crc *crc;
>   struct resource *res;
>   int ret;
> + int algs_size;
>   
>   crc = devm_kzalloc(dev, sizeof(*crc), GFP_KERNEL);
>   if (!crc)
> @@ 

RE: [PATCH] crypto: virtio - Refacotor virtio_crypto driver for new virito crypto services

[Zeng, Xin]

Hi Herbert:
   Ping... any comments for this patch?

Regards
Xin

< -Original Message-
< From: Zeng, Xin
< Sent: Friday, June 23, 2017 11:31 PM
< To: herb...@gondor.apana.org.au; virtio-...@lists.oasis-open.org
< Cc: linux-crypto@vger.kernel.org; arei.gong...@huawei.com; Zeng, Xin
< 
< Subject: [PATCH] crypto: virtio - Refacotor virtio_crypto driver for new 
virito
< crypto services
< 
< In current virtio crypto device driver, some common data structures and
< implementations that should be used by other virtio crypto algorithms
< (e.g. asymmetric crypto algorithms) introduce symmetric crypto algorithms
< specific implementations.
< This patch refactors these pieces of code so that they can be reused by
< other virtio crypto algorithms.
< 
< Acked-by: Gonglei 
< Signed-off-by: Xin Zeng 
< ---
<  drivers/crypto/virtio/virtio_crypto_algs.c   | 109 
+--
<  drivers/crypto/virtio/virtio_crypto_common.h |  22 +-
<  drivers/crypto/virtio/virtio_crypto_core.c   |  37 ++---
<  3 files changed, 98 insertions(+), 70 deletions(-)
< 
< diff --git a/drivers/crypto/virtio/virtio_crypto_algs.c
< b/drivers/crypto/virtio/virtio_crypto_algs.c
< index 49defda..5035b0d 100644
< --- a/drivers/crypto/virtio/virtio_crypto_algs.c
< +++ b/drivers/crypto/virtio/virtio_crypto_algs.c
< @@ -27,12 +27,68 @@
<  #include 
<  #include "virtio_crypto_common.h"
< 
< +
< +struct virtio_crypto_ablkcipher_ctx {
< + struct virtio_crypto *vcrypto;
< + struct crypto_tfm *tfm;
< +
< + struct virtio_crypto_sym_session_info enc_sess_info;
< + struct virtio_crypto_sym_session_info dec_sess_info;
< +};
< +
< +struct virtio_crypto_sym_request {
< + struct virtio_crypto_request base;
< +
< + /* Cipher or aead */
< + uint32_t type;
< + struct virtio_crypto_ablkcipher_ctx *ablkcipher_ctx;
< + struct ablkcipher_request *ablkcipher_req;
< + uint8_t *iv;
< + /* Encryption? */
< + bool encrypt;
< +};
< +
<  /*
<   * The algs_lock protects the below global virtio_crypto_active_devs
<   * and crypto algorithms registion.
<   */
<  static DEFINE_MUTEX(algs_lock);
<  static unsigned int virtio_crypto_active_devs;
< +static void virtio_crypto_ablkcipher_finalize_req(
< + struct virtio_crypto_sym_request *vc_sym_req,
< + struct ablkcipher_request *req,
< + int err);
< +
< +static void virtio_crypto_dataq_sym_callback
< + (struct virtio_crypto_request *vc_req, int len)
< +{
< + struct virtio_crypto_sym_request *vc_sym_req =
< + container_of(vc_req, struct virtio_crypto_sym_request, base);
< + struct ablkcipher_request *ablk_req;
< + int error;
< +
< + /* Finish the encrypt or decrypt process */
< + if (vc_sym_req->type == VIRTIO_CRYPTO_SYM_OP_CIPHER) {
< + switch (vc_req->status) {
< + case VIRTIO_CRYPTO_OK:
< + error = 0;
< + break;
< + case VIRTIO_CRYPTO_INVSESS:
< + case VIRTIO_CRYPTO_ERR:
< + error = -EINVAL;
< + break;
< + case VIRTIO_CRYPTO_BADMSG:
< + error = -EBADMSG;
< + break;
< + default:
< + error = -EIO;
< + break;
< + }
< + ablk_req = vc_sym_req->ablkcipher_req;
< + virtio_crypto_ablkcipher_finalize_req(vc_sym_req,
< + ablk_req, error);
< + }
< +}
< 
<  static u64 virtio_crypto_alg_sg_nents_length(struct scatterlist *sg)
<  {
< @@ -286,13 +342,14 @@ static int virtio_crypto_ablkcipher_setkey(struct
< crypto_ablkcipher *tfm,
<  }
< 
<  static int
< -__virtio_crypto_ablkcipher_do_req(struct virtio_crypto_request *vc_req,
< +__virtio_crypto_ablkcipher_do_req(struct virtio_crypto_sym_request
< *vc_sym_req,
<   struct ablkcipher_request *req,
<   struct data_queue *data_vq)
<  {
<   struct crypto_ablkcipher *tfm = crypto_ablkcipher_reqtfm(req);
< + struct virtio_crypto_ablkcipher_ctx *ctx = vc_sym_req->ablkcipher_ctx;
< + struct virtio_crypto_request *vc_req = _sym_req->base;
<   unsigned int ivsize = crypto_ablkcipher_ivsize(tfm);
< - struct virtio_crypto_ablkcipher_ctx *ctx = vc_req->ablkcipher_ctx;
<   struct virtio_crypto *vcrypto = ctx->vcrypto;
<   struct virtio_crypto_op_data_req *req_data;
<   int src_nents, dst_nents;
< @@ -326,9 +383,9 @@ __virtio_crypto_ablkcipher_do_req(struct
< virtio_crypto_request *vc_req,
<   }
< 
<   vc_req->req_data = req_data;
< - vc_req->type = VIRTIO_CRYPTO_SYM_OP_CIPHER;
< + vc_sym_req->type = VIRTIO_CRYPTO_SYM_OP_CIPHER;
<   /* Head of operation */
< - if (vc_req->encrypt) {
< + if (vc_sym_req->encrypt) {
<   req_data->header.session_id =
<   

[PATCH] drivers: staging: ccree: use __func__ to get function name in error messages.

[Dhananjay Balan]

fixes checkpatch warning.

Signed-off-by: Dhananjay Balan 
---
 drivers/staging/ccree/ssi_driver.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/ccree/ssi_driver.c 
b/drivers/staging/ccree/ssi_driver.c
index d7b9a636d907..e0faca0a30a6 100644
--- a/drivers/staging/ccree/ssi_driver.c
+++ b/drivers/staging/ccree/ssi_driver.c
@@ -81,7 +81,7 @@ void dump_byte_array(const char *name, const u8 *the_array, 
unsigned long size)
char line_buf[80];
 
if (!the_array) {
-   SSI_LOG_ERR("cannot dump_byte_array - NULL pointer\n");
+   SSI_LOG_ERR("cannot %s - NULL pointer\n", __func__);
return;
}
 
-- 
2.13.2

Re: [PATCH 1/3] staging: ccree: Replace kzalloc with devm_kzalloc

[Greg KH]

On Sat, Jul 15, 2017 at 01:21:54PM +0530, suni...@techveda.org wrote:
> From: Suniel Mahesh 
> 
> It is recommended to use managed function devm_kzalloc, which
> simplifies driver cleanup paths and driver code.
> This patch does the following:
> (a) replace kzalloc with devm_kzalloc.
> (b) drop kfree(), because memory allocated with devm_kzalloc() is
> automatically freed on driver detach, otherwise it leads to a double
> free.
> (c) remove unnecessary blank lines.
> 
> Signed-off-by: Suniel Mahesh 
> ---
> Note:
> - Patch was tested and built(ARCH=arm) on next-20170714.
>   No build issues reported, however it was not tested on
>   real hardware.
> ---
>  drivers/staging/ccree/ssi_driver.c | 10 --
>  1 file changed, 4 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/staging/ccree/ssi_driver.c 
> b/drivers/staging/ccree/ssi_driver.c
> index 78709b92..f231ecf 100644
> --- a/drivers/staging/ccree/ssi_driver.c
> +++ b/drivers/staging/ccree/ssi_driver.c
> @@ -224,13 +224,15 @@ static int init_cc_resources(struct platform_device 
> *plat_dev)
>   struct resource *req_mem_cc_regs = NULL;
>   void __iomem *cc_base = NULL;
>   bool irq_registered = false;
> - struct ssi_drvdata *new_drvdata = kzalloc(sizeof(struct ssi_drvdata), 
> GFP_KERNEL);
> + struct ssi_drvdata *new_drvdata;
>   struct device *dev = _dev->dev;
>   struct device_node *np = dev->of_node;
>   u32 signature_val;
>   int rc = 0;
>  
> - if (unlikely(!new_drvdata)) {
> + new_drvdata = devm_kzalloc(_dev->dev, sizeof(struct ssi_drvdata),

sizeof(*new_drvdata), right?

thanks,

greg k-h

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

[Antoine Tenart]

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.

Signed-off-by: Antoine Tenart 
---
 drivers/crypto/inside-secure/safexcel_hash.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/crypto/inside-secure/safexcel_hash.c 
b/drivers/crypto/inside-secure/safexcel_hash.c
index 8527a5899a2f..a11b2edb41b9 100644
--- a/drivers/crypto/inside-secure/safexcel_hash.c
+++ b/drivers/crypto/inside-secure/safexcel_hash.c
@@ -883,9 +883,6 @@ static int safexcel_hmac_sha1_setkey(struct crypto_ahash 
*tfm, const u8 *key,
if (ret)
return ret;
 
-   memcpy(ctx->ipad, , SHA1_DIGEST_SIZE);
-   memcpy(ctx->opad, , SHA1_DIGEST_SIZE);
-
for (i = 0; i < ARRAY_SIZE(istate.state); i++) {
if (ctx->ipad[i] != le32_to_cpu(istate.state[i]) ||
ctx->opad[i] != le32_to_cpu(ostate.state[i])) {
@@ -894,6 +891,9 @@ static int safexcel_hmac_sha1_setkey(struct crypto_ahash 
*tfm, const u8 *key,
}
}
 
+   memcpy(ctx->ipad, , SHA1_DIGEST_SIZE);
+   memcpy(ctx->opad, , SHA1_DIGEST_SIZE);
+
return 0;
 }
 
-- 
2.13.3

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

[Antoine Tenart]

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.

Reported-by: Dan Carpenter 
Signed-off-by: Antoine Tenart 
---
 drivers/crypto/inside-secure/safexcel_hash.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/crypto/inside-secure/safexcel_hash.c 
b/drivers/crypto/inside-secure/safexcel_hash.c
index a11b2edb41b9..3f819399cd95 100644
--- a/drivers/crypto/inside-secure/safexcel_hash.c
+++ b/drivers/crypto/inside-secure/safexcel_hash.c
@@ -883,7 +883,7 @@ static int safexcel_hmac_sha1_setkey(struct crypto_ahash 
*tfm, const u8 *key,
if (ret)
return ret;
 
-   for (i = 0; i < ARRAY_SIZE(istate.state); i++) {
+   for (i = 0; i < SHA1_DIGEST_SIZE / sizeof(u32); i++) {
if (ctx->ipad[i] != le32_to_cpu(istate.state[i]) ||
ctx->opad[i] != le32_to_cpu(ostate.state[i])) {
ctx->base.needs_inv = true;
-- 
2.13.3

[RESEND,PATCH v4 3/3] 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 
Reviewed-by: Fabien Dessenne 
---
 drivers/crypto/stm32/stm32_crc32.c | 68 --
 1 file changed, 58 insertions(+), 10 deletions(-)

diff --git a/drivers/crypto/stm32/stm32_crc32.c 
b/drivers/crypto/stm32/stm32_crc32.c
index ec83b1e..12fbd98 100644
--- a/drivers/crypto/stm32/stm32_crc32.c
+++ b/drivers/crypto/stm32/stm32_crc32.c
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -39,6 +40,9 @@ struct stm32_crc {
struct clk   *clk;
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 +110,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 +157,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 +170,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;
@@ -243,6 +276,7 @@ static int stm32_crc_probe(struct platform_device *pdev)
struct stm32_crc *crc;
struct resource *res;
int ret;
+   int algs_size;
 
crc = devm_kzalloc(dev, sizeof(*crc), GFP_KERNEL);
if (!crc)
@@ -269,13 +303,26 @@ static int stm32_crc_probe(struct platform_device *pdev)
return ret;
}
 
+   /* set key, poly and reverse support if device is of F7 series */
+   if (of_device_is_compatible(crc->dev->of_node, "st,stm32f7-crc")) {
+   crc->key_support = true;
+   crc->poly_support = true;
+   crc->reverse_support = true;
+   }
+
platform_set_drvdata(pdev, crc);
 
spin_lock(_list.lock);
list_add(>list, _list.dev_list);
spin_unlock(_list.lock);
 
-   ret = crypto_register_shashes(algs, ARRAY_SIZE(algs));
+   /* For F4 

[RESEND,PATCH v4 2/3] dt-bindings : Document the STM32F4 CRC32 binding

[Cosar Dindar]

Add device tree binding for STM32F4.

Signed-off-by: Cosar Dindar 
---
 Documentation/devicetree/bindings/crypto/st,stm32-crc.txt | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/crypto/st,stm32-crc.txt 
b/Documentation/devicetree/bindings/crypto/st,stm32-crc.txt
index 3ba92a5..1e9af69 100644
--- a/Documentation/devicetree/bindings/crypto/st,stm32-crc.txt
+++ b/Documentation/devicetree/bindings/crypto/st,stm32-crc.txt
@@ -1,7 +1,9 @@
 * STMicroelectronics STM32 CRC
 
 Required properties:
-- compatible: Should be "st,stm32f7-crc".
+- compatible: Should be one of the following string.
+ "st,stm32f7-crc"
+ "st,stm32f4-crc"
 - reg: The address and length of the peripheral registers space
 - clocks: The input clock of the CRC instance
 
-- 
2.7.4

[RESEND,PATCH v4 0/2] Add support for the STM32F4 CRC32

[Cosar Dindar]

This patch series add hardware CRC32 ("Ethernet") calculation support
for STMicroelectronics STM32F429.

Polynomial and key setting are not supported, key is fixed as 0x4C11DB7
and poly is 0x.

Module is tested on STM32F429-disco board with crypto testmgr using
cases within the key 0x.

Changes in v4:
  - Edited patchset brief.

Cosar Dindar (2):
  dt-bindings : Document the STM32F4 CRC32 binding
  crypto : stm32 - Add STM32F4 CRC32 support

[PATCH] crypto: authencesn - Fix digest_null crash

[Herbert Xu]

When authencesn is used together with digest_null a crash will
occur on the decrypt path.  This is because normally we perform
a special setup to preserve the ESN, but this is skipped if there
is no authentication.  However, on the post-authentication path
it always expects the preservation to be in place, thus causing
a crash when digest_null is used.

This patch fixes this by also skipping the post-processing when
there is no authentication.

Fixes: 104880a6b470 ("crypto: authencesn - Convert to new AEAD...")
Cc: 
Reported-by: Jan Tluka 
Signed-off-by: Herbert Xu 

diff --git a/crypto/authencesn.c b/crypto/authencesn.c
index 6f8f6b8..0cf5fef 100644
--- a/crypto/authencesn.c
+++ b/crypto/authencesn.c
@@ -248,6 +248,9 @@ static int crypto_authenc_esn_decrypt_tail(struct 
aead_request *req,
u8 *ihash = ohash + crypto_ahash_digestsize(auth);
u32 tmp[2];
 
+   if (!authsize)
+   goto decrypt;
+
/* Move high-order bits of sequence number back. */
scatterwalk_map_and_copy(tmp, dst, 4, 4, 0);
scatterwalk_map_and_copy(tmp + 1, dst, assoclen + cryptlen, 4, 0);
@@ -256,6 +259,8 @@ static int crypto_authenc_esn_decrypt_tail(struct 
aead_request *req,
if (crypto_memneq(ihash, ohash, authsize))
return -EBADMSG;
 
+decrypt:
+
sg_init_table(areq_ctx->dst, 2);
dst = scatterwalk_ffwd(areq_ctx->dst, dst, assoclen);
 
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt