Re: [PATCH] avoid entropy starvation due to stack protection

Am 15.12.2012 20:15, schrieb Ondřej Bílka: Why not use nonblocking pool and seed nonblocking pool only with half of collected entropy to get /dev/random in almost all practical scenarios nonblocking? I would not recommend changing /dev/urandom. First, we would change the characteristic of a

Re: [PATCH] avoid entropy starvation due to stack protection

Am 16.12.2012 01:30, schrieb Theodore Ts'o: On Fri, Dec 14, 2012 at 06:36:41PM +0100, Stephan Mueller wrote: That patch is about one week from a mainline merge, btw. Initially I was also thinking about get_random_int. But stack protection depends on non-predictable numbers to ensure it cannot

[PATCH] Change userspace MKDEV, MAJOR, MINOR-macros from 8+8 bit, to 12+20 bit layout

Delete old userspace-only versions (8+8 bit). Instead expose the kernel-space definitions (12+20 bit). Signed-off-by: Stephan Mueller frukto...@gmail.com --- Browsing some code I found that user-space and kernel-space macros for (un-)packing major/minor device numbers differ. The user-space

Re: [PATCH] Change userspace MKDEV, MAJOR, MINOR-macros from 8+8 bit, to 12+20 bit layout

Am 14.09.2014 19:46, schrieb Greg KH: On Sun, Sep 14, 2014 at 07:35:28PM +0200, Stephan Müller wrote: Delete old userspace-only versions (8+8 bit). Instead expose the kernel-space definitions (12+20 bit). Signed-off-by: Stephan Mueller frukto...@gmail.com --- Browsing some code I found

Re: [PATCH] Revert "hwrng: core - zeroize buffers with random data"

Am Mittwoch, 8. Februar 2017, 17:57:23 CET schrieb Linus Torvalds: Hi Linus, > Stephan, Herbert? The zeroes in /dev/hwrng output are obviously > complete crap, so there's something badly wrong somewhere. > > The locking, for example, is completely buggered. There's even a > comment about it,

Re: [PATCH] random: Don't overwrite CRNG state in crng_initialize()

Am Donnerstag, 9. Februar 2017, 02:04:32 CET schrieb Alden Tondettar: Hi Alden, > On Thu, Feb 09, 2017 at 07:47:25AM +0100, Greg Kroah-Hartman wrote: > > On Wed, Feb 08, 2017 at 08:31:26PM -0700, Alden Tondettar wrote: > > > In short, the situation is: > > > > > > A) No usable hardware RNG or

Re: [PATCH 3/8] random: trigger random_ready callback upon crng_init == 1

Am Dienstag, 17. Januar 2017, 23:12:50 CET schrieb Theodore Ts'o: Hi Theodore, > On Tue, Dec 27, 2016 at 11:39:57PM +0100, Stephan Müller wrote: > > The random_ready callback mechanism is intended to replicate the > > getrandom system call behavior to in-kernel users. As the getra

Re: Problem with RSA test from testmgr

Am Dienstag, 28. Februar 2017, 16:59:53 CET schrieb Corentin Labbe: Hi Corentin, > hello > > I work on the sun8i-ce crypto accelerator and I have some problem with the > RSA part. > > The RSA register fail at the first RSA test (encrypt 512bit) with this > output: [ 8480.146843] alg: akcipher:

Re: Problem with RSA test from testmgr

Am Dienstag, 28. Februar 2017, 17:45:53 CET schrieb Corentin Labbe: Hi Corentin, > On Tue, Feb 28, 2017 at 05:08:35PM +0100, Stephan Müller wrote: > > Am Dienstag, 28. Februar 2017, 16:59:53 CET schrieb Corentin Labbe: > > > > Hi Corentin, > > > > > hello

Re: Problem with RSA test from testmgr

Am Donnerstag, 2. März 2017, 03:15:13 CET schrieb Tadeusz Struk: Hi Tadeusz, > > memset(ptextp, 0, 256); > memcpy(ptextp + 64 - 8, ptext_ex, plen); I actually have tested that and it did not return the data the kernel implementation would return Ciao Stephan

Re: Problem with RSA test from testmgr

Am Mittwoch, 1. März 2017, 13:04:14 CET schrieb Corentin Labbe: Hi Corentin, > > I got the following: > > [1.086228] alg: akcipher: encrypt test failed. Invalid output > [1.092196] : 6e 7c 8a 75 e7 30 80 d1 5e ab 9b db a2 cf ed db > [1.098882] 0010: c9 b2 db 43 bd 9a b9

