Re: [RFC PATCH v2] crypto: Add IV generation algorithms

On Thu, Dec 22, 2016 at 04:25:12PM +0530, Binoy Jayan wrote: > > > It doesn't have to live outside of dm-crypt. You can register > > these IV generators from there if you really want. > > Sorry, but I didn't understand this part. What I mean is that moving the IV generators into the crypto API

Re: Test AEAD/authenc algorithms from userspace

On 21-12-2016 14:24, Herbert Xu wrote: > On Mon, Dec 19, 2016 at 04:08:11PM +0530, Harsh Jain wrote: >> Hi Herbert, >> >> TLS default mode of operation is MAC-then-Encrypt for Authenc algos. >> Currently framework only supports EtM used in IPSec. User space >> programs like openssl cannot use

Re: George's crazy full state idea (Re: HalfSipHash Acceptable Usage)

Hannes Frederic Sowa wrote: > A lockdep test should still be done. ;) Adding might_lock() annotations will improve coverage a lot. > Yes, that does look nice indeed. Accounting for bits instead of bytes > shouldn't be a huge problem either. Maybe it gets a bit more verbose in > case you can't

Re: George's crazy full state idea (Re: HalfSipHash Acceptable Usage)

On 22.12.2016 22:11, George Spelvin wrote: >> I do tend to like Ted's version in which we use batched >> get_random_bytes() output. If it's fast enough, it's simpler and lets >> us get the full strength of a CSPRNG. > > With the ChaCha20 generator, that's fine, although note that this abandons >

Re: [PATCH v2 11/12] crypto: atmel-authenc: add support to authenc(hmac(shaX),Y(aes)) modes

Hi Cyrille, [auto build test WARNING on cryptodev/master] [also build test WARNING on next-20161222] [cannot apply to v4.9] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Cyrille-Pitchen/crypto

Re: George's crazy full state idea (Re: HalfSipHash Acceptable Usage)

> I do tend to like Ted's version in which we use batched > get_random_bytes() output. If it's fast enough, it's simpler and lets > us get the full strength of a CSPRNG. With the ChaCha20 generator, that's fine, although note that this abandons anti-backtracking entirely. It also takes locks,

Re: BPF hash algo (Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5)

On 22.12.2016 20:56, Andy Lutomirski wrote: > It's also not quite clear to me why userspace needs to be able to > calculate the digest on its own. A bpf(BPF_CALC_PROGRAM_DIGEST) > command that takes a BPF program as input and hashes it would seem to > serve the same purpose, and that would allow

Re: BPF hash algo (Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5)

On Thu, Dec 22, 2016 at 11:34 AM, Alexei Starovoitov wrote: > On Thu, Dec 22, 2016 at 9:25 AM, Andy Lutomirski wrote: >> On Thu, Dec 22, 2016 at 8:59 AM, Hannes Frederic Sowa >> wrote: >>> On Thu, 2016-12-22 at 08:07

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

On Thu, Dec 22, 2016 at 07:08:37PM +0100, Hannes Frederic Sowa wrote: > I wasn't concerned about performance but more about DoS resilience. I > wonder how safe half md4 actually is in terms of allowing users to > generate long hash chains in the filesystem (in terms of length > extension attacks

Re: BPF hash algo (Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5)

On Thu, Dec 22, 2016 at 9:25 AM, Andy Lutomirski wrote: > On Thu, Dec 22, 2016 at 8:59 AM, Hannes Frederic Sowa > wrote: >> On Thu, 2016-12-22 at 08:07 -0800, Andy Lutomirski wrote: >> >> We don't prevent ebpf programs being loaded based on the

Re: George's crazy full state idea (Re: HalfSipHash Acceptable Usage)

On Thu, Dec 22, 2016 at 11:24 AM, George Spelvin wrote: >> Having slept on this, I like it less. The problem is that a >> backtracking attacker doesn't just learn H(random seed || entropy_0 || >> secret || ...) -- they learn the internal state of the hash function >>

