Re: Computing GHASH for GCM when IV > 12 Bytes

Am Donnerstag, 16. August 2018, 09:14:59 CEST schrieb Jitendra Lulla: Hi Jitendra, > Hi Stephen, > > I could not spot in the kernel where we are computing GHASH when the > IV is bigger than 12 Bytes for GCM encryption. > > libkcapi and kernel appears to ignore the bytes beyond 12th byte in the

random: ensure use of aligned buffers with ChaCha20

The function extract_crng invokes the ChaCha20 block operation directly on the user-provided buffer. The block operation operates on u32 words. Thus the extract_crng function expects the buffer to be aligned to u32 as it is visible with the parameter type of extract_crng. However, get_random_bytes

Re: [PATCH 2/3] crypto: hisilicon SEC security accelerator driver

Am Montag, 16. Juli 2018, 12:43:41 CEST schrieb Jonathan Cameron: Hi Jonathan, > +static int sec_alg_skcipher_setkey_aes_xts(struct crypto_skcipher *tfm, > + const u8 *key, unsigned int > keylen) +{ > + enum sec_cipher_alg alg; > + > + switch

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

The cipher implementations of the kernel crypto API favor in-place cipher operations. Thus, switch the CTR cipher operation in the DRBG to perform in-place operations. This is implemented by using the output buffer as input buffer and zeroizing it before the cipher operation to implement a CTR

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

Am Donnerstag, 19. Juli 2018, 11:34:33 CEST schrieb Herbert Xu: Hi Herbert, > I think this is an abuse of virt_addr_valid. It's meant to catch > bogus uses of SG lists, it's not meant to be a guarantee that an > address can be used on an SG list. Thanks for your insights. > > A better

[PATCH 1/2] crypto: DH - update test for public key verification

By adding a zero byte-length for the DH parameter Q value, the public key verification test is disabled for the given test. Reported-by: Eric Biggers Signed-off-by: Stephan Mueller --- crypto/testmgr.h | 4 1 file changed, 4 insertions(+) diff --git a/crypto/testmgr.h b/crypto/testmgr.h

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

Am Mittwoch, 11. Juli 2018, 06:10:59 CEST schrieb Eric Biggers: Hi Eric, > You forgot to update the self-tests in the kernel, so they're failing now, > as you *did* change the interface (the "key" is encoded differently now). I was actually looking for failing self tests. But accidentally I

Re: [PATCH] crypto: dh - fix calculating encoded key size

("crypto: dh - add public key verification test") > Signed-off-by: Eric Biggers Thanks. Reviewed-by: Stephan Müller Ciao Stephan

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

The SGL can directly operate caller-provided memory with the exception of stack memory. The DRBG detects whether the caller provided non-suitable memory and uses the scratchpad only on those circumstances. This patch increases the speed of the CTR DRBG by 1 to 3 percent depending on the buffer

[PATCH 0/2] crypto: DRBG - performance improvements for CTR DRBG

Hi Herbert, Please find CTR DRBG performance improvements with the patches attached. In the following, there is an example log taken with my LRNG implementation using the getrandom(2) system call demonstrating the difference. Without the patch set: 16 bytes| 12.267661 MB/s|

[PATCH 1/2] crypto: DRBG - eliminate constant reinitialization of SGL

The CTR DRBG requires two SGLs pointing to input/output buffers for the CTR AES operation. The used SGLs always have only one entry. Thus, the SGL can be initialized during allocation time, preventing a re-initialization of the SGLs during each call. The performance is increased by about 1 to 3

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

Hi, Changes v2: * addition of a check that mpi_alloc succeeds. ---8<--- According to SP800-56A section 5.6.2.1, the public key to be processed for the DH operation shall be checked for appropriateness. The check shall covers the full verification test in case the domain parameter Q is provided

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

Hi, This patch is an RFC to discuss the following: step 1 in dh_is_pubkey_valid requires the public key to be in the range of 1 < y < p - 1. The currently implemented check is 1 < y < p since the calculation of p - 1 requires the presence of mpi_sub or mpi_sub_ui. Both functions are currently not

[PATCH] crypto: ECDH - add public key verification test

According to SP800-56A section 5.6.2.1, the public key to be processed for the ECDH operation shall be checked for appropriateness. When the public key is considered to be an ephemeral key, the partial validation test as defined in SP800-56A section 5.6.2.3.4 can be applied. The partial

Re: cryptomgr_test / drbg_ctr: BUG: sleeping function called from invalid context

Am Freitag, 18. Mai 2018, 10:36:04 CEST schrieb Geert Uytterhoeven: Hi Geert, > > I tried following the code path, but couldn't find where it went wrong. > > mutex_lock(>drbg_mutex) is called from drbg_instantiate(), which is > inlined by the compiler into drbg_kcapi_seed(). > > Do you have a

4.16: /dev/random - a new approach

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

libkcapi v1.1.0 released

Hi, The Linux kernel exports a network interface of type AF_ALG to allow user space to utilize the kernel crypto API. libkcapi uses this network interface and exports an easy to use API so that a developer does not need to consider the low-level network interface handling. The library does

[PATCH] crypto: drbg - set freed buffers to NULL

Add the Fixes, CC stable tags. ---8<--- During freeing of the internal buffers used by the DRBG, set the pointer to NULL. It is possible that the context with the freed buffers is reused. In case of an error during initialization where the pointers do not yet point to allocated memory, the NULL

[PATCH] crypto: drbg - set freed buffers to NULL

Sorry, this time with the proper subject line. ---8<--- During freeing of the internal buffers used by the DRBG, set the pointer to NULL. It is possible that the context with the freed buffers is reused. In case of an error during initialization where the pointers do not yet point to allocated

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

Hi Dimitry, This fix prevents the kernel from crashing when injecting the fault. Stack traces are yet shown but I guess that is expected every time a fault is injected. As to why KASAN did not notice this one, I am not sure. Maybe it is because I use two buffer pointers to point to (almost) the

[PATCH] crypto: DRBG - guard uninstantion by lock

Am Sonntag, 8. April 2018, 17:41:17 CEST schrieb Dmitry Vyukov: Hi Dmitry, > > Hi, > > Here is config and kernel commit: > https://groups.google.com/d/msg/syzkaller-bugs/PINYyzoaG1s/ntZPOZdcCAAJ > You can also find compiler and image here if necessary: >

[PATCH] AF_ALG: register completely initialized request in list

Hi, May I ask to check whether this patch fixes the issue? I cannot re-create the issue with the reproducter. Yet, as far as I understand, you try to induce errors which shall validate whether the error code paths are correct. The fix below should ensure this now. Thanks a lot. ---8<--- >From

Re: WARNING in kmem_cache_free

Am Sonntag, 8. April 2018, 13:18:06 CEST schrieb Dmitry Vyukov: Hi Dmitry, > > Running syz-repro utility on this log, I think I've found the guilty guy: > https://gist.githubusercontent.com/dvyukov/1dd75d55efd238e7207af1cc38478b3a/ > raw/403859b56b161a6fbb158e8953fac5bb6e73b1a1/gistfile1.txt >

Re: error in libkcapi 1.0.3 for aead aio

Am Sonntag, 25. Februar 2018, 06:25:06 CET schrieb Harsh Jain: Hi Harsh, > Hi Stephan, > > 1 of the test mentioned in test.sh is failing for AEAD AIO operation even > thought driver is returning EBADMSG(as expected) to af_alg with latest > cryptodev tree. > > Debug log and strace attached. >

Re: [PATCH v3 0/4] crypto: AF_ALG AIO improvements

Am Freitag, 23. Februar 2018, 13:00:26 CET schrieb Herbert Xu: Hi Herbert, > On Fri, Feb 23, 2018 at 09:33:33AM +0100, Stephan Müller wrote: > > A simple copy operation, however, will imply that in one AIO recvmsg > > request, only *one* IOCB can be set and processed. > >

Re: [PATCH v3 0/4] crypto: AF_ALG AIO improvements

Am Donnerstag, 22. Februar 2018, 14:06:00 CET schrieb Herbert Xu: Hi Herbert, > On Fri, Feb 09, 2018 at 11:02:27PM +0100, Stephan Müller wrote: > > Hi, > > > > Herbert, the patch 1 is meant for stable. However, this patch as is > > only applies to the new AF_ALG inter

[PATCH v3 3/4] crypto: AF_ALG - allow driver to serialize IV access

The mutex in AF_ALG to serialize access to the IV ensures full serialization of requests sent to the crypto driver. However, the hardware may implement serialization to the IV such that preparation work without touching the IV can already happen while the IV is processed by another operation.

[PATCH v3 0/4] crypto: AF_ALG AIO improvements

Hi, Herbert, the patch 1 is meant for stable. However, this patch as is only applies to the new AF_ALG interface implementation. Though, the issue goes back to the first implementation of AIO support. Shall I try prepare a patch for the old AF_ALG implementation as well? Changes from v2: *

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

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 of CBC)

