[PATCH 0/5] crypto: eliminate redundant decryption test vectors

Hello, When adding the Speck cipher support I was annoyed by having to add both encryption and decryption test vectors, since they are redundant: the decryption ones are just the encryption ones with the input and result flipped. It turns out that's nearly always the case for all the other

Re: [PATCH v2] fscrypt: log the crypto algorithm implementations

On Fri, May 18, 2018 at 10:58:14AM -0700, Eric Biggers wrote: > Log the crypto algorithm driver name for each fscrypt encryption mode on > its first use, also showing a friendly name for the mode. > > This will help people determine whether the expected implementations are > being used. In some

Re: [PATCH v2] fscrypt: add Speck128/256 support

On Mon, May 07, 2018 at 05:22:08PM -0700, Eric Biggers wrote: > fscrypt currently only supports AES encryption. However, many low-end > mobile devices have older CPUs that don't have AES instructions, e.g. > the ARMv8 Cryptography Extensions. Currently, user data on such devices > is not

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

[PATCH] crypto: x86/aegis256 - Fix wrong key buffer size

From: Ondrej Mosnacek AEGIS-256 key is two blocks, not one. Fixes: 1d373d4e8e15 ("crypto: x86 - Add optimized AEGIS implementations") Reported-by: Eric Biggers Signed-off-by: Ondrej Mosnacek ---

Re: [PATCH 3/3] crypto: x86 - Add optimized AEGIS implementations

2018-05-20 4:41 GMT+02:00 Eric Biggers : > Hi Ondrej, > > On Fri, May 11, 2018 at 02:12:51PM +0200, Ondrej Mosnáček wrote: >> From: Ondrej Mosnacek >> >> This patch adds optimized implementations of AEGIS-128, AEGIS-128L, >> and AEGIS-256, utilizing the

[PATCH 3/6] crypto: crc32-generic - remove __crc32_le()

From: Eric Biggers The __crc32_le() wrapper function is pointless. Just call crc32_le() directly instead. Signed-off-by: Eric Biggers --- crypto/crc32_generic.c | 10 ++ 1 file changed, 2 insertions(+), 8 deletions(-) diff --git

[PATCH 2/6] crypto: crc32c-generic - remove cra_alignmask

From: Eric Biggers crc32c-generic sets an alignmask, but actually its ->update() works with any alignment; only its ->setkey() and outputting the final digest assume an alignment. To prevent the buffer from having to be aligned by the crypto API for just these cases, switch

[PATCH 6/6] crypto: testmgr - add more unkeyed crc32 and crc32c test vectors

From: Eric Biggers crc32c has an unkeyed test vector but crc32 did not. Add the crc32c one (which uses an empty input) to crc32 too, and also add a new one to both that uses a nonempty input. These test vectors verify that crc32 and crc32c implementations use the correct

[PATCH 1/6] crypto: crc32-generic - use unaligned access macros when needed

From: Eric Biggers crc32-generic doesn't have a cra_alignmask set, which is desired as its ->update() works with any alignment. However, it incorrectly assumes 4-byte alignment in ->setkey() and when outputting the final digest. Fix this by using the unaligned access

[PATCH 0/6] crypto: crc32 cleanups and unkeyed tests

This series fixes up alignment for crc32-generic and crc32c-generic, removes test vectors for bfin_crc that are no longer needed, and adds unkeyed test vectors for crc32 and an extra unkeyed test vector for crc32c. Adding the unkeyed test vectors also required a testmgr change to allow a single

[PATCH 4/6] crypto: testmgr - remove bfin_crc "hmac(crc32)" test vectors

From: Eric Biggers The Blackfin CRC driver was removed by commit 9678a8dc53c1 ("crypto: bfin_crc - remove blackfin CRC driver"), but it was forgotten to remove the corresponding "hmac(crc32)" test vectors. I see no point in keeping them since nothing else appears to

[PATCH 5/6] crypto: testmgr - fix testing OPTIONAL_KEY hash algorithms

From: Eric Biggers Since testmgr uses a single tfm for all tests of each hash algorithm, once a key is set the tfm won't be unkeyed anymore. But with crc32 and crc32c, the key is really the "default initial state" and is optional; those algorithms should have both keyed and

Re: [PATCH 3/3] crypto: x86 - Add optimized AEGIS implementations

Hi Ondrej, On Fri, May 11, 2018 at 02:12:51PM +0200, Ondrej Mosnáček wrote: > From: Ondrej Mosnacek > > This patch adds optimized implementations of AEGIS-128, AEGIS-128L, > and AEGIS-256, utilizing the AES-NI and SSE2 x86 extensions. > > Signed-off-by: Ondrej Mosnacek