Re: George's crazy full state idea (Re: HalfSipHash Acceptable Usage)

> Having slept on this, I like it less. The problem is that a > backtracking attacker doesn't just learn H(random seed || entropy_0 || > secret || ...) -- they learn the internal state of the hash function > that generates that value. This probably breaks any attempt to apply > security

Re: [PATCH 11/12] crypto: atmel-authenc: add support to authenc(hmac(shaX),Y(aes)) modes

Hi Cyrille, [auto build test ERROR on cryptodev/master] [also build test ERROR on next-20161222] [cannot apply to v4.9] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Cyrille-Pitchen/crypto

Re: [PATCH v3 2/2] crypto: mediatek - add DT bindings documentation

On Mon, Dec 19, 2016 at 10:20:45AM +0800, Ryder Lee wrote: > Add DT bindings documentation for the crypto driver > > Signed-off-by: Ryder Lee > --- > .../devicetree/bindings/crypto/mediatek-crypto.txt | 27 > ++ > 1 file changed, 27 insertions(+) >

Re: BPF hash algo (Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5)

On Thu, Dec 22, 2016 at 5:59 PM, Hannes Frederic Sowa wrote: > We don't prevent ebpf programs being loaded based on the digest but > just to uniquely identify loaded programs from user space and match up > with their source. Okay, so in that case, a weak hashing

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

On Thu, Dec 22, 2016 at 7:08 PM, Hannes Frederic Sowa wrote: > I wasn't concerned about performance but more about DoS resilience. I > wonder how safe half md4 actually is in terms of allowing users to > generate long hash chains in the filesystem (in terms of length >

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

On 22.12.2016 16:54, Theodore Ts'o wrote: > On Thu, Dec 22, 2016 at 02:10:33PM +0100, Jason A. Donenfeld wrote: >> On Thu, Dec 22, 2016 at 1:47 PM, Hannes Frederic Sowa >> wrote: >>> following up on what appears to be a random subject: ;) >>> >>> IIRC, ext4 code by

Re: BPF hash algo (Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5)

On Thu, 2016-12-22 at 09:25 -0800, Andy Lutomirski wrote: > On Thu, Dec 22, 2016 at 8:59 AM, Hannes Frederic Sowa > wrote: > > On Thu, 2016-12-22 at 08:07 -0800, Andy Lutomirski wrote: > > > > > > You mean: > > > > > > commit 7bd509e311f408f7a5132fcdde2069af65fa05ae

Re: BPF hash algo (Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5)

On Thu, Dec 22, 2016 at 8:59 AM, Hannes Frederic Sowa wrote: > On Thu, 2016-12-22 at 08:07 -0800, Andy Lutomirski wrote: >> On Thu, Dec 22, 2016 at 7:51 AM, Hannes Frederic Sowa >> wrote: >> > On Thu, 2016-12-22 at 16:41 +0100, Jason A.

Re: BPF hash algo (Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5)

On Thu, 2016-12-22 at 08:07 -0800, Andy Lutomirski wrote: > On Thu, Dec 22, 2016 at 7:51 AM, Hannes Frederic Sowa > wrote: > > On Thu, 2016-12-22 at 16:41 +0100, Jason A. Donenfeld wrote: > > > Hi Hannes, > > > > > > On Thu, Dec 22, 2016 at 4:33 PM, Hannes Frederic

Re: BPF hash algo (Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5)

On Thu, Dec 22, 2016 at 8:28 AM, Jason A. Donenfeld wrote: > Hi all, > > I don't know what your design requirements are for this. It looks like > you're generating some kind of crypto digest of a program, and you > need to avoid collisions. If you'd like to go with a PRF (keyed

[PATCH v2 00/12] crypto: atmel-authenc: add support to authenc(hmac(shaX),Y(aes)) modes

