Re: crypto: FIPS 200 mode

Am Dienstag, dem 30.03.2021 um 15:26 -0700 schrieb Randy Dunlap: > > The Kconfig help text for CRYPTO_FIPS says > > config CRYPTO_FIPS > bool "FIPS 200 compliance" > ... > help >   This option enables the fips boot option which is >   required if you want the

Re: [PATCH v2] Documentation: crypto: add info about "fips=" boot option

Am Dienstag, dem 30.03.2021 um 15:44 -0700 schrieb Eric Biggers: > On Tue, Mar 30, 2021 at 09:38:55AM -0700, Randy Dunlap wrote: > > On 3/29/21 10:29 PM, Eric Biggers wrote: > > > On Mon, Mar 29, 2021 at 10:06:51PM -0700, Randy Dunlap wrote: > > > > Having just seen a report of using "fips=1" on

Re: [PATCH 3/5] crypto: add RFC5869 HKDF

Am Mittwoch, dem 06.01.2021 um 23:30 -0800 schrieb Eric Biggers: > On Mon, Jan 04, 2021 at 10:49:13PM +0100, Stephan Müller wrote: > > RFC5869 specifies an extract and expand two-step key derivation > > function. The HKDF implementation is provided as a service function that > > operates on a

Re: [PATCH 5/5] fs: use HKDF implementation from kernel crypto API

. > > > > Signed-off-by: Stephan Mueller > > --- > >  fs/crypto/Kconfig   |   2 +- > >  fs/crypto/fscrypt_private.h |   4 +- > >  fs/crypto/hkdf.c    | 108 +--- > >  3 files changed, 30 insertions(+), 84 d

Re: [PATCH 0/5] Add KDF implementations to crypto API

Am Montag, dem 04.01.2021 um 14:20 -0800 schrieb Eric Biggers: > On Mon, Jan 04, 2021 at 10:45:57PM +0100, Stephan Müller wrote: > > The HKDF addition is used to replace the implementation in the filesystem > > crypto extension. This code was tested by using an EXT4 encrypted file > > system that

Re: drivers/char/random.c needs a (new) maintainer

Am Mittwoch, dem 23.12.2020 um 15:32 +0100 schrieb Jason A. Donenfeld: > > I would, however, be interested in a keccak-based construction. But > just using the keccak permutation does not automatically make it > "SHA-3", so we're back at the same issue again. FIPS is simply not > interesting for

Re: [PATCH v4 4/5] crypto: hisilicon/hpre - add 'ECDH' algorithm

Am Mittwoch, dem 16.12.2020 um 10:39 +0800 schrieb yumeng: > > > > > Am Freitag, den 11.12.2020, 14:30 +0800 schrieb Meng Yu: > > > > > > +/* size in bytes of the n prime */ > > > +#define HPRE_ECC_NIST_P128_N_SIZE  16 > > > > Do we truly need P-128? Besides, I do not see that curve being

Re: [PATCH v4 5/5] crypto: hisilicon/hpre - add 'CURVE25519' algorithm

