Re: random.c: LFSR polynomials are not irreducible/primitive

[Stephan Mueller]

Am Dienstag, 15. August 2017, 17:12:24 CEST schrieb Theodore Ts'o:

Hi Theodore, Jeffrey,
> 
> Stephan, if you have any comments on the proposal made by David
> Fontaine and Olivier Vivolo, I'd appreciate hearing them!

(from Jefferey):

> This may be helpful, too. I use it to look up minimal weight
> irreducibles when I need them.
> http://www.hpl.hp.com/techreports/98/HPL-98-135.pdf

Thanks for the list of polynomials. There is even another list that I used for 
my LRNG: http://courses.cse.tamu.edu/csce680/walker/lfsr_table.pdf.

The problem with all of these polynomials is that their taps are very close 
together and are mostly in the high parts. As there is a chance that adjacent 
event values that shall be processed with the LFSR have some form of 
correlation, having taps close together is not good, especially when they are 
in the high parts of the polynomial.

To counter that effect, either polynomials with spaced-out taps are good (as 
sought by Ted).

There is another solution that I found which was confirmed by mathematicians 
to be of no effect regarding the polynomial behavior: instead of updating 
adjacent words in the entropy pool, update words that are more spaced apart. 
The key is that the spacing must ensure that still all words are evenly 
updated. Updating more spaced-apart words will effectively counter potential 
correlations in adjacent input data when these adjacent values are XORed due 
to polynomials with close taps.

In my LRNG I use the value 67 (a prime number), since I have taps that are 
close together in the high parts. The value 67 is somewhat in the middle of 
the smallest pool size (having 128 words) and thus should have the largest 
spacing possible for the smallest pool. The spacing does not need to be a 
prime number, it is sufficient that this value is odd to ensure that all words 
are evenly accessed by the spacing.

Translating that consideration into the code found in random.c, the following 
line is affected:

i = (i - 1) & wordmask;

This line could be changed to something like:

i = (i - 13) & wordmask;

Why 13? Well, it is a prime number (I like primes :-) ) and it is somewhat in 
the middle of the smallest pool size of 32 words.

Though, as we have polynomials that are spread out more evenly, we do not need 
that change. Yet, if the impact on having such large polynomials (and thus 
doing that many XORs for each byte in the event value) is considered to great 
speed-wise, we could use much smaller polynomials, even when their taps are 
not spaced apart.

Ciao
Stephan

[PATCH] crypto: doc - clarify return values for async hash methods

[Kamil Konieczny]

>From af1b10e1e6aaf67f8dc45ed78de89b0469794a98 Mon Sep 17 00:00:00 2001
From: Kamil Konieczny 
Date: Thu, 17 Aug 2017 12:11:36 +0200
Subject: [PATCH] crypto: doc - clarify return values for async hash methods

* fix documentation of return values for crypto_ahash_init(),
  crypto_ahash_finup(), crypto_ahash_final(),
  crypto_ahash_digest() and crypto_ahash_update()

Also while at it:

* add notes for device driver developers in struct ahash_alg
  description

* fix description of @final method in struct ahash_alg

* fix typo in crypto_ahash_finup() description

Signed-off-by: Kamil Konieczny 
---
 include/crypto/hash.h | 28 
 1 file changed, 16 insertions(+), 12 deletions(-)