Hi all, this series of patches has been based and tested on next-20161222 with CRYPTO_MANAGER_DISABLED_TESTS not set. The series adds support to the hmac(shaX) algorithms first, then combines both the Atmel SHA and AES hardware accelerators to implement authenc(hmac(shaX),Y(aes)) algorithms

[PATCH v2 01/12] crypto: atmel-sha: create function to get an Atmel SHA device

This is a transitional patch: it creates the atmel_sha_find_dev() function, which will be used in further patches to share the source code responsible for finding a Atmel SHA device. Signed-off-by: Cyrille Pitchen --- drivers/crypto/atmel-sha.c | 15 +++ 1

[PATCH v2 03/12] crypto: atmel-sha: make atmel_sha_done_task more generic

This patch is a transitional patch. It updates atmel_sha_done_task() to make it more generic. Indeed, it adds a new .resume() member in the atmel_sha_dev structure. This hook is called from atmel_sha_done_task() to resume processing an asynchronous request. Signed-off-by: Cyrille Pitchen

[PATCH v2 02/12] crypto: atmel-sha: update request queue management to make it more generic

This patch is a transitional patch. It splits the atmel_sha_handle_queue() function. Now atmel_sha_handle_queue() only manages the request queue and calls a new .start() hook from the atmel_sha_ctx structure. This hook allows to implement different kind of requests still handled by a single queue.

[PATCH v2 05/12] crypto: atmel-sha: add atmel_sha_wait_for_data_ready()

This patch simply defines a helper function to test the 'Data Ready' flag of the Status Register. It also gives a chance for the crypto request to be processed synchronously if this 'Data Ready' flag is already set when polling the Status Register. Indeed, running synchronously avoid the latency

[PATCH v2 08/12] crypto: atmel-sha: add simple DMA transfers

This patch adds a simple function to perform data transfer with the DMA controller. Signed-off-by: Cyrille Pitchen --- drivers/crypto/atmel-sha.c | 116 + 1 file changed, 116 insertions(+) diff --git

[PATCH v2 10/12] crypto: atmel-aes: fix atmel_aes_handle_queue()

This patch fixes the value returned by atmel_aes_handle_queue(), which could have been wrong previously when the crypto request was started synchronously but became asynchronous during the ctx->start() call. Signed-off-by: Cyrille Pitchen ---

[PATCH v2 06/12] crypto: atmel-sha: add SHA_MR_MODE_IDATAR0

This patch defines an alias macro to SHA_MR_MODE_PDC, which is not suited for DMA usage. Signed-off-by: Cyrille Pitchen --- drivers/crypto/atmel-sha-regs.h | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/crypto/atmel-sha-regs.h

[PATCH v2 12/12] crypto: atmel-sha: add verbose debug facilities to print hw register names

When VERBOSE_DEBUG is defined and SHA_FLAGS_DUMP_REG flag is set in dd->flags, this patch prints the register names and values when performing IO accesses. Signed-off-by: Cyrille Pitchen --- drivers/crypto/atmel-sha.c | 110

[PATCH v2 04/12] crypto: atmel-sha: redefine SHA_FLAGS_SHA* flags to match SHA_MR_ALGO_SHA*

This patch modifies the SHA_FLAGS_SHA* flags: those algo flags are now organized as values of a single bitfield instead of individual bits. This allows to reduce the number of bits needed to encode all possible values. Also the new values match the SHA_MR_ALGO_SHA* values hence the algorithm

[PATCH v2 11/12] crypto: atmel-authenc: add support to authenc(hmac(shaX),Y(aes)) modes

This patchs allows to combine the AES and SHA hardware accelerators on some Atmel SoCs. Doing so, AES blocks are only written to/read from the AES hardware. Those blocks are also transferred from the AES to the SHA accelerator internally, without additionnal accesses to the system busses. Hence,

[PATCH v2 07/12] crypto: atmel-sha: add atmel_sha_cpu_start()

This patch adds a simple function to perform data transfer with PIO, hence handled by the CPU. Signed-off-by: Cyrille Pitchen --- drivers/crypto/atmel-sha.c | 90 ++ 1 file changed, 90 insertions(+) diff --git

