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

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

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

Hi, I modified my code as suggested by Stephan and Eric. Moving the code from the header files into *.c source files slowed down the compression and decompression speed by a factor of up to 20. I made no changes to the code itself, that would explain, why it is so much slower. Signed-off-by:

Re: [PATCH] tls: Add support for encryption using async offload accelerator

On Wed, Jan 31, 2018 at 8:10 AM, Gilad Ben-Yossef wrote: > Hi Vakul, > > On Wed, Jan 31, 2018 at 12:36 PM, Vakul Garg wrote: >> Async crypto accelerators (e.g. drivers/crypto/caam) support offloading >> GCM operation. If they are enabled,

Re: [PATCH] tls: Add support for encryption using async offload accelerator

Hi Vakul, On Wed, Jan 31, 2018 at 12:36 PM, Vakul Garg wrote: > Async crypto accelerators (e.g. drivers/crypto/caam) support offloading > GCM operation. If they are enabled, crypto_aead_encrypt() return error > code -EINPROGRESS. In this case tls_do_encryption() needs to wait

Re: Odroid HC1 cryptsetup:encrypt sata driver

Hi Kamil, On 30 January 2018 at 21:02, Kamil Konieczny wrote: > Hi Anand, > > On 24.01.2018 14:04, Anand Moon wrote: >> Hi Kamil Konieczny, >> >> I am looking in setup of encrypted sata hard-disk on Odroid XU4/HC1 device. >> using following encryption method. >>

[PATCH] tls: Add support for encryption using async offload accelerator

Async crypto accelerators (e.g. drivers/crypto/caam) support offloading GCM operation. If they are enabled, crypto_aead_encrypt() return error code -EINPROGRESS. In this case tls_do_encryption() needs to wait on a completion till the time the response for crypto offload request is received.

[PATCH v3 1/5] crypto: caam: Fix null dereference at error path