Am Freitag, den 11.12.2020, 14:30 +0800 schrieb Meng Yu: >    > +/* curve25519 */ > +static u64 curve25519_g_x[] = { 0x0009, 0x, > +   0x, 0x }; > +static u64 curve25519_p[] = { 0xffed,

Re: [PATCH v4 4/5] crypto: hisilicon/hpre - add 'ECDH' algorithm

Am Freitag, den 11.12.2020, 14:30 +0800 schrieb Meng Yu: > > +/* size in bytes of the n prime */ > +#define HPRE_ECC_NIST_P128_N_SIZE  16 Do we truly need P-128? Besides, I do not see that curve being defined in contemporary cipher specs. > +#define HPRE_ECC_NIST_P192_N_SIZE  24 >

Re: [PATCH v3 4/5] crypto: hisilicon/hpre - add 'ECDH' algorithm

Am Mittwoch, den 18.11.2020, 11:47 +0800 schrieb Meng Yu: Hi Meng, > Enable 'ECDH' algorithm in Kunpeng 930. > > Signed-off-by: Meng Yu > Reviewed-by: Zaibo Xu > --- >  drivers/crypto/hisilicon/hpre/hpre.h    |   2 +- >  drivers/crypto/hisilicon/hpre/hpre_crypto.c | 802 >

Re: [PATCH v36 00/13] /dev/random - a new approach

Am Montag, 19. Oktober 2020, 21:28:50 CET schrieb Stephan Müller: Hi, > > * Performance > > - Faster by up to 75% in the critical code path of the interrupt handler >depending on data collection size configurable at kernel compile time - >the default is about equal in performance with

Re: jitterentropy: `jent_mod_init()` takes 17 ms

Am Dienstag, 10. November 2020, 10:37:02 CET schrieb Paul Menzel: Hi Paul, > Dear Stephan, > > > Thank you for the quick reply. > > Am 10.11.20 um 10:25 schrieb Stephan Mueller: > > Am Montag, 9. November 2020, 20:31:02 CET schrieb Paul Menzel: > >

Re: jitterentropy: `jent_mod_init()` takes 17 ms

Am Montag, 9. November 2020, 20:31:02 CET schrieb Paul Menzel: Hi Paul, > Dear Linux folks, > > > By mistake I built `XFRM_ESP` into the Linux kernel, resulting in > > CONFIG_CRYPTO_SEQIV=y > CONFIG_CRYPTO_ECHAINIV=y > > and also the Jitterentropy RNG to be built in. > >

Re: [DISCUSSION PATCH 00/41] random: possible ways towards NIST SP800-90B compliance

Am Mittwoch, 7. Oktober 2020, 06:24:09 CEST schrieb Eric Biggers: Hi Eric, > > Note that having multiple RNG implementations would cause fragmentation, > more maintenance burden, etc. So IMO, that should be a last resort. > Instead we should try to find an implementation that works for

Re: [PATCH] crypto: jitterentropy - bind statically into kernel

Am Montag, 5. Oktober 2020, 08:44:39 CEST schrieb Ard Biesheuvel: Hi Ard, > On Mon, 5 Oct 2020 at 08:40, Stephan Mueller wrote: > > Am Montag, 5. Oktober 2020, 08:24:46 CEST schrieb Ard Biesheuvel: > > > > Hi Ard, > > > > > If jitterentropy is a sp

Re: [PATCH] crypto: jitterentropy - bind statically into kernel

Am Montag, 5. Oktober 2020, 08:24:46 CEST schrieb Ard Biesheuvel: Hi Ard, > If jitterentropy is a special case, we could put a alternate > non-'static inline' version of random_get_entropy() in the core > kernel, and only export it if JITTER_ENTROPY is built as a module in > the first place. But

Re: [DISCUSSION PATCH 00/41] random: possible ways towards NIST SP800-90B compliance

Am Freitag, 2. Oktober 2020, 15:15:55 CEST schrieb Willy Tarreau: Hi Willy, > > And this is all ??? > > Possibly a lot of people got used to seeing the numerous versions > and are less attentive to new series, it's possible that your message > will wake everyone up. I think that points to my

Re: get_cycles from modular code in jitterentropy, was Re: [PATCH] clocksource: clint: Export clint_time_val for modules

Am Freitag, 2. Oktober 2020, 08:49:05 CEST schrieb Christoph Hellwig: Hi Christoph, > On Tue, Sep 29, 2020 at 11:56:18PM -0700, Palmer Dabbelt wrote: > > clint_time_val will soon be used by the RISC-V implementation of > > random_get_entropy(), which is a static inline function that may be used

Re: [DISCUSSION PATCH 00/41] random: possible ways towards NIST SP800-90B compliance

Am Montag, 21. September 2020, 09:58:16 CEST schrieb Nicolai Stange: Hi Nicolai, > Hi all, > > first of all, my apologies for the patch bomb following up in reply to this > mail here -- it's not meant to receive any serious review at all, but only > to support the discussion I'm hoping to get

Re: [PATCH v35 01/13] Linux Random Number Generator

Am Freitag, 18. September 2020, 15:02:17 CEST schrieb kernel test robot: Hi, > All errors (new ones prefixed by >>): > >> drivers/char/lrng/lrng_chacha20.c:33:8: error: structure variable > >> 'chacha20' with 'latent_entropy' attribute has a non-integer field > >> 'block' > 33 | struct

Re: [PATCH v33 01/12] Linux Random Number Generator

Am Mittwoch, 26. August 2020, 16:27:42 CEST schrieb kernel test robot: Hi, > >> drivers/char/lrng/lrng_chacha20.c:54:47: sparse: sparse: cast to > >> restricted __le32 >drivers/char/lrng/lrng_chacha20.c:58:47: sparse: sparse: cast to > restricted __le32 -- Thanks for the reports. Both, the

Re: [PATCH v34 01/12] Linux Random Number Generator

Am Dienstag, 25. August 2020, 13:28:53 CEST schrieb kernel test robot: Hi, > All warnings (new ones prefixed by >>): > >> drivers/char/lrng/lrng_drng.c:381:6: warning: no previous prototype for > >> 'lrng_reset' [-Wmissing-prototypes] > 381 | void lrng_reset(void) > > |

Re: [PATCH] crypto: drbg: check blocklen is non zero

assumed to be non zero. > So turn the assumption into a check. > > Fixes: 541af946fe13 ("crypto: drbg - SP800-90A Deterministic Random Bit > Generator") > > Signed-off-by: Tom Rix Thank you. Reviewed-by: Stephan Mueller Ciao Stephan

Re: [PATCH v31 00/12] /dev/random - a new approach with full SP800-90B

Am Dienstag, 28. Juli 2020, 22:40:44 CEST schrieb Pavel Machek: Hi Pavel, > Hi! > > > The following patch set provides a different approach to /dev/random which > > is called Linux Random Number Generator (LRNG) to collect entropy within > > the Linux kernel. The main improvements compared to

Re: [PATCH v2 13/14] crypto: sun8i-ce: Add support for the PRNG

Am Montag, 15. Juni 2020, 15:02:53 CEST schrieb LABBE Corentin: Hi, > I still dont see any memset_secure in kzfree (mm/slab_common.c). > Does I miss something ? Nope, you do not miss anything, it seems that the patch that I had seen did not go in. > > Regards Ciao Stephan

Re: [PATCH v2] crypto: DRBG - always try to free Jitter RNG instance

Am Freitag, 5. Juni 2020, 08:16:46 CEST schrieb Eric Biggers: Hi Eric, > On Fri, Jun 05, 2020 at 07:58:15AM +0200, Stephan Mueller wrote: > > Am Freitag, 5. Juni 2020, 02:43:36 CEST schrieb Eric Biggers: > > > > Hi Eric, > > > > > On Thu, Jun 04, 2020 at 08

Re: [PATCH v2] crypto: DRBG - always try to free Jitter RNG instance

be deallocated. > > > > Reported-by: syzbot+2e635807decef724a...@syzkaller.appspotmail.com > > Fixes: 97f2650e5040 ("crypto: drbg - always seeded with SP800-90B ...") > > Signed-off-by: Stephan Mueller > > --- > > > > crypto/drbg.c | 3 +++ > > 1 f

Re: [PATCH] crypto: DRBG - always try to free Jitter RNG instance

be deallocated. > > > > Reported-by: syzbot+2e635807decef724a...@syzkaller.appspotmail.com > > Fixes: 97f2650e5040 ("crypto: drbg - always seeded with SP800-90B ...") > > Signed-off-by: Stephan Mueller > > --- > > > > crypto/drbg.c | 3 +++ > &g

Re: [PATCH v2 1/2] hwrng: iproc-rng200 - Set the quality value

Am Mittwoch, 20. Mai 2020, 14:00:01 CEST schrieb Krzysztof Kozlowski: Hi Krzysztof, > On Wed, 20 May 2020 at 13:53, Stephan Mueller wrote: > > > > That said, the illustrated example is typical for hardware RNGs. Yet > > > > it is never guaranteed to work that

Re: [PATCH v2 1/2] hwrng: iproc-rng200 - Set the quality value

Am Mittwoch, 20. Mai 2020, 12:44:33 CEST schrieb Lukasz Stelmach: Hi Lukasz, > It was <2020-05-20 śro 11:18>, when Stephan Mueller wrote: > > Am Mittwoch, 20. Mai 2020, 11:10:32 CEST schrieb Lukasz Stelmach: > >> It was <2020-05-20 śro 08:23>, when Stephan Muelle

Re: [PATCH v2 1/2] hwrng: iproc-rng200 - Set the quality value

Am Mittwoch, 20. Mai 2020, 11:10:32 CEST schrieb Lukasz Stelmach: Hi Lukasz, > It was <2020-05-20 śro 08:23>, when Stephan Mueller wrote: > > Am Dienstag, 19. Mai 2020, 23:25:51 CEST schrieb Łukasz Stelmach: > >> The value was estimaded with ea_iid[1] using on

Re: [PATCH v2 1/2] hwrng: iproc-rng200 - Set the quality value

Am Dienstag, 19. Mai 2020, 23:25:51 CEST schrieb Łukasz Stelmach: Hi Łukasz, > The value was estimaded with ea_iid[1] using on 10485760 bytes read from > the RNG via /dev/hwrng. The min-entropy value calculated using the most > common value estimate (NIST SP 800-90P[2], section 6.3.1) was

Re: [PATCH 1/2] hwrng: iproc-rng200 - Set the quality value

Am Freitag, 15. Mai 2020, 11:01:48 CEST schrieb Lukasz Stelmach: Hi Lukasz, As I mentioned, all that is or seems to be analyzed here is the quality of the cryptographic post-processing. Thus none of the data can be used for getting an idea of the entropy content. That said, the ent value

Re: [PATCH 1/2] hwrng: iproc-rng200 - Set the quality value

Am Freitag, 15. Mai 2020, 00:18:41 CEST schrieb Lukasz Stelmach: Hi Lukasz, > > I am running tests using SP800-90B tools and the first issue I can see > is the warning that samples contain less than 1e6 bytes of data. I know > little about maths behind random number generators, but I have

Re: [PATCH 1/2] hwrng: iproc-rng200 - Set the quality value

Am Donnerstag, 14. Mai 2020, 21:07:33 CEST schrieb Łukasz Stelmach: Hi Łukasz, > The value has been estimaded by obtainig 1024 chunks of data 128 bytes > (1024 bits) each from the generator and finding chunk with minimal > entropy using the ent(1) tool. The value was 6.327820 bits of entropy >

Re: [PATCH 2/2] hwrng: exynos - Set the quality value

Am Donnerstag, 14. Mai 2020, 21:07:34 CEST schrieb Łukasz Stelmach: Hi Łukasz, > The value has been estimaded by obtainig 1024 chunks of data 128 bytes > (1024 bits) each from the generator and finding chunk with minimal > entropy using the ent(1) tool. The value was 6.332937 bits of entropy >

Re: [PATCH 5.4 regression fix] x86/boot: Provide memzero_explicit

Am Montag, 7. Oktober 2019, 11:06:04 CEST schrieb Hans de Goede: Hi Hans, > Hi Stephan, > > On 07-10-2019 10:59, Stephan Mueller wrote: > > Am Montag, 7. Oktober 2019, 10:55:01 CEST schrieb Hans de Goede: > > > > Hi Hans, > > > >> The purgatory co

Re: [PATCH v2 0/6] General Key Derivation Function Support

Am Freitag, 8. Februar 2019, 09:05:47 CET schrieb Herbert Xu: Hi Herbert, > > > Also, shall we add the signature verification enforcemnt to the helper as > > well? > > What do you mean by that? We need to invoke the function crypto_check_module_sig when the module is loaded. Do you have any

Re: [PATCH v2 0/6] General Key Derivation Function Support

Am Freitag, 8. Februar 2019, 08:45:58 CET schrieb Herbert Xu: Hi Herbert, > We could easily add self-tests for the helper. Thanks for the clarification. And do you have a suggestion how we can should ensure that the self-tests are run only once? Also, shall we add the signature verification

Re: [PATCH v2 0/6] General Key Derivation Function Support

Am Mittwoch, 30. Januar 2019, 11:08:54 CET schrieb Herbert Xu: Hi Herbert, > I'm still not convinced why this needs to go into the crypto API > instead of being hosted in a helper which should achieve pretty > much the same result. How do you propose to handle the FIPS 140-2 related

Re: [PATCH v2 0/6] General Key Derivation Function Support

Am Mittwoch, 16. Januar 2019, 12:06:54 CET schrieb Stephan Müller: Hi Herbert, > Changes v2: > * Incorporation of all comments from Eric Biggers > > Stephan Mueller (6): > crypto: add template handling for RNGs > crypto: kdf - SP800-108 Key Derivation Function > cr

Re: [RFC PATCH 4/5] crypto: Adds user space interface for ALG_SET_KEY_TYPE

Am Donnerstag, 17. Januar 2019, 08:02:20 CET schrieb Kalyani Akula: Hi Kalyani, > ALG_SET_KEY_TYPE requires caller to pass the key_type to be used > for AES encryption/decryption. > > Sometimes the cipher key will be stored in the > device's hardware. So, there is a need to specify > the

Re: [PATCH 4/6] crypto: hkdf - RFC5869 Key Derivation Function

Am Montag, 14. Januar 2019, 18:53:16 CET schrieb Eric Biggers: Hi Eric, > > I would not suggest this, because that rounds contrary to the concept of > > the kernel crypto API IMHO. The caller has to provide the wrapping > > cipher. It is perfectly viable to allow a caller to invoke a specific >

Re: [PATCH 1/5 v2] PM / hibernate: Create snapshot keys handler

Am Mittwoch, 9. Januar 2019, 18:34:55 CET schrieb Eric Biggers: Hi Eric, > That would not meet my performance requirements as I want to precompute > HKDF-Extract, and then do HKDF-Expand many times. Also the HKDF-Expand part > should be thread-safe and not require allocating memory, especially

Re: [PATCH 0/5 v2][RFC] Encryption and authentication for hibernate snapshot image

Am Mittwoch, 9. Januar 2019, 17:39:58 CET schrieb joeyli: Hi joeyli, > > I am doing encrypt-then-MAC. Note, this is what the authenc() AEAD cipher does. Ciao Stephan

Re: [PATCH 1/5 v2] PM / hibernate: Create snapshot keys handler

Am Mittwoch, 9. Januar 2019, 09:21:04 CET schrieb Eric Biggers: Hi Eric, > > FWIW, it's been very slow going since I've been working on other projects > and I also need to be very sure to get the API changes right, but I still > plan to change the KDF in fscrypt (a.k.a. ext4/f2fs/ubifs

Re: [PATCH 1/5 v2] PM / hibernate: Create snapshot keys handler

Am Mittwoch, 9. Januar 2019, 07:58:28 CET schrieb James Bottomley: Hi James, > On Wed, 2019-01-09 at 07:45 +0100, Stephan Mueller wrote: > > Am Mittwoch, 9. Januar 2019, 01:44:31 CET schrieb James Bottomley: > > > > Hi James, > > > > > Actually, it would be

Re: [PATCH 1/5 v2] PM / hibernate: Create snapshot keys handler

Am Mittwoch, 9. Januar 2019, 01:44:31 CET schrieb James Bottomley: Hi James, > Actually, it would be enormously helpful if we could reuse these pieces > for the TPM as well. Could you please help me understand whether the KDFs in TPM are directly usable as a standalone cipher primitive or

Re: [PATCH 1/5 v2] PM / hibernate: Create snapshot keys handler

Am Mittwoch, 9. Januar 2019, 00:54:22 CET schrieb Andy Lutomirski: Hi Andy, > > I think that, if the crypto API is going to grow a KDF facility, it should > be done right. Have a key type or flag or whatever that says “this key may > *only* be used to derive keys using such-and-such algorithm”,

Re: [PATCH 1/5 v2] PM / hibernate: Create snapshot keys handler

Am Dienstag, 8. Januar 2019, 06:03:58 CET schrieb Herbert Xu: Hi Herbert, > Are we going to have multiple implementations for the same KDF? > If not then the crypto API is not a good fit. To consolidate > multiple implementations of the same KDF, simply provide helpers > for them. It is

Re: [PATCH 1/5 v2] PM / hibernate: Create snapshot keys handler

Am Montag, 7. Januar 2019, 16:33:27 CET schrieb joeyli: Hi Herbert, > > > use an official KDF type like SP800-108 or HKDF? > > > > You find the counter-KDF according to SP800-108 in security/keys/dh.c > > (search for functions *kdf*). > > > > Or we may start pulling in KDF support into the

Re: [RFC PATCH 4/4] crypto: Add EC-RDSA algorithm

Am Montag, 7. Januar 2019, 09:07:10 CET schrieb Vitaly Chikunov: Hi Vitaly, > > Why do you manually parse the ASN.1 structure instead of using the ASN.1 > > parser? > > I am not sure this worth effort and will not be most degenerate use of > asn1_ber_decoder, since 1) I only need to parse one

Re: [PATCH 1/5 v2] PM / hibernate: Create snapshot keys handler

Am Sonntag, 6. Januar 2019, 09:01:27 CET schrieb Stephan Mueller: Hi, > > + memcpy(skey.key, ukp->data, ukp->datalen); > > Where would skey.key be destroyed again? Now I see it - it is in patch 4. Please disregard my comment. Ciao Stephan

Re: [PATCH 3/5] PM / hibernate: Encrypt snapshot image

Am Donnerstag, 3. Januar 2019, 15:32:25 CET schrieb Lee, Chun-Yi: Hi Chun, > To protect the secret in memory snapshot image, this patch adds the > logic to encrypt snapshot pages by AES-CTR. Using AES-CTR is because > it's simple, fast and parallelizable. But this patch didn't implement >

Re: [PATCH 1/5 v2] PM / hibernate: Create snapshot keys handler

Am Donnerstag, 3. Januar 2019, 15:32:23 CET schrieb Lee, Chun-Yi: Hi Chun, > This patch adds a snapshot keys handler for using the key retention > service api to create keys for snapshot image encryption and > authentication. > > This handler uses TPM trusted key as the snapshot master key, and

Re: [PATCH 2/5] PM / hibernate: Generate and verify signature for snapshot image

Am Donnerstag, 3. Januar 2019, 15:32:24 CET schrieb Lee, Chun-Yi: Hi Chun, > +int snapshot_image_verify_decrypt(void) > +{ > + int ret, i; > + > + if (!h_buf) { > + ret = -ENOMEM; > + goto error; > + } > + > + ret = snapshot_key_init(); > + if (ret) >

Re: [PATCH] crypto: mark cts(cbc(aes)) as FIPS allowed

Am Sonntag, 4. November 2018, 11:05:24 CET schrieb Gilad Ben-Yossef: Hi Gilad, > As per Sp800-38A addendum from Oct 2010[1], cts(cbc(aes)) is > allowed as a FIPS mode algorithm. Mark it as such. > > [1] https://csrc.nist.gov/publications/detail/sp/800-38a/addendum/final There are several types

Re: [PATCH] crypto: mark cts(cbc(aes)) as FIPS allowed

Am Sonntag, 4. November 2018, 11:05:24 CET schrieb Gilad Ben-Yossef: Hi Gilad, > As per Sp800-38A addendum from Oct 2010[1], cts(cbc(aes)) is > allowed as a FIPS mode algorithm. Mark it as such. > > [1] https://csrc.nist.gov/publications/detail/sp/800-38a/addendum/final There are several types

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

Am Freitag, 13. April 2018, 14:53:13 CEST schrieb Theodore Y. Ts'o: Hi Theodore, > > This was always the original design intent, but I screwed up and no > one noticed until Jann reached out to be and said, "Hey this > doesn't seem to make much sense". I disagree, but I guess you would have

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

Am Freitag, 13. April 2018, 14:53:13 CEST schrieb Theodore Y. Ts'o: Hi Theodore, > > This was always the original design intent, but I screwed up and no > one noticed until Jann reached out to be and said, "Hey this > doesn't seem to make much sense". I disagree, but I guess you would have

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

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

Re: [PATCH] crypto: DRBG - guard uninstantion by lock

Am Mittwoch, 11. April 2018, 14:29:45 CEST schrieb Dmitry Vyukov: Hi Dmitry, > > What do you mean by description of the fault? > It's kernel standard FAULT_INJECTION facility, it injects faults > mainly into kmalloc/slab_alloc (also in a bunch of other things, but > in this case this seems to be

Re: [PATCH] crypto: DRBG - guard uninstantion by lock

Am Mittwoch, 11. April 2018, 14:29:45 CEST schrieb Dmitry Vyukov: Hi Dmitry, > > What do you mean by description of the fault? > It's kernel standard FAULT_INJECTION facility, it injects faults > mainly into kmalloc/slab_alloc (also in a bunch of other things, but > in this case this seems to be

Re: [PATCH] crypto: DRBG - guard uninstantion by lock

Am Dienstag, 10. April 2018, 17:23:46 CEST schrieb Dmitry Vyukov: Hi Dmitry, > Stephan, > > Do you have any hypothesis as to why this is not detected by KASAN and > causes silent corruptions? > We generally try to understand such cases and improve KASAN so that it > catches such cases more

Re: [PATCH] crypto: DRBG - guard uninstantion by lock

Am Dienstag, 10. April 2018, 17:23:46 CEST schrieb Dmitry Vyukov: Hi Dmitry, > Stephan, > > Do you have any hypothesis as to why this is not detected by KASAN and > causes silent corruptions? > We generally try to understand such cases and improve KASAN so that it > catches such cases more

Re: [PATCH] AF_ALG: register completely initialized request in list

Am Montag, 9. April 2018, 09:51:13 CEST schrieb Dmitry Vyukov: Hi Dmitry, > You can ask syzbot to test by replying to its report email with a test > command, see: > https://github.com/google/syzkaller/blob/master/docs/syzbot.md#communication > -with-syzbot > > Note that all testing of KMSAN

Re: [PATCH] AF_ALG: register completely initialized request in list

Am Montag, 9. April 2018, 09:51:13 CEST schrieb Dmitry Vyukov: Hi Dmitry, > You can ask syzbot to test by replying to its report email with a test > command, see: > https://github.com/google/syzkaller/blob/master/docs/syzbot.md#communication > -with-syzbot > > Note that all testing of KMSAN

Re: [PATCH] crypto: DRBG - guard uninstantion by lock

Am Montag, 9. April 2018, 00:46:03 CEST schrieb Theodore Y. Ts'o: Hi Theodore, > > So the syzbot will run while the patch goes through the normal e-mail > review process, which is kind of neat. :-) Thank you very much for the hint. That is a neat feature indeed. As I came late to the party

Re: [PATCH] crypto: DRBG - guard uninstantion by lock

Am Montag, 9. April 2018, 00:46:03 CEST schrieb Theodore Y. Ts'o: Hi Theodore, > > So the syzbot will run while the patch goes through the normal e-mail > review process, which is kind of neat. :-) Thank you very much for the hint. That is a neat feature indeed. As I came late to the party

Re: [PATCH] crypto: ctr: avoid VLA use

Am Mittwoch, 14. März 2018, 14:46:29 CET schrieb Salvatore Mesoraca: Hi Salvatore, > 2018-03-14 14:31 GMT+01:00 Stephan Mueller <smuel...@chronox.de>: > > Am Mittwoch, 14. März 2018, 14:17:30 CET schrieb Salvatore Mesoraca: > > > > Hi Salvatore, >

Re: [PATCH] crypto: ctr: avoid VLA use

Am Mittwoch, 14. März 2018, 14:46:29 CET schrieb Salvatore Mesoraca: Hi Salvatore, > 2018-03-14 14:31 GMT+01:00 Stephan Mueller : > > Am Mittwoch, 14. März 2018, 14:17:30 CET schrieb Salvatore Mesoraca: > > > > Hi Salvatore, > >

Re: [PATCH] crypto: ctr: avoid VLA use

Am Mittwoch, 14. März 2018, 14:17:30 CET schrieb Salvatore Mesoraca: Hi Salvatore, > if (walk.nbytes) { > - crypto_ctr_crypt_final(, child); > - err = blkcipher_walk_done(desc, , 0); > + err = crypto_ctr_crypt_final(, child); > + err =

Re: [PATCH] crypto: ctr: avoid VLA use

Am Mittwoch, 14. März 2018, 14:17:30 CET schrieb Salvatore Mesoraca: Hi Salvatore, > if (walk.nbytes) { > - crypto_ctr_crypt_final(, child); > - err = blkcipher_walk_done(desc, , 0); > + err = crypto_ctr_crypt_final(, child); > + err =

Re: [PATCH v3] input: bcm5974 - Add driver for Apple Magic Trackpad 2

Am Dienstag, 27. Februar 2018, 17:37:45 CET schrieb Stephan Mueller: Hi Jiri, Dimity, Henrik, > Am Sonntag, 21. Januar 2018, 23:06:55 CET schrieb Stephan Müller: > > Hi Jiri, Dimity, Henrik, > > > Hi, > > > > Changes v3: > > * port to 4.15-rc8 > >

Re: [PATCH v3] input: bcm5974 - Add driver for Apple Magic Trackpad 2

Am Dienstag, 27. Februar 2018, 17:37:45 CET schrieb Stephan Mueller: Hi Jiri, Dimity, Henrik, > Am Sonntag, 21. Januar 2018, 23:06:55 CET schrieb Stephan Müller: > > Hi Jiri, Dimity, Henrik, > > > Hi, > > > > Changes v3: > > * port to 4.15-rc8 > >

Re: [PATCH v3] input: bcm5974 - Add driver for Apple Magic Trackpad 2

Am Sonntag, 21. Januar 2018, 23:06:55 CET schrieb Stephan Müller: Hi Jiri, Dimity, Henrik, > Hi, > > Changes v3: > * port to 4.15-rc8 > * small code cleanups (isolation of type casts to functions pertaining > to the Apple Magic Trackpad 2 > * clean up all checkpatch.pl errors and warnings

Re: [PATCH v3] input: bcm5974 - Add driver for Apple Magic Trackpad 2

Am Sonntag, 21. Januar 2018, 23:06:55 CET schrieb Stephan Müller: Hi Jiri, Dimity, Henrik, > Hi, > > Changes v3: > * port to 4.15-rc8 > * small code cleanups (isolation of type casts to functions pertaining > to the Apple Magic Trackpad 2 > * clean up all checkpatch.pl errors and warnings

Re: [PATCH 14/14] x86/crypto: aesni: Update aesni-intel_glue to use scatter/gather

Am Montag, 12. Februar 2018, 20:51:28 CET schrieb Dave Watson: Hi Dave, > Add gcmaes_en/decrypt_sg routines, that will do scatter/gather > by sg. Either src or dst may contain multiple buffers, so > iterate over both at the same time if they are different. > If the input is the same as the

Re: [PATCH 14/14] x86/crypto: aesni: Update aesni-intel_glue to use scatter/gather

Am Montag, 12. Februar 2018, 20:51:28 CET schrieb Dave Watson: Hi Dave, > Add gcmaes_en/decrypt_sg routines, that will do scatter/gather > by sg. Either src or dst may contain multiple buffers, so > iterate over both at the same time if they are different. > If the input is the same as the

Re: AIO operation and CMSG

Am Mittwoch, 17. Januar 2018, 20:22:13 CET schrieb Christoph Hellwig: Hi Christoph, > On Sun, Jan 14, 2018 at 09:01:00AM +0100, Stephan Müller wrote: > > The syscall io_submit sends data to the kernel and invokes the respective > > handler function in the kernel such as the recvmsg handler. What

Re: AIO operation and CMSG

Am Mittwoch, 17. Januar 2018, 20:22:13 CET schrieb Christoph Hellwig: Hi Christoph, > On Sun, Jan 14, 2018 at 09:01:00AM +0100, Stephan Müller wrote: > > The syscall io_submit sends data to the kernel and invokes the respective > > handler function in the kernel such as the recvmsg handler. What

Re: [PATCH v2] net/core: Increase default optmem_max limit

or use > in real world applications. > > Signed-off-by: Björn Esser <besse...@fedoraproject.org> Considering NR_FILE defining the default maximum number of file descriptors, at max 335 MB of RAM (32 bit) or 670 MB (64 bit) could be allocated which I would assume to be ok in curr

Re: [PATCH v2] net/core: Increase default optmem_max limit

or use > in real world applications. > > Signed-off-by: Björn Esser Considering NR_FILE defining the default maximum number of file descriptors, at max 335 MB of RAM (32 bit) or 670 MB (64 bit) could be allocated which I would assume to be ok in current systems. Reviewed-by: Stephan Mueller Ciao Stephan

Re: [PATCH 1/2] crypto: Implement a generic crypto statistics

Am Freitag, 12. Januar 2018, 10:07:30 CET schrieb LABBE Corentin: Hi LABBE, > > > > diff --git a/include/uapi/linux/cryptouser.h > > > b/include/uapi/linux/cryptouser.h index 19bf0ca6d635..15e51ccb3679 > > > 100644 > > > --- a/include/uapi/linux/cryptouser.h > > > +++

Re: [PATCH 1/2] crypto: Implement a generic crypto statistics

Am Freitag, 12. Januar 2018, 10:07:30 CET schrieb LABBE Corentin: Hi LABBE, > > > > diff --git a/include/uapi/linux/cryptouser.h > > > b/include/uapi/linux/cryptouser.h index 19bf0ca6d635..15e51ccb3679 > > > 100644 > > > --- a/include/uapi/linux/cryptouser.h > > > +++

Re: [PATCH 1/2] crypto: Implement a generic crypto statistics

Am Donnerstag, 11. Januar 2018, 20:56:56 CET schrieb Corentin Labbe: Hi Corentin, > This patch implement a generic way to get statistics about all crypto > usages. > > Signed-off-by: Corentin Labbe > --- > crypto/Kconfig | 11 >

Re: [PATCH 1/2] crypto: Implement a generic crypto statistics

Am Donnerstag, 11. Januar 2018, 20:56:56 CET schrieb Corentin Labbe: Hi Corentin, > This patch implement a generic way to get statistics about all crypto > usages. > > Signed-off-by: Corentin Labbe > --- > crypto/Kconfig | 11 > crypto/ablkcipher.c | 9

Re: [PATCH 3/7] crypto: ccree: add ablkcipher support

Am Donnerstag, 11. Januar 2018, 10:17:10 CET schrieb Gilad Ben-Yossef: Hi Gilad, > + // verify weak keys > + if (ctx_p->flow_mode == S_DIN_to_DES) { > + if (!des_ekey(tmp, key) && > + (crypto_tfm_get_flags(tfm) & CRYPTO_TFM_REQ_WEAK_KEY)) { > +

Re: [PATCH 3/7] crypto: ccree: add ablkcipher support

Am Donnerstag, 11. Januar 2018, 10:17:10 CET schrieb Gilad Ben-Yossef: Hi Gilad, > + // verify weak keys > + if (ctx_p->flow_mode == S_DIN_to_DES) { > + if (!des_ekey(tmp, key) && > + (crypto_tfm_get_flags(tfm) & CRYPTO_TFM_REQ_WEAK_KEY)) { > +

Re: [PATCH v2] crypto: AF_ALG - limit mask and type

stered multiple times potentially exhausting kernel memory. > > > > Reported-by: syzbot <syzkal...@googlegroups.com> > > Cc: <sta...@vger.kernel.org> > > Signed-off-by: Stephan Mueller <smuel...@chronox.de> > > This will break users of CRYPTO_ALG_KER

Re: [PATCH v2] crypto: AF_ALG - limit mask and type

stered multiple times potentially exhausting kernel memory. > > > > Reported-by: syzbot > > Cc: > > Signed-off-by: Stephan Mueller > > This will break users of CRYPTO_ALG_KERN_DRIVER_ONLY. I think > we should add CRYPTO_ALG_TESTED to the blacklist since there is

Re: [RFC] syzbot process

Am Donnerstag, 21. Dezember 2017, 14:22:40 CET schrieb Andrey Ryabinin: Hi Andrey, > 2017-12-21 15:52 GMT+03:00 Dmitry Vyukov : > > Any other proposals, thoughts, ideas? > > a) Assume that patches send in replies to the bug report are fixes. > > b) Almost the same as your

Re: [RFC] syzbot process

Am Donnerstag, 21. Dezember 2017, 14:22:40 CET schrieb Andrey Ryabinin: Hi Andrey, > 2017-12-21 15:52 GMT+03:00 Dmitry Vyukov : > > Any other proposals, thoughts, ideas? > > a) Assume that patches send in replies to the bug report are fixes. > > b) Almost the same as your "syzbot-fix: HASH"

Re: [PATCH RFC 2/3] crypto: Implement a generic crypto statistics

Am Mittwoch, 20. Dezember 2017, 21:09:26 CET schrieb Corentin Labbe: Hi Corentin, > This patch implement a generic way to get statistics about all crypto > usages. > > Signed-off-by: Corentin Labbe > --- > crypto/Kconfig | 11 +++ > crypto/ahash.c

Re: [PATCH RFC 2/3] crypto: Implement a generic crypto statistics

Am Mittwoch, 20. Dezember 2017, 21:09:26 CET schrieb Corentin Labbe: Hi Corentin, > This patch implement a generic way to get statistics about all crypto > usages. > > Signed-off-by: Corentin Labbe > --- > crypto/Kconfig | 11 +++ > crypto/ahash.c | 18 + >

Re: [PATCH RFC 1/3] crypto: Prevent to register duplicate cra_driver_name

Am Mittwoch, 20. Dezember 2017, 21:09:25 CET schrieb Corentin Labbe: Hi Corentin, > Each crypto algorithm "cra_name" can have multiple implementation called > "cra_driver_name". > If two different implementation have the same cra_driver_name, nothing > can easily differentiate them. >

Re: [PATCH RFC 1/3] crypto: Prevent to register duplicate cra_driver_name

Am Mittwoch, 20. Dezember 2017, 21:09:25 CET schrieb Corentin Labbe: Hi Corentin, > Each crypto algorithm "cra_name" can have multiple implementation called > "cra_driver_name". > If two different implementation have the same cra_driver_name, nothing > can easily differentiate them. >

Re: KASAN: use-after-free Read in crypto_aead_free_instance

Am Mittwoch, 20. Dezember 2017, 11:15:38 CET schrieb Dmitry Vyukov: Hi Dmitry, > > What will be its meaning? How will it differ from fix? Maybe a short clarification would help: what is the meaning of the syz fix marker? Depending on this answer, all that I am thinking of is to mark bug

Re: KASAN: use-after-free Read in crypto_aead_free_instance

Am Mittwoch, 20. Dezember 2017, 11:15:38 CET schrieb Dmitry Vyukov: Hi Dmitry, > > What will be its meaning? How will it differ from fix? Maybe a short clarification would help: what is the meaning of the syz fix marker? Depending on this answer, all that I am thinking of is to mark bug

  1   2   3   4   5   6   7   8   9   10   >