[PATCH v2 09/12] crypto: atmel-sha: add support to hmac(shaX)

This patch adds support to the hmac(shaX) algorithms. Signed-off-by: Cyrille Pitchen --- drivers/crypto/atmel-sha-regs.h | 4 + drivers/crypto/atmel-sha.c | 598 +++- 2 files changed, 601 insertions(+), 1 deletion(-) diff

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

On Thu, Dec 22, 2016 at 5:30 PM, Theodore Ts'o wrote: > I'd do this first, as one set. Adding a new file to crypto is > unlikely to cause merge conflicts. Ack. > >> 2. convert char/random to use siphash. to: ted ts'o's random-next > > I'm confused, I thought you had agreed to

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

On Thu, Dec 22, 2016 at 05:16:47PM +0100, Jason A. Donenfeld wrote: > Could you offer a bit of advice on how to manage dependencies between > patchsets during merge windows? I'm a bit new to the process. > > Specifically, we how have 4 parts: > 1. add siphash, and use it for some networking code.

Re: BPF hash algo (Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5)

Hi all, I don't know what your design requirements are for this. It looks like you're generating some kind of crypto digest of a program, and you need to avoid collisions. If you'd like to go with a PRF (keyed hash function) that uses some kernel secret key, then I'd strongly suggest using

[PATCH 05/12] crypto: atmel-sha: add atmel_sha_wait_for_data_ready()

This patch simply defines a helper function to test the 'Data Ready' flag of the Status Register. It also gives a chance for the crypto request to be processed synchronously if this 'Data Ready' flag is already set when polling the Status Register. Indeed, running synchronously avoid the latency

[PATCH 01/12] crypto: atmel-sha: create function to get an Atmel SHA device

This is a transitional patch: it creates the atmel_sha_find_dev() function, which will be used in further patches to share the source code responsible for finding a Atmel SHA device. Signed-off-by: Cyrille Pitchen --- drivers/crypto/atmel-sha.c | 15 +++ 1

[PATCH 11/12] crypto: atmel-authenc: add support to authenc(hmac(shaX),Y(aes)) modes

This patchs allows to combine the AES and SHA hardware accelerators on some Atmel SoCs. Doing so, AES blocks are only written to/read from the AES hardware. Those blocks are also transferred from the AES to the SHA accelerator internally, without additionnal accesses to the system busses. Hence,

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

Hi Ted, On Thu, Dec 22, 2016 at 4:58 PM, Theodore Ts'o wrote: > Can we do this as a separate series, please? At this point, it's a > completely separate change from a logical perspective, and we can take > in the change through the random.git tree. > > Changes that touch files

[PATCH 03/12] crypto: atmel-sha: make atmel_sha_done_task more generic

This patch is a transitional patch. It updates atmel_sha_done_task() to make it more generic. Indeed, it adds a new .resume() member in the atmel_sha_dev structure. This hook is called from atmel_sha_done_task() to resume processing an asynchronous request. Signed-off-by: Cyrille Pitchen

[PATCH 10/12] crypto: atmel-aes: fix atmel_aes_handle_queue()

This patch fixes the value returned by atmel_aes_handle_queue(), which could have been wrong previously when the crypto request was started synchronously but became asynchronous during the ctx->start() call. Signed-off-by: Cyrille Pitchen ---

[PATCH 12/12] crypto: atmel-sha: add verbose debug facilities to print hw register names

When VERBOSE_DEBUG is defined and SHA_FLAGS_DUMP_REG flag is set in dd->flags, this patch prints the register names and values when performing IO accesses. Signed-off-by: Cyrille Pitchen --- drivers/crypto/atmel-sha.c | 110

[PATCH 07/12] crypto: atmel-sha: add atmel_sha_cpu_start()

