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 syste
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 th
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 calle
gt; >
> > 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
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 w
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 o
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
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, 0xfff
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
> +#defi
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
> +
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 e
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:
> >> By mi
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.
>
> CRYPT
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 everyone
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
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
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 pa
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
>
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 go
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 chac
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 _
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)
>
> | ^~
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
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 th
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
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
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
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
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 way
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
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 10485760
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 7.96446
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 inde
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 noticed
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
> in
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
> in
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
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 co
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 en
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 requirements
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
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 informa
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
> >
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 n
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
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 encryption
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
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 does
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”, a
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 unlikel
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 ker
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 ty
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
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
> paralle
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
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)
> +
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
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 e
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 i
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
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 relia
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 bugs
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 and
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,
> >
Am Mittwoch, 14. März 2018, 14:17:30 CET schrieb Salvatore Mesoraca:
Hi Salvatore,
> if (walk.nbytes) {
> - crypto_ctr_crypt_final(&walk, child);
> - err = blkcipher_walk_done(desc, &walk, 0);
> + err = crypto_ctr_crypt_final(&walk, child);
> +
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
> >
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 (exc
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 output
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
e enough for 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
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
> > > +++ b/include/uapi/linux/crypto
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 ++
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)) {
> +
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
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" pr
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 +
> crypto
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.
> Furthermore
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
repor
Am Mittwoch, 20. Dezember 2017, 10:50:10 CET schrieb Dmitry Vyukov:
Hi Dmitry,
> On Wed, Dec 20, 2017 at 10:29 AM, Stephan Mueller
wrote:
> > Am Mittwoch, 20. Dezember 2017, 10:19:43 CET schrieb Dmitry Vyukov:
> >
> > Hi Dmitry,
> >
> >> > This issue va
Am Mittwoch, 20. Dezember 2017, 10:19:43 CET schrieb Dmitry Vyukov:
Hi Dmitry,
> >
> > This issue vanishes after applying the patch "[PATCH v2] crypto: AF_ALG -
> > limit mask and type".
>
> Hi Stephan,
>
> syzbot does not understand arbitrary English prose, it only understands
this:
> > Once
Am Montag, 18. Dezember 2017, 06:50:01 CET schrieb syzbot:
Hi,
> Hello,
>
> syzkaller hit the following crash on
> 82bcf1def3b5f1251177ad47c44f7e17af039b4b
> git://git.cmpxchg.org/linux-mmots.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
Am Montag, 18. Dezember 2017, 06:50:01 CET schrieb syzbot:
Hi,
> Hello,
>
> syzkaller hit the following crash on
> 41d8c16909ebda40f7b4982a7f5e2ad102705ade
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw
ug where user space is able to cause one cipher to be
> > registered multiple times potentially exhausting kernel memory.
> >
> > Reported-by: syzbot
> > Cc:
> > Signed-off-by: Stephan Mueller
>
> The syzkaller reproducer triggered a crash in crypto_remov
Am Freitag, 8. Dezember 2017, 12:39:06 CET schrieb Jonathan Cameron:
Hi Jonathan,
>
> As a heads up, the other nasties we've found so far are around hitting
> limits on the various socket buffers. When you run into those you can end
> up with parts of the data to be encrypted going through with
riority before
> software implementations, but allow them to be selected in FIPS-mode
> (fips=1 in the kernel command line).
>
> Signed-off-by: Łukasz Stelmach
Reviewed-by: Stephan Mueller
Ciao
Stephan
Am Dienstag, 5. Dezember 2017, 13:35:57 CET schrieb Łukasz Stelmach:
Hi Łukasz,
> Use memcpy_fromio() instead of custom exynos_rng_copy_random() function
> to retrieve generated numbers from the registers of PRNG.
>
> Remove unnecessary invocation of cpu_relax().
>
> Signed-off-by: Łukasz Stelm
second?!
Another suggestion: maybe you want to add a comment to the reseed function to
indicate it is for enhanced backtracking resistance. Otherwise a lot of folks
would scratch their head why such code exists in the first place. :-)
Other than that:
Reviewed-by: Stephan Mueller
Ciao
Stephan
Am Dienstag, 5. Dezember 2017, 13:42:14 CET schrieb Łukasz Stelmach:
Hi Łukasz,
> exynos-rng is one of many implementations of stdrng. With priority as
> low as 100 it isn't selected, if software implementations (DRBG) are
> available.
What about using 300? The reason is the following: in the no
Am Mittwoch, 29. November 2017, 11:22:34 CET schrieb Herbert Xu:
Hi Herbert,
> On Wed, Nov 29, 2017 at 11:17:26AM +0100, Stephan Müller wrote:
> > @@ -111,6 +111,12 @@ static int _aead_recvmsg(struct socket *sock, struct
> > msghdr *msg,>
> > size_t usedpages = 0; /* [in] RX bufs
Am Mittwoch, 29. November 2017, 08:10:49 CET schrieb Herbert Xu:
Hi Herbert,
>
> But anyway this isn't suitable for stable where we should just fix
> it by making it not crash.
I will send a patch right away moving the wait out.
Later on I will elaborate on your suggestion to move the context-
Am Mittwoch, 29. November 2017, 00:02:40 CET schrieb Herbert Xu:
Hi Herbert,
> > --- a/crypto/algif_aead.c
> > +++ b/crypto/algif_aead.c
> > @@ -110,6 +110,7 @@ static int _aead_recvmsg(struct socket *sock, struct
> > msghdr *msg,>
> > size_t outlen = 0; /* [out] RX bufs produce
; + }
>
> - if (areq->tsgl && areq->tsgl_entries)
Why do you want to remove the check for areq->tsgl_entries? I know in the
current code that cannot happen. But it should be caught in case of a
programming error.
Thus, should we add a BUG_ON(!areq->tsgl_entries)?
Otherwise:
Reviewed-by: Stephan Mueller
Ciao
Stephan
.13: this code is not affected by this
issue because the sleep happens before any member of the context is
dereferenced.
Eric, may I ask you to check the attached patch? Note, I did not yet test that
patch myself. Thanks a lot.
---8<---
>From a06f26e1baaf6acb855ab8fb55a220a176aa0b9f Mon Se
Am Dienstag, 28. November 2017, 08:53:07 CET schrieb Eric Biggers:
Hi Eric,
> On Mon, Nov 27, 2017 at 09:37:38PM -0800, Eric Biggers wrote:
> > On Mon, Nov 27, 2017 at 10:56:47AM -0800, syzbot wrote:
> > > Hello,
> > >
> > > syzkaller hit the following crash on
> > > 1ea8d039f9edcfefb20d8ddfe136
, absolutely -- the null cipher is allocated together with the AEAD cipher
and should be freed together with the AEAD cipher.
Thanks a lot.
Reviewed-by: Stephan Mueller
Ciao
Stephan
Am Montag, 27. November 2017, 23:43:08 CET schrieb Eric Biggers:
Hi Eric,
> No, that doesn't help. I tested v4.15-rc1 with all the extra commits from
> crypto-2.6.git/master applied:
>
> crypto: algif_aead - skip SGL entries with NULL page
> crypto: af_alg - remove locking in async
o/keywrap.c: In function ‘crypto_kw_encrypt’:
> crypto/keywrap.c:224: warning: integer constant is too large for ‘long’
> type
>
> Fixes: 9e49451d7a15365d ("crypto: keywrap - simplify code")
> Signed-off-by: Geert Uytterhoeven
Thank you
Reviewed-by: Stephan Mueller
Ciao
Stephan
Am Donnerstag, 19. Oktober 2017, 22:45:06 CEST schrieb Jason A. Donenfeld:
Hi Jason,
> We now structure things in a way that assumes the seeding function is
> always eventually called.
>
> Signed-off-by: Jason A. Donenfeld
> ---
> crypto/drbg.c | 20 +---
> 1 file changed, 5 in
Am Samstag, 21. Oktober 2017, 19:53:54 CEST schrieb SF Markus Elfring:
Hi Markus,
> From: Markus Elfring
> Date: Sat, 21 Oct 2017 19:29:11 +0200
>
> Adjust jump targets so that a bit of exception handling can be better
> reused at the end of this function.
>
> This issue was detected by using
Am Mittwoch, 20. September 2017, 16:01:21 CEST schrieb Jason A. Donenfeld:
Hi Jason,
>
> Section 3 shows an attack with repeated nonces, which we don't do here.
Maybe I miss a point here, but zero IVs is no repetition of nonces?
Ciao
Stephan
1 - 100 of 938 matches
Mail list logo