From: Rui Miguel Silva caam_remove already removes the debugfs entry, so we need to remove the one immediately before calling caam_remove. This fix a NULL dereference at error paths is caam_probe fail. [bod: changed name prefix to "crypto: caam: Fix .."] [bod: added Fixes

[PATCH v3 0/5] Enable CAAM on i.MX7s fix TrustZone issues

V3: - Added Cc: clk driver maintainers - Fabio Estevam - Added Cc: i.MX arch maintainers - Fabio Estevam - Removed bouncing email address for Herbert Xu V2-resend: - Patch 0005 lost in the ether - resending V2: - Endian detection is ok with TrustZone enabled Horia. Endian detection logic

[PATCH v3 2/5] crypto: caam: Fix endless loop when RNG is already initialized

commit 1005bccd7a4a ("crypto: caam - enable instantiation of all RNG4 state handles") introduces a control when incrementing ent_delay which contains the following comment above it: /* * If either SH were instantiated by somebody else * (e.g. u-boot) then it is assumed that the entropy *

[PATCH v3 3/5] crypto: caam: do not use mem and emi_slow clock for imx7x

From: Rui Miguel Silva I.MX7x only use two clocks for the CAAM module, so make sure we do not try to use the mem and the emi_slow clock when running in that imx7d and imx7s machine type. [bod: fixed minor trailing whitespace issue] Signed-off-by: Rui Miguel Silva

[PATCH v3 4/5] clk: imx7d: add CAAM clock

From: Rui Miguel Silva Add CAAM clock so that we could use the Cryptographic Acceleration and Assurance Module (CAAM) hardware block. Signed-off-by: Rui Miguel Silva Cc: Michael Turquette Cc: Stephen Boyd

[PATCH v3 5/5] ARM: dts: imx7s: add CAAM device node

From: Rui Miguel Silva Add CAAM device node to the i.MX7s device tree. Signed-off-by: Rui Miguel Silva Cc: Shawn Guo Cc: Sascha Hauer Cc: linux-arm-ker...@lists.infradead.org Cc: "Horia Geantă"

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

On Sat, Dec 23, 2017 at 01:58:01AM -0800, syzbot wrote: > Hello, > > syzkaller hit the following crash on > 6084b576dca2e898f5c101baef151f7bfdbb606d > 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 console

Re: BUG: unable to handle kernel paging request in aead_accept_parent_nokey

On Sun, Dec 17, 2017 at 09:51:01PM -0800, syzbot wrote: > Hello, > > syzkaller hit the following crash on > 41d8c16909ebda40f7b4982a7f5e2ad102705ade > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master > compiler: gcc (GCC) 7.1.1 20170620 > .config is attached > Raw console

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

On Tue, Dec 19, 2017 at 01:03:00PM -0800, syzbot wrote: > Hello, > > syzkaller hit the following crash on > 6084b576dca2e898f5c101baef151f7bfdbb606d > 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 console

Re: BUG: unable to handle kernel paging request in hmac_init_tfm

On Mon, Dec 18, 2017 at 11:36:01AM -0800, syzbot wrote: > Hello, > > syzkaller hit the following crash on > 6084b576dca2e898f5c101baef151f7bfdbb606d > 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 console

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

Hi Stephan, >>> 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 source file. >> This way there is no function defined in a header

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

Hi Eric, >> Currently ZRAM uses the compression-algorithms from the crypto-api. >> None of the current compression-algorithms in the crypto-api is designed >> to compress 4KiB chunks of data efficiently. >> This patch adds a new compression-algorithm especially designed for ZRAM, >> to compress

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

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

Hi Benjamin, On Tue, Jan 30, 2018 at 04:08:57PM +0100, Benjamin Warnke wrote: > Currently ZRAM uses the compression-algorithms from the crypto-api. > None of the current compression-algorithms in the crypto-api is designed > to compress 4KiB chunks of data efficiently. > This patch adds a new

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

Hi Stephan, thanks for your fast response. > Please run checkpatch.pl on the patch and fix the formatting issues. I've run checkpatch.pl again and fixed all errors and warnings except the warnings about printk. Compression does not have it's own subsystem, that is why I used printk(KERN_INFO

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

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

Re: [RFC crypto v3 8/9] chtls: Register the ULP

On 01/30/18 06:51 AM, Atul Gupta wrote: > What I was referring is that passing "tls" ulp type in setsockopt > may be insufficient to make the decision when multi HW assist Inline > TLS solution exists. Setting the ULP doesn't choose HW or SW implementation, I think that should be done later when

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

On Tue, 30 Jan 2018 09:27:04 +0100 Stephan Müller wrote: > 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 >

Re: Odroid HC1 cryptsetup:encrypt sata driver

Hi Anand, On 24.01.2018 14:04, Anand Moon wrote: > Hi Kamil Konieczny, > > I am looking in setup of encrypted sata hard-disk on Odroid XU4/HC1 device. > using following encryption method. > > aes-cbc-essiv:sha256 128 > aes-cbc-essiv:sha256 256 > > Here is my defconfig I am using.

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

From: Jonathan Cameron This accelerator is found inside hisilicon hip06 and hip07 SoCs. Each instance provides a number of queues which feed a different number of backend accleration units. The queues are operating in an out of order mode in the interests of

[RFC PATCH 3/3] arm64: dts: hisi: add SEC crypto accelerator nodes for hip07 SoC

From: Jonathan Cameron Enable all 4 SEC units available on d05 boards. Signed-off-by: Jonathan Cameron --- arch/arm64/boot/dts/hisilicon/hip07.dtsi | 293 +++ 1 file changed, 293 insertions(+) diff --git

[RFC PATCH 0/3] Hisilicon SEC accelerator driver

From: Jonathan Cameron This an RFC for a couple of reasons: 1) There is some ongoing discussion on how to handle IVs in the AF_ALG interface when doing async IO. There are a few corners of handling in here that are performance enhancements based on Stephan's

[RFC PATCH 1/3] dt-bindings: Add bindings for Hisilicon SEC crypto accelerators.

From: Jonathan Cameron The hip06 and hip07 SoCs contain a number of these crypto units which accelerate AES and DES operations. Signed-off-by: Jonathan Cameron --- .../bindings/crypto/hisilicon,hip07-sec.txt| 71

Re: [PATCH v2] tpm: Move Linux RNG connection to hwrng

On Tue, Jan 30, 2018 at 10:52:13PM +1100, James Morris wrote: > On Tue, 30 Jan 2018, Jarkko Sakkinen wrote: > > > On Sat, Jan 27, 2018 at 12:20:18PM +0530, PrasannaKumar Muralidharan wrote: > > > Hi Jarkko, > > > > > > On 17 November 2017 at 19:27, Jarkko Sakkinen > > >

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

Currently ZRAM uses the compression-algorithms from the crypto-api. None of the current compression-algorithms in the crypto-api is designed to compress 4KiB chunks of data efficiently. This patch adds a new compression-algorithm especially designed for ZRAM, to compress small pieces of data more

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

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

Re: [PATCH v2] tpm: Move Linux RNG connection to hwrng

On Tue, 30 Jan 2018, Jarkko Sakkinen wrote: > On Sat, Jan 27, 2018 at 12:20:18PM +0530, PrasannaKumar Muralidharan wrote: > > Hi Jarkko, > > > > On 17 November 2017 at 19:27, Jarkko Sakkinen > > wrote: > > > On Fri, Nov 17, 2017 at 03:28:53PM +0200, Jarkko

[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