[PATCH v3 2/4] crypto: AF_ALG - inline IV support

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 of CBC)

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

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. When the user decides that he wants to send multiple AIO requests concurrently and wants the crypto driver to handle the serialization,

Re: [PATCH v2 2/4] crypto: AF_ALG - inline IV support

Am Mittwoch, 7. Februar 2018, 14:54:08 CET schrieb Jonathan Cameron: Hi Jonathan, > > It's not a 'bug' as such, but this does currently break the crypto-perf > test for aio and iiv in the libkcapi branch. We can perhaps make it > more forgiving... I just pushed an update for the IIV branch of

[PATCH v2 3/4] crypto: AF_ALG - allow driver to serialize IV access

The mutex in AF_ALG to serialize access to the IV ensures full serialization of requests sent to the crypto driver. However, the hardware may implement serialization to the IV such that preparation work without touching the IV can already happen while the IV is processed by another operation.

[PATCH v2 0/4] crypto: AF_ALG AIO improvements

Hi Herbert, Herbert, the patch 1 is meant for stable. However, this patch as is only applies to the new AF_ALG interface implementation. Though, the issue goes back to the first implementation of AIO support. Shall I try prepare a patch for the old AF_ALG implementation as well? Changes from v1:

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

Crypto drivers may implement a streamlined serialization support for AIO requests that is reported by the CRYPTO_TFM_REQ_PARALLEL flag to the crypto user. When the user decides that he wants to send multiple AIO requests concurrently and wants the crypto driver to handle the serialization, the

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

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 of CBC)