diff --git a/include/crypto/hash.h b/include/crypto/hash.h
index b5727bcd2336..0ed31fd80242 100644
--- a/include/crypto/hash.h
+++ b/include/crypto/hash.h
@@ -75,6 +75,7 @@ struct ahash_request {
  *   state of the HASH transformation at the beginning. This shall fill in
  *   the internal structures used during the entire duration of the whole
  *   transformation. No data processing happens at this point.
+ *   Note: mandatory.
  * @update: Push a chunk of data into the driver for transformation. This
  *function actually pushes blocks of data from upper layers into the
  *driver, which then passes those to the hardware as seen fit. This
@@ -84,16 +85,20 @@ struct ahash_request {
  *context, as this function may be called in parallel with the same
  *transformation object. Data processing can happen synchronously
  *[SHASH] or asynchronously [AHASH] at this point.
+ *Note: mandatory.
  * @final: Retrieve result from the driver. This function finalizes the
  *transformation and retrieves the resulting hash from the driver and
  *pushes it back to upper layers. No data processing happens at this
- *point.
+ *point unless hardware requires it to finish the transformation
+ *(then the data buffered by the device driver is processed).
+ *Note: mandatory.
  * @finup: Combination of @update and @final. This function is effectively a
  *combination of @update and @final calls issued in sequence. As some
  *hardware cannot do @update and @final separately, this callback was
  *added to allow such hardware to be used at least by IPsec. Data
  *processing can happen synchronously [SHASH] or asynchronously [AHASH]
  *at this point.
+ *Note: optional.
  * @digest: Combination of @init and @update and @final. This function
  * effectively behaves as the entire chain of operations, @init,
  * @update and @final issued in sequence. Just like @finup, this was
@@ -416,11 +421,10 @@ static inline bool crypto_ahash_has_setkey(struct 
crypto_ahash *tfm)
  *  needed to perform the cipher operation
  *
  * This function is a "short-hand" for the function calls of
- * crypto_ahash_update and crypto_shash_final. The parameters have the same
+ * crypto_ahash_update and crypto_ahash_final. The parameters have the same
  * meaning as discussed for those separate functions.
  *
- * Return: 0 if the message digest creation was successful; < 0 if an error
- *occurred
+ * Return: see crypto_ahash_final()
  */
 int crypto_ahash_finup(struct ahash_request *req);
 
@@ -433,8 +437,11 @@ int crypto_ahash_finup(struct ahash_request *req);
  * based on all data added to the cipher handle. The message digest is placed
  * into the output buffer registered with the ahash_request handle.
  *
- * Return: 0 if the message digest creation was successful; < 0 if an error
- *occurred
+ * Return:
+ * 0   if the message digest was successfully calculated;
+ * -EINPROGRESSif data is feeded into hardware (DMA) or queued for 
later;
+ * -EBUSY  if queue is full and request should be resubmitted later;
+ * other < 0   if an error occurred
  */
 int crypto_ahash_final(struct ahash_request *req);
 
@@ -447,8 +454,7 @@ int crypto_ahash_final(struct ahash_request *req);
  * crypto_ahash_update and crypto_ahash_final. The parameters have the same
  * meaning as discussed for those separate three functions.
  *
- * Return: 0 if the message digest creation was successful; < 0 if an error
- *occurred
+ * Return: see crypto_ahash_final()
  */
 int crypto_ahash_digest(struct ahash_request *req);
 
@@ -493,8 +499,7 @@ static inline int crypto_ahash_import(struct ahash_request 
*req, const void *in)
  * handle. Any potentially existing state created by previous operations is
  * discarded.
  *
- * Return: 0 if the message digest initialization was successful; < 0 if an
- *error occurred
+ * Return: see crypto_ahash_final()
  */
 static inline int crypto_ahash_init(struct ahash_request *req)
 {
@@ -510,8 +515,7 @@ static inline int crypto_ahash_init(struct ahash_request 
*req)

Re: [RFC PATCH 00/10] crypto: caam - add DPAA2 (DPSECI) driver

[Herbert Xu]

On Thu, Aug 10, 2017 at 08:42:43PM +0300, Horia Geantă wrote:
>
> Patches 5-9 are the core of the patch set, adding the driver.
> For symmetric encryption the legacy ablkcipher interface is used; the
> plan is to convert to skcipher all CAAM frontends at once at a certain
> point in time.

I'm fine with these patches.

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

Re: crypto: ccp: use dma_mapping_error to check map error

[Herbert Xu]

On Tue, Aug 08, 2017 at 09:42:47PM +0800, Pan Bian wrote:
> The return value of dma_map_single() should be checked by
> dma_mapping_error(). However, in function ccp_init_dm_workarea(), its
> return value is checked against NULL, which could result in failures.
> 
> Signed-off-by: Pan Bian 

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

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

[Herbert Xu]

On Thu, Aug 03, 2017 at 03:46:35PM +0200, Mogens Lauridsen wrote:
> This driver previously used a spinlock. The spinlock is not
> used any more, but the spinlock variable was still there
> and also being initialized.
> 
> Signed-off-by: Mogens Lauridsen 

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

Re: [PATCH] crypto: sahara - Fix dma unmap direction

[Herbert Xu]

On Thu, Aug 03, 2017 at 03:34:12PM +0200, Mogens Lauridsen wrote:
> The direction used in dma_unmap_sg in aes calc is wrong.
> This result in the cache not being invalidated correct when aes
> calculation is done and result has been dma'ed to memory.
> This is seen as sporadic wrong result from aes calc.
> 
> Signed-off-by: Mogens Lauridsen 

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

Re: [PATCH RESEND] lib/mpi: fix build with clang

[Herbert Xu]

On Mon, Aug 07, 2017 at 10:31:20AM -0700, Stefan Agner wrote:
> Use just @ to denote comments which works with gcc and clang.
> Otherwise clang reports an escape sequence error:
>   error: invalid % escape in inline assembly string
> 
> Use %0-%3 as operand references, this avoids:
>   error: invalid operand in inline asm: 'umull ${1:r}, ${0:r}, ${2:r}, ${3:r}'
> 
> Also remove superfluous casts on output operands to avoid warnings
> such as:
>   warning: invalid use of a cast in an inline asm context requiring an l-value
> 
> Signed-off-by: Stefan Agner 
> Acked-by: Arnd Bergmann 

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

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

[Rob Herring]

On Tue, Aug 15, 2017 at 09:19:43AM +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..7c6d599
> --- /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 interrupt
> +
> +Optional properties:
> +- resets: The input reset of the CRYP instance
> +
> +Example:
> +cryp1: cryp@5006 {

crypto@..

> + compatible = "st,stm32f756-cryp";
> + reg = <0x5006 0x400>;
> + interrupts = <79>;
> + clocks = < 0 STM32F7_AHB2_CLOCK(CRYP)>;
> + resets = < STM32F7_AHB2_RESET(CRYP)>;
> + status = "disabled";

Don't show status in examples.

Otherwise,

Acked-by: Rob Herring 

> +};
> -- 
> 2.7.4
> 

[PATCH] crypto: nx: 842: constify vio_device_id

[Arvind Yadav]

vio_device_id are not supposed to change at runtime. All functions
working with vio_device_id provided by  work with
const vio_device_id. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
 drivers/crypto/nx/nx-842-pseries.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/crypto/nx/nx-842-pseries.c 
b/drivers/crypto/nx/nx-842-pseries.c
index cddc6d8..bf52cd1 100644
--- a/drivers/crypto/nx/nx-842-pseries.c
+++ b/drivers/crypto/nx/nx-842-pseries.c
@@ -1082,7 +1082,7 @@ static int nx842_remove(struct vio_dev *viodev)
return 0;
 }
 
-static struct vio_device_id nx842_vio_driver_ids[] = {
+static const struct vio_device_id nx842_vio_driver_ids[] = {
{"ibm,compression-v1", "ibm,compression"},
{"", ""},
 };
-- 
2.7.4

Re: [PATCH v8 0/4] crypto: add algif_akcipher user space API

[Tudor Ambarus]

Hi, all,

On 08/11/2017 07:05 PM, Marcel Holtmann wrote:

Hi Stephan,


AF_ALG is best suited for crypto use cases where a socket is set up once
and there are lots of reads and writes to justify the setup cost. With
asymmetric crypto, the setup cost is high when you might only use the
socket for a brief time to do one verify or encrypt operation.


To me, the entire AF_ALG purpose is solely to export hardware support to user
space. That said, if user space wants an accelerator, a socket would be opened
once followed by numerous read/write requests.

Besides, I am aware of Tadeusz' patch to link algif_akcipher to the keyring
and I planned to port it to the current implementation. But I thought I offer
a small patch focusing on the externalization of the akcipher API first.

I think the keyctl and AF_ALG are no opponents, but rather are orthogonal to
each other. The statement I made for the KPP AF_ALG RFC applies here too:

"""
I am aware and in fact supported development of the DH support in the keys
subsystem. The question will be raised whether the AF_ALG KPP interface is
superfluous in light of the keys DH support. My answer is that AF_ALG KPP is
orthogonal to the keys DH support. The keys DH support use case is that
the keys are managed inside the kernel and thus has the focus on the
key management. Contrary, AF_ALG KPP does not really focus on key management
but simply externalizes the DH/ECDH support found in the kernel including
hardware acceleration. User space is in full control of the key life cycle.
This way, AF_ALG could be used to complement user-space network protocol
implementations like TLS or IKE to offload the resource intense DH
calculations to accelerators.
“""


we do not need two interfaces for doing the same thing. Especially not one that 
can not handle hardware backed keys. And more important if you can not abstract 
an accelerator that doesn’t expose the private key at all.


I'm working with a crypto accelerator (find it at [1]) that is capable
of generating random ecc private keys internally within the device that
are never revealed outside of it. The keys can be further used for ECDH
and ECDSA.

The simplest way to access my device from user-space is to go through
af_alg. We can permit the users to provide NULL keys, and if so, we can
generate the keys inside the kernel/hardware. If hardware supports
key generation and retention, it will use it, else the keys
will be generated inside the kernel. Either way it's a win, we don't
reveal the private keys to user-space. Going through the keyring
subsystem seems superfluous in this case.

My use case compared with the one of using keyring subsystem to access
keys from TPMs or Intel's sgx enclave seem orthogonal. What do you
think?

Cheers,
ta

[1] http://www.microchip.com/wwwproducts/en/ATECC508A
The driver can be found in drivers/crypto/atmel-ecc* in Herbert's tree.

[PATCH] crypto: nx: constify vio_device_id

[Arvind Yadav]

vio_device_id are not supposed to change at runtime. All functions
working with vio_device_id provided by  work with
const vio_device_id. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
 drivers/crypto/nx/nx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/crypto/nx/nx.c b/drivers/crypto/nx/nx.c
index 036057a..3a5e31b 100644
--- a/drivers/crypto/nx/nx.c
+++ b/drivers/crypto/nx/nx.c
@@ -833,7 +833,7 @@ static void __exit nx_fini(void)
vio_unregister_driver(_driver.viodriver);
 }
 
-static struct vio_device_id nx_crypto_driver_ids[] = {
+static const struct vio_device_id nx_crypto_driver_ids[] = {
{ "ibm,sym-encryption-v1", "ibm,sym-encryption" },
{ "", "" }
 };
-- 
2.7.4

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

[Mimi Zohar]

On Fri, 2017-08-04 at 19:03 -0300, Thiago Jung Bauermann wrote:
> This patch introduces the modsig keyword to the IMA policy syntax to
> specify that a given hook should expect the file to have the IMA signature
> appended to it. Here is how it can be used in a rule:
> 
> appraise func=KEXEC_KERNEL_CHECK appraise_type=modsig|imasig
> 
> With this rule, IMA will accept either an appended signature or a signature
> stored in the extended attribute. In that case, it will first check whether
> there is an appended signature, and if not it will read it from the
> extended attribute.
> 
> The format of the appended signature is the same used for signed kernel
> modules. This means that the file can be signed with the scripts/sign-file
> tool, with a command line such as this:
> 
> $ sign-file sha256 privkey_ima.pem x509_ima.der vmlinux
> 
> This code only works for files that are hashed from a memory buffer, not
> for files that are read from disk at the time of hash calculation. In other
> words, only hooks that use kernel_read_file can support appended
> signatures. This means that only FIRMWARE_CHECK, KEXEC_KERNEL_CHECK,
> KEXEC_INITRAMFS_CHECK and POLICY_CHECK can be supported.
> 
> This feature warrants a separate config option because enabling it brings
> in many other config options.
> 
> Signed-off-by: Thiago Jung Bauermann 

Other than the appended signature not being properly included in the
measurement list, the patch seems to be working.  This patch is on the
rather large size. Could you go back and break this patch up into
smaller, more concise patches, with clear patch descriptions (eg.
separate code cleanup from changes, new policy option, code for
appraising an attached signature, storing the appended signature in
the measurement list, etc)?

thanks!

Mimi

> ---
>  security/integrity/ima/Kconfig|  13 +++
>  security/integrity/ima/Makefile   |   1 +
>  security/integrity/ima/ima.h  |  70 +++-
>  security/integrity/ima/ima_appraise.c | 178 
> +-
>  security/integrity/ima/ima_main.c |   7 +-
>  security/integrity/ima/ima_modsig.c   | 178 
> ++
>  security/integrity/ima/ima_policy.c   |  26 +++--
>  security/integrity/ima/ima_template_lib.c |  14 ++-
>  security/integrity/integrity.h|   4 +-
>  9 files changed, 443 insertions(+), 48 deletions(-)
> 
> diff --git a/security/integrity/ima/Kconfig b/security/integrity/ima/Kconfig
> index 35ef69312811..55f734a6124b 100644
> --- a/security/integrity/ima/Kconfig
> +++ b/security/integrity/ima/Kconfig
> @@ -163,6 +163,19 @@ config IMA_APPRAISE_BOOTPARAM
> This option enables the different "ima_appraise=" modes
> (eg. fix, log) from the boot command line.
> 
> +config IMA_APPRAISE_MODSIG
> + bool "Support module-style signatures for appraisal"
> + depends on IMA_APPRAISE
> + depends on INTEGRITY_ASYMMETRIC_KEYS
> + select PKCS7_MESSAGE_PARSER
> + select MODULE_SIG_FORMAT
> + default n
> + help
> +Adds support for signatures appended to files. The format of the
> +appended signature is the same used for signed kernel modules.
> +The modsig keyword can be used in the IMA policy to allow a hook
> +to accept such signatures.
> +
>  config IMA_TRUSTED_KEYRING
>   bool "Require all keys on the .ima keyring be signed (deprecated)"
>   depends on IMA_APPRAISE && SYSTEM_TRUSTED_KEYRING
> diff --git a/security/integrity/ima/Makefile b/security/integrity/ima/Makefile
> index 29f198bde02b..c72026acecc3 100644
> --- a/security/integrity/ima/Makefile
> +++ b/security/integrity/ima/Makefile
> @@ -8,5 +8,6 @@ obj-$(CONFIG_IMA) += ima.o
>  ima-y := ima_fs.o ima_queue.o ima_init.o ima_main.o ima_crypto.o ima_api.o \
>ima_policy.o ima_template.o ima_template_lib.o
>  ima-$(CONFIG_IMA_APPRAISE) += ima_appraise.o
> +ima-$(CONFIG_IMA_APPRAISE_MODSIG) += ima_modsig.o
>  ima-$(CONFIG_HAVE_IMA_KEXEC) += ima_kexec.o
>  obj-$(CONFIG_IMA_BLACKLIST_KEYRING) += ima_mok.o
> diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h
> index d52b487ad259..5492af2cd7c7 100644
> --- a/security/integrity/ima/ima.h
> +++ b/security/integrity/ima/ima.h
> @@ -190,6 +190,8 @@ enum ima_hooks {
>   __ima_hooks(__ima_hook_enumify)
>  };
> 
> +extern const char *const func_tokens[];
> +
>  /* LIM API function definitions */
>  int ima_get_action(struct inode *inode, int mask,
>  enum ima_hooks func, int *pcr);
> @@ -236,9 +238,10 @@ int ima_policy_show(struct seq_file *m, void *v);
>  #ifdef CONFIG_IMA_APPRAISE
>  int ima_appraise_measurement(enum ima_hooks func,
>struct integrity_iint_cache *iint,
> -  struct file *file, const unsigned char *filename,
> -  struct evm_ima_xattr_data *xattr_value,
> -  int xattr_len, int 

Re: [PATCH 3/6] crypto: jz4780-rng: Add Ingenic JZ4780 hardware PRNG driver

[Stephan Mueller]

Am Donnerstag, 17. August 2017, 20:25:17 CEST schrieb PrasannaKumar 
Muralidharan:

Hi PrasannaKumar,

> +
> +static int jz4780_rng_generate(struct crypto_rng *tfm,
> +const u8 *src, unsigned int slen,
> +u8 *dst, unsigned int dlen)
> +{
> + struct jz4780_rng_ctx *ctx = crypto_rng_ctx(tfm);
> + struct jz4780_rng *rng = ctx->rng;
> + u32 data;
> +
> + /*
> +  * JZ4780 Programmers manual says the RNG should not run continuously
> +  * for more than 1s. So enable RNG, read data and disable it.
> +  * NOTE: No issue was observed with MIPS creator CI20 board even when
> +  * RNG ran continuously for longer periods. This is just a precaution.
> +  *
> +  * A delay is required so that the current RNG data is not bit shifted
> +  * version of previous RNG data which could happen if random data is
> +  * read continuously from this device.
> +  */
> + jz4780_rng_writel(rng, 1, REG_RNG_CTRL);
> + do {
> + data = jz4780_rng_readl(rng, REG_RNG_DATA);
> + memcpy((void *)dst, (void *), 4);

How do you know that dst is a multiple of 4 bytes? When dlen is only 3, you 
overflow the buffer.

> + dlen -= 4;
> + dst += 4;
> + udelay(20);
> + } while (dlen >= 4);
> +
> + if (dlen > 0) {
> + data = jz4780_rng_readl(rng, REG_RNG_DATA);
> + memcpy((void *)dst, (void *), dlen);
> + }
> + jz4780_rng_writel(rng, 0, REG_RNG_CTRL);
> +
> + return 0;
> +}

Ciao
Stephan

[PATCH] hwrng: pseries: constify vio_device_id

[Arvind Yadav]

vio_device_id are not supposed to change at runtime. All functions
working with vio_device_id provided by  work with
const vio_device_id. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
 drivers/char/hw_random/pseries-rng.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/char/hw_random/pseries-rng.c 
b/drivers/char/hw_random/pseries-rng.c
index d9f46b4..4e2a3f6 100644
--- a/drivers/char/hw_random/pseries-rng.c
+++ b/drivers/char/hw_random/pseries-rng.c
@@ -72,7 +72,7 @@ static int pseries_rng_remove(struct vio_dev *dev)
return 0;
 }
 
-static struct vio_device_id pseries_rng_driver_ids[] = {
+static const struct vio_device_id pseries_rng_driver_ids[] = {
{ "ibm,random-v1", "ibm,random"},
{ "", "" }
 };
-- 
2.7.4

[PATCH 0/6] crypto: Add driver for JZ4780 PRNG

[PrasannaKumar Muralidharan]

This patch series adds support of pseudo random number generator found
in Ingenic's JZ4780 and X1000 SoC.

The PRNG hardware block registers are a part of same hardware block
that has clock and power registers which is handled by CGU driver.
Ingenic M200 SoC contains power related registers that are present
after the PRNG registers. So instead of reducing the register range,
syscon interface is used to expose a register map that is used by both
CGU driver and this driver. Changes made to jz4740-cgu.c is only compile
tested.

PrasannaKumar Muralidharan (6):
  crypto: jz4780-rng: Add devicetree bindings for RNG in JZ4780 SoC
  crypto: jz4780-rng: Make ingenic CGU driver use syscon
  crypto: jz4780-rng: Add Ingenic JZ4780 hardware PRNG driver
  crypto: jz4780-rng: Add RNG node to jz4780.dtsi
  crypto: jz4780-rng: Add myself as mainatainer for JZ4780 PRNG driver
  crypto: jz4780-rng: Enable PRNG support in CI20 defconfig

 .../devicetree/bindings/rng/ingenic,jz4780-rng.txt |  24 +++
 MAINTAINERS|   5 +
 arch/mips/boot/dts/ingenic/jz4740.dtsi |  14 +-
 arch/mips/boot/dts/ingenic/jz4780.dtsi |  18 ++-
 arch/mips/configs/ci20_defconfig   |   5 +
 drivers/clk/ingenic/cgu.c  |  46 +++---
 drivers/clk/ingenic/cgu.h  |   9 +-
 drivers/clk/ingenic/jz4740-cgu.c   |  30 ++--
 drivers/clk/ingenic/jz4780-cgu.c   |  10 +-
 drivers/crypto/Kconfig |  19 +++
 drivers/crypto/Makefile|   1 +
 drivers/crypto/jz4780-rng.c| 173 +
 12 files changed, 304 insertions(+), 50 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/rng/ingenic,jz4780-rng.txt
 create mode 100644 drivers/crypto/jz4780-rng.c

-- 
2.10.0

[PATCH 1/6] crypto: jz4780-rng: Add devicetree bindings for RNG in JZ4780 SoC

[PrasannaKumar Muralidharan]

Add devicetree bindings for hardware pseudo random number generator
present in Ingenic JZ4780 SoC.

Signed-off-by: PrasannaKumar Muralidharan 
---
 .../devicetree/bindings/rng/ingenic,jz4780-rng.txt | 24 ++
 1 file changed, 24 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/rng/ingenic,jz4780-rng.txt

diff --git a/Documentation/devicetree/bindings/rng/ingenic,jz4780-rng.txt 
b/Documentation/devicetree/bindings/rng/ingenic,jz4780-rng.txt
new file mode 100644
index 000..88a0a92
--- /dev/null
+++ b/Documentation/devicetree/bindings/rng/ingenic,jz4780-rng.txt
@@ -0,0 +1,24 @@
+Ingenic jz4780 RNG driver
+
+Required properties:
+- compatible : Should be "ingenic,jz4780-rng"
+
+Example:
+
+cgu_registers {
+   compatible = "simple-mfd", "syscon";
+   reg = <0x1000 0x100>;
+
+   cgu: jz4780-cgu@1000 {
+   compatible = "ingenic,jz4780-cgu";
+
+   clocks = <>, <>;
+   clock-names = "ext", "rtc";
+
+   #clock-cells = <1>;
+   };
+
+   rng: rng@d8 {
+   compatible = "ingenic,jz480-rng";
+   };
+};
-- 
2.10.0

[PATCH 2/6] crypto: jz4780-rng: Make ingenic CGU driver use syscon

[PrasannaKumar Muralidharan]

Ingenic PRNG registers are a part of the same hardware block as clock
and power stuff. It is handled by CGU driver. Ingenic M200 SoC has power
related registers that are after the PRNG registers. So instead of
shortening the register range use syscon interface to expose regmap.
This regmap is used by the PRNG driver.

Signed-off-by: PrasannaKumar Muralidharan 
---
 arch/mips/boot/dts/ingenic/jz4740.dtsi | 14 +++
 arch/mips/boot/dts/ingenic/jz4780.dtsi | 14 +++
 drivers/clk/ingenic/cgu.c  | 46 +-
 drivers/clk/ingenic/cgu.h  |  9 +--
 drivers/clk/ingenic/jz4740-cgu.c   | 30 +++---
 drivers/clk/ingenic/jz4780-cgu.c   | 10 
 6 files changed, 73 insertions(+), 50 deletions(-)

diff --git a/arch/mips/boot/dts/ingenic/jz4740.dtsi 
b/arch/mips/boot/dts/ingenic/jz4740.dtsi
index 2ca7ce7..ada5e67 100644
--- a/arch/mips/boot/dts/ingenic/jz4740.dtsi
+++ b/arch/mips/boot/dts/ingenic/jz4740.dtsi
@@ -34,14 +34,18 @@
clock-frequency = <32768>;
};
 
-   cgu: jz4740-cgu@1000 {
-   compatible = "ingenic,jz4740-cgu";
+   cgu_registers {
+   compatible = "simple-mfd", "syscon";
reg = <0x1000 0x100>;
 
-   clocks = <>, <>;
-   clock-names = "ext", "rtc";
+   cgu: jz4780-cgu@1000 {
+   compatible = "ingenic,jz4740-cgu";
 
-   #clock-cells = <1>;
+   clocks = <>, <>;
+   clock-names = "ext", "rtc";
+
+   #clock-cells = <1>;
+   };
};
 
rtc_dev: rtc@10003000 {
diff --git a/arch/mips/boot/dts/ingenic/jz4780.dtsi 
b/arch/mips/boot/dts/ingenic/jz4780.dtsi
index 4853ef6..1301694 100644
--- a/arch/mips/boot/dts/ingenic/jz4780.dtsi
+++ b/arch/mips/boot/dts/ingenic/jz4780.dtsi
@@ -34,14 +34,18 @@
clock-frequency = <32768>;
};
 
-   cgu: jz4780-cgu@1000 {
-   compatible = "ingenic,jz4780-cgu";
+   cgu_registers {
+   compatible = "simple-mfd", "syscon";
reg = <0x1000 0x100>;
 
-   clocks = <>, <>;
-   clock-names = "ext", "rtc";
+   cgu: jz4780-cgu@1000 {
+   compatible = "ingenic,jz4780-cgu";
 
-   #clock-cells = <1>;
+   clocks = <>, <>;
+   clock-names = "ext", "rtc";
+
+   #clock-cells = <1>;
+   };
};
 
pinctrl: pin-controller@1001 {
diff --git a/drivers/clk/ingenic/cgu.c b/drivers/clk/ingenic/cgu.c
index e8248f9..2f12c7c 100644
--- a/drivers/clk/ingenic/cgu.c
+++ b/drivers/clk/ingenic/cgu.c
@@ -29,6 +29,18 @@
 
 #define MHZ (1000 * 1000)
 
+unsigned int cgu_readl(struct ingenic_cgu *cgu, unsigned int reg)
+{
+   unsigned int val = 0;
+   regmap_read(cgu->regmap, reg, );
+   return val;
+}
+
+int cgu_writel(struct ingenic_cgu *cgu, unsigned int val, unsigned int reg)
+{
+   return regmap_write(cgu->regmap, reg, val);
+}
+
 /**
  * ingenic_cgu_gate_get() - get the value of clock gate register bit
  * @cgu: reference to the CGU whose registers should be read
@@ -43,7 +55,7 @@ static inline bool
 ingenic_cgu_gate_get(struct ingenic_cgu *cgu,
 const struct ingenic_cgu_gate_info *info)
 {
-   return readl(cgu->base + info->reg) & BIT(info->bit);
+   return cgu_readl(cgu, info->reg) & BIT(info->bit);
 }
 
 /**
@@ -60,14 +72,14 @@ static inline void
 ingenic_cgu_gate_set(struct ingenic_cgu *cgu,
 const struct ingenic_cgu_gate_info *info, bool val)
 {
-   u32 clkgr = readl(cgu->base + info->reg);
+   u32 clkgr = cgu_readl(cgu, info->reg);
 
if (val)
clkgr |= BIT(info->bit);
else
clkgr &= ~BIT(info->bit);
 
-   writel(clkgr, cgu->base + info->reg);
+   cgu_writel(cgu, clkgr, info->reg);
 }
 
 /*
@@ -91,7 +103,7 @@ ingenic_pll_recalc_rate(struct clk_hw *hw, unsigned long 
parent_rate)
pll_info = _info->pll;
 
spin_lock_irqsave(>lock, flags);
-   ctl = readl(cgu->base + pll_info->reg);
+   ctl = cgu_readl(cgu, pll_info->reg);
spin_unlock_irqrestore(>lock, flags);
 
m = (ctl >> pll_info->m_shift) & GENMASK(pll_info->m_bits - 1, 0);
@@ -190,7 +202,7 @@ ingenic_pll_set_rate(struct clk_hw *hw, unsigned long 
req_rate,
clk_info->name, req_rate, rate);
 
spin_lock_irqsave(>lock, flags);
-   ctl = readl(cgu->base + pll_info->reg);
+   ctl = cgu_readl(cgu, pll_info->reg);
 
ctl &= ~(GENMASK(pll_info->m_bits - 1, 0) << pll_info->m_shift);
ctl |= (m - pll_info->m_offset) << pll_info->m_shift;
@@ -204,11 +216,11 @@ ingenic_pll_set_rate(struct clk_hw *hw, unsigned long 
req_rate,
ctl &= ~BIT(pll_info->bypass_bit);
  

[PATCH 3/6] crypto: jz4780-rng: Add Ingenic JZ4780 hardware PRNG driver

[PrasannaKumar Muralidharan]

JZ4780 SoC pseudo random number generator driver using crypto framework.

Adding a delay before reading RNG data and disabling RNG after reading
data was suggested by Jeffery Walton.

Tested-by: Mathieu Malaterre 
Suggested-by: Jeffrey Walton 
Signed-off-by: PrasannaKumar Muralidharan 
---
 drivers/crypto/Kconfig  |  19 +
 drivers/crypto/Makefile |   1 +
 drivers/crypto/jz4780-rng.c | 173 
 3 files changed, 193 insertions(+)
 create mode 100644 drivers/crypto/jz4780-rng.c

diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 8fa7e72..8263622 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -614,6 +614,25 @@ config CRYPTO_DEV_IMGTEC_HASH
  hardware hash accelerator. Supporting MD5/SHA1/SHA224/SHA256
  hashing algorithms.
 
+config CRYPTO_DEV_JZ4780_RNG
+   tristate "JZ4780 HW pseudo random number generator support"
+   depends on MACH_JZ4780 || COMPILE_TEST
+   depends on HAS_IOMEM
+   select CRYPTO_RNG
+   select REGMAP
+   select SYSCON
+   select MFD_SYSCON
+   ---help---
+ This driver provides kernel-side support through the
+ cryptographic API for the pseudo random number generator
+ hardware found in ingenic JZ4780 and X1000 SoC. MIPS
+ Creator CI20 uses JZ4780 SoC.
+
+ To compile this driver as a module, choose M here: the
+ module will be called jz4780-rng.
+
+ If unsure, say Y.
+
 config CRYPTO_DEV_SUN4I_SS
tristate "Support for Allwinner Security System cryptographic 
accelerator"
depends on ARCH_SUNXI && !64BIT
diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
index b12eb3c..3a3d970 100644
--- a/drivers/crypto/Makefile
+++ b/drivers/crypto/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_CRYPTO_DEV_GEODE) += geode-aes.o
 obj-$(CONFIG_CRYPTO_DEV_HIFN_795X) += hifn_795x.o
 obj-$(CONFIG_CRYPTO_DEV_IMGTEC_HASH) += img-hash.o
 obj-$(CONFIG_CRYPTO_DEV_IXP4XX) += ixp4xx_crypto.o
+obj-$(CONFIG_CRYPTO_DEV_JZ4780_RNG) += jz4780-rng.o
 obj-$(CONFIG_CRYPTO_DEV_MV_CESA) += mv_cesa.o
 obj-$(CONFIG_CRYPTO_DEV_MARVELL_CESA) += marvell/
 obj-$(CONFIG_CRYPTO_DEV_MEDIATEK) += mediatek/
diff --git a/drivers/crypto/jz4780-rng.c b/drivers/crypto/jz4780-rng.c
new file mode 100644
index 000..a03f2a0
--- /dev/null
+++ b/drivers/crypto/jz4780-rng.c
@@ -0,0 +1,173 @@
+/*
+ * jz4780-rng.c - Random Number Generator driver for the jz4780
+ *
+ * Copyright (c) 2017 PrasannaKumar Muralidharan 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation;
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define REG_RNG_CTRL   0xD8
+#define REG_RNG_DATA   0xDC
+
+/* Context for crypto */
+struct jz4780_rng_ctx {
+   struct jz4780_rng *rng;
+};
+
+/* Device associated memory */
+struct jz4780_rng {
+   struct device *dev;
+   struct regmap *regmap;
+};
+
+static struct jz4780_rng *jz4780_rng;
+
+static int jz4780_rng_readl(struct jz4780_rng *rng, u32 offset)
+{
+   u32 val = 0;
+   int ret;
+
+   ret = regmap_read(rng->regmap, offset, );
+   if (!ret)
+   return val;
+
+   return ret;
+}
+
+static int jz4780_rng_writel(struct jz4780_rng *rng, u32 val, u32 offset)
+{
+   return regmap_write(rng->regmap, offset, val);
+}
+
+static int jz4780_rng_generate(struct crypto_rng *tfm,
+  const u8 *src, unsigned int slen,
+  u8 *dst, unsigned int dlen)
+{
+   struct jz4780_rng_ctx *ctx = crypto_rng_ctx(tfm);
+   struct jz4780_rng *rng = ctx->rng;
+   u32 data;
+
+   /*
+* JZ4780 Programmers manual says the RNG should not run continuously
+* for more than 1s. So enable RNG, read data and disable it.
+* NOTE: No issue was observed with MIPS creator CI20 board even when
+* RNG ran continuously for longer periods. This is just a precaution.
+*
+* A delay is required so that the current RNG data is not bit shifted
+* version of previous RNG data which could happen if random data is
+* read continuously from this device.
+*/
+   jz4780_rng_writel(rng, 1, REG_RNG_CTRL);
+   do {
+   data = jz4780_rng_readl(rng, REG_RNG_DATA);
+   memcpy((void *)dst, (void *), 4);
+   dlen -= 4;
+   dst += 4;
+   udelay(20);
+   } while (dlen >= 4);
+
+   if (dlen > 0) {
+  

[PATCH 4/6] crypto: jz4780-rng: Add RNG node to jz4780.dtsi

[PrasannaKumar Muralidharan]

This patch adds RNG node to jz4780.dtsi.

Signed-off-by: PrasannaKumar Muralidharan 
---
 arch/mips/boot/dts/ingenic/jz4780.dtsi | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/mips/boot/dts/ingenic/jz4780.dtsi 
b/arch/mips/boot/dts/ingenic/jz4780.dtsi
index 1301694..865b9bf 100644
--- a/arch/mips/boot/dts/ingenic/jz4780.dtsi
+++ b/arch/mips/boot/dts/ingenic/jz4780.dtsi
@@ -46,6 +46,10 @@
 
#clock-cells = <1>;
};
+
+   rng: rng@d8 {
+   compatible = "ingenic,jz480-rng";
+   };
};
 
pinctrl: pin-controller@1001 {
-- 
2.10.0

[PATCH 6/6] crypto: jz4780-rng: Enable PRNG support in CI20 defconfig

[PrasannaKumar Muralidharan]

Enable PRNG driver support in MIPS Creator CI20 default config.

Signed-off-by: PrasannaKumar Muralidharan 
---
 arch/mips/configs/ci20_defconfig | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/mips/configs/ci20_defconfig b/arch/mips/configs/ci20_defconfig
index b42cfa7..9f48f2c 100644
--- a/arch/mips/configs/ci20_defconfig
+++ b/arch/mips/configs/ci20_defconfig
@@ -88,6 +88,11 @@ CONFIG_SERIAL_8250_RUNTIME_UARTS=5
 CONFIG_SERIAL_8250_INGENIC=y
 CONFIG_SERIAL_OF_PLATFORM=y
 # CONFIG_HW_RANDOM is not set
+CONFIG_CRYPTO_USER=y
+CONFIG_CRYPTO_USER_API=y
+CONFIG_CRYPTO_USER_API_RNG=y
+CONFIG_CRYPTO_HW=y
+CONFIG_CRYPTO_DEV_JZ4780_RNG=y
 CONFIG_I2C=y
 CONFIG_I2C_JZ4780=y
 CONFIG_GPIO_SYSFS=y
-- 
2.10.0

[PATCH 5/6] crypto: jz4780-rng: Add myself as mainatainer for JZ4780 PRNG driver

[PrasannaKumar Muralidharan]

Add myself as the maintainer of JZ4780 SoC's PRNG drvier.

Signed-off-by: PrasannaKumar Muralidharan 
---
 MAINTAINERS | 5 +
 1 file changed, 5 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 45ec467..ee8c6f6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6733,6 +6733,11 @@ L:   linux-...@lists.infradead.org
 S: Maintained
 F: drivers/mtd/nand/jz4780_*
 
+INGENIC JZ4780 PRNG DRIVER
+M: PrasannaKumar Muralidharan 
+S: Maintained
+F: drivers/crypto/jz4780-rng.c
+
 INOTIFY
 M: John McCutchan 
 M: Robert Love 
-- 
2.10.0