Re: [PATCH 1/5] random: fix crng_ready() test

Am Freitag, 13. April 2018, 03:30:42 CEST schrieb Theodore Ts'o: Hi Theodore, > The crng_init variable has three states: > > 0: The CRNG is not initialized at all > 1: The CRNG has a small amount of entropy, hopefully good enough for >early-boot, non-cryptographical use cases > 2: The CRNG

[PATCH 1/5] random: fix crng_ready() test

The crng_init variable has three states: 0: The CRNG is not initialized at all 1: The CRNG has a small amount of entropy, hopefully good enough for early-boot, non-cryptographical use cases 2: The CRNG is fully initialized and we are sure it is safe for cryptographic use cases. The

[PATCH 2/5] random: use a different mixing algorithm for add_device_randomness()

add_device_randomness() use of crng_fast_load() was highly problematic. Some callers of add_device_randomness() can pass in a large amount of static information. This would immediately promote the crng_init state from 0 to 1, without really doing much to initialize the primary_crng's internal

[PATCH 4/5] random: crng_reseed() should lock the crng instance that it is modifying

Reported-by: Jann Horn Fixes: 1e7f583af67b ("random: make /dev/urandom scalable for silly...") Cc: sta...@kernel.org # 4.8+ Signed-off-by: Theodore Ts'o Reviewed-by: Jann Horn --- drivers/char/random.c | 4 ++-- 1 file changed, 2

[PATCH 3/5] random: set up the NUMA crng instances after the CRNG is fully initialized

Until the primary_crng is fully initialized, don't initialize the NUMA crng nodes. Otherwise users of /dev/urandom on NUMA systems before the CRNG is fully initialized can get very bad quality randomness. Of course everyone should move to getrandom(2) where this won't be an issue, but there's a

[PATCH 5/5] random: add new ioctl RNDRESEEDCRNG

Add a new ioctl which forces the the crng to be reseeded. Signed-off-by: Theodore Ts'o Cc: sta...@kernel.org --- drivers/char/random.c | 13 - include/uapi/linux/random.h | 3 +++ 2 files changed, 15 insertions(+), 1 deletion(-) diff --git

Re: CAAM and IMA/EVM : caam_rsa_enc: DECO: desc idx 7: Protocol Size Error

Hi Horia, On Thu, Apr 12, 2018 at 4:12 AM, Horia Geantă wrote: > Yes, driver needs to strip off leading zeros from input data before feeding it > to the accelerator. > I am working at a fix. I was able to to strip off the leading zeros from input data as you suggested.

Re: [PATCH v4 2/2] crypto: caam - allow retrieving 'era' from register

Hi Fabio, 2018-04-11 9:45 GMT-03:00 Fabio Estevam : > From: Fabio Estevam > > The 'era' information can be retrieved from CAAM registers, so > introduce a caam_get_era_from_hw() function that gets it via register > reads in case the 'fsl,sec-era'

libkcapi v1.1.0 released

Hi, The Linux kernel exports a network interface of type AF_ALG to allow user space to utilize the kernel crypto API. libkcapi uses this network interface and exports an easy to use API so that a developer does not need to consider the low-level network interface handling. The library does

Re: CAAM and IMA/EVM : caam_rsa_enc: DECO: desc idx 7: Protocol Size Error

On 4/11/2018 8:26 PM, Fabio Estevam wrote: > Hi Horia, > > On Wed, Apr 11, 2018 at 7:15 AM, Horia Geantă wrote: > >> You'd want to make sure rsa is offloaded to caam in this case - check in >> /proc/crypto. >> IIRC there are some i.mx parts that don't have support for

[PATCH] crypto: drbg - set freed buffers to NULL

Add the Fixes, CC stable tags. ---8<--- During freeing of the internal buffers used by the DRBG, set the pointer to NULL. It is possible that the context with the freed buffers is reused. In case of an error during initialization where the pointers do not yet point to allocated memory, the NULL