This patch adds a simple function to perform data transfer with PIO, hence handled by the CPU. Signed-off-by: Cyrille Pitchen --- drivers/crypto/atmel-sha.c | 90 ++ 1 file changed, 90 insertions(+) diff --git

[PATCH 04/12] crypto: atmel-sha: redefine SHA_FLAGS_SHA* flags to match SHA_MR_ALGO_SHA*

This patch modifies the SHA_FLAGS_SHA* flags: those algo flags are now organized as values of a single bitfield instead of individual bits. This allows to reduce the number of bits needed to encode all possible values. Also the new values match the SHA_MR_ALGO_SHA* values hence the algorithm

[PATCH 06/12] crypto: atmel-sha: add SHA_MR_MODE_IDATAR0

This patch defines an alias macro to SHA_MR_MODE_PDC, which is not suited for DMA usage. Signed-off-by: Cyrille Pitchen --- drivers/crypto/atmel-sha-regs.h | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/crypto/atmel-sha-regs.h

[PATCH 09/12] crypto: atmel-sha: add support to hmac(shaX)

This patch adds support to the hmac(shaX) algorithms. Signed-off-by: Cyrille Pitchen --- drivers/crypto/atmel-sha-regs.h | 4 + drivers/crypto/atmel-sha.c | 598 +++- 2 files changed, 601 insertions(+), 1 deletion(-) diff

[PATCH 08/12] crypto: atmel-sha: add simple DMA transfers

This patch adds a simple function to perform data transfer with the DMA controller. Signed-off-by: Cyrille Pitchen --- drivers/crypto/atmel-sha.c | 116 + 1 file changed, 116 insertions(+) diff --git

[PATCH 02/12] crypto: atmel-sha: update request queue management to make it more generic

This patch is a transitional patch. It splits the atmel_sha_handle_queue() function. Now atmel_sha_handle_queue() only manages the request queue and calls a new .start() hook from the atmel_sha_ctx structure. This hook allows to implement different kind of requests still handled by a single queue.

[PATCH 00/12] crypto: atmel-authenc: add support to authenc(hmac(shaX),Y(aes)) modes

Hi all, this series of patches has been based and tested on next-20161222 with CRYPTO_MANAGER_DISABLED_TESTS not set. The series adds support to the hmac(shaX) algorithms first, then combines both the Atmel SHA and AES hardware accelerators to implement authenc(hmac(shaX),Y(aes)) algorithms

Re: George's crazy full state idea (Re: HalfSipHash Acceptable Usage)

On Wed, Dec 21, 2016 at 6:07 PM, Andy Lutomirski wrote: > On Wed, Dec 21, 2016 at 5:13 PM, George Spelvin > wrote: >> As a separate message, to disentangle the threads, I'd like to >> talk about get_random_long(). >> >> After some thinking, I still

BPF hash algo (Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5)

On Thu, Dec 22, 2016 at 7:51 AM, Hannes Frederic Sowa wrote: > On Thu, 2016-12-22 at 16:41 +0100, Jason A. Donenfeld wrote: >> Hi Hannes, >> >> On Thu, Dec 22, 2016 at 4:33 PM, Hannes Frederic Sowa >> wrote: >> > IPv6 you cannot touch

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

On Thu, Dec 22, 2016 at 07:03:29AM +0100, Jason A. Donenfeld wrote: > I find this compelling. We'll have one csprng for both > get_random_int/long and for /dev/urandom, and we'll be able to update > that silly warning on the comment of get_random_int/long to read > "gives output of either rdrand

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

On Thu, Dec 22, 2016 at 02:10:33PM +0100, Jason A. Donenfeld wrote: > On Thu, Dec 22, 2016 at 1:47 PM, Hannes Frederic Sowa > wrote: > > following up on what appears to be a random subject: ;) > > > > IIRC, ext4 code by default still uses half_md4 for hashing of

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

On Thu, Dec 22, 2016 at 4:51 PM, Hannes Frederic Sowa wrote: > This algorithm should be a non-seeded algorithm, because the hashes > should be stable and verifiable by user space tooling. Thus this would > need a hashing algorithm that is hardened against pre-image >

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