[PATCH v2 2/4] crypto: AF_ALG - inline IV support

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 of CBC)

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

Am Dienstag, 30. Januar 2018, 16:29:52 CET schrieb Jonathan Cameron: Hi Jonathan, > + /* Special path for single element SGLs with small packets. */ > + if (sg_is_last(sgl) && sgl->length <= SEC_SMALL_PACKET_SIZE) { This looks strangely familiar. Is this code affected by a similar issue

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

Am Dienstag, 30. Januar 2018, 20:49:00 CET schrieb Benjamin Warnke: Hi Benjamin, > > In general: I do not think that having larger C functions in header files > > is a proper coding style. > > How should I solve this? > > Option 1: > Move everything in the lib/zbewalgo folder into a single

[PATCH] crypto: AF_ALG AIO - lock context IV

Hi Harsh, may I as you to try the attached patch on your Chelsio driver? Please invoke the following command from libkcapi: kcapi -d 2 -x 9 -e -c "cbc(aes)" -k 8d7dd9b0170ce0b5f2f8e1aa768e01e91da8bfc67fd486d081b28254c99eb423 -i 7fbc02ebf5b93322329df9bfccb635af -p

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

Hi Herbert, I tried to summarize the use cases of the AIO support at [1]. The use case covering the inline IV support is documented in section [2]. It naturally would depend on this patch to be accepted. What is your take on this use case? What is your take on the issue outlined at [3]?

[PATCH v2] crypto: AES-NI GCM - handle zero length dst buffer

Hi Herbert, Sorry, I forgot to CC you on this patch -- v2 is unchanged from the original patch. It only adds you in copy. ---8<--- GCM can be invoked with a zero destination buffer. This is possible if the AAD and the ciphertext have zero lengths and only the tag exists in the source buffer

[PATCH] crypto: AES-NI GCM - handle zero length dst buffer

GCM can be invoked with a zero destination buffer. This is possible if the AAD and the ciphertext have zero lengths and only the tag exists in the source buffer (i.e. a source buffer cannot be zero). In this case, the GCM cipher only performs the authentication and no decryption operation. When

AES-NI: BUG in gcmaes_decrypt

Hi, When compiling the current cryptodev-2.6 tree with CONFIG_DEBUG_SG and invoking a gcm(aes) decrypt operation with an empty ciphertext and an empty AAD, I get the following BUG: [ 79.294243] [ cut here ] [ 79.294903] kernel BUG at

Re: AF_ALG: skb limits

Am Dienstag, 12. Dezember 2017, 14:59:21 CET schrieb Jonathan Cameron: Hi Jonathan, > On Fri, 8 Dec 2017 13:43:20 +0100 > > Stephan Mueller wrote: > > Am Freitag, 8. Dezember 2017, 12:39:06 CET schrieb Jonathan Cameron: > > > > Hi Jonathan, > > > > > As a heads up, the

[PATCH v4] crypto: AF_ALG - whitelist mask and type

Hi, sorry, I forgot the right tags. ---8<--- The user space interface allows specifying the type and mask field used to allocate the cipher. Only a subset of the possible flags are intended for user space. Therefore, white-list the allowed flags. In case the user space caller uses at least one

[PATCH v3] crypto: AF_ALG - whitelist mask and type

The user space interface allows specifying the type and mask field used to allocate the cipher. Only a subset of the possible flags are intended for user space. Therefore, white-list the allowed flags. In case the user space caller uses at least one non-allowed flag, EINVAL is returned.

Re: [PATCH 1/3] crypto: salsa20-generic - cleanup and convert to skcipher API

Am Montag, 1. Januar 2018, 00:46:40 CET schrieb Eric Biggers: Hi Eric, > > -static void salsa20_wordtobyte(u8 output[64], const u32 input[16]) > +static void salsa20_block(u32 *state, u32 *stream) Shouldn't stream be __le32? This could get rid of the type casting further down. > { >

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

Am Mittwoch, 20. Dezember 2017, 08:48:01 CET schrieb syzbot: Hi, > Hello, > > syzkaller hit the following crash on > 032b4cc8ff84490c4bc7c4ef8c91e6d83a637538 > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master > compiler: gcc (GCC) 7.1.1 20170620 > .config is attached >

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

The user space interface allows specifying the type and the mask field used to allocate the cipher. As user space can precisely select the desired cipher by using either the name or the driver name, additional selection options for cipher are not considered necessary and relevant for user space.

[PATCH] crypto: AF_ALG - limit mask and type

Hi Herbert, you see the reported problem by simply using sa.salg_mask = 0x; Note, I am not fully sure about whether CRYPTO_AF_ALG_ALLOWED_MASK and CRYPTO_AF_ALG_ALLOWED_TYPE have the correct value. But I think that all that user space should reach is potentially the ASYNC flag and the

[PATCH] crypto: AF_ALG - fix race accessing cipher request

Hi Herbert, This patch would go on top of 7d2c3f54e6f646887d019faa45f35d6fe9fe82ce "crypto: af_alg - remove locking in async callback" found in Linus' tree which is not yet in the cryptodev-2.6 tree. In addition, this patch is already on top of the other patches discussed on this list fixing

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, > > It sort of worked for skcipher because it didn't care if ctx->enc > or even ctx->iv changed midstream. But even there I don't think > we need to wait a second time. In fact waiting a second time could > result in

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

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

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

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

Re: general protection fault in crypto_remove_spawns

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

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

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

Re: general protection fault in scatterwalk_copychunks

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

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

Am Montag, 27. November 2017, 19:56:46 CET schrieb syzbot: Hi, > Hello, > > syzkaller hit the following crash on > 6fc478f80f6809cc4b1a4230f47a62d3b7378dc0 > 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 2/3] hwrng: exynos - add Samsung Exynos True RNG driver

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

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

