Re: [PATCH v3 1/3] crypto: hw_random - Add new Exynos RNG driver

Am Sonntag, 26. März 2017, 20:00:12 CEST schrieb Krzysztof Kozlowski: Hi Krzysztof, > > Would it make sense to add another outer loop here to allow all of slen to > > be injected into the DRNG? Note, in some cases, a user wants to add more > > seed into the DRNG than the actual seed size. In

Re: [PATCH v3 1/3] crypto: hw_random - Add new Exynos RNG driver

> Oh my, if you are right with your first guess, this is a bad DRNG design. > > Just out of curiousity: what happens if a caller invokes the seed function > twice or more times (each time with the sufficient amount of bits)? What is > your guess here? Should the second seed use the random data

Re: [PATCH v3 1/3] crypto: hw_random - Add new Exynos RNG driver

Am Sonntag, 26. März 2017, 18:01:26 CEST schrieb Krzysztof Kozlowski: Hi Krzysztof, > > > + if (slen < EXYNOS_RNG_SEED_SIZE) { > > > + dev_warn(rng->dev, "Seed too short (only %u bytes)\n", > > > slen); + return -EINVAL; > > > + } > > > > Will it be

[PATCH 3/7] crypto: aes/x86 - eliminate set_key() handling for IRQ context

The crypto API does not allow setkey() to be used in interrupt context, and so the fallback to crypto_aes_expand_key() is dead code which can be eliminated. This removes a dependency on crypto_aes_expand_key() which will be fulfilled by another driver after a subsequent patch. Signed-off-by: Ard

Re: [PATCH v3 1/3] crypto: hw_random - Add new Exynos RNG driver