On Thu, 2016-12-22 at 16:41 +0100, Jason A. Donenfeld wrote: > Hi Hannes, > > On Thu, Dec 22, 2016 at 4:33 PM, Hannes Frederic Sowa > wrote: > > IPv6 you cannot touch anymore. The hashing algorithm is part of uAPI. > > You don't want to give people new IPv6 addresses

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

Hi Hannes, On Thu, Dec 22, 2016 at 4:33 PM, Hannes Frederic Sowa wrote: > IPv6 you cannot touch anymore. The hashing algorithm is part of uAPI. > You don't want to give people new IPv6 addresses with the same stable > secret (across reboots) after a kernel upgrade.

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

On Thu, 2016-12-22 at 16:29 +0100, Jason A. Donenfeld wrote: > On Thu, Dec 22, 2016 at 4:12 PM, Jason A. Donenfeld wrote: > > As a first step, I'm considering adding a patch to move halfmd4.c > > inside the ext4 domain, or at the very least, simply remove it from > >

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

On Thu, Dec 22, 2016 at 4:12 PM, Jason A. Donenfeld wrote: > As a first step, I'm considering adding a patch to move halfmd4.c > inside the ext4 domain, or at the very least, simply remove it from > linux/cryptohash.h. That'll then leave the handful of bizarre sha1 > usages to

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

On Thu, Dec 22, 2016 at 4:05 PM, Hannes Frederic Sowa wrote: > This change would need a new version of the ext4 super block, because > you should not change existing file systems. Right. As a first step, I'm considering adding a patch to move halfmd4.c inside the

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

On 22.12.2016 14:10, Jason A. Donenfeld wrote: > On Thu, Dec 22, 2016 at 1:47 PM, Hannes Frederic Sowa > wrote: >> following up on what appears to be a random subject: ;) >> >> IIRC, ext4 code by default still uses half_md4 for hashing of filenames >> in the htree.

[PATCH] crypto: qat - increase number of supported devices

From: Xin Zeng The unsigned long type for init_status and start_status in service_hndl are not long enough to represent more than 64 acceleration devices. Use an array instead. Signed-off-by: Xin Zeng Signed-off-by: Giovanni Cabiddu

[PATCH] crypto: qat - initialize cra_flags before register into kpp

Initialize dh.base.cra_flags before registering the dh algorithm. Without this fix, the registration of the dh algorithm might fail if the qat driver is restarted. Signed-off-by: Sushil Kumar Signed-off-by: Giovanni Cabiddu ---

[PATCH] crypto: qat - modify format of dev top level debugfs entries

From: Pablo Marcos Oltra Remove leading zeros in pci function number to be consistent with output from lspci. Signed-off-by: Pablo Marcos Oltra Signed-off-by: Giovanni Cabiddu ---

[PATCH] crypto: qat - fix bar discovery for c62x

Some accelerators of the c62x series have only two bars. This patch skips BAR0 if the accelerator does not have it. Signed-off-by: Giovanni Cabiddu --- drivers/crypto/qat/qat_c62x/adf_drv.c | 2 +- drivers/crypto/qat/qat_common/adf_accel_devices.h | 1 +

[PATCH] crypto: qat - zero esram only for DH85x devices

Zero embedded ram in DH85x devices. This is not needed for newer generations as it is done by HW. Signed-off-by: Giovanni Cabiddu --- drivers/crypto/qat/qat_common/qat_hal.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[PATCH] crypto: qat - replace hardcoded BIT(0) in vf_isr

Replace BIT(0) macro with proper definition in pf2vf path Signed-off-by: Giovanni Cabiddu --- drivers/crypto/qat/qat_common/adf_vf_isr.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/crypto/qat/qat_common/adf_vf_isr.c

[PATCH] crypto: qat - fix comments describing adf_disable_sriov()