[PATCH v2][RESEND] X.509: unpack RSA signatureValue field from BIT STRING

The signatureValue field of a X.509 certificate is encoded as a BIT STRING. For RSA signatures this BIT STRING is of so-called primitive subtype, which contains a u8 prefix indicating a count of unused bits in the encoding. We have to strip this prefix from signature data, just as we already do

[PATCH] crypto: Mark MORUS SIMD glue as x86-specific

From: Ondrej Mosnacek Commit 56e8e57fc3a7 ("crypto: morus - Add common SIMD glue code for MORUS") accidetally consiedered the glue code to be usable by different architectures, but it seems to be only usable on x86. This patch moves it under arch/x86/crypto and adds

[cryptodev:master 68/69] crypto/morus640_glue.c:147:2: error: too few arguments to function 'kernel_fpu_begin'

tree: https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master head: 6ecc9d9ff91ff26769e58164b6216c6189cb8302 commit: 56e8e57fc3a707bf4f23f88c4822e6cbc9a950dc [68/69] crypto: morus - Add common SIMD glue code for MORUS config: s390-allmodconfig (attached as .config)

[PATCH] crypto: chtls - fix a missing-check bug

In do_chtls_setsockopt(), the tls crypto info is first copied from the poiner 'optval' in userspace and saved to 'tmp_crypto_info'. Then the 'version' of the crypto info is checked. If the version is not as expected, i.e., TLS_1_2_VERSION, error code -ENOTSUPP is returned to indicate that the

Re: [PATCH 0/4] Add support for MORUS AEAD algorithm

On Fri, May 11, 2018 at 02:19:08PM +0200, Ondrej Mosnáček wrote: > From: Ondrej Mosnacek > > This patchset adds the MORUS AEAD algorithm implementation to the Linux > Crypto API. > > MORUS [1] is a dedicated AEAD algorithm focused on SIMD instructions and > designed for

Re: [PATCH 0/3] Add support for AEGIS AEAD algorithm

On Fri, May 11, 2018 at 02:12:48PM +0200, Ondrej Mosnáček wrote: > From: Ondrej Mosnacek > > This patchset adds the AEGIS AEAD algorithm implementation to the Linux > Crypto API. > > AEGIS [1] is a dedicated AEAD algorithm based on the AES round function and > designed

Re: [PATCH] crypto: reorder paes test lexicographically

On Fri, May 11, 2018 at 09:04:06AM +0100, Gilad Ben-Yossef wrote: > Due to a snafu "paes" testmgr tests were not ordered > lexicographically, which led to boot time warnings. > Reorder the tests as needed. > > Fixes: a794d8d ("crypto: ccree - enable support for hardware keys") > Reported-by:

Re: [PATCH] crypto: nx: fix spelling mistake: "seqeunce" -> "sequence"

On Wed, May 09, 2018 at 10:16:36AM +0100, Colin King wrote: > From: Colin Ian King > > Trivial fix to spelling mistake in CSB_ERR error message text > > Signed-off-by: Colin Ian King Patch applied. Thanks. -- Email: Herbert Xu

Re: [PATCH] crypto: chelsio: request to HW should wrap

On Thu, May 10, 2018 at 10:14:42AM +0530, Atul Gupta wrote: > -Tx request and data is copied to HW Q in 64B desc, check for > end of queue and adjust the current position to start from > beginning before passing the additional request info. > -key context copy should check key length only > -Few

Re: [PATCH] hwrng: n2: fix spelling mistake: "restesting" -> "retesting"

Colin King wrote: > From: Colin Ian King > > Trivial fix to spelling mistake in dev_err error message > > Signed-off-by: Colin Ian King Patch applied. Thanks. -- Email: Herbert Xu

[PATCH v2] fscrypt: log the crypto algorithm implementations

Log the crypto algorithm driver name for each fscrypt encryption mode on its first use, also showing a friendly name for the mode. This will help people determine whether the expected implementations are being used. In some cases we've seen people do benchmarks and reject using encryption for

Re: [RFC PATCH 5/5] KEYS: add KPP ecdh parser

Hi, Denis, On 05/14/2018 10:54 PM, Denis Kenzior wrote: Hi Tudor, On 02/28/2018 10:52 AM, Tudor Ambarus wrote: The ECDH private keys are expected to be encoded with the ecdh helpers from kernel. Use the ecdh helpers to check if the key is valid. If valid, allocate a tfm and set the private

Re: [RFC PATCH 1/5] KEYS: Provide key type operations for kpp ops