The code paths protected by the socket-lock do not use or modify the socket in a non-atomic fashion. The actions pertaining the socket do not even need to be handled as an atomic operation. Thus, the socket-lock can be safely ignored. This fixes a bug regarding scheduling in atomic as the

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

Am Freitag, 10. November 2017, 08:29:40 CET schrieb Stephan Müller: Hi, > The TX SGL may contain SGL entries that are assigned a NULL page. This > may happen if a multi-stage AIO operation is performed where the data > for each stage is pointed to by one SGL entry. Upon c

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

The TX SGL may contain SGL entries that are assigned a NULL page. This may happen if a multi-stage AIO operation is performed where the data for each stage is pointed to by one SGL entry. Upon completion of that stage, af_alg_pull_tsgl will assign NULL to the SGL entry. The NULL cipher used to

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

The code paths protected by the socket-lock do not use or modify the socket in a non-atomic fashion. The actions pertaining the socket do not even need to be handled as an atomic operation. Thus, the socket-lock can be safely ignored. This fixes a bug regarding scheduling in atomic as the

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

Am Mittwoch, 25. Oktober 2017, 17:26:31 CET schrieb Romain Izard: Hi Romain, the patch below should cover the issue you see. Would you mind testing it? Thanks Stephan ---8<--- The code paths protected by the socket-lock do not use or modify the socket in a non-atomic fashion. The actions

