Re: BUG: libkcapi tests trigger sleep-in-atomic bug in VMX code (ppc64)

Am Dienstag, 21. August 2018, 14:48:11 CEST schrieb Ondrej Mosnáček: Hi Ondrej, Marcelo, (+Marcelo) > Looking at crypto/algif_skcipher.c, I can see that skcipher_recvmsg() > holds the socket lock the whole time and yet passes > CRYPTO_TFM_REQ_MAY_SLEEP to the cipher implementation. Isn't that

Re: random: ensure use of aligned buffers with ChaCha20

Am Donnerstag, 9. August 2018, 21:40:12 CEST schrieb Eric Biggers: Hi Eric, > while (bytes >= CHACHA20_BLOCK_SIZE) { > chacha20_block(state, stream); > - crypto_xor(dst, (const u8 *)stream, CHACHA20_BLOCK_SIZE); > + crypto_xor(dst, stream,

Re: random: ensure use of aligned buffers with ChaCha20

Am Donnerstag, 9. August 2018, 21:21:32 CEST schrieb Theodore Y. Ts'o: Hi Theodore, > I'm wondering whether we have kernel code that actually tries to > extract more than 64 bytes, so I'm not sure how often we enter the > while loop at all. Out of curiosity, did you find this from code >

Re: random: ensure use of aligned buffers with ChaCha20

Am Donnerstag, 9. August 2018, 21:07:18 CEST schrieb Eric Biggers: Hi Eric, > This patch is backwards: the temporary buffer is used when the buffer is > *aligned*, not misaligned. And more problematically, 'buf' is never > incremented in one of the cases... Of course, it needs to be reversed.

Re: [PATCH] crypto: CTR DRBG - in-place cipher operation

Am Freitag, 27. Juli 2018, 12:53:35 CEST schrieb Herbert Xu: Hi Herbert, > On Fri, Jul 20, 2018 at 07:42:01PM +0200, Stephan Müller wrote: > > @@ -1747,10 +1733,18 @@ static int drbg_kcapi_sym_ctr(struct drbg_state > > *drbg,> > > u8 *outbuf, u32 outlen) > > > > { >

Re: [PATCH 2/2] crypto: DRBG - use caller buffer if suitable

>> On Fri, Jul 20, 2018 at 07:09:05AM +0200, Stephan Mueller wrote: >> >> Maybe I have a different understanding of how such interface should look >> like. >> >> Can you give me some more detail on how you envision such virtual address >> interface s

Re: [PATCH 2/2] crypto: DRBG - use caller buffer if suitable

> Am 20.07.2018 um 05:54 schrieb Herbert Xu : > >> On Thu, Jul 19, 2018 at 10:57:16PM +0200, Stephan Müller wrote: >> >> Therefore, I am not sure that either having an SGL interface for the RNG API >> or a virtual address interface for the sync skcipher would be helpful. > > Could you

Re: [RFC PATCH] crypto: DH - add public key verification test

Am Dienstag, 26. Juni 2018, 12:17:42 CEST schrieb Stephan Müller: Hi, > + MPI val = mpi_alloc(0); I just saw that I did not check for val after allocation. That will be fixed in another installment of the patch. Ciao Stephan

Re: Q for a new API for the random device driver

Am Mittwoch, 6. Juni 2018, 14:48:33 CEST schrieb Harald Freudenberger: Hi Harald, > > I am still searching for a way to provide our good hardware entropy > source to the random pool in the random device driver. So I'd like to > have a new arch interface which is called when the random pool finds

Re: PBKDF2 support in the linux kernel

Am Samstag, 26. Mai 2018, 14:17:11 CEST schrieb Jeffrey Walton: Hi Jeffrey, > On Thu, May 24, 2018 at 5:11 AM, Stephan Mueller <smuel...@chronox.de> wrote: > > Am Donnerstag, 24. Mai 2018, 10:33:07 CEST schrieb Rafael J. Wysocki: > > > > Hi Rafael, > > >

Re: PBKDF2 support in the linux kernel

Am Donnerstag, 24. Mai 2018, 11:27:56 CEST schrieb Rafael J. Wysocki: Hi Rafael, > On Thursday, May 24, 2018 11:11:32 AM CEST Stephan Mueller wrote: > > Am Donnerstag, 24. Mai 2018, 10:33:07 CEST schrieb Rafael J. Wysocki: > > > > Hi Rafael, > > Hi Stephan, > &

Re: PBKDF2 support in the linux kernel

Am Donnerstag, 24. Mai 2018, 10:33:07 CEST schrieb Rafael J. Wysocki: Hi Rafael, > So the problem is that Yu would like to use this for hibernation encryption > done entirely in the kernel. But why do you need to perform PBKDF in kernel space? If you retain the password information in the

Re: PBKDF2 support in the linux kernel

Am Donnerstag, 24. Mai 2018, 04:45:00 CEST schrieb Eric Biggers: Hi Eric, > > "Not having to rely on any third-party library" is not an excuse to add > random code to the kernel, which runs in a privileged context. Please do > PBKDF2 in userspace instead. I second that. Besides, if you really

Re: PBKDF2 support in the linux kernel

Am Dienstag, 22. Mai 2018, 05:00:40 CEST schrieb Yu Chen: Hi Yu, > Hi all, > The request is that, we'd like to generate a symmetric key derived from > user provided passphase(not rely on any third-party library). May I know if > there is a PBKDF2(Password-Based Key Derivation Function 2) support

Re: IV generation

Am Montag, 7. Mai 2018, 13:19:47 CEST schrieb Gilad Ben-Yossef: Hi Gilad, > ah... so if I have hardware that can implement say, seqiv, I can > register "seqiv(rfc4106(gcm(aes)))" and, assuming priorities are > right, it will be used? That is the question I cannot fully answer. Seqiv is a

Re: IV generation

Am Montag, 7. Mai 2018, 08:26:08 CEST schrieb Gilad Ben-Yossef: Hi Gilad, > Hi, > > A quick question: am I correct in my understanding that there is now > no automatic IV generation support for either skcipher nor aead? > And if I'm wrong, can someone point to an example of a driver that >

Re: GCM and XTS: kcapi result not matching with NIST vectors

Am Montag, 23. April 2018, 07:51:35 CEST schrieb Jitendra Lulla: Hi Jitendra, > > TEST 2: > > Similarly for XTS also we have one mismatch: > https://csrc.nist.gov/CSRC/media/Projects/Cryptographic-Algorithm-Validation > -Program/documents/aes/XTSTestVectors.zip > > /XTSTestVectors/format

Re: GCM and XTS: kcapi result not matching with NIST vectors

Am Montag, 23. April 2018, 07:51:35 CEST schrieb Jitendra Lulla: Hi Jitendra, > Hi, > > Consider the following 2 invocations from kcapi and the results we get > from it. They are not matching with the NIST vectors [links pasted > below]. > > Could somebody please tell why that could be

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] 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: [RFC PATCH 0/5] KEYS: add kpp keyctl operations

Am Mittwoch, 11. April 2018, 13:08:11 CEST schrieb Tudor Ambarus: Hi Tudor, > Hi, > > There was a long discussion about which interface to chose to export > akcipher and kpp to user-space. This series came as an alternative to > what Stephan proposed for af_alg[1]. I would like some feedback

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] 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: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: [tpmdd-devel] in-kernel user of ecdsa

Am Montag, 12. März 2018, 22:55:35 CET schrieb James Bottomley: Hi James, > > ECDSA is not implemented currently in the kernel crypto API. > > an ECDSA signature is produced as a ECDH operation using the DSA > algorithm instead of KDFe, so it's trivial with what we have; signature >

Re: [tpmdd-devel] in-kernel user of ecdsa

Am Montag, 12. März 2018, 19:09:18 CET schrieb James Bottomley: Hi James, > On Mon, 2018-03-12 at 19:07 +0200, Tudor Ambarus wrote: > > Hi, > > > > Would you consider using ECDSA in the kernel module signing facility? > > When compared with RSA, ECDSA has shorter keys, the key generation > >

Re: error in libkcapi 1.0.3 for aead aio

Am Mittwoch, 28. Februar 2018, 08:34:21 CET schrieb Harsh Jain: Hi Harsh, > Try with gdb. AIO(-x 10) works fine with step by step debugging. Also > verified by adding print in "af_alg_async_cb" for received err value. > Driver is sending -74 here. I am unable to reproduce the issue. Both

Re: [PATCH v3 4/4] crypto: add CRYPTO_TFM_REQ_IV_SERIALIZE flag

Am Sonntag, 18. Februar 2018, 15:25:27 CET schrieb Gilad Ben-Yossef: Hi Gilad, > On Sat, Feb 10, 2018 at 12:04 AM, Stephan Müller wrote: > > Crypto drivers may implement a streamlined serialization support for AIO > > requests that is reported by the

Re: [PATCH v3 1/4] crypto: AF_ALG AIO - lock context IV

Am Donnerstag, 15. Februar 2018, 14:04:53 CET schrieb Stephan Mueller: Hi Stephan, > Am Donnerstag, 15. Februar 2018, 13:45:53 CET schrieb Harsh Jain: > > Hi Harsh, > > > > Could you please elaborate what you mean with "partial tag" support? > > >

Re: [PATCH v3 1/4] crypto: AF_ALG AIO - lock context IV

Am Donnerstag, 15. Februar 2018, 13:45:53 CET schrieb Harsh Jain: Hi Harsh, > > Could you please elaborate what you mean with "partial tag" support? > > Here is the catch, Calculation of tag depends on total payload length > atleast for shaX, gcm,ccm mode on which I have worked. > > If we take

Re: [PATCH v3 1/4] crypto: AF_ALG AIO - lock context IV

Am Donnerstag, 15. Februar 2018, 12:38:12 CET schrieb Harsh Jain: Hi Harsh, > On 15-02-2018 12:47, Stephan Mueller wrote: > > Am Donnerstag, 15. Februar 2018, 08:03:20 CET schrieb Harsh Jain: > > > > Hi Harsh, > > > >> Even after guarantee of seriali

Re: [PATCH v3 1/4] crypto: AF_ALG AIO - lock context IV

Am Donnerstag, 15. Februar 2018, 08:03:20 CET schrieb Harsh Jain: Hi Harsh, > Even after guarantee of serialization, In the end we will get wrong result > as mentioned above. which destination side cannot decrypt it. What I feel > is scenario of sending 2 of more IOCB in case of AEAD itself is

Re: [PATCH v3 1/4] crypto: AF_ALG AIO - lock context IV

Am Donnerstag, 15. Februar 2018, 06:30:36 CET schrieb Harsh Jain: Hi Harsh, > On 14-02-2018 18:22, Stephan Mueller wrote: > > Am Mittwoch, 14. Februar 2018, 06:43:53 CET schrieb Harsh Jain: > > > > Hi Harsh, > > > >> Patch set is working fine wit

Re: [PATCH v3 1/4] crypto: AF_ALG AIO - lock context IV

Am Mittwoch, 14. Februar 2018, 06:43:53 CET schrieb Harsh Jain: Hi Harsh, > > Patch set is working fine with chelsio Driver. Thank you. > Do we really need IV locking mechanism for AEAD algo because AEAD algo's > don't support Partial mode operation and Driver are not updating(atleast >

Re: [PATCH v3 4/4] crypto: add CRYPTO_TFM_REQ_IV_SERIALIZE flag

Am Mittwoch, 14. Februar 2018, 06:50:38 CET schrieb Harsh Jain: Hi Harsh, > On 10-02-2018 03:34, Stephan Müller wrote: > > Crypto drivers may implement a streamlined serialization support for AIO > > requests that is reported by the CRYPTO_ALG_SERIALIZES_IV_ACCESS flag to > > the crypto user.

Re: [PATCH] crypto: Fix incorrect values in PKCS#1 test vector

off-by: Giovanni Cabiddu <giovanni.cabi...@intel.com> > Signed-off-by: Conor McLoughlin <conor.mclough...@intel.com> Reviewed-by: Stephan Mueller <smuel...@chronox.de> Ciao Stephan

Re: hashing bit oriented messages

Am Montag, 12. Februar 2018, 07:18:20 CET schrieb Jitendra Lulla: Hi Jitendra, > Hi, > > the following NIST link has test vectors for SHA1/2/3. > https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/se > cure-hashing > > They have test vectors for bit oriented messages

Re: [PATCH v2 4/4] crypto: add CRYPTO_TFM_REQ_PARALLEL flag

Am Mittwoch, 7. Februar 2018, 17:14:12 CET schrieb Jonathan Cameron: Hi Jonathan, > Actually those were fine on the basis that inline iv is > obvious enough, it was CRYPTO_TFM_REQ_PARALLEL that > was causing me confusion. > > Sorry, wasn't terribly clear on that! Ok, I will add some comments

Re: [PATCH v2 4/4] crypto: add CRYPTO_TFM_REQ_PARALLEL flag

Am Mittwoch, 7. Februar 2018, 16:39:11 CET schrieb Jonathan Cameron: Hi Jonathan, > On Wed, 7 Feb 2018 13:48:32 +0100 > > Stephan Mueller <smuel...@chronox.de> wrote: > > Am Mittwoch, 7. Februar 2018, 08:44:04 CET schrieb Stephan Müller: > > > > Hi, > >

Re: [PATCH v2 4/4] crypto: add CRYPTO_TFM_REQ_PARALLEL flag

Am Mittwoch, 7. Februar 2018, 08:44:04 CET schrieb Stephan Müller: Hi, > diff --git a/crypto/algif_aead.c b/crypto/algif_aead.c > index 3970ad7f6fd0..da010405eea0 100644 > --- a/crypto/algif_aead.c > +++ b/crypto/algif_aead.c > @@ -66,13 +66,22 @@ static int aead_sendmsg(struct socket *sock,

Re: [RFC PATCH 2/3] crypto: hisilicon hacv1 driver

Am Montag, 5. Februar 2018, 15:02:03 CET schrieb Jonathan Cameron: Hi Jonathan, > I could drop this for the initial submission and bring it in as an > optimization with supporting numbers as a follow up patch. I am not disputing the code itself. It just occurred to me that the code is similar

Re: [PATCH] crypto: AF_ALG AIO - lock context IV

Am Donnerstag, 1. Februar 2018, 11:06:30 CET schrieb Gilad Ben-Yossef: Hi Gilad, > 2. Pointing out that the problem solved (and rightfully so) by mutex in > AF_ALG AIO implementation must exists elsewhere as well - for example > IPsec, and is probably solved there too, so if we add the flag as >

Re: [PATCH] crypto: AF_ALG AIO - lock context IV

Am Donnerstag, 1. Februar 2018, 10:35:07 CET schrieb Gilad Ben-Yossef: Hi Gilad, > > > > Which works well for the sort of optimization I did and for hardware that > > can do iv dependency tracking itself. If hardware dependency tracking was > > avilable, you would be able to queue up requests

Re: [PATCH] crypto: AF_ALG AIO - lock context IV

h IOCB. The ctx->iv is read for > >> > the crypto operation and written back after the crypto operation. Thus, > >> > processing of multiple IOCBs must be serialized. > >> > > >> > As the AF_ALG interface is used by user space, a mutex provid

Re: [PATCH v2 2/4] crypto: aesni - Enable one-sided zero copy for gcm(aes) request buffers

Am Dienstag, 23. Januar 2018, 21:19:14 CET schrieb Junaid Shahid: Hi Junaid, > gcmaes_encrypt/decrypt perform zero-copy crypto if both the source and > destination satisfy certain conditions (single sglist entry located in > low-mem or within a single high-mem page). But two copies are done >

Re: Subject: [PATCH] crypto: add zbewalgo compression algorithm for zram

Am Dienstag, 30. Januar 2018, 16:08:57 CET schrieb Benjamin Warnke: Hi Benjamin, Please run checkpatch.pl on the patch and fix the formatting issues. In general: I do not think that having larger C functions in header files is a proper coding style. Also, having static variables header files

Re: [PATCH] crypto: AF_ALG AIO - lock context IV

Am Dienstag, 30. Januar 2018, 09:27:04 CET schrieb Stephan Müller: Hi, > +/** > + * af_alg_put_iv - release lock on IV in case CTX IV is used > + * > + * @sk [in] AF_ALG socket > + */ > +void af_alg_put_iv(struct sock *sk) > +{ > + struct alg_sock *ask = alg_sk(sk); > + struct af_alg_ctx

Re: [PATCH 2/4] crypto: aesni - Enable one-sided zero copy for gcm(aes) request buffers

Am Dienstag, 23. Januar 2018, 00:04:01 CET schrieb Junaid Shahid: Hi Junaid, > gcmaes_encrypt/decrypt perform zero-copy crypto if both the source and > destination satisfy certain conditions (single sglist entry located in > low-mem or within a single high-mem page). But two copies are done >

Re: [PATCH] crypto: AF_ALG - inline IV support

Am Montag, 22. Januar 2018, 15:11:53 CET schrieb Jonathan Cameron: Hi Jonathan, > On Mon, 15 Jan 2018 10:35:34 +0100 > > Stephan Mueller <smuel...@chronox.de> wrote: > > The kernel crypto API requires the caller to set an IV in the request > > data structure. That r

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: [RFC] AF_ALG AIO and IV

Am Montag, 15. Januar 2018, 15:42:58 CET schrieb Jonathan Cameron: Hi Jonathan, > > What about: > > > > sendmsg(IV, data) > > sendmsg(data) > > .. > > AIO recvmsg with multiple IOCBs > > AIO recvmsg with multiple IOCBs > > .. > > sendmsg(IV, data) > > .. > > > > This implies, however, that

Re: [RFC] AF_ALG AIO and IV

Am Montag, 15. Januar 2018, 15:25:38 CET schrieb Jonathan Cameron: Hi Jonathan, > On Mon, 15 Jan 2018 14:15:42 +0100 > > Stephan Mueller <smuel...@chronox.de> wrote: > > Am Montag, 15. Januar 2018, 13:59:27 CET schrieb Jonathan Cameron: > > > > Hi Jon

Re: [RFC] AF_ALG AIO and IV

Am Montag, 15. Januar 2018, 13:59:27 CET schrieb Jonathan Cameron: Hi Jonathan, > > > > But there may be hardware that cannot/will not track such dependencies. > > Yet, it has multiple hardware queues. Such hardware can still handle > > parallel requests when they are totally independent from

Re: [RFC] AF_ALG AIO and IV

Am Montag, 15. Januar 2018, 12:05:03 CET schrieb Jonathan Cameron: Hi Jonathan, > On Fri, 12 Jan 2018 14:21:15 +0100 > > Stephan Mueller <smuel...@chronox.de> wrote: > > Hi, > > > > The kernel crypto API requires the caller to set an IV in the request data

Re: [RFC] AF_ALG AIO and IV

Am Freitag, 12. Januar 2018, 14:21:15 CET schrieb Stephan Mueller: Hi, > > 1. Require that the cipher implementations serialize any AIO requests that > have dependencies. I.e. for CBC, requests need to be serialized by the > driver. For, say, ECB or XTS no serialization is neces

[PATCH] crypto: AF_ALG - inline IV support

erface by giving the user the choice to provide the IV either via sendmsg (the current approach) or as part of the data (the additional approach). Signed-off-by: Stephan Mueller <smuel...@chronox.de> --- crypto/af_alg.c | 79 - crypto/alg

[RFC] AF_ALG AIO and IV

Hi, The kernel crypto API requires the caller to set an IV in the request data structure. That request data structure shall define one particular cipher operation. During the cipher operation, the IV is read by the cipher implementation and eventually the potentially updated IV (e.g. in case

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 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] crypto: Fix race around ctx->rcvused by making it atomic_t

Am Freitag, 22. Dezember 2017, 08:48:03 CET schrieb Herbert Xu: Hi Herbert, > On Tue, Dec 19, 2017 at 10:31:22AM +, Jonathan Cameron wrote: > > This variable was increased and decreased without any protection. > > Result was an occasional misscount and negative wrap around resulting > > in

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 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 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, 10:50:10 CET schrieb Dmitry Vyukov: Hi Dmitry, > On Wed, Dec 20, 2017 at 10:29 AM, Stephan Mueller <smuel...@chronox.de> wrote: > > Am Mittwoch, 20. Dezember 2017, 10:19:43 CET schrieb Dmitry Vyukov: > > > > Hi Dmitry, > >

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

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

Re: [PATCH] crypto: Fix race around ctx->rcvused by making it atomic_t

Am Dienstag, 19. Dezember 2017, 12:26:42 CET schrieb Jonathan Cameron: Hi Jonathan, > > > + atomic_set(>rcvused, 0); > > > > I think ATOMIC_INIT(0) is more suitable here. > > It's ugly to use it to assign a dynamic element like this. > > ctx->rcvused = (atomic_t)ATOMIC_INIT(0); You are

Re: [PATCH] crypto: Fix race around ctx->rcvused by making it atomic_t

clude > #include > +#include > #include > > #include > @@ -150,7 +151,7 @@ struct af_alg_ctx { > struct crypto_wait wait; > > size_t used; > - size_t rcvused; > + atomic_t rcvused; > > bool more; > bool merge; > @@ -215,7 +216,7 @@ static inline int af_alg_rcvbuf(struct sock *sk) > struct af_alg_ctx *ctx = ask->private; > > return max_t(int, max_t(int, sk->sk_rcvbuf & PAGE_MASK, PAGE_SIZE) - > - ctx->rcvused, 0); > + atomic_read(>rcvused), 0); > } > > /** Other than the comments above: Reviewed-by: Stephan Mueller <smuel...@chronox.de> Ciao Stephan

Re: RFC: Crypto: Race in updating available writable socket memory.

Am Montag, 18. Dezember 2017, 15:26:00 CET schrieb Jonathan Cameron: Hi Jonathan, > Hi All, > > I came across this one but am not sure how heavy weight a fix we want to > apply. > > I was getting failures on af_alg_readable in af_alg_get_rsgl which made > little sense as I had wmem set to a

Re: KASAN: use-after-free Read in __list_del_entry_valid (2)

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.

Re: BUG: unable to handle kernel NULL pointer dereference in __crypto_alg_lookup

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

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

ug where user space is able to cause one cipher to be > > registered multiple times potentially exhausting kernel memory. > > > > Reported-by: syzbot <syzkal...@googlegroups.com> > > Cc: <sta...@vger.kernel.org> > > Signed-off-by: Stephan Mueller <smue

AF_ALG: skb limits

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

Re: [crypto 6/8] chtls: TCB and Key program

Am Donnerstag, 7. Dezember 2017, 16:08:04 CET schrieb Atul Gupta: Hi Atul, > > As far as I see, the key is part of the skb (via kctx). This skb is > > released after being processed. The release calls kfree_skb which does > > not zeroize the key. Wouldn't it make sense to clear the memory of the

Re: [crypto 6/8] chtls: TCB and Key program

Am Donnerstag, 7. Dezember 2017, 15:21:03 CET schrieb Atul Gupta: Hi Atul, > > memzero_explicit(key)? > [Atul] may not be required as entire info of size keylen and AEAD_H_SIZE is > copied onto kctx->key. Key data is received from user, while ghash is > memset and locally generated Sure, but

Re: [PATCH] crypto: exynos - Icrease the priority of the driver

ty before > software implementations, but allow them to be selected in FIPS-mode > (fips=1 in the kernel command line). > > Signed-off-by: Łukasz Stelmach <l.stelm...@samsung.com> Reviewed-by: Stephan Mueller <smuel...@chronox.de> Ciao Stephan

Re: [PATCH 2/3] crypto: exynos - Improve performance of PRNG

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

Re: [PATCH 3/3] crypto: exynos - Reseed PRNG after generating 2^16 random bytes

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 <smuel...@c

Re: [RFC] crypto: exynos - Icrease the priority of the driver

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

Re: [crypto 6/8] chtls: TCB and Key program

Am Dienstag, 5. Dezember 2017, 12:40:29 CET schrieb Atul Gupta: Hi Atul, > program the tx and rx key on chip. > > Signed-off-by: Atul Gupta > --- > drivers/crypto/chelsio/chtls/chtls_hw.c | 394 > 1 file changed, 394 insertions(+) >

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

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

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

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

Re: general protection fault in af_alg_free_areq_sgls

; + } > > - 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 <smuel...@chronox.de> Ciao Stephan

Re: general protection fault in blkcipher_walk_done

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 > > >

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

m> > Cc: <sta...@vger.kernel.org> # v4.14+ > Signed-off-by: Eric Biggers <ebigg...@google.com> Yes, 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 <smuel...@chronox.de> Ciao Stephan

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

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

Re: x509 parsing bug + fuzzing crypto in the userspace

Am Freitag, 24. November 2017, 17:25:55 CET schrieb Dmitry Vyukov: Hi Dmitry, > Eric also pointed me to grep. But I can't say the code is intuitive. > I've spent way more time than I expected to just get a list of all > algorithms with their types. Say, in some cases algorithm descriptions > do

Re: x509 parsing bug + fuzzing crypto in the userspace

Am Freitag, 24. November 2017, 17:18:08 CET schrieb Dmitry Vyukov: Hi Dmitry, > > > {"rfc7539esp", []int{ALG_BLKCIPHER, ALG_HASH}}, > > {"rfc7539", []int{ALG_BLKCIPHER, ALG_HASH}}, > > {"rfc4543", []int{ALG_AEAD}}, > > {"rfc4106",

Re: x509 parsing bug + fuzzing crypto in the userspace

Am Freitag, 24. November 2017, 17:10:59 CET schrieb Dmitry Vyukov: Hi Dmitry, > That's more-or-less what I did. Here: > > var allAlgs = map[int][]algDesc{ > ALG_AEAD: []algDesc{ > // templates: > {"authencesn", []int{ALG_HASH, ALG_BLKCIPHER}}, > {"gcm", []int{ALG_CIPHER}}, > >

Re: [PATCH v3] crypto: algif_aead - skip SGL entries with NULL page

L page. Thus, the code needs to advance the start > > pointer into the SGL to the first non-NULL entry. > > > > This fixes a crash visible on Intel x86 32 bit using the libkcapi test > > suite. > > > > Fixes: 72548b093ee38 ("crypto: algif_aead - copy AAD fr

Re: x509 parsing bug + fuzzing crypto in the userspace

Am Freitag, 24. November 2017, 16:53:26 CET schrieb Dmitry Vyukov: Hi Dmitry, > > You cannot talk to the inner ciphers. You only talk to one cipher that you > > referred to with the name. Remember, the name is ONLY used to tell the > > kernel which parts to put together during allocation. After

Re: [PATCH v3] crypto: AF_ALG - remove locking in async callback

ces for a crypto operation is moved into a > > common function of af_alg_free_resources. > > > > Fixes: e870456d8e7c8 ("crypto: algif_skcipher - overhaul memory > > management") Fixes: d887c52d6ae43 ("crypto: algif_aead - overhaul memory > > management") Re

Re: x509 parsing bug + fuzzing crypto in the userspace

Am Freitag, 24. November 2017, 15:55:59 CET schrieb Dmitry Vyukov: Hi Dmitry, > On Fri, Nov 24, 2017 at 3:36 PM, Stephan Mueller <smuel...@chronox.de> wrote: > > Am Freitag, 24. November 2017, 14:49:49 CET schrieb Dmitry Vyukov: > > > > Hi Dmitry, > > >

Re: x509 parsing bug + fuzzing crypto in the userspace

Am Freitag, 24. November 2017, 14:49:49 CET schrieb Dmitry Vyukov: Hi Dmitry, > I've cooked syzkaller change that teaches it to generate more > algorithm names. Probably not idea, but much better than was before: > https://github.com/google/syzkaller/blob/ddf7b3e0655cf6dfeacfe509e477c1486d2 >

Re: x509 parsing bug + fuzzing crypto in the userspace

Am Freitag, 24. November 2017, 14:49:49 CET schrieb Dmitry Vyukov: Hi Dmitry, > On Thu, Nov 23, 2017 at 1:35 PM, Stephan Mueller <smuel...@chronox.de> wrote: > > Am Donnerstag, 23. November 2017, 12:34:54 CET schrieb Dmitry Vyukov: > > > > Hi Dmitry, > >

Re: x509 parsing bug + fuzzing crypto in the userspace

Am Donnerstag, 23. November 2017, 12:34:54 CET schrieb Dmitry Vyukov: Hi Dmitry, > Btw, I've started doing some minimal improvements, did not yet sorted > out alg types/names, and fuzzer started scratching surface: > > WARNING: kernel stack regs has bad 'bp' value 77 Nov 23 2017 12:29:36 CET >

  1   2   3   4   5   6   7   8   9   10   >