Hi, Denis, Thanks for the review! Please see inline. On 05/14/2018 09:48 PM, Denis Kenzior wrote: Hi Tudor, On 02/28/2018 10:52 AM, Tudor Ambarus wrote: Provide three new operations in the key_type struct that can be used to provide access to kpp operations. These will be implemented for the

Re: [PATCH 3/3] arm64: dts: renesas: r8a7795: add ccree binding

On Thu, May 17, 2018 at 04:12:23PM +0300, Gilad Ben-Yossef wrote: > On Thu, May 17, 2018 at 12:04 PM, Simon Horman wrote: > > On Thu, May 17, 2018 at 11:01:57AM +0300, Gilad Ben-Yossef wrote: > >> On Wed, May 16, 2018 at 10:43 AM, Simon Horman wrote: > >>

[PATCH v6 07/28] x86/asm/crypto: annotate local functions

Use the newly added SYM_FUNC_START_LOCAL to annotate starts of all functions which do not have ".globl" annotation, but their ends are annotated by ENDPROC. This is needed to balance ENDPROC for tools that generate debuginfo. To be symmetric, we also convert their ENDPROCs to the new

[PATCH v6 09/28] x86/asm: annotate aliases

_key_expansion_128 is an alias to _key_expansion_256a, __memcpy to memcpy, xen_syscall32_target to xen_sysenter_target, and so on. Annotate them all using the new SYM_FUNC_START_ALIAS, SYM_FUNC_START_LOCAL_ALIAS, and SYM_FUNC_END_ALIAS. This will make the tools generating the debuginfo happy.

[PATCH v6 24/28] x86_64/asm: change all ENTRY+ENDPROC to SYM_FUNC_*

These are all functions which are invoked from elsewhere, so we annotate them as global using the new SYM_FUNC_START. And their ENDPROC's by SYM_FUNC_END. And make sure ENTRY/ENDPROC is not defined on X86_64, given these were the last users. Signed-off-by: Jiri Slaby

[PATCH v6 27/28] x86_32/asm: change all ENTRY+ENDPROC to SYM_FUNC_*

These are all functions which are invoked from elsewhere, so we annotate them as global using the new SYM_FUNC_START. And their ENDPROC's by SYM_FUNC_END. Now, we can finally force ENTRY/ENDPROC to be undefined on X86. Signed-off-by: Jiri Slaby Cc: "H. Peter Anvin"

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

Hi, After enabling CONFIG_CRYPTO_DRBG_CTR, I start seeing during kernel boot: BUG: sleeping function called from invalid context at include/crypto/algapi.h:416 in_atomic(): 1, irqs_disabled(): 0, pid: 203, name: cryptomgr_test 1 lock held by cryptomgr_test/203: #0: (ptrval)

[PATCH] fscrypt: log the crypto algorithm implementations

Log the crypto algorithm driver name for each fscrypt encryption mode on its first use, also showing a friendly name for the mode. This will help people determine whether the expected implementations are being used. In some cases we've seen people do benchmarks and reject using encryption for

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

On Thu, May 17, 2018 at 08:01:04AM +0200, Christophe LEROY wrote: > > On a powerpc embedded board which has an mpc8xx processor running at 133Mhz, > I now get the startup done in more than 7 minutes instead of 30 seconds. > This is due to the webserver blocking on read on /dev/random until we get

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