On Sun, Mar 26, 2017 at 07:05:48PM +0200, Stephan Müller wrote: > Am Sonntag, 26. März 2017, 18:46:02 CEST schrieb PrasannaKumar Muralidharan: > > HiKrzysztof, > > > >> > + if (slen < EXYNOS_RNG_SEED_SIZE) { > > >> > + dev_warn(rng->dev, "Seed too short (only %u

Re: [PATCH 6/7] crypto: aes - split off shared AES tables and key expansion routines

On Sun, 26 Mar 2017, Ard Biesheuvel wrote: > [...] > +static const u32 rco_tab[10] = { 1, 2, 4, 8, 16, 32, 64, 128, 27, 54 }; You could consider using u8 for this table. This is a tiny space saving and normally it shouldn't make the runtime any slower on most architectures. Nicolas

Re: [PATCH v3 1/3] crypto: hw_random - Add new Exynos RNG driver

On 26 March 2017 at 21:31, Krzysztof Kozlowski wrote: > On Sun, Mar 26, 2017 at 08:50:42PM +0530, PrasannaKumar Muralidharan wrote: >> .Have some minor comments. Please feel free to correct if I am wrong. >> >> On 25 March 2017 at 21:56, Krzysztof Kozlowski

Re: [PATCH v3 1/3] crypto: hw_random - Add new Exynos RNG driver

Am Samstag, 25. März 2017, 17:26:52 CEST schrieb Krzysztof Kozlowski: Hi Krzysztof, > +static int exynos_rng_set_seed(struct exynos_rng_dev *rng, > +const u8 *seed, unsigned int slen) > +{ > + u32 val; > + int i; > + > + dev_dbg(rng->dev, "Seeding with %u

Re: [PATCH v3 1/3] crypto: hw_random - Add new Exynos RNG driver

On Sun, Mar 26, 2017 at 07:11:28PM +0200, Stephan Müller wrote: > Am Samstag, 25. März 2017, 17:26:52 CEST schrieb Krzysztof Kozlowski: > > +static int exynos_rng_set_seed(struct exynos_rng_dev *rng, > > + const u8 *seed, unsigned int slen) > > +{ > > + u32 val; > > +

Re: [PATCH 0/7] crypto: aes - allow generic AES to be omitted

On Sun, 26 Mar 2017, 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

Re: [PATCH v3 1/3] crypto: hw_random - Add new Exynos RNG driver

Am Sonntag, 26. März 2017, 18:46:02 CEST schrieb PrasannaKumar Muralidharan: Hi Krzysztof, > >> > + if (slen < EXYNOS_RNG_SEED_SIZE) { > >> > + dev_warn(rng->dev, "Seed too short (only %u bytes)\n", > >> > slen); + return -EINVAL; > >> > + } > >> >

[PATCH 6/7] crypto: aes - split off shared AES tables and key expansion routines

Various accelerated scalar AES drivers reuse the lookup tables and key expansion routines in crypto/aes_generic.o, but not the actual encryption/decryption routines themselves. So split them off into a separate module with its own Kconfig symbol CRYPTO_AES_CORE. Signed-off-by: Ard Biesheuvel

[PATCH 7/7] crypto: aes - allow alternative AES drivers to fulfil AES dependency

Allow other AES drivers than crypto/aes_generic.o to fulfil soft dependencies on AES. This allows CRYPTO_AES to be disabled if no hard dependencies on it are enabled. Signed-off-by: Ard Biesheuvel --- arch/arm/crypto/Kconfig | 1 + arch/arm64/crypto/Kconfig | 1 +

[PATCH 5/7] crypto: aes - move crypto_aes_expand_key() to fixed-time AES driver

Both the original generic AES code and the new fixed-time AES driver contain C implementations of crypto_aes_expand_key() which are functionally equivalent to each other. However, the former version pulls in crypto/aes_generic.o in its entirety, consisting of 16 KB of lookup tables and fully

[PATCH 2/7] crypto: aes - add new Kconfig symbol for soft dependency on AES

Many drivers have a soft dependency on the availability of any crypto driver that implements the "aes" cipher. To separate this notion from the link time dependency on the tables or routines in the generic AES driver, introduce a new Kconfig symbol CRYPTO_NEED_AES and use it to replace any

[PATCH 4/7] crypto: aes/arm64 - eliminate dependency on crypto_aes_set_key()

Call crypto_aes_expand_key() rather than crypto_aes_set_key() so that we can move to another implementation of it in a subsequent patch. Signed-off-by: Ard Biesheuvel --- arch/arm64/crypto/aes-glue.c | 12 +--- 1 file changed, 9 insertions(+), 3 deletions(-)

[PATCH 0/7] crypto: aes - allow generic AES to be omitted

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

Re: [PATCH 6/7] crypto: aes - split off shared AES tables and key expansion routines

On 26 March 2017 at 20:50, Nicolas Pitre wrote: > On Sun, 26 Mar 2017, Ard Biesheuvel wrote: > >> [...] >> +static const u32 rco_tab[10] = { 1, 2, 4, 8, 16, 32, 64, 128, 27, 54 }; > > You could consider using u8 for this table. This is a tiny space saving > and normally

[PATCH 1/7] drivers/crypto/Kconfig: drop bogus CRYPTO_AES dependencies

In preparation of fine tuning the dependency relations between the accelerated AES drivers and the core support code, let's remove the dependency declarations that are false. None of these modules have link time dependencies on the generic AES code, nor do they declare any AES algos with

Re: [PATCH] padata: avoid race in reordering

I've got a few other races in padata, I think, that I'm working on fixing. If these pan out, I'll submit them exclusively to -crypto instead of -netdev, to avoid this confusion next time. Of course, if I'm able to fix these, then I'll probably be bald from pulling my hair out during this insane

Re: [PATCH v3 1/3] crypto: hw_random - Add new Exynos RNG driver

.Have some minor comments. Please feel free to correct if I am wrong. On 25 March 2017 at 21:56, Krzysztof Kozlowski wrote: > Replace existing hw_ranndom/exynos-rng driver with a new, reworked one. > This is a driver for pseudo random number generator block which on > Exynos4

Re: [PATCH v3 1/3] crypto: hw_random - Add new Exynos RNG driver

On Sun, Mar 26, 2017 at 08:50:42PM +0530, PrasannaKumar Muralidharan wrote: > .Have some minor comments. Please feel free to correct if I am wrong. > > On 25 March 2017 at 21:56, Krzysztof Kozlowski wrote: > > Replace existing hw_ranndom/exynos-rng driver with a new, reworked