Re: memory leak in crypto_create_tfm

Probably a bug in crypto/drbg.c. Stephan, can you take a look? On Tue, Jun 02, 2020 at 08:41:21PM -0700, syzbot wrote: > Hello, > > syzbot found the following crash on: > > HEAD commit:19409891 Merge tag 'pnp-5.8-rc1' of git://git.kernel.org/p.. > git tree: upstream > console output:

memory leak in crypto_create_tfm

Hello, syzbot found the following crash on: HEAD commit:19409891 Merge tag 'pnp-5.8-rc1' of git://git.kernel.org/p.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=13165aa610 kernel config: https://syzkaller.appspot.com/x/.config?x=6d41e63a2c7e0715 das

Re: [PATCH 1/4] qat: fix misunderstood -EBUSY return code

Hi Mikulas, thanks for your patch. See below. On Mon, Jun 01, 2020 at 06:03:33PM +0200, Mikulas Patocka wrote: > Using dm-crypt with QAT result in deadlocks. > > If a crypto routine returns -EBUSY, it is expected that the crypto driver > have already queued the request and the crypto API user sh

Re: [RFC PATCH net 1/1] net/tls(TLS_SW): Add selftest for 'chunked' sendfile test

On Tue, 2 Jun 2020 14:56:25 + Pooja Trivedi wrote: > This selftest tests for cases where sendfile's 'count' > parameter is provided with a size greater than the intended > file size. > > Motivation: When sendfile is provided with 'count' parameter > value that is greater than the size of the

Re: [PATCH] crypto: add adler32 to CryptoAPI

On Tue, Jun 02, 2020 at 03:59:40PM +, Sebastien Buisson wrote: > > > Le 1 juin 2020 à 09:13, Eric Biggers a écrit : > > > > On Thu, May 28, 2020 at 07:00:51PM +0200, sbuisson@gmail.com wrote: > >> From: Sebastien Buisson > >> > >> Add adler32 to CryptoAPI so that it can be used with th

Re: [PATCH] crypto: add adler32 to CryptoAPI

> Le 1 juin 2020 à 09:13, Eric Biggers a écrit : > > On Thu, May 28, 2020 at 07:00:51PM +0200, sbuisson@gmail.com wrote: >> From: Sebastien Buisson >> >> Add adler32 to CryptoAPI so that it can be used with the normal kernel >> API, and potentially accelerated if architecture-specific >> o

Announce loop-AES-v3.7q file/swap crypto package

loop-AES changes since previous release: - Worked around kernel interface changes on 5.7 kernels bzip2 compressed tarball is here: http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.7q.tar.bz2 md5sum b9628468b35e92feee63eccfee8e4863 http://loop-aes.sourceforge.net/loop-AES/loop-AES

[RFC PATCH net 1/1] net/tls(TLS_SW): Add selftest for 'chunked' sendfile test

This selftest tests for cases where sendfile's 'count' parameter is provided with a size greater than the intended file size. Motivation: When sendfile is provided with 'count' parameter value that is greater than the size of the file, kTLS example fails to send the file correctly. Last chunk of t

[RFC 0/1] net/tls(TLS_SW): Data integrity issue with sw kTLS using sendfile

When sendfile is used for kTLS file delivery and the size provided to sendfile via its 'count' parameter is greater than the file size, kTLS fails to send the file correctly. The last chunk of the file is not sent, and the data integrity of the file is compromised on the receiver side. Based on

[PATCH v2] crypto: hisilicon - allow smaller reads in debugfs

Originally this code rejected any read less than 256 bytes. There is no need for this artificial limit. We should just use the normal helper functions to read a string from the kernel. Signed-off-by: Dan Carpenter --- v2: Use simple_read_from_buffer(). The v1 was slightly half arsed because I

Re: Security Random Number Generator support

On 2020-06-02 13:14, Ard Biesheuvel wrote: On Tue, 2 Jun 2020 at 10:15, Neal Liu wrote: These patch series introduce a security random number generator which provides a generic interface to get hardware rnd from Secure state. The Secure state can be Arm Trusted Firmware(ATF), Trusted Execution

Re: Security Random Number Generator support

On Tue, 2 Jun 2020 at 10:15, Neal Liu wrote: > > These patch series introduce a security random number generator > which provides a generic interface to get hardware rnd from Secure > state. The Secure state can be Arm Trusted Firmware(ATF), Trusted > Execution Environment(TEE), or even EL2 hyperv

Re: [PATCH 05/15] crypto: inside-secure - use PCI_IRQ_MSI_TYPES where appropriate

On Tue, Jun 02, 2020 at 01:32:49PM +0200, Antoine Tenart wrote: > > Quoting Piotr Stankiewicz (2020-06-02 11:20:19) > > Seeing as there is shorthand available to use when asking for any type > > of interrupt, or any type of message signalled interrupt, leverage it. > > > > Signed-off-by: Piotr St

[PATCH 5/4] dm-integrity: sleep and retry on allocation errors

dm-integrity: sleep and retry on allocation errors Some hardware crypto drivers use GFP_ATOMIC allocations in the request routine. These allocations can randomly fail - for example, they fail if too many network packets are received. If we propagated the failure up to the I/O stack, it would caus

Re: [PATCH 05/15] crypto: inside-secure - use PCI_IRQ_MSI_TYPES where appropriate

Hello Piotr, Quoting Piotr Stankiewicz (2020-06-02 11:20:19) > Seeing as there is shorthand available to use when asking for any type > of interrupt, or any type of message signalled interrupt, leverage it. > > Signed-off-by: Piotr Stankiewicz > Reviewed-by: Andy Shevchenko Reviewed-by: Antoin

Re: [PATCH] crypto: caam - add clock info for VFxxx SoCs

On 6/2/2020 2:07 AM, Andrey Smirnov wrote: > Add a small bit of plumbing necessary to use CAAM on VFxxx SoCs. > > Signed-off-by: Andrey Smirnov > Cc: Chris Healy > Cc: Horia Geantă > Cc: Herbert Xu > Cc: Fabio Estevam > Cc: linux-...@nxp.com > Cc: linux-crypto@vger.kernel.org > Cc: linux-ker.

Re: [PATCH v6 2/2] hwrng: add sec-rng driver

On Tue, Jun 02, 2020 at 04:14:38PM +0800, Neal Liu wrote: > For security awareness SoCs on ARMv8 with TrustZone enabled, > peripherals like entropy sources is not accessible from normal world > (linux) and rather accessible from secure world (HYP/ATF/TEE) only. > This driver aims to provide a gener

[PATCH 05/15] crypto: inside-secure - use PCI_IRQ_MSI_TYPES where appropriate

Seeing as there is shorthand available to use when asking for any type of interrupt, or any type of message signalled interrupt, leverage it. Signed-off-by: Piotr Stankiewicz Reviewed-by: Andy Shevchenko --- drivers/crypto/inside-secure/safexcel.c | 2 +- 1 file changed, 1 insertion(+), 1 delet

[PATCH 00/15] forward MSIx vector enable error code in pci_alloc_irq_vectors_affinity

The primary objective of this patch series is to change the behaviour of pci_alloc_irq_vectors_affinity such that it forwards the MSI-X enable error code when appropriate. In the process, though, it was pointed out that there are multiple places in the kernel which check/ask for message signalled i

[PATCH v6 2/2] hwrng: add sec-rng driver

For security awareness SoCs on ARMv8 with TrustZone enabled, peripherals like entropy sources is not accessible from normal world (linux) and rather accessible from secure world (HYP/ATF/TEE) only. This driver aims to provide a generic interface to Arm Trusted Firmware or Hypervisor rng service. S

Security Random Number Generator support

These patch series introduce a security random number generator which provides a generic interface to get hardware rnd from Secure state. The Secure state can be Arm Trusted Firmware(ATF), Trusted Execution Environment(TEE), or even EL2 hypervisor. Patch #1..2 adds sec-rng kernel driver for Trustz

[PATCH v6 1/2] dt-bindings: rng: add bindings for sec-rng

Add bindings for ARM TrustZone based Security Random Number Generator. Signed-off-by: Neal Liu --- Documentation/devicetree/bindings/rng/sec-rng.yaml | 53 1 file changed, 53 insertions(+) create mode 100644 Documentation/devicetree/bindings/rng/sec-rng.yaml diff --git a

[PATCH v3 0/3] crypto: virtio: Fix three issues

Patch 1 & 2: fix two crash issues, Link: https://lkml.org/lkml/2020/1/23/205 Patch 3: fix another functional issue Changes since v2: - put another bugfix together Changes since v1: - remove some redundant checks [Jason] - normalize the commit message [Markus] Cc: Gonglei Cc: Herbert Xu Cc:

[PATCH v3 3/3] crypto: virtio: Fix dest length calculation in __virtio_crypto_skcipher_do_req()

The src/dst length is not aligned with AES_BLOCK_SIZE(which is 16) in some testcases in tcrypto.ko. For example, the src/dst length of one of cts(cbc(aes))'s testcase is 17, the crypto_virtio driver will set @src_data_len=16 but @dst_data_len=17 in this case and get a wrong at then end. SRC: pp

[PATCH v3 1/3] crypto: virtio: Fix src/dst scatterlist calculation in __virtio_crypto_skcipher_do_req()

The system will crash when the users insmod crypto/tcrypt.ko with mode=38 ( testing "cts(cbc(aes))" ). Usually the next entry of one sg will be @sg@ + 1, but if this sg element is part of a chained scatterlist, it could jump to the start of a new scatterlist array. Fix it by sg_next() on calculati

[PATCH v3 2/3] crypto: virtio: Fix use-after-free in virtio_crypto_skcipher_finalize_req()

The system'll crash when the users insmod crypto/tcrypto.ko with mode=155 ( testing "authenc(hmac(sha1),cbc(aes))" ). It's caused by reuse the memory of request structure. In crypto_authenc_init_tfm(), the reqsize is set to: [PART 1] sizeof(authenc_request_ctx) + [PART 2] ictx->reqoff + [PAR