On Wed, May 16, 2018 at 05:07:08PM -0700, Srivatsa S. Bhat wrote: > > On a Photon OS VM running on VMware ESXi, this patch causes a boot speed > regression of 5 minutes :-( [ The VM doesn't have haveged or rng-tools > (rngd) installed. ] > > [1.420246] EXT4-fs (sda2): re-mounted. Opts:

Re: [PATCH 3/3] arm64: dts: renesas: r8a7795: add ccree binding

Hi Gilad, On Thu, May 17, 2018 at 3:41 PM, Gilad Ben-Yossef wrote: > On Thu, May 17, 2018 at 4:35 PM, Geert Uytterhoeven > wrote: >> On Thu, May 17, 2018 at 3:09 PM, Gilad Ben-Yossef >> wrote: >>> On Thu, May 17, 2018 at 1:16 PM,

Re: [PATCH 3/3] arm64: dts: renesas: r8a7795: add ccree binding

On Thu, May 17, 2018 at 4:35 PM, Geert Uytterhoeven wrote: > Hi Gilad, > > On Thu, May 17, 2018 at 3:09 PM, Gilad Ben-Yossef wrote: >> On Thu, May 17, 2018 at 1:16 PM, Geert Uytterhoeven >> wrote: >>> However, even with your clock

Re: [PATCH 3/3] arm64: dts: renesas: r8a7795: add ccree binding

Hi Gilad, On Thu, May 17, 2018 at 3:09 PM, Gilad Ben-Yossef wrote: > On Thu, May 17, 2018 at 1:16 PM, Geert Uytterhoeven > wrote: >> However, even with your clock patch, the signature checking fails for me, >> on both R-Car H3 ES1.0 and ES2.0. >> Does

[PATCH] crypto: inside-secure - do not use memset on MMIO

This patch fixes the Inside Secure driver which uses a memtset() call to set an MMIO area from the cryptographic engine to 0. This is wrong as memset() isn't guaranteed to work on MMIO for many reasons. This led to kernel paging request panics in certain cases. Use memset_io() instead. Fixes:

Re: [PATCH 3/3] arm64: dts: renesas: r8a7795: add ccree binding

On Thu, May 17, 2018 at 12:16 PM, Geert Uytterhoeven wrote: > On Thu, May 17, 2018 at 10:01 AM, Gilad Ben-Yossef > wrote: >> On Wed, May 16, 2018 at 10:43 AM, Simon Horman wrote: >>> On Tue, May 15, 2018 at 04:50:44PM +0200, Geert

Re: [PATCH 3/3] arm64: dts: renesas: r8a7795: add ccree binding

On Thu, May 17, 2018 at 12:04 PM, Simon Horman wrote: > On Thu, May 17, 2018 at 11:01:57AM +0300, Gilad Ben-Yossef wrote: >> On Wed, May 16, 2018 at 10:43 AM, Simon Horman wrote: >> > On Tue, May 15, 2018 at 04:50:44PM +0200, Geert Uytterhoeven wrote: >>

Re: [PATCH 3/3] arm64: dts: renesas: r8a7795: add ccree binding

On Thu, May 17, 2018 at 1:16 PM, Geert Uytterhoeven wrote: > Hi Gilad, > > On Thu, May 17, 2018 at 10:01 AM, Gilad Ben-Yossef > wrote: >> On Wed, May 16, 2018 at 10:43 AM, Simon Horman wrote: >>> On Tue, May 15, 2018 at 04:50:44PM

Re: [PATCH 1/3] crypto: ccree: drop signature register check

Herbert, On Tue, May 15, 2018 at 3:29 PM, Gilad Ben-Yossef wrote: > We were using the content of the signature register as a sanity > check for the hardware functioning but it turns out not all > implementers use the same values so the check is giving false > negative on

Re: [PATCH 3/3] arm64: dts: renesas: r8a7795: add ccree binding

Hi Gilad, On Thu, May 17, 2018 at 10:01 AM, Gilad Ben-Yossef wrote: > On Wed, May 16, 2018 at 10:43 AM, Simon Horman wrote: >> On Tue, May 15, 2018 at 04:50:44PM +0200, Geert Uytterhoeven wrote: >>> On Tue, May 15, 2018 at 2:29 PM, Gilad Ben-Yossef

Re: [PATCH 3/3] arm64: dts: renesas: r8a7795: add ccree binding

On Thu, May 17, 2018 at 11:01:57AM +0300, Gilad Ben-Yossef wrote: > On Wed, May 16, 2018 at 10:43 AM, Simon Horman wrote: > > On Tue, May 15, 2018 at 04:50:44PM +0200, Geert Uytterhoeven wrote: > >> Hi Gilad, > >> > >> On Tue, May 15, 2018 at 2:29 PM, Gilad Ben-Yossef

Re: [PATCH 2/3] clk: renesas: r8a7795: Add ccree clock

Hi Gilad, On Thu, May 17, 2018 at 10:00 AM, Gilad Ben-Yossef wrote: > On Tue, May 15, 2018 at 5:47 PM, Geert Uytterhoeven > wrote: >> On Tue, May 15, 2018 at 2:29 PM, Gilad Ben-Yossef >> wrote: >>> This patch adds the clock used

Re: [PATCH] crypto: reorder paes test lexicographically

On Fri, May 11, 2018 at 09:04:06AM +0100, Gilad Ben-Yossef wrote: > Due to a snafu "paes" testmgr tests were not ordered > lexicographically, which led to boot time warnings. > Reorder the tests as needed. > > Fixes: a794d8d ("crypto: ccree - enable support for hardware keys") > Reported-by:

Re: [PATCH 3/3] arm64: dts: renesas: r8a7795: add ccree binding

On Wed, May 16, 2018 at 10:43 AM, Simon Horman wrote: > On Tue, May 15, 2018 at 04:50:44PM +0200, Geert Uytterhoeven wrote: >> Hi Gilad, >> >> On Tue, May 15, 2018 at 2:29 PM, Gilad Ben-Yossef >> wrote: >> > Add bindings for CryptoCell instance in the

Re: [PATCH 2/3] clk: renesas: r8a7795: Add ccree clock

On Tue, May 15, 2018 at 5:47 PM, Geert Uytterhoeven wrote: > Hi Gilad, > > On Tue, May 15, 2018 at 2:29 PM, Gilad Ben-Yossef wrote: >> This patch adds the clock used by the CryptoCell 630p instance in the SoC. >> >> Signed-off-by: Gilad Ben-Yossef

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

Le 13/04/2018 à 19:00, Theodore Y. Ts'o a écrit : On Fri, Apr 13, 2018 at 03:05:01PM +0200, Stephan Mueller wrote: What I would like to point out that more and more folks change to getrandom(2). As this call will now unblock much later in the boot cycle, these systems see a significant

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

On 4/13/18 10:00 AM, Theodore Y. Ts'o wrote: > On Fri, Apr 13, 2018 at 03:05:01PM +0200, Stephan Mueller wrote: >> >> What I would like to point out that more and more folks change to >> getrandom(2). As this call will now unblock much later in the boot cycle, >> these systems see a significant

Re: [PATCH 3/3] arm64: dts: renesas: r8a7795: add ccree binding

On Tue, May 15, 2018 at 04:50:44PM +0200, Geert Uytterhoeven wrote: > Hi Gilad, > > On Tue, May 15, 2018 at 2:29 PM, Gilad Ben-Yossef wrote: > > Add bindings for CryptoCell instance in the SoC. > > > > Signed-off-by: Gilad Ben-Yossef > > Thanks for

linux-next: WARNING: CPU: 0 PID: 41 at crypto/testmgr.c:3720 alg_test+0x117/0x520

Hello, I see the next warning in a kernel log. [ 15.775150] WARNING: CPU: 0 PID: 41 at crypto/testmgr.c:3720 alg_test+0x117/0x520 [ 15.776068] Modules linked in: [ 15.776068] CPU: 0 PID: 41 Comm: cryptomgr_test Not tainted 4.17.0-rc5-next-20180515-1-g7efa9d087be2 #20 [ 15.776068]

Re: [PATCH 3/3] arm64: dts: renesas: r8a7795: add ccree binding

Hi Gilad, On Tue, May 15, 2018 at 2:29 PM, Gilad Ben-Yossef wrote: > Add bindings for CryptoCell instance in the SoC. > > Signed-off-by: Gilad Ben-Yossef Thanks for your patch! > --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi > +++

Re: [PATCH 2/3] clk: renesas: r8a7795: Add ccree clock

Hi Gilad, On Tue, May 15, 2018 at 2:29 PM, Gilad Ben-Yossef wrote: > This patch adds the clock used by the CryptoCell 630p instance in the SoC. > > Signed-off-by: Gilad Ben-Yossef Thanks for your patch! > --- a/drivers/clk/renesas/r8a7795-cpg-mssr.c >

Re: [PATCH] crypto: reorder paes test lexicographically

On Fri, 2018-05-11 at 09:04 +0100, Gilad Ben-Yossef wrote: > Due to a snafu "paes" testmgr tests were not ordered > lexicographically, which led to boot time warnings. > Reorder the tests as needed. > > Fixes: a794d8d ("crypto: ccree - enable support for hardware keys") > Reported-by: Abdul

[PATCH 1/3] crypto: ccree: drop signature register check

We were using the content of the signature register as a sanity check for the hardware functioning but it turns out not all implementers use the same values so the check is giving false negative on certain SoCs and so we drop it. Signed-off-by: Gilad Ben-Yossef ---

[PATCH 2/3] clk: renesas: r8a7795: Add ccree clock

This patch adds the clock used by the CryptoCell 630p instance in the SoC. Signed-off-by: Gilad Ben-Yossef --- drivers/clk/renesas/r8a7795-cpg-mssr.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/clk/renesas/r8a7795-cpg-mssr.c

[PATCH 3/3] arm64: dts: renesas: r8a7795: add ccree binding

Add bindings for CryptoCell instance in the SoC. Signed-off-by: Gilad Ben-Yossef --- arch/arm64/boot/dts/renesas/r8a7795.dtsi | 8 1 file changed, 8 insertions(+) diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi

[PATCH 0/3] enable ccree on Renesas R-Car platform

The following patch set enables CryptoCell present in the Renesas R-Car SoC. Gilad Ben-Yossef (3): crypto: ccree: drop signature register check clk: renesas: r8a7795: Add ccree clock arm64: dts: renesas: r8a7795: add ccree binding arch/arm64/boot/dts/renesas/r8a7795.dtsi | 8

[ANNOUNCE] Linux Security Summit Europe 2018 - CFP

== ANNOUNCEMENT AND CALL FOR PARTICIPATION LINUX SECURITY SUMMIT EUROPE 2018 25-26 October

Re: [RFC PATCH 5/5] KEYS: add KPP ecdh parser

Hi Tudor, On 02/28/2018 10:52 AM, Tudor Ambarus wrote: The ECDH private keys are expected to be encoded with the ecdh helpers from kernel. Use the ecdh helpers to check if the key is valid. If valid, allocate a tfm and set the private key. There is a one-to-one binding between the private key

Re: [RFC PATCH 1/5] KEYS: Provide key type operations for kpp ops

Hi Tudor, On 02/28/2018 10:52 AM, Tudor Ambarus wrote: Provide three new operations in the key_type struct that can be used to provide access to kpp operations. These will be implemented for the asymmetric key type in a later patch and may refer to a key retained in RAM by the kernel or a key

Re: [PATCH 2/5] crypto: chtls: wait for memory sendmsg, sendpage

Hi Atul, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on cryptodev/master] [also build test WARNING on v4.17-rc5 next-20180514] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: WARNING: kernel stack regs has bad 'bp' value (3)

On Sat, May 12, 2018 at 12:11:17PM +0200, Ard Biesheuvel wrote: > On 12 May 2018 at 11:50, Dmitry Vyukov wrote: > > On Sat, May 12, 2018 at 11:09 AM, Ard Biesheuvel > > wrote: > >> (+ Arnd) > >> > >> On 12 May 2018 at 10:43, Dmitry Vyukov

[PATCH v2 06/10] crypto: inside-secure - fix the hash then encrypt/decrypt types

This commit fixes the CONTEXT_CONTROL_TYPE_HASH_ENCRYPT_OUT and CONTEXT_CONTROL_TYPE_HASH_DECRYPT_OUT types by assigning the right value, and by renaming CONTEXT_CONTROL_TYPE_HASH_DECRYPT_OUT to CONTEXT_CONTROL_TYPE_HASH_DECRYPT_IN. This is not submitted as a fix for older kernel versions as

[PATCH v2 02/10] crypto: inside-secure - rework cipher functions for future AEAD support

This patch reworks the Inside Secure cipher functions, to remove all skcipher specific information and structure from all functions generic enough to be shared between skcipher and aead algorithms. This is a cosmetic only patch. Signed-off-by: Antoine Tenart ---

[PATCH v2 05/10] crypto: inside-secure - make the key and context size computation dynamic

This patches makes the key and context size computation dynamic when using memzero_explicit() on these two arrays. This is safer, cleaner and will help future modifications of the driver when these two parameters sizes will changes (the context size will be bigger when using AEAD algorithms).

[PATCH v2 08/10] crypto: inside-secure - authenc(hmac(sha256),cbc(aes)) support

This patch adds support for the first AEAD algorithm in the Inside Secure SafeXcel driver, authenc(hmac(sha256),cbc(aes)). As this is the first AEAD algorithm added to this driver, common AEAD functions are added as well. Signed-off-by: Antoine Tenart ---

[PATCH v2 09/10] crypto: inside-secure - authenc(hmac(sha224),cbc(aes)) support

This patch adds the authenc(hmac(sha224),cbc(aes)) AEAD algorithm support to the Inside Secure SafeXcel driver. Signed-off-by: Antoine Tenart --- drivers/crypto/inside-secure/safexcel.c | 1 + drivers/crypto/inside-secure/safexcel.h | 1 +

[PATCH v2 04/10] crypto: inside-secure - make the context control size dynamic

This patch makes the context control size computation dynamic, not to rely on hardcoded values. This is better for the future, and will help adding the AEAD support. Signed-off-by: Antoine Tenart --- drivers/crypto/inside-secure/safexcel_cipher.c | 5 ++--- 1 file

[PATCH v2 10/10] crypto: inside-secure - authenc(hmac(sha1),cbc(aes)) support

This patch adds the authenc(hmac(sha1),cbc(aes)) AEAD algorithm support to the Inside Secure SafeXcel driver. Signed-off-by: Antoine Tenart --- drivers/crypto/inside-secure/safexcel.c | 1 + drivers/crypto/inside-secure/safexcel.h | 1 +

[PATCH v2 00/10] crypto: inside-secure - AEAD support

This series brings AEAD algorithms to the Inside Secure SafeXcel driver. The first 7 commits rework the driver to allow the future AEAD addition, and then 3 commits add AEAD functions and 3 algorithms. This is based on top of v4.17-rc5. Thanks! Antoine Since v1: - Reworked the driver to

[PATCH v2 07/10] crypto: inside-secure - improve error reporting

This patch improves the error reporting from the Inside Secure driver to the upper layers and crypto consumers. All errors reported by the engine aren't fatal, and some may be genuine. Signed-off-by: Antoine Tenart --- drivers/crypto/inside-secure/safexcel.c |

[PATCH v2 01/10] crypto: inside-secure - remove VLAs

This patch removes the use of VLAs to allocate requests on the stack, by removing both SKCIPHER_REQUEST_ON_STACK and AHASH_REQUEST_ON_STACK. As we still need to allocate requests on the stack to ease the creation of invalidation requests a new, non-VLA, definition is used: EIP197_REQUEST_ON_STACK.

[PATCH v2 03/10] crypto: inside-secure - rework the alg type settings in the context

This patches reworks the way the algorithm type is set in the context, by using the fact that the decryption algorithms are just a combination of the algorithm encryption type and CONTEXT_CONTROL_TYPE_NULL_IN. This will help having simpler code when adding the AEAD support, to avoid ending up

Re: [PATCH 2/5] crypto: chtls: wait for memory sendmsg, sendpage

On Mon, May 14, 2018 at 04:30:56PM +0530, Atul Gupta wrote: > Reported-by: Gustavo A. R. Silva > Signed-off-by: Atul Gupta There isn't a commit message for this. It should say what the user visible effects of this bug are. I haven't seen

Re: [PATCH 1/2] crypto: vmx - Remove overly verbose printk from AES init routines

Herbert Xu writes: > On Thu, May 03, 2018 at 10:29:29PM +1000, Michael Ellerman wrote: >> In the vmx AES init routines we do a printk(KERN_INFO ...) to report >> the fallback implementation we're using. >> >> However with a slow console this can significantly affect

[PATCH] crypto: chtls: generic handling of data and hdr

removed redundant check and made TLS PDU and header recv handling common as received from HW. Ensure that only tls header is read in cpl_rx_tls_cmp read-ahead and skb is freed when entire data is processed. Signed-off-by: Atul Gupta Signed-off-by: Harsh Jain

[PATCH 0/5] build warnings cleanup

Build warnings cleanup reported for - using only 128b key - wait for buffer in sendmsg/sendpage - check for null before using skb - free rspq_skb_cache in error path - indentation Atul Gupta (5): crypto:chtls: key len correction crypto: chtls: wait for memory sendmsg, sendpage crypto:

[PATCH 5/5] crypto: chtls: free beyond end rspq_skb_cache

Reported-by: Dan Carpenter Signed-off-by: Atul Gupta --- drivers/crypto/chelsio/chtls/chtls_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/crypto/chelsio/chtls/chtls_main.c

[PATCH 4/5] crypto: chtls: kbuild warnings

- unindented continue - check for null page - signed return Reported-by: Dan Carpenter Signed-off-by: Atul Gupta --- drivers/crypto/chelsio/chtls/chtls_io.c | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git

[PATCH 1/5] crypto:chtls: key len correction

corrected the key length to copy 128b key. Removed 192b and 256b key as user input supports key of size 128b in gcm_ctx Reported-by: Dan Carpenter Signed-off-by: Atul Gupta --- drivers/crypto/chelsio/chtls/chtls_hw.c | 6 +- 1 file changed,

[PATCH 2/5] crypto: chtls: wait for memory sendmsg, sendpage

Reported-by: Gustavo A. R. Silva Signed-off-by: Atul Gupta --- drivers/crypto/chelsio/chtls/chtls.h | 1 + drivers/crypto/chelsio/chtls/chtls_io.c | 90 +-- drivers/crypto/chelsio/chtls/chtls_main.c | 1 + 3

[PATCH 3/5] crypto: chtls: dereference null variable

skb dereferenced before check in sendpage Reported-by: Dan Carpenter Signed-off-by: Atul Gupta --- drivers/crypto/chelsio/chtls/chtls_io.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git

Re: [RFC PATCH 0/5] KEYS: add kpp keyctl operations

ping again. On 04/11/2018 02:08 PM, Tudor Ambarus wrote: 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 before diving into tpm. Best,

[no subject]

пользователь веб-почты Обратите внимание, что 95% ваших писем, полученных после обновления сервера веб-почты в последнее время в нашей базе данных, были отложены. Регулярно получать и отправлять свои сообщения. Техническая команда нашей веб-почты обновит вашу учетную запись в течение 3

Re: WARNING: kernel stack regs has bad 'bp' value (3)

On 12 May 2018 at 11:50, Dmitry Vyukov wrote: > On Sat, May 12, 2018 at 11:09 AM, Ard Biesheuvel > wrote: >> (+ Arnd) >> >> On 12 May 2018 at 10:43, Dmitry Vyukov wrote: >>> On Fri, Feb 2, 2018 at 11:18 PM, Eric Biggers

Re: WARNING: kernel stack regs has bad 'bp' value (3)

On Sat, May 12, 2018 at 11:09 AM, Ard Biesheuvel wrote: > (+ Arnd) > > On 12 May 2018 at 10:43, Dmitry Vyukov wrote: >> On Fri, Feb 2, 2018 at 11:18 PM, Eric Biggers wrote: >>> On Fri, Feb 02, 2018 at 02:57:32PM +0100, Dmitry

Re: WARNING: kernel stack regs has bad 'bp' value (3)

(+ Arnd) On 12 May 2018 at 10:43, Dmitry Vyukov wrote: > On Fri, Feb 2, 2018 at 11:18 PM, Eric Biggers wrote: >> On Fri, Feb 02, 2018 at 02:57:32PM +0100, Dmitry Vyukov wrote: >>> On Fri, Feb 2, 2018 at 2:48 PM, syzbot >>>

Re: WARNING: kernel stack regs has bad 'bp' value (3)

On Fri, Feb 2, 2018 at 11:18 PM, Eric Biggers wrote: > On Fri, Feb 02, 2018 at 02:57:32PM +0100, Dmitry Vyukov wrote: >> On Fri, Feb 2, 2018 at 2:48 PM, syzbot >> wrote: >> > Hello, >> > >> > syzbot hit the following

[RFC] crypto: Remove mcryptd

This patch attempts to remove the mcryptd interface and expose the sha1 multibuffer algorithm as a proper ahash to the inner algorithm. 1. Host the flusher helper in sha1_mb.c instead of mcryptd.c (need to change the names of these functions) 2. Remove unnecessary mcryptd structure

RE: [PATCH V8 1/5] crypto: Multi-buffer encryption infrastructure support

>-Original Message- >From: Herbert Xu [mailto:herb...@gondor.apana.org.au] >Sent: Thursday, May 10, 2018 9:46 PM >To: Dey, Megha >Cc: linux-ker...@vger.kernel.org; linux-crypto@vger.kernel.org; >da...@davemloft.net >Subject: Re: [PATCH V8 1/5] crypto: Multi-buffer

RE: [PATCH v2 1/7] crypto: chtls: wait for memory sendmsg, sendpage

Will do, for further clarity will divide patches into build error fix, bug fix and change made for comment received. Regards -Original Message- From: linux-crypto-ow...@vger.kernel.org [mailto:linux-crypto-ow...@vger.kernel.org] On Behalf Of Herbert Xu Sent: Friday, May 11, 2018 9:26 PM

Re: [PATCH 1/2] crypto: vmx - Remove overly verbose printk from AES init routines

On Thu, May 03, 2018 at 10:29:29PM +1000, Michael Ellerman wrote: > In the vmx AES init routines we do a printk(KERN_INFO ...) to report > the fallback implementation we're using. > > However with a slow console this can significantly affect the speed of > crypto operations. Using 'cryptsetup

Re: [PATCH resend 00/10] crypto: arm64 - play nice with CONFIG_PREEMPT

On Mon, Apr 30, 2018 at 06:18:20PM +0200, Ard Biesheuvel wrote: > Hello Herbert, > > These are the patches that depend on the arm64/assembler.h patches that > inadvertently got pulled into the cryptodev tree and reverted shortly > after. Those have now been merged into Linus's tree, and so the >

Re: [PATCH v2 1/7] crypto: chtls: wait for memory sendmsg, sendpage

On Wed, May 02, 2018 at 12:25:33AM +0530, Atul Gupta wrote: > Reported-by: Gustavo A. R. Silva > Signed-off-by: Atul Gupta These patches really should be sent to netdev as well and I'd like to see some acks from there. Also please add a cover

[PATCH 2/4] crypto: testmgr - Add test vectors for MORUS

From: Ondrej Mosnacek This patch adds test vectors for MORUS-640 and MORUS-1280. The test vectors were generated using the reference implementation from SUPERCOP (see code comments for more details). Signed-off-by: Ondrej Mosnacek --- crypto/testmgr.c

<    4   5   6   7   8   9   10   11   12   13   >