From: Ahsan Atta Signed-off-by: Ahsan Atta Signed-off-by: Giovanni Cabiddu --- drivers/crypto/qat/qat_common/adf_sriov.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[PATCH] crypto: qat - fix indentation

From: Ahsan Atta Signed-off-by: Ahsan Atta Signed-off-by: Giovanni Cabiddu --- drivers/crypto/qat/qat_common/adf_dev_mgr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: [PATCH v6 1/2] sparc: fix a building error reported by kbuild

Guys, so was it fixed or not? I can not compile current git kernel: linux-2.6$ git desc v4.9-11937-g52bce91165e5 linux-2.6$ git status On branch master Your branch is up-to-date with 'origin/master'. nothing to commit, working tree clean linux-2.6$ git log --oneline

Re: [PATCH 1/3] crypto: Change lz4 modules to work with new lz4 compressor module version

Cc Herbert and linux-crypto on this https://marc.info/?l=linux-kernel=148226084823926 On (12/20/16 19:53), Sven Schmidt wrote: > > This patch updates the crypto modules using LZ4 compression to work with the > new LZ4 kernel module version. > > Signed-off-by: Sven Schmidt

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

On Thu, Dec 22, 2016 at 1:47 PM, Hannes Frederic Sowa wrote: > following up on what appears to be a random subject: ;) > > IIRC, ext4 code by default still uses half_md4 for hashing of filenames > in the htree. siphash seems to fit this use case pretty good. I saw

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

Hi Ted, On Thu, 2016-12-22 at 00:41 -0500, Theodore Ts'o wrote: > On Thu, Dec 22, 2016 at 03:49:39AM +0100, Jason A. Donenfeld wrote: > > > > Funny -- while you guys were sending this back & forth, I was writing > > my reply to Andy which essentially arrives at the same conclusion. > > Given

Re: [RFC PATCH v2] crypto: Add IV generation algorithms

Hi Herbert, On 22 December 2016 at 14:25, Herbert Xu wrote: > On Tue, Dec 13, 2016 at 11:01:08AM +0100, Milan Broz wrote: >> >> By the move everything to cryptoAPI we are basically introducing some >> strange mix >> of IV and modes there, I wonder how this is going

RE: dm-crypt optimization

-Original Message- From: Herbert Xu [mailto:herb...@gondor.apana.org.au] Sent: Thursday, December 22, 2016 10:59 AM To: Binoy Jayan Cc: Milan Broz; Oded Golombek; Ofir Drang; Arnd Bergmann; Mark Brown; Alasdair Kergon; David S. Miller; private-...@linaro.org; dm-de...@redhat.com;

Re: dm-crypt optimization

On Thu, Dec 22, 2016 at 01:55:59PM +0530, Binoy Jayan wrote: > > > Support of bigger block sizes would be unsafe without additional mechanism > > that provides > > atomic writes of multiple sectors. Maybe it applies to 4k as well on some > > devices though...) > > Did you mean write to the

Re: [RFC PATCH v2] crypto: Add IV generation algorithms

On Tue, Dec 13, 2016 at 11:01:08AM +0100, Milan Broz wrote: > > By the move everything to cryptoAPI we are basically introducing some strange > mix > of IV and modes there, I wonder how this is going to be maintained. > Anyway, Herbert should say if it is ok... Well there is precedent in how do

Re: dm-crypt optimization

Hi Milan, On 21 December 2016 at 18:17, Milan Broz wrote: > So the core problem is that your crypto accelerator can operate efficiently > only > with bigger batch sizes. Thank you for the reply. Yes, that would be rather an improvement when having bigger block sizes. >

Re: George's crazy full state idea (Re: HalfSipHash Acceptable Usage)

> True, but it's called get_random_int(), and it seems like making it > stronger, especially if the performance cost is low to zero, is a good > thing. If it's cheap enough, I don't mind. But it's documented as being marginal-quality, used where speed is more important. In particular, it's