Re: [PATCH v4 2/3] drivers: crypto: Add the Virtual Function driver for CPT

Am Donnerstag, 12. Januar 2017, 16:40:32 CET schrieb George Cherian: Hi George, > > > > Sure, please do not forget to invoke xts_verify_key. > > Should I be using xts_check_key or xts_verify_key? Both are identical except for the input parameter -- the one requires crypto_skcipher, the other

Re: [PATCH v4 2/3] drivers: crypto: Add the Virtual Function driver for CPT

Am Mittwoch, 11. Januar 2017, 16:58:17 CET schrieb George Cherian: Hi George, > I will add a seperate function for xts setkey and make changes as following. > > ... > > > >> + > >> +struct crypto_alg algs[] = { { > >> + .cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER | CRYPTO_ALG_ASYNC, > >> +

Re: [PATCH v4 2/3] drivers: crypto: Add the Virtual Function driver for CPT

Am Mittwoch, 11. Januar 2017, 10:56:50 CET schrieb George Cherian: Hi George, > +int cvm_enc_dec_setkey(struct crypto_ablkcipher *cipher, const u8 *key, > +u32 keylen) > +{ > + struct crypto_tfm *tfm = crypto_ablkcipher_tfm(cipher); > + struct cvm_enc_ctx *ctx =

Re: [PATCH v2 11/12] crypto: atmel-authenc: add support to authenc(hmac(shaX),Y(aes)) modes

Am Montag, 9. Januar 2017, 19:24:12 CET schrieb Cyrille Pitchen: Hi Cyrille, > >> +static int atmel_aes_authenc_copy_assoc(struct aead_request *req) > >> +{ > >> + size_t buflen, assoclen = req->assoclen; > >> + off_t skip = 0; > >> + u8 buf[256]; > >> + > >> + while (assoclen) { > >> +

Re: [PATCH v2 11/12] crypto: atmel-authenc: add support to authenc(hmac(shaX),Y(aes)) modes

Am Donnerstag, 22. Dezember 2016, 17:38:00 CET schrieb Cyrille Pitchen: Hi Cyrille, > This patchs allows to combine the AES and SHA hardware accelerators on > some Atmel SoCs. Doing so, AES blocks are only written to/read from the > AES hardware. Those blocks are also transferred from the AES to

[ANNOUNCE] /dev/random - a new approach (code for 4.10-rc1)

Hi, The patch set that can be downloaded at [1] provides a different approach to / dev/random which I call Linux Random Number Generator (LRNG) to collect entropy within the Linux kernel. The main improvements compared to the legacy /dev/random is to provide sufficient entropy during boot time

[PATCH 0/8] random: cleanup of code after removal of nonblocking pool

Hi Ted, with the removal of the nonblocking_pool, several code paths are now unused which were only applicable to the nonblocking pool. This patch set removes these unused code paths. Also, a code path in the add_interrupt_randomness function that is never used is removed. In addition, the FIPS

[PATCH 2/8] random: remove stale urandom_init_wait

The urandom_init_wait wait queue is a left over from the pre-ChaCha20 times and can therefore be savely removed. Signed-off-by: Stephan Mueller --- drivers/char/random.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/char/random.c b/drivers/char/random.c index

[PATCH 6/8] random: fix comment for unused random_min_urandom_seed

The variable random_min_urandom_seed is not needed any more as it defined the reseeding behavior of the nonblocking pool. Though it is not needed any more, it is left in the code for user space interface compatibility. Signed-off-by: Stephan Mueller ---

[PATCH 1/8] random: remove stale maybe_reseed_primary_crng

>From 5e84a71d4c4b3c7f015878c0907102634603d270 Mon Sep 17 00:00:00 2001 From: Stephan Mueller Date: Thu, 15 Dec 2016 12:42:33 +0100 Subject: The function maybe_reseed_primary_crng is not used anywhere and thus can be removed. Besides, it contains the check crng_init >

[PATCH 3/8] random: trigger random_ready callback upon crng_init == 1

The random_ready callback mechanism is intended to replicate the getrandom system call behavior to in-kernel users. As the getrandom system call unblocks with crng_init == 1, trigger the random_ready wakeup call at the same time. Signed-off-by: Stephan Mueller ---

[PATCH 5/8] random: remove variable limit

The variable limit was used to identify the nonblocking pool's unlimited random number generation. As the nonblocking pool is a thing of the past, remove the limit variable and any conditions around it (i.e. preserve the branches for limit == 1). Signed-off-by: Stephan Mueller

[PATCH 7/8] random: remove noop function call to xfer_secondary_pool

Since the introduction of the ChaCha20 DRNG, extract_entropy is only invoked with the input_pool. For this entropy pool, xfer_secondary_pool is a no-op and can therefore be safely removed. Signed-off-by: Stephan Mueller --- drivers/char/random.c | 1 - 1 file changed, 1

[PATCH 8/8] random: move FIPS continuous test to output functions

The current lockation of the FIPS continuous self test covers the input_pool only. However, the FIPS continuous self test shall cover the output of the random number generator, i.e. the blocking pool and the ChaCha20 DRNG. This patch therefore moves the continuous test to the output function used

[PATCH 4/8] random: remove unused branch in hot code path

The variable ip is defined to be a __u64 which is always 8 bytes on any architecture. Thus, the check for sizeof(ip) > 4 will always be true. As the check happens in a hot code path, remove the branch. Signed-off-by: Stephan Mueller --- drivers/char/random.c | 3 +-- 1

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 v2 1/3] crypto: hw_random - Add new Exynos RNG driver

Am Freitag, 24. März 2017, 19:26:04 CET schrieb Krzysztof Kozlowski: Hi Krzysztof, > +static unsigned int exynos_rng_copy_random(struct exynos_rng_dev *rng, > +u8 *dst, unsigned int dlen) > +{ > + unsigned int cnt = 0; > + int i, j; > + u32

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

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; > >> > + } > >> >

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 v2 1/3] crypto: hw_random - Add new Exynos RNG driver

Am Samstag, 25. März 2017, 08:36:48 CET schrieb Krzysztof Kozlowski: Hi Krzysztof, > On Fri, Mar 24, 2017 at 09:41:59PM +0100, Stephan Müller wrote: > > Am Freitag, 24. März 2017, 19:26:04 CET schrieb Krzysztof Kozlowski: > > > > Hi Krzysztof, > >

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

Am Dienstag, 28. März 2017, 18:48:24 CEST schrieb Krzysztof Kozlowski: Hi Krzysztof, > I tested a little bit and: > 1. Seeding with some value > 2. generating random, > 3. kcapi_rng_destroy+kcrng_init, (I cannot do a hardware reset except >reboot of entire system) > 4. seeding with the same

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

>nor for periodic re-seed). Instead the driver will just generate new > random numbers (suggested by Stephan Müller). Thank you. Regarding the cryptographic aspects: Reviewed-by: Stephan Müller <smuel...@chronox.de> Ciao Stephan

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

Am Montag, 27. März 2017, 06:23:11 CEST schrieb PrasannaKumar Muralidharan: Hi PrasannaKumar, > > 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

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

Am Freitag, 24. März 2017, 15:24:44 CET schrieb Krzysztof Kozlowski: Hi Krzysztof, > + > +static int exynos_rng_set_seed(struct exynos_rng_dev *rng, > +const u8 *seed, unsigned int slen) > +{ > + int ret, i; > + u32 val; > + > + dev_dbg(rng->dev, "Seeding

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

Am Freitag, 24. März 2017, 15:43:48 CET schrieb Krzysztof Kozlowski: Hi Krzysztof, > On Fri, Mar 24, 2017 at 03:37:59PM +0100, Stephan Müller wrote: > > Am Freitag, 24. März 2017, 15:24:44 CET schrieb Krzysztof Kozlowski: > > > > Hi Krzysztof, > > > > > + &

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

Am Freitag, 24. März 2017, 15:51:56 CET schrieb Krzysztof Kozlowski: Hi Krzysztof, > > I'll use the generated random numbers. If you do that, may I propse that you update this seed field periodically? E.g. with every (or every other) user request for random data, you may update that field

Re: [ANNOUNCE] /dev/random - a new approach (code for 4.11-rc1)

Am Samstag, 18. März 2017, 11:11:57 CET schrieb Jeffrey Walton: Hi Jeffrey, > > The design and implementation is driven by a set of goals described in [2] > > that the LRNG completely implements. Furthermore, [2] includes a > > comparison with RNG design suggestions such as SP800-90B, SP800-90C,

Re: [ANNOUNCE] /dev/random - a new approach (code for 4.11-rc1)

Am Samstag, 18. März 2017, 14:43:18 CET schrieb Jeffrey Walton: Hi Jeffrey, > > I am not sure how this statement relates to the quote above. RDSEED is the > > CBC-MACed output of the flip-flop providing the raw noise. > > > > RDRAND is the output of the SP800-90A CTR DRBG that is seeded by the

Re: [PATCH] crypto: testmgr - mark ctr(des3_ede) as fips_allowed

Am Montag, 20. März 2017, 21:28:05 CET schrieb Marcelo Henrique Cerri: Hi Marcelo, > 3DES is missing the fips_allowed flag for CTR mode. > > Signed-off-by: Marcelo Henrique Cerri Acked-by: Stephan Mueller Ciao Stephan

Re: [ANNOUNCE] /dev/random - a new approach (code for 4.11-rc1)

Am Freitag, 17. März 2017, 16:31:29 CET schrieb Jason A. Donenfeld: Hi Jason, > Hey Stephan, > > Have you considered submitting this without so many options? For > example -- just unconditionally using ChaCha20 instead of the > configurable crypto API functions? And either removing the FIPS140

Re: [PATCH] KEYS: fix build failure with CONFIG_KEY_DH_OPERATIONS

Am Dienstag, 11. April 2017, 14:45:12 CEST schrieb Tobias Regnery: Hi Tobias, > With CONFIG_KEY_DH_OPERATIONS=y and CONFIG_CRYPTO=m we get the following > link error: Thanks for the patch. I just released the very same patch :-) David, I guess it makes more sense now to simply apply that patch

Re: [PATCH v2 6/9] staging: ccree: add FIPS support

Am Donnerstag, 20. April 2017, 15:13:00 CEST schrieb Gilad Ben-Yossef: Hi Gilad, > +/* The function verifies that tdes keys are not weak.*/ > +static int ssi_fips_verify_3des_keys(const u8 *key, unsigned int keylen) > +{ > +#ifdef CCREE_FIPS_SUPPORT > +tdes_keys_t *tdes_key =

Re: [PATCH v2 6/9] staging: ccree: add FIPS support

Am Sonntag, 23. April 2017, 11:48:58 CEST schrieb Gilad Ben-Yossef: Hi Gilad, > I do wonder if there is value in alternate behavior of stopping crypto > API on FIPS error rather than a panic though. I will try to get an > explanation why we do it this way. In FIPS, all crypto function must

Re: [PATCH v2 6/9] staging: ccree: add FIPS support

Am Montag, 24. April 2017, 08:06:09 CEST schrieb Gilad Ben-Yossef: Hi Gilad, > > Well, it turns out there is and we do :-) > > This is from crypto/des_generic.c: > > /* > * RFC2451: > * > * For DES-EDE3, there is no known need to reject weak or > * complementation keys. Any weakness

Re: [PATCH v2 6/9] staging: ccree: add FIPS support

Am Montag, 24. April 2017, 08:16:50 CEST schrieb Stephan Müller: Hi Gilad, > > > > int __des3_ede_setkey(u32 *expkey, u32 *flags, const u8 *key, > > > > unsigned int keylen) > > > > However, this does not check that k1 == k3. In thi

Re: [PATCH v2 6/9] staging: ccree: add FIPS support

Am Montag, 24. April 2017, 09:04:13 CEST schrieb Gilad Ben-Yossef: Hi Gilad, > > Thanks you for the clarification. As I think is obvious by now I am > not a FIPS expert by any stretch. > > Isn't the requirements on DRBG or KDF invocations pertain to key > generation only? > What happens if you

Re: [PATCH v2 6/9] staging: ccree: add FIPS support

Am Montag, 24. April 2017, 09:07:45 CEST schrieb Gilad Ben-Yossef: Hi Gilad, > I guess we could change the function to indicate that a key is valid > for decryption but not encryption > and have the implementation limiting based on that if there is an > interest in SP800-131A compliance. I

[ANNOUNCE] /dev/random - a new approach (code for 4.11-rc1)

Hi, The patch set that can be downloaded at [1] provides a different approach to / dev/random which I call Linux Random Number Generator (LRNG) to collect entropy within the Linux kernel. The main improvements compared to the legacy /dev/random is to provide sufficient entropy during boot time

[PATCH] Constantly reseed nonblocking_pool during initialization

Hi Ted, The issue fixed by the patch below is visible in all kernels between 3.13 and 4.7. The patch is developed against 4.7.0. It is tested against 4.4.53. If you concur, I would recommend to send it to stable. ---8<--- The nonblocking_pool is reseeded after the expiry of

Re: [PATCH] Crypto_user: Make crypto user API available for all net ns

Am Donnerstag, 13. Juli 2017, 16:22:32 CEST schrieb Christian Langrock: Hi Christian, > With this patch it's possible to use crypto user API form all > network namespaces, not only form the initial net ns. Is this wise? The crypto_user interface allows root users to change settings in the

Re: Decreasing time for `rsa_init`

Am Mittwoch, 12. Juli 2017, 12:59:58 CEST schrieb Paul Menzel: Hi Paul, > Dear Linux crypto folks, > > > Building CRYPTO_RSA not as module, but into the Linux kernel, > `rsa_init()` takes 130 ms on an ASRock E350M1. > > (Timings are shown by adding `initcall_debug` to Linux command line [1].

[RFC PATCH v12 2/4] random: conditionally compile code depending on LRNG

When selecting the LRNG for compilation, disable add_disk_randomness and its supporting function. CC: Greg Kroah-Hartman CC: Arnd Bergmann CC: Jason A. Donenfeld Signed-off-by: Stephan Mueller ---

[RFC PATCH v12 0/4] /dev/random - a new approach

Hi, after distributing patches for the Linux-RNG - a new approach for the last half year, I would like to submit this RFC for inclusion into the kernel. The following patch set provides a different approach to /dev/random which I call Linux Random Number Generator (LRNG) to collect entropy

[RFC PATCH v12 4/4] LRNG - enable compile

Add LRNG compilation support. CC: Greg Kroah-Hartman CC: Arnd Bergmann CC: Jason A. Donenfeld Signed-off-by: Stephan Mueller --- drivers/char/Kconfig | 10 ++ drivers/char/Makefile | 10 +- 2

Re: [RFC PATCH v12 2/4] random: conditionally compile code depending on LRNG

Am Dienstag, 18. Juli 2017, 10:13:55 CEST schrieb Arnd Bergmann: Hi Arnd, > On Tue, Jul 18, 2017 at 9:58 AM, Stephan Müller <smuel...@chronox.de> wrote: > > When selecting the LRNG for compilation, disable add_disk_randomness and > > its supporting function. > > >

Re: [RFC PATCH v12 1/4] crypto: make Jitter RNG directly accessible

Am Dienstag, 18. Juli 2017, 10:49:59 CEST schrieb Greg Kroah-Hartman: Hi Greg, > > > This issue was discussed during the inclusion of the Jitter RNG C code > > into > > the kernel. > > Ok, that was then, this is now, why not change it now? How does > including types.h change anything? At the

Re: [RFC PATCH v12 2/4] random: conditionally compile code depending on LRNG

Am Dienstag, 18. Juli 2017, 10:47:00 CEST schrieb Arnd Bergmann: Hi Arnd, > On Tue, Jul 18, 2017 at 10:37 AM, Stephan Müller <smuel...@chronox.de> wrote: > > Am Dienstag, 18. Juli 2017, 10:13:55 CEST schrieb Arnd Bergmann: > >> On Tue, Jul 18, 2017 at 9:58 A

Re: [RFC PATCH v12 4/4] LRNG - enable compile

Am Dienstag, 18. Juli 2017, 10:51:41 CEST schrieb Arnd Bergmann: Hi Arnd, > On Tue, Jul 18, 2017 at 9:59 AM, Stephan Müller <smuel...@chronox.de> wrote: > > Add LRNG compilation support. > > > > diff --git a/drivers/char/Makefile b/drivers/char/Makefile > &

Re: [RFC PATCH v12 1/4] crypto: make Jitter RNG directly accessible

Am Dienstag, 18. Juli 2017, 11:16:10 CEST schrieb Arnd Bergmann: Hi Arnd, > I guess ideally you just move the inner half of lrng_get_jent(), > i.e. everything inside of the spinlock, plus the buffer, into that file. > That should keep the low-level side separate from the caller. Yes, I concur.

[RFC PATCH v12 1/4] crypto: make Jitter RNG directly accessible

To support the LRNG operation which allocates the Jitter RNG separately from the kernel crypto API, extract the relevant information into a separate header file. CC: Greg Kroah-Hartman CC: Arnd Bergmann CC: Jason A. Donenfeld

[RFC PATCH v12 3/4] Linux Random Number Generator

The LRNG with the following properties: * noise source: interrupts timing with fast boot time seeding * lockless LFSR to collect raw entropy * use of standalone ChaCha20 based RNG with the option to use a different DRNG selectable at compile time * "atomic" seeding of secondary DRBG to

Re: [RFC PATCH v12 1/4] crypto: make Jitter RNG directly accessible

Am Dienstag, 18. Juli 2017, 10:30:14 CEST schrieb Greg Kroah-Hartman: Hi Greg, > > +typedefunsigned long long __u64; > > +typedeflong long __s64; > > types.h already has these defines, don't re-typedef them again... The issue is that the C code is compiled without

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

Am Dienstag, 18. Juli 2017, 10:32:10 CEST schrieb Greg Kroah-Hartman: Hi Greg, > external references do not last as long as the kernel change log does :( What would be the best way to cite a 50+ page document? I got a suggestion to include the ASCII version of the document into Documentation/

Re: [RFC PATCH v12 1/4] crypto: make Jitter RNG directly accessible

Am Dienstag, 18. Juli 2017, 11:02:02 CEST schrieb Arnd Bergmann: Hi Arnd, > > I can see why the jitterentropy implementation avoids using kernel headers, > the problem now is that part of it gets moved into a new header, and that > already violates the original principle. > > From my reading of

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

Am Dienstag, 18. Juli 2017, 10:52:12 CEST schrieb Greg Kroah-Hartman: Hi Greg, > > > I have stated the core concerns I have with random.c in [1]. To remedy > > these core concerns, major changes to random.c are needed. With the past > > experience, I would doubt that I get the changes into

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

Am Dienstag, 18. Juli 2017, 23:08:16 CEST schrieb Theodore Ts'o: Hi Theodore, > > I've been trying to take the best features and suggestions from your > proposal and integrating them into /dev/random already. Things that > I've chosen not take is basically because I disbelieve that the Jitter >

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

Am Mittwoch, 19. Juli 2017, 03:51:33 CEST schrieb Theodore Ts'o: Hi Theodore, > If the real unpredictability is really coming from the interrupts > changing the state of the CPU microarchitecture, the real question is > how many interrupts do you need before you consider things > "unpredictable"

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

Am Freitag, 21. Juli 2017, 05:08:47 CEST schrieb Theodore Ts'o: Hi Theodore, > On Thu, Jul 20, 2017 at 09:00:02PM +0200, Stephan Müller wrote: > > I concur with your rationale where de-facto the correlation is effect is > > diminished and eliminated with the fast_pool and the

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

Am Mittwoch, 19. Juli 2017, 19:26:03 CEST schrieb Theodore Ts'o: Hi Theodore, > On Wed, Jul 19, 2017 at 08:22:18AM +0200, Stephan Müller wrote: > > In the email [1] I have expressed the core concerns I see -- none of them > > address the need to keep the Jitter RNG as o

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

Am Freitag, 21. Juli 2017, 17:09:11 CEST schrieb Arnd Bergmann: Hi Arnd, > On Fri, Jul 21, 2017 at 10:57 AM, Stephan Müller <smuel...@chronox.de> wrote: > > Am Freitag, 21. Juli 2017, 05:08:47 CEST schrieb Theodore Ts'o: > >> Um, the timer is the largest number of

[PATCH v11 2/5] random: conditionally compile code depending on LRNG

When selecting the LRNG for compilation, disable the legacy /dev/random implementation. The LRNG is a drop-in replacement for the legacy /dev/random which implements the same in-kernel and user space API. Only the hooks of /dev/random into other parts of the kernel need to be disabled.

[PATCH v11 3/5] Linux Random Number Generator

The LRNG with the following properties: * noise source: interrupts timing with fast boot time seeding * lockless LFSR to collect raw entropy * use of kernel crypto API DRBG * in case kernel crypto API is not compiled, use standalone ChaCha20 based RNG * used cipher types for hashes and DRBG

[PATCH v11 4/5] LRNG - enable compile

Add LRNG compilation support. Signed-off-by: Stephan Mueller --- drivers/char/Kconfig | 10 ++ drivers/char/Makefile | 10 +- 2 files changed, 19 insertions(+), 1 deletion(-) diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig index 31adbeb..ee26190

[PATCH v11 0/5] /dev/random - a new approach

Hi, The following patch set provides a different approach to /dev/random which I call Linux Random Number Generator (LRNG) to collect entropy within the Linux kernel. The main improvements compared to the legacy /dev/random is to provide sufficient entropy during boot time as well as in virtual

[PATCH v11 5/5] LRNG - add ChaCha20 support

In case the kernel crypto API is not compiled, use ChaCha20 stream cipher as DRNG. The LRNG ChaCha20 support provides the DRNG implementation with the generate and update functions. Th DRNG implements enhanced backward secrecy by re-creating the entire internal state after generating random

[PATCH v11 1/5] crypto: DRBG - externalize DRBG functions for LRNG

This patch allows several DRBG functions to be called by the LRNG kernel code paths outside the drbg.c file. Signed-off-by: Stephan Mueller --- crypto/drbg.c | 11 +-- include/crypto/drbg.h | 7 +++ 2 files changed, 12 insertions(+), 6 deletions(-)

Re: [PATCH v11 4/5] LRNG - enable compile (fwd)

ile > > CC: kbuild-...@01.org > In-Reply-To: <2619717.m11260e...@positron.chronox.de> > TO: "Stephan Müller" <smuel...@chronox.de> > CC: linux-kernel@vger.kernel.org > CC: linux-cry...@vger.kernel.org, "Jason A. Donenfeld" <ja...@zx2c4.com> >

Re: [PATCH] fix ptr_ret.cocci warnings

Am Montag, 15. Mai 2017, 12:52:11 CEST schrieb Julia Lawall: Hi Julia, > Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR > > Generated by: scripts/coccinelle/api/ptr_ret.cocci Thank you, included -- it will be present in the next release. Ciao Stephan

Re: jitterentropy init test failure on ARMv7 with gcc 6.2

Am Mittwoch, 10. Mai 2017, 17:40:40 CEST schrieb Octavian Purdila: Hi Octavian, > Hi Stephan, > > Recently I started seeing the following on some of our ARMv7 boards > (IMX7D): > > jitterentropy: Initialization failed with host not compliant with > requirements: 2 > > and I traced this to the

Re: [PATCH v1 3/3] crypto: cavium - Register the CNN55XX supported crypto algorithms.

Am Donnerstag, 11. Mai 2017, 14:18:34 CEST schrieb srikanth jampala: Hi srikanth, > Hi Stephan, > > On Wednesday 10 May 2017 07:26 PM, Stephan Müller wrote: > > Am Mittwoch, 10. Mai 2017, 15:06:40 CEST schrieb Srikanth Jampala: > > > > Hi Srikanth, > &g

Re: [PATCH v1 3/3] crypto: cavium - Register the CNN55XX supported crypto algorithms.

Am Mittwoch, 10. Mai 2017, 15:06:40 CEST schrieb Srikanth Jampala: Hi Srikanth, In general: you are using the ablkcipher API. I think it is on its way out and being replaced with skcipher. Maybe it makes sense to replace it here too. It could be as simple as s/ ablkcipher/skcipher/g > +static

Re: [kernel-hardening] Re: [PATCH v4 06/13] iscsi: ensure RNG is seeded before use

Am Montag, 26. Juni 2017, 03:23:09 CEST schrieb Nicholas A. Bellinger: Hi Nicholas, > Hi Stephan, Lee & Jason, > > (Adding target-devel CC') > > Apologies for coming late to the discussion. Comments below. > > On Sun, 2017-06-18 at 10:04 +0200, Stephan Müller wrote:

Re: get_random_bytes returns bad randomness before seeding is complete

Am Freitag, 2. Juni 2017, 16:59:56 CEST schrieb Jason A. Donenfeld: Hi Jason, > > Alternatively, I'm open to other solutions people might come up with. How about stirring in some data from the Jitter RNG that we have in the kernel already and that is used for the DRBG in case get_random_bytes

Re: get_random_bytes returns bad randomness before seeding is complete

Am Freitag, 2. Juni 2017, 16:59:56 CEST schrieb Jason A. Donenfeld: Hi Jason, > Alternatively, I'm open to other solutions people might come up with. One addition, there is an issue (I would call it a bug) in random.c before 4.8 where the nonblocking_pool is not reseeded during early boot even

Re: get_random_bytes returns bad randomness before seeding is complete

Am Sonntag, 4. Juni 2017, 00:54:39 CEST schrieb Jeffrey Walton: Hi Jeffrey, > On Sat, Jun 3, 2017 at 5:45 PM, Sandy Harris wrote: > > ... > > Of course this will fail on systems with no high-res timer. Are there > > still some of those? It might be done in about 1000

Re: [kernel-hardening] Re: [PATCH v3 04/13] crypto/rng: ensure that the RNG is ready before using

Am Mittwoch, 7. Juni 2017, 00:19:10 CEST schrieb Henrique de Moraes Holschuh: Hi Henrique, > On that same idea, one could add an early_initramfs handler for entropy > data. Any data that comes from outside during the boot process, be it some NVRAM location, the /var/lib...seed file for

Re: [PATCH v2 2/2] crypto: engine - Permit to enqueue skcipher request

Am Dienstag, 6. Juni 2017, 15:44:17 CEST schrieb Corentin Labbe: Hi Corentin, > The crypto engine could actually only enqueue hash and ablkcipher request. > This patch permit it to enqueue skcipher requets by adding all necessary > functions. > The only problem is that ablkcipher and skcipher id

Re: [kernel-hardening] Re: [PATCH v4 13/13] random: warn when kernel uses unseeded randomness

Am Donnerstag, 15. Juni 2017, 13:03:48 CEST schrieb Michael Ellerman: Hi Michael, > > Even with this patch, it's still pretty spammy (today's linux-next): > I would think that the issue regarding the logging is relevant for cryptographic use cases or use cases requiring strong random numbers

Re: [kernel-hardening] Re: [PATCH v4 06/13] iscsi: ensure RNG is seeded before use

Am Samstag, 17. Juni 2017, 05:45:57 CEST schrieb Lee Duncan: Hi Lee, > In your testing, how long might a process have to wait? Are we talking > seconds? Longer? What about timeouts? > In current kernels (starting with 4.8) this timeout should clear within a few seconds after boot. In older

Re: [PATCH 0/6] Constant Time Memory Comparisons Are Important

Am Samstag, 10. Juni 2017, 04:59:06 CEST schrieb Jason A. Donenfeld: Hi Jason, > Whenever you're comparing two MACs, it's important to do this using > crypto_memneq instead of memcmp. With memcmp, you leak timing information, > which could then be used to iteratively forge a MAC. This is far too

Re: [kernel-hardening] Re: [PATCH v4 13/13] random: warn when kernel uses unseeded randomness

Am Sonntag, 18. Juni 2017, 17:46:25 CEST schrieb Theodore Ts'o: Hi Theodore, > > IMHO, users using the get_random_u64 or get_random_u32 are use cases that > > do not require a fully seeded DRNG thus do not need a cryptographically > > strong random number. Hence, I would think that the logging

Re: [kernel-hardening] Re: [PATCH v3 04/13] crypto/rng: ensure that the RNG is ready before using

Am Dienstag, 6. Juni 2017, 19:03:19 CEST schrieb Theodore Ts'o: Hi Theodore, > On Tue, Jun 06, 2017 at 02:34:43PM +0200, Jason A. Donenfeld wrote: > > Yes, I agree whole-heartedly. A lot of people have proposals for > > fixing the direct idea of entropy gathering, but for whatever reason, > >

Crash during fork/clone

Hi, in unregular intervals, I see the following crash. This crash happens if I start a test run that executes a large number of scripts sequentially. It happens with vanilla kernels from kernel.org and Fedora kernels. If my memory serves me well, I saw the first types of these crashes with

Re: general protection fault in scatterwalk_copychunks

Am Dienstag, 28. November 2017, 18:24:01 CET schrieb syzbot: Hi, > Hello, > > syzkaller hit the following crash on > 1ea8d039f9edcfefb20d8ddfe136930f6e551529 > git://git.cmpxchg.org/linux-mmots.git/master > compiler: gcc (GCC) 7.1.1 20170620 > .config is attached > Raw console output is

[PATCH v2] crypto: AF_ALG - race-free access of encryption flag

Hi Herbert, I verified the correctnes of the patch with Eric's test program. Without the patch, the issue is present. With the patch, the kernel happily lives ever after. Changes v2: change the submission into a proper patch Ciao Stephan ---8<--- The function af_alg_get_rsgl may sleep to wait

Re: general protection fault in crypto_remove_spawns

Am Montag, 27. November 2017, 19:56:46 CET schrieb syzbot: Hi Herbert, The issue seems to trigger a bug whose results we have seen before. When starting the reproducer and stopping it shortly thereafter, I see the numerous identical entries in /proc/crypto: name : cmac(des3_ede)

Re: [PATCH 2/3] hwrng: exynos - add Samsung Exynos True RNG driver

Am Freitag, 24. November 2017, 13:09:06 CET schrieb Krzysztof Kozlowski: Hi Krzysztof, > >> > >> 1. I was rather thinking about extending existing exynos-rng.c [1] so > >> it would be using TRNG as seed for PRNG as this gives you much more > >> random data. Instead you developed totally separate

[PATCH v2] crypto: AF_ALG - wait for data at beginning of recvmsg

The wait for data is a non-atomic operation that can sleep and therefore potentially release the socket lock. The release of the socket lock allows another thread to modify the context data structure. The waiting operation for new data therefore must be called at the beginning of recvmsg. This

  1   2   3   4   >