Re: [PATCH v2] crypto: shash - Fix zero-length shash ahash digest crash

his patch fixes it by checking the length first. The patch fixes the issue. > > Cc: <sta...@vger.kernel.org> > Reported-by: Stephan Müller<smuel...@chronox.de> > Signed-off-by: Herbert Xu <herb...@gondor.apana.org.au> Tested-by: Stephan Müller <smuel...@chronox.de> Ciao Stephan

Re: [PATCH 1/2] crypto: skcipher - noop for enc/dec with NULL data

Am Montag, 9. Oktober 2017, 16:19:25 CEST schrieb Herbert Xu: Hi Herbert, > On Sat, Oct 07, 2017 at 02:56:24PM +0200, Stephan Müller wrote: > > Though, this opens up the shash issue I tried to fix. > > Does this patch fix the crash? I get the following during boot:

[ANNOUNCE] libkcapi v1.0.0 released

Hi, The Linux kernel exports a network interface of type AF_ALG to allow user space to utilize the kernel crypto API. libkcapi uses this network interface and exports an easy to use API so that a developer does not need to consider the low-level network interface handling. The library does

Re: [PATCH 1/2] crypto: skcipher - noop for enc/dec with NULL data

. Thank you. This fixes the issue. Tested-by: Stephan Müller <smuel...@chronox.de> Though, this opens up the shash issue I tried to fix. [ 213.090857] [ cut here ] [ 213.091318] kernel BUG at ./include/linux/scatterlist.h:123! [ 213.091986] invalid opcode: [#1]

Re: [PATCH 1/2] crypto: skcipher - noop for enc/dec with NULL data

Am Samstag, 7. Oktober 2017, 05:07:52 CEST schrieb Herbert Xu: Hi Herbert, > On Sat, Oct 07, 2017 at 04:53:46AM +0200, Stephan Müller wrote: > > I use authenc(hmac(sha256),cbc(aes)) which in turn uses cbc-aes-aesni on > > my > > system. > > So where exactly is i

Re: [PATCH 1/2] crypto: skcipher - noop for enc/dec with NULL data

Am Samstag, 7. Oktober 2017, 04:46:35 CEST schrieb Herbert Xu: Hi Herbert, > Hmm this just papers over bugs in the underlying code. Which > algorithm is causing the crash with a zero input? They're supposed > to handle this case. The bug happens with authenc. It is surely possible to modify

[PATCH v2] crypto: keywrap - simplify code

Hi Herbert, Changes v2: * use __be64 for A and R variables * eliminate tbe variable * use initial IV value with cpu_to_be64 when accessing variable A ---8<--- The code is simplified by using two __be64 values for the operation instead of using two arrays of u8. This allows to get rid of the

[PATCH] crypto: keywrap - simplify code

The code is simplified by using two u64 values for the operation instead of using two arrays of u8. This allows to get rid of the memory alignment code. In addition, the crypto_xor can be replaced with a native XOR operation. Finally, the definition of the variables is re-arranged such that the

Re: [PATCH 0/2] fix authenc() kernel crash

Am Sonntag, 24. September 2017, 08:22:54 CEST schrieb Stephan Müller: Hi Herbert, (private) > Hi Herbert, > > The two patches together fix a kernel crash that can be triggered via > AF_ALG when using authenc() with zero plaintext. > > The changes are also tested to verif

[PATCH 0/2] fix authenc() kernel crash

Hi Herbert, The two patches together fix a kernel crash that can be triggered via AF_ALG when using authenc() with zero plaintext. The changes are also tested to verify that the hashing on null data is still supported. I suspect that the vulnerability fixed with patch 1 is present in abklcipher

[PATCH 2/2] crypto: shash - no kmap of zero SG

In case the caller provides an SG with zero data, prevent a kmap of the page pointed to by the SG. In this case, it is possible that the page does not exist. This fixes a crash in authenc() when the plaintext is zero and thus the encryption operation is a noop. In this case, no input data exists

[PATCH] crypto: DRBG - fix freeing of resources

During the change to use aligned buffers, the deallocation code path was not updated correctly. The current code tries to free the aligned buffer pointer and not the original buffer pointer as it is supposed to. Thus, the code is updated to free the original buffer pointer and set the aligned

Re: md5sum (from libkcapi) fails as splice() returns -ENOKEY

Am Montag, 11. September 2017, 19:07:31 CEST schrieb christophe leroy: Hi christophe, > Hello Stephan, > > I'm trying to use md5sum from the latest libkcapi 0.14 and I getting a > failure with return code -5. > > What am I missing ? See strace below, splice() return -ENOKEY. The ENOKEY error

Re: [PATCH v2] crypto: add NULL check to scatterwalk_start

Am Samstag, 9. September 2017, 00:20:50 CEST schrieb Stephan Müller: Hi Herbert, > walk->sg = sg; > - walk->offset = sg->offset; > + if (sg) > + walk->offset = sg->offset; > + else > + walk->offset = 0; > } After

[PATCH v2] crypto: add NULL check to scatterwalk_start

Am Donnerstag, 7. September 2017, 08:01:08 CEST schrieb Herbert Xu: Hi Herbert, > On Thu, Sep 07, 2017 at 07:48:53AM +0200, Stephan Müller wrote: > > There is already such check: > > > > static inline int crypto_aead_decrypt(struct aead_request *req) > > { > >

Re: [PATCH] crypto: authenc - cryptlen must be at least AAD len

Am Donnerstag, 7. September 2017, 05:54:05 CEST schrieb Herbert Xu: Hi Herbert, > > > > What is your opinion: should this check be rather added to > > crypto_aead_encrypt (similar to a sanity check found in > > crypto_aead_decrypt)? > > Doesn't this apply to decryption as well? There is

Re: [PATCH] crypto: authenc - cryptlen must be at least AAD len

Am Mittwoch, 6. September 2017, 21:22:44 CEST schrieb Stephan Müller: Hi Herbert, > With AF_ALG, AAD len and cryptlen can be set freely by unprivileged > user space. The cipher implementation must therefore validate the input > data for sanity. For AEAD ciphers, this implies that cryp

[PATCH] crypto: authenc - cryptlen must be at least AAD len

With AF_ALG, AAD len and cryptlen can be set freely by unprivileged user space. The cipher implementation must therefore validate the input data for sanity. For AEAD ciphers, this implies that cryptlen must be at least as large as AAD size. This fixes a kernel crash that can be triggered via

[PATCH] crypto: AF_ALG - remove SGL end indicator when chaining

The SGL is MAX_SGL_ENTS + 1 in size. The last SG entry is used for the chaining and is properly updated with the sg_chain invocation. During the filling-in of the initial SG entries, sg_mark_end is called for each SG entry. This is appropriate as long as no additional SGL is chained with the

[PATCH] crypto: AF_ALG - update correct dst SGL entry

When two adjacent TX SGL are processed and parts of both TX SGLs are pulled into the per-request TX SGL, the wrong per-request TX SGL entries were updated. This fixes a NULL pointer dereference when a cipher implementation walks the TX SGL where some of the SGL entries were NULL. Signed-off-by:

Re: [PATCH v8 3/4] crypto: AF_ALG -- add asymmetric cipher

Am Freitag, 11. August 2017, 14:51:10 CEST schrieb Tudor Ambarus: Hi Tudor, I have covered all your requests > > > + size_t used = 0; > > initialization to zero not needed. You can directly initialize to > ctx->used or don't initialize at all. It is not initialized now. We cannot use

[PATCH v4] crypto: only call put_page on referenced and used pages

Hi Herbert, This patch was created against the current Linus development tree. The functional test was conducted at the time v3 was aired. The patch v4 is compile-tested. Ciao Stephan ---8<--- For asynchronous operation, SGs are allocated without a page mapped to them or with a page that is

Re: [PATCH v8 0/4] crypto: add algif_akcipher user space API

Am Freitag, 11. August 2017, 07:13:30 CEST schrieb Marcel Holtmann: Hi Marcel, > > > > The last round of reviews for AF_ALG akcipher left off at an impasse > > around a year ago: the consensus was that hardware key support was > > needed, but that requirement was in conflict with the "always

[PATCH] crypto: AF_ALG - get_page upon reassignment to TX SGL

Hi Herbert, The error can be triggered with the following test. Invoking that test in a while [ 1 ] loop shows that no memory is leaked. #include #include int main(int argc, char *argv[]) { char buf[8192]; struct kcapi_handle *handle; struct iovec iov; int ret;

Re: [PATCH v8 1/4] crypto: AF_ALG -- add sign/verify API

Am Donnerstag, 10. August 2017, 15:59:33 CEST schrieb Tudor Ambarus: Hi Tudor, > On 08/10/2017 04:03 PM, Stephan Mueller wrote: > > Is there a style requirement for that? checkpatch.pl does not complain. I > > thought that one liners in a conditional should not have braces? > > Linux coding

[PATCH v8 3/4] crypto: AF_ALG -- add asymmetric cipher

This patch adds the user space interface for asymmetric ciphers. The interface allows the use of sendmsg as well as vmsplice to provide data. The akcipher interface implementation uses the common AF_ALG interface code regarding TX and RX SGL handling. Signed-off-by: Stephan Mueller

[PATCH v8 2/4] crypto: AF_ALG -- add setpubkey setsockopt call

For supporting asymmetric ciphers, user space must be able to set the public key. The patch adds a new setsockopt call for setting the public key. Signed-off-by: Stephan Mueller --- crypto/af_alg.c | 18 +- include/crypto/if_alg.h | 1 +

[PATCH v8 4/4] crypto: algif_akcipher - enable compilation

Add the Makefile and Kconfig updates to allow algif_akcipher to be compiled. Signed-off-by: Stephan Mueller --- crypto/Kconfig | 9 + crypto/Makefile | 1 + 2 files changed, 10 insertions(+) diff --git a/crypto/Kconfig b/crypto/Kconfig index

[PATCH v8 0/4] crypto: add algif_akcipher user space API

Hi, This patch set adds the AF_ALG user space API to externalize the asymmetric cipher API recently added to the kernel crypto API. The patch set is tested with the user space library of libkcapi [1]. Use [1] test/test.sh for a full test run. The test covers the following scenarios: *

[PATCH v8 1/4] crypto: AF_ALG -- add sign/verify API

Add the flags for handling signature generation and signature verification. The af_alg helper code as well as the algif_skcipher and algif_aead code must be changed from a boolean indicating the cipher operation to an integer because there are now 4 different cipher operations that are defined.

[PATCH] crypto: MPI - kunmap after finishing accessing buffer

Hi Herbert, I found that issue while playing around with edge conditions in my algif_akcipher implementation. This issue only manifests in a segmentation violation on 32 bit machines and with an SGL where each SG points to one byte. SGLs with larger buffers seem to be not affected by this issue.

[PATCH] crypto: algif_aead - fix comment regarding memory layout

Signed-off-by: Stephan Mueller --- crypto/algif_aead.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/crypto/algif_aead.c b/crypto/algif_aead.c index 48d46e74ed0d..516b38c3a169 100644 --- a/crypto/algif_aead.c +++ b/crypto/algif_aead.c @@ -201,11

[PATCH v2] crypto: AF_ALG - consolidation of duplicate code

Hi Herbert, as agreed, the individual patches from the first submission are now changed. After review of the changes I had to apply to algif_aead and algif_skcipher, I saw that they are all in the category that you agreed that can be rolled into this patch. Though, I documented the changes so

Re: [PATCH 00/16] crypto: AF_ALG - consolidation

Am Dienstag, 1. August 2017, 11:08:33 CEST schrieb Herbert Xu: Hi Herbert, > > How about you separate into three patches? The first two make > changes to algif_skcipher/algif_aead so that they can be merged, > and the last one does the actual merging. > Ok, I can do that. How would you want to

Re: [PATCH 00/16] crypto: AF_ALG - consolidation

Am Dienstag, 1. August 2017, 10:58:58 CEST schrieb Herbert Xu: Hi Herbert, > > This split makes no sense. I don't see why you can't merge them > into a single patch if it's just rearranging the code. If you want to merge all into one patch, I am fine. I thought that separating all out makes

  1   2   3   4   >