Re: [dm-devel] [PATCH] dm: switch dm-verity to async hash crypto API

On Sun, Jan 29, 2017 at 09:39:20AM +0200, Gilad Ben-Yossef wrote: > Hi Odrej, > > On Thu, Jan 26, 2017 at 1:34 PM, Ondrej Mosnáček > wrote: > > Hi Gilad, > > > > 2017-01-24 15:38 GMT+01:00 Gilad Ben-Yossef : > >> - v->tfm =

[dm-devel] [PATCH] dm crypt: fix free of bad values after tfm allocation failure

If crypt_alloc_tfms() had to allocate multiple tfms and it failed before the last allocation, then it would call crypt_free_tfms() and free pointers from uninitialized memory. Fix by allocating zeroed memory. Signed-off-by: Eric Biggers <ebigg...@google.com> --- drivers/md/dm-crypt.c | 2

Re: [dm-devel] [RFC PATCH 5/6] crypto: aesni-intel - Add bulk request support

On Thu, Jan 12, 2017 at 01:59:57PM +0100, Ondrej Mosnacek wrote: > This patch implements bulk request handling in the AES-NI crypto drivers. > The major advantage of this is that with bulk requests, the kernel_fpu_* > functions (which are usually quite slow) are now called only once for the >

[dm-devel] [PATCH] dm crypt: remove obsolete references to per-CPU state

From: Eric Biggers <ebigg...@google.com> dm-crypt used to use separate crypto transforms for each CPU, but this is no longer the case. To avoid confusion, fix up obsolete comments and rename setup_essiv_cpu(). Signed-off-by: Eric Biggers <ebigg...@google.com> --- drivers/md/dm-

Re: [dm-devel] [RFC 07/10] fscrypt: move to generic async completion

Hi Gilad, On Sat, May 06, 2017 at 03:59:56PM +0300, Gilad Ben-Yossef wrote: > int fscrypt_do_page_crypto(const struct inode *inode, fscrypt_direction_t rw, > u64 lblk_num, struct page *src_page, > struct page *dest_page, unsigned int len, > @@

Re: [dm-devel] [RFC 01/10] crypto: factor async completion for general use

Hi Gilad, On Sat, May 06, 2017 at 03:59:50PM +0300, Gilad Ben-Yossef wrote: > Invoking a possibly async. crypto op and waiting for completion > while correctly handling backlog processing is a common task > in the crypto API implementation and outside users of it. > > This patch re-factors one

Re: [dm-devel] [RFC 01/10] crypto: factor async completion for general use

On Thu, May 11, 2017 at 10:29:47AM +0300, Gilad Ben-Yossef wrote: > > With regards to the wait being uninterruptible, I agree that this should be > > the > > default behavior, because I think users waiting for specific crypto > > requests are > > generally not prepared to handle the wait

[dm-devel] [PATCH] dm: constify argument arrays

From: Eric Biggers <ebigg...@google.com> The arrays of 'struct dm_arg' are never modified by the device-mapper core, so constify them so that they are placed in .rodata. (Exception: the args array in dm-raid cannot be constified because it is allocated on the stack and modified.) Sign

[dm-devel] [PATCH] dm ioctl: constify ioctl lookup table

From: Eric Biggers <ebigg...@google.com> Constify the lookup table for device-mapper ioctls so that it is placed in .rodata. Signed-off-by: Eric Biggers <ebigg...@google.com> --- drivers/md/dm-ioctl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/md/

Re: [dm-devel] [PATCH v6 0/2] IV Generation algorithms for dm-crypt

On Fri, Jun 23, 2017 at 04:13:41PM +0800, Herbert Xu wrote: > Binoy Jayan wrote: > > === > > dm-crypt optimization for larger block sizes > >

[dm-devel] [PATCH] dm bufio: fix integer overflow when limiting maximum cache size

/vmalloc.h. Fixes: 95d402f057f2 ("dm: add bufio") Cc: <sta...@vger.kernel.org> # v3.2+ Signed-off-by: Eric Biggers <ebigg...@google.com> --- drivers/md/dm-bufio.c | 15 ++- 1 file changed, 6 insertions(+), 9 deletions(-) diff --git a/drivers/md/dm-bufio.c b/drive

Re: [dm-devel] [PATCH] md: dm-crypt: Add Inline Encryption support for dmcrypt

Hi Ladvine, On Wed, May 30, 2018 at 02:52:07PM +, Ladvine D Almeida wrote: > On Monday 28 May 2018 05:33 PM, Milan Broz wrote: > > On 05/28/2018 03:01 PM, Ladvine D Almeida wrote: > >> This patch adds new option > >> -- perform_inline_encrypt > >> that set the option inside dmcrypt to use

Re: [dm-devel] [PATCH v2 10/11] crypto: ahash: Remove VLA usage for AHASH_REQUEST_ON_STACK

a_req_ctx > 664 artpec6_hash_request_context > > So, this chooses 720 as a larger "round" number for the max. > > [1] > https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com > > Cc: Herbert Xu > Cc: "David S. Miller&

Re: [dm-devel] [PATCH 06/11] crypto: cbc: Remove VLA usage

On Wed, Jun 20, 2018 at 12:04:03PM -0700, Kees Cook wrote: > In the quest to remove all stack VLA usage from the kernel[1], this > uses the upper bounds on blocksize. > > [1] > https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com > > Signed-off-by: Kees

Re: [dm-devel] [PATCH 09/11] crypto: shash: Remove VLA usage in unaligned hashing

On Wed, Jun 20, 2018 at 12:04:06PM -0700, Kees Cook wrote: > In the quest to remove all stack VLA usage from the kernel[1], this uses > the newly defined max alignment to perform unaligned hashing to avoid > VLAs, and drops the helper function while adding sanity checks on the > resulting buffer

Re: [dm-devel] [PATCH 04/11] dm verity fec: Remove VLA usage

On Wed, Jun 20, 2018 at 12:04:01PM -0700, Kees Cook wrote: > In the quest to remove all stack VLA usage from the kernel[1], this > uses the newly defined max digest size macro. Also adds a sanity-check > at use-time. > > [1] >

Re: [dm-devel] [PATCH 05/11] crypto alg: Introduce max blocksize and alignmask

On Wed, Jun 20, 2018 at 12:04:02PM -0700, Kees Cook wrote: > In the quest to remove all stack VLA usage from the kernel[1], this > exposes the existing upper bound on crypto block sizes for VLA removal, > and introduces a new check for alignmask (current maximum in the kernel > is 63 from manual

Re: [dm-devel] [PATCH 07/11] crypto: xcbc: Remove VLA usage

On Wed, Jun 20, 2018 at 12:04:04PM -0700, Kees Cook wrote: > In the quest to remove all stack VLA usage from the kernel[1], this uses > the maximum blocksize and adds a sanity check. > > [1] > https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com > >

Re: [dm-devel] [PATCH 05/11] crypto alg: Introduce max blocksize and alignmask

On Wed, Jun 20, 2018 at 05:04:08PM -0700, Kees Cook wrote: > On Wed, Jun 20, 2018 at 4:40 PM, Eric Biggers wrote: > > On Wed, Jun 20, 2018 at 12:04:02PM -0700, Kees Cook wrote: > >> In the quest to remove all stack VLA usage from the kernel[1], this > >> exposes the exi

Re: [dm-devel] [PATCH v3 9/9] crypto: shash: Remove VLA usage in unaligned hashing

On Thu, Jun 28, 2018 at 05:28:43PM -0700, Kees Cook wrote: > In the quest to remove all stack VLA usage from the kernel[1], this uses > the newly defined max alignment to perform unaligned hashing to avoid > VLAs, and drops the helper function while adding sanity checks on the > resulting buffer

Re: [dm-devel] [PATCH v3 9/9] crypto: shash: Remove VLA usage in unaligned hashing

On Sun, Jul 01, 2018 at 10:04:59AM -0700, Kees Cook wrote: > On Sat, Jun 30, 2018 at 12:03 AM, Eric Biggers wrote: > > On Thu, Jun 28, 2018 at 05:28:43PM -0700, Kees Cook wrote: > >> @@ -88,11 +81,13 @@ static int shash_update_unaligned(struct shash_desc > >

Re: [dm-devel] [PATCH v5 10/11] crypto: ahash: Remove VLA usage for AHASH_REQUEST_ON_STACK

On Mon, Jul 16, 2018 at 09:21:49PM -0700, Kees Cook wrote: > In the quest to remove all stack VLA usage from the kernel[1], this caps > the ahash request size similar to the other limits and adds a sanity > check at initialization. AHASH_REQUEST_ON_STACK is special, though: it > is only ever used

Re: [dm-devel] [PATCH v5 05/11] crypto: ahash: Remove VLA usage

On Mon, Jul 16, 2018 at 09:21:44PM -0700, Kees Cook wrote: > In the quest to remove all stack VLA usage from the kernel[1], this > introduces max size macros for ahash, as already done for shash, and > adjust the crypto user to max state size. > > [1] >

Re: [dm-devel] [PATCH v5 05/11] crypto: ahash: Remove VLA usage

On Tue, Jul 17, 2018 at 01:07:50PM -0700, Kees Cook wrote: > On Tue, Jul 17, 2018 at 9:39 AM, Eric Biggers wrote: > > On Mon, Jul 16, 2018 at 09:21:44PM -0700, Kees Cook wrote: > >> In the quest to remove all stack VLA usage from the kernel[1], this > >> introduce

Re: [dm-devel] [PATCH] dm crypt: Convert essiv from ahash to shash

h. The stack allocation will be made a fixed size in a > later patch to the crypto subsystem. > > [1] > https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com > > Signed-off-by: Kees Cook Reviewed-by: Eric Biggers >

Re: [dm-devel] [PATCH v3] crypto: xts - Drop use of auxiliary buffer

Hi Ondrej, On Wed, Sep 05, 2018 at 01:30:39PM +0200, Ondrej Mosnacek wrote: > Since commit acb9b159c784 ("crypto: gf128mul - define gf128mul_x_* in > gf128mul.h"), the gf128mul_x_*() functions are very fast and therefore > caching the computed XTS tweaks has only negligible advantage over >

Re: [dm-devel] [PATCH v4] crypto: xts - Drop use of auxiliary buffer

Hi Ondrej, On Mon, Sep 10, 2018 at 01:28:41PM +0200, Ondrej Mosnacek wrote: > > -static int init_crypt(struct skcipher_request *req, crypto_completion_t done) > +static int xor_tweak_pre(struct skcipher_request *req) > { > - struct priv *ctx =

Re: [dm-devel] [PATCH] Add an option to dm-verity to validate hashes at most once

Hi Patrik, On Tue, Mar 06, 2018 at 03:14:56PM -0800, Patrik Torstensson wrote: > Add an option to dm-verity to validate hashes at most once > to allow platforms that is CPU/memory contraint to be > protected by dm-verity against offline attacks. > > The option introduces a bitset that is used to

Re: [dm-devel] [PATCH 2/2] md: dm-verity: allow parallel processing of bio blocks

[+Cc linux-crypto] Hi Yael, On Sun, Mar 25, 2018 at 07:41:30PM +0100, Yael Chemla wrote: > Allow parallel processing of bio blocks by moving to async. completion > handling. This allows for better resource utilization of both HW and > software based hash tfm and therefore better performance

[dm-devel] [PATCH] dm verity: log the hash algorithm implementation

From: Eric Biggers Log the hash algorithm's driver name when a dm-verity target is created. This will help people determine whether the expected implementation is being used. It can make an enormous difference; e.g., SHA-256 on ARM can be 8x faster with the crypto extensions than without

[dm-devel] [PATCH] dm crypt: log the encryption algorithm implementation

From: Eric Biggers Log the encryption algorithm's driver name when a dm-crypt target is created. This will help people determine whether the expected implementation is being used. In some cases we've seen people do benchmarks and reject using encryption for performance reasons, when in fact

Re: [dm-devel] [PATCH v3 1/2] crypto: lrw - Optimize tweak computation

Hi Ondrej, On Tue, Sep 11, 2018 at 09:42:38AM +0200, Ondrej Mosnacek wrote: > This patch rewrites the tweak computation to a slightly simpler method > that performs less bswaps. Based on performance measurements the new > code seems to provide slightly better performance than the old one. > >

Re: [dm-devel] [PATCH v3 2/2] crypto: lrw - Do not use auxiliary buffer

On Tue, Sep 11, 2018 at 09:42:39AM +0200, Ondrej Mosnacek wrote: > This patch simplifies the LRW template to recompute the LRW tweaks from > scratch in the second pass and thus also removes the need to allocate a > dynamic buffer using kmalloc(). > > As discussed at [1], the use of kmalloc causes

Re: [dm-devel] [RFC PATCH 0/3] crypto: switch to shash for ESSIV generation

[+Cc linux-fscrypt] On Sun, Jun 16, 2019 at 09:13:01PM +0200, Ard Biesheuvel wrote: > > > > - ESSIV is useful only for CBC mode. I wish we move to some better mode > > in the future instead of cementing CBC use... But if it helps people > > to actually use unpredictable IV for CBC, it is the

Re: [RFC PATCH 0/3] crypto: switch to shash for ESSIV generation

t; - testing - suggestions welcome on existing testing frameworks for dm-crypt > and/or fscrypt > > Cc: Herbert Xu > Cc: Eric Biggers > > Ard Biesheuvel (3): > crypto: essiv - create a new shash template for IV generation > dm crypt: switch to essiv shash > fscr

Re: [PATCH v3 6/6] crypto: arm64/aes - implement accelerated ESSIV/CBC mode

On Wed, Jun 19, 2019 at 06:29:21PM +0200, Ard Biesheuvel wrote: > Add an accelerated version of the 'essiv(cbc(aes),aes,sha256)' > skcipher, which is used by fscrypt, and in some cases, by dm-crypt. > This avoids a separate call into the AES cipher for every invocation. > > Signed-off-by: Ard

Re: [PATCH v3 2/6] fs: crypto: invoke crypto API for ESSIV handling

On Wed, Jun 19, 2019 at 06:29:17PM +0200, Ard Biesheuvel wrote: > Instead of open coding the calculations for ESSIV handling, use a > ESSIV skcipher which does all of this under the hood. > > Signed-off-by: Ard Biesheuvel > --- > fs/crypto/Kconfig | 1 + > fs/crypto/crypto.c

Re: [dm-devel] [PATCH v3 1/6] crypto: essiv - create wrapper template for ESSIV generation

On Wed, Jun 19, 2019 at 06:29:16PM +0200, Ard Biesheuvel wrote: > diff --git a/crypto/essiv.c b/crypto/essiv.c > new file mode 100644 > index ..45e9d10b8614 > --- /dev/null > +++ b/crypto/essiv.c > @@ -0,0 +1,630 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * ESSIV skcipher

Re: [PATCH v3 1/6] crypto: essiv - create wrapper template for ESSIV generation

On Thu, Jun 20, 2019 at 09:30:41AM +0200, Ard Biesheuvel wrote: > On Thu, 20 Jun 2019 at 03:14, Herbert Xu wrote: > > > > On Wed, Jun 19, 2019 at 06:04:17PM -0700, Eric Biggers wrote: > > > > > > > +#define ESSIV_IV_SIZE sizeof(u64) /

Re: [PATCH v5 5/7] crypto: essiv - add test vector for essiv(cbc(aes),aes,sha256)

On Wed, Jun 26, 2019 at 10:40:45PM +0200, Ard Biesheuvel wrote: > Add a test vector for the ESSIV mode that is the most widely used, > i.e., using cbc(aes) and sha256. > > Signed-off-by: Ard Biesheuvel > --- > crypto/tcrypt.c | 9 + > crypto/testmgr.c | 6 + > crypto/testmgr.h | 213

Re: [PATCH v5 7/7] crypto: arm64/aes - implement accelerated ESSIV/CBC mode

On Wed, Jun 26, 2019 at 10:40:47PM +0200, Ard Biesheuvel wrote: > Add an accelerated version of the 'essiv(cbc(aes),aes,sha256' > skcipher, which is used by fscrypt, and in some cases, by dm-crypt. > This avoids a separate call into the AES cipher for every invocation. This technically should say

Re: [PATCH v5 2/7] fs: crypto: invoke crypto API for ESSIV handling

On Wed, Jun 26, 2019 at 10:40:42PM +0200, Ard Biesheuvel wrote: > diff --git a/fs/crypto/keyinfo.c b/fs/crypto/keyinfo.c > index dcd91a3fbe49..82c7eb86ca00 100644 > --- a/fs/crypto/keyinfo.c > +++ b/fs/crypto/keyinfo.c > @@ -19,8 +19,6 @@ > #include > #include "fscrypt_private.h" Can you

Re: [dm-devel] [RFC PATCH v5 1/1] Add dm verity root hash pkcs7 sig validation.

Hi Jaskaran, one comment (I haven't reviewed this in detail): On Wed, Jun 19, 2019 at 12:10:48PM -0700, Jaskaran Khurana wrote: > diff --git a/drivers/md/Kconfig b/drivers/md/Kconfig > index db269a348b20..2d658a3512cb 100644 > --- a/drivers/md/Kconfig > +++ b/drivers/md/Kconfig > @@ -475,6 +475,7

Re: [RFC PATCH v5 0/1] Add dm verity root hash pkcs7 sig validation.

On Wed, Jun 19, 2019 at 12:10:47PM -0700, Jaskaran Khurana wrote: > This patch set adds in-kernel pkcs7 signature checking for the roothash of > the dm-verity hash tree. > The verification is to support cases where the roothash is not secured by > Trusted Boot, UEFI Secureboot or similar

Re: [RFC PATCH v5 1/1] Add dm verity root hash pkcs7 sig validation.

Hi Jaskaran, On Thu, Jun 27, 2019 at 06:49:58PM -0700, Jaskaran Singh Khurana wrote: > > > On Thu, 27 Jun 2019, Eric Biggers wrote: > > > Hi Jaskaran, one comment (I haven't reviewed this in detail): > > > > On Wed, Jun 19, 2019 at 12:10:48PM -0700, Jaskaran K

Re: [dm-devel] [PATCH v7 2/7] fs: crypto: invoke crypto API for ESSIV handling

Hi Ard, On Tue, Jul 02, 2019 at 06:48:10PM +0200, Ard Biesheuvel wrote: > Instead of open coding the calculations for ESSIV handling, use a > ESSIV skcipher which does all of this under the hood. > > Signed-off-by: Ard Biesheuvel > --- > fs/crypto/Kconfig | 1 + > fs/crypto/crypto.c

Re: [RFC PATCH v5 0/1] Add dm verity root hash pkcs7 sig validation.

On Fri, Jun 28, 2019 at 12:45:11PM -0700, Jaskaran Singh Khurana wrote: > > Hello Eric, > On Thu, 27 Jun 2019, Eric Biggers wrote: > > > On Wed, Jun 19, 2019 at 12:10:47PM -0700, Jaskaran Khurana wrote: > > > This patch set adds in-kernel pkcs7 signature checking for t

Re: [PATCH v3 6/6] crypto: arm64/aes - implement accelerated ESSIV/CBC mode

On Wed, Jun 19, 2019 at 06:29:21PM +0200, Ard Biesheuvel wrote: > Add an accelerated version of the 'essiv(cbc(aes),aes,sha256)' > skcipher, which is used by fscrypt, and in some cases, by dm-crypt. > This avoids a separate call into the AES cipher for every invocation. > > Signed-off-by: Ard

Re: [dm-devel] [PATCH v4 0/6] crypto: switch to crypto API for ESSIV generation

On Sun, Jun 23, 2019 at 11:30:41AM +0200, Ard Biesheuvel wrote: > On Fri, 21 Jun 2019 at 10:09, Ard Biesheuvel wrote: > > > > From: Ard Biesheuvel > > > ... > > > > - given that hardware already exists that can perform en/decryption > > including > > ESSIV generation of a range of blocks, it

Re: [PATCH v6 2/7] fs: crypto: invoke crypto API for ESSIV handling

On Fri, Jun 28, 2019 at 05:21:07PM +0200, Ard Biesheuvel wrote: > diff --git a/fs/crypto/keyinfo.c b/fs/crypto/keyinfo.c > index dcd91a3fbe49..f39667d4316a 100644 > --- a/fs/crypto/keyinfo.c > +++ b/fs/crypto/keyinfo.c > @@ -13,14 +13,10 @@ > #include > #include > #include > -#include >

Re: [PATCH v6 1/7] crypto: essiv - create wrapper template for ESSIV generation

On Fri, Jun 28, 2019 at 05:21:06PM +0200, Ard Biesheuvel wrote: > Implement a template that wraps a (skcipher,cipher,shash) or > (aead,cipher,shash) tuple so that we can consolidate the ESSIV handling > in fscrypt and dm-crypt and move it into the crypto API. This will result > in better test

Re: [dm-devel] [PATCH v10 2/7] fs: crypto: invoke crypto API for ESSIV handling

On Tue, Aug 13, 2019 at 08:09:41AM +0300, Ard Biesheuvel wrote: > On Mon, 12 Aug 2019 at 22:47, Eric Biggers wrote: > > > > On Mon, Aug 12, 2019 at 05:53:19PM +0300, Ard Biesheuvel wrote: > > > Instead of open coding the calculations for ESSIV handling, use a > > &

Re: [PATCH v10 2/7] fs: crypto: invoke crypto API for ESSIV handling

On Mon, Aug 12, 2019 at 05:53:19PM +0300, Ard Biesheuvel wrote: > Instead of open coding the calculations for ESSIV handling, use a > ESSIV skcipher which does all of this under the hood. > > Signed-off-by: Ard Biesheuvel This looks fine (except for one comment below), but this heavily

Re: [PATCH v10 1/7] crypto: essiv - create wrapper template for ESSIV generation

On Mon, Aug 12, 2019 at 05:53:18PM +0300, Ard Biesheuvel wrote: > + switch (type) { > + case CRYPTO_ALG_TYPE_BLKCIPHER: > + skcipher_inst = kzalloc(sizeof(*skcipher_inst) + > + sizeof(*ictx), GFP_KERNEL); > + if (!skcipher_inst) >

Re: [dm-devel] xts fuzz testing and lack of ciphertext stealing support

On Sun, Aug 11, 2019 at 01:12:56PM +0200, Milan Broz wrote: > On 10/08/2019 06:39, Ard Biesheuvel wrote: > > Truncated IVs are a huge issue, since we already expose the correct > > API via AF_ALG (without any restrictions on how many of the IV bits > > are populated), and apparently, if your

Re: xts fuzz testing and lack of ciphertext stealing support

On Wed, Jul 17, 2019 at 05:09:31PM +, Horia Geanta wrote: > On 7/17/2019 1:16 AM, Eric Biggers wrote: > > Hi Horia, > > > > On Tue, Jul 16, 2019 at 05:46:29PM +, Horia Geanta wrote: > >> Hi, > >> > >> With fuzz testing enable

Re: [dm-devel] xts fuzz testing and lack of ciphertext stealing support

On Thu, Jul 18, 2019 at 01:19:41PM +0200, Milan Broz wrote: > > > From that perspective - to prevent people from doing cryptographically > > stupid things - > > IMHO it would be better to just pull the CTS into the XTS implementation > > i.e. make > > xts natively support blocks that are not a

Re: [dm-devel] dm-crypt error when CONFIG_CRYPTO_AUTHENC is disabled

On Fri, Sep 20, 2019 at 05:27:46PM -0400, Mike Snitzer wrote: > On Fri, Sep 20 2019 at 3:21pm -0400, > Milan Broz wrote: > > > On 20/09/2019 19:37, Mike Snitzer wrote: > > > On Fri, Sep 20 2019 at 11:44am -0400, > > > Thibaut Sautereau wrote: > > > > > >> Hi, > > >> > > >> I just got a

[dm-devel] [PATCH] docs: dm-integrity: remove reference to ARC4

From: Eric Biggers ARC4 is no longer considered secure, so it shouldn't be used, even as just an example. Signed-off-by: Eric Biggers --- Documentation/admin-guide/device-mapper/dm-integrity.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/admin-guide

Re: [dm-devel] [PATCH] dm-verity: unnecessary data blocks that need not read hash blocks

On Wed, Dec 11, 2019 at 11:32:40AM +0800, zhou xianrong wrote: > From: "xianrong.zhou" > > If check_at_most_once enabled, just like verity work the prefetching work > should check for data block bitmap firstly before reading hash block > as well. Skip bit-set data blocks from both ends of data

Re: [dm-devel] [Question] Confusion of the meaning for encrypto API's return value

On Mon, Dec 16, 2019 at 03:18:54PM +0800, Xu Zaibo wrote: > Hi, > > I get a confusion. > > According to my understanding, That 'crypto_skcipher_encrypt(request)' > returns '-EBUSY ' > > means the caller should call this API again with the request. However, as my > knowledge in > > 'dm-crypt',

Re: [dm-devel] [PATCH] dm-verity: unnecessary data blocks that need not read hash blocks

On Mon, Dec 16, 2019 at 02:02:33AM +, xianrong.zhou(周先荣) wrote: > hey Eric: > > On Wed, Dec 11, 2019 at 11:32:40AM +0800, zhou xianrong wrote: > > From: "xianrong.zhou" > > > > If check_at_most_once enabled, just like verity work the prefetching > > work should check for data block bitmap

Re: [dm-devel] kernel BUG at drivers/md/persistent-data/dm-space-map-disk.c:178

(https://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=for-next=2137c0dcc04b24efb4c38d4b46b7194575718dd5) and it has: Reported-by: Eric Biggers This is wrong, I didn't report this. I think you meant to put: Reported-by: Eric Wheeler - Eric (the other one) -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel

Re: [dm-devel] [PATCH] dm-verity: unnecessary data blocks that need not read hash blocks

On Mon, Dec 16, 2019 at 10:50:26AM -0800, Eric Biggers wrote: > On Mon, Dec 16, 2019 at 02:02:33AM +, xianrong.zhou(周先荣) wrote: > > hey Eric: > > > > On Wed, Dec 11, 2019 at 11:32:40AM +0800, zhou xianrong wrote: > > > From: "xianrong.zhou" > >

Re: [dm-devel] [PATCH] dm-verity:unnecessary data blocks that need not read hash blocks

On Tue, Jan 07, 2020 at 10:48:43AM +0800, zhou_xianrong wrote: > Subject: [PATCH] dm-verity:unnecessary data blocks that need not read Please use a proper commit subject. It should begin with "dm verity: " and use the imperative tense to describe the change, e.g. dm verity: don't

[dm-devel] [PATCH v3] dm verity: don't prefetch hash blocks for already-verified data

nching 91 apps every 15s repeated 21 times, prefetching was only done for 447177/4776629 = 9.36% of data blocks. Tested-by: ruxian.feng Co-developed-by: yuanjiong.gao Signed-off-by: yuanjiong.gao Signed-off-by: xianrong.zhou [EB: simplified the 'while' loops and improved the commit message]

[dm-devel] [PATCH] block: make bio_crypt_clone() return an error code

From: Eric Biggers Callers of bio_clone_fast() may use a gfp_mask that excludes GFP_DIRECT_RECLAIM. For example, map_request() uses GFP_ATOMIC. If this were to happen, the mempool_alloc() in __bio_crypt_clone() can fail, causing a NULL dereference. In reality map_request() currently never has

[dm-devel] [PATCH v2 3/3] block: warn if !__GFP_DIRECT_RECLAIM in bio_crypt_set_ctx()

From: Eric Biggers bio_crypt_set_ctx() assumes its gfp_mask argument always includes __GFP_DIRECT_RECLAIM, so that the mempool_alloc() will always succeed. For now this assumption is still fine, since no callers violate it. Making bio_crypt_set_ctx() able to fail would add unneeded complexity

[dm-devel] [PATCH v2 2/3] block: make blk_crypto_rq_bio_prep() able to fail

From: Eric Biggers blk_crypto_rq_bio_prep() assumes its gfp_mask argument always includes __GFP_DIRECT_RECLAIM, so that the mempool_alloc() will always succeed. However, blk_crypto_rq_bio_prep() might be called with GFP_ATOMIC via setup_clone() in drivers/md/dm-rq.c. This case isn't currently

[dm-devel] [PATCH v2 1/3] block: make bio_crypt_clone() able to fail

From: Eric Biggers bio_crypt_clone() assumes its gfp_mask argument always includes __GFP_DIRECT_RECLAIM, so that the mempool_alloc() will always succeed. However, bio_crypt_clone() might be called with GFP_ATOMIC via setup_clone() in drivers/md/dm-rq.c, or with GFP_NOWAIT via kcryptd_io_read

[dm-devel] [PATCH v2 0/3] block: fix up bio_crypt_ctx allocation

. - Added kerneldoc for bio_crypt_clone(). - Adjusted commit message. Eric Biggers (3): block: make bio_crypt_clone() able to fail block: make blk_crypto_rq_bio_prep() able to fail block: warn if !__GFP_DIRECT_RECLAIM in bio_crypt_set_ctx() block/bio.c | 20

Re: [dm-devel] [PATCH v2 0/3] block: fix up bio_crypt_ctx allocation

On Mon, Sep 28, 2020 at 01:59:34PM -0700, Eric Biggers wrote: > On Tue, Sep 15, 2020 at 08:53:12PM -0700, Eric Biggers wrote: > > This series makes allocation of encryption contexts either able to fail, > > or explicitly require __GFP_DIRECT_RECLAIM (via WARN_ON_ONCE). > &

Re: [dm-devel] [PATCH 3/3] dm: enable may_passthrough_inline_crypto on some targets

On Wed, Sep 09, 2020 at 11:44:22PM +, Satya Tangirala wrote: > From: Eric Biggers > > dm-linear and dm-flakey obviously can pass through inline crypto support. > > dm-zero should declare that it passes through inline crypto support, since > any reads from dm-zero sh

Re: [dm-devel] [PATCH 1/3] block: keyslot-manager: Introduce passthrough keyslot manager

ilities based on those of the > underlying devices. Blk-crypto does not attempt to program keys into any > keyslots in the passthrough keyslot manager. Instead, if/when the bio is > resubmitted to the underlying device, blk-crypto will try to program the > key into the underlying device's keyslot mana

Re: [dm-devel] [PATCH 2/3] dm: add support for passing through inline crypto support

On Wed, Sep 09, 2020 at 11:44:21PM +, Satya Tangirala wrote: > From: Eric Biggers > > Update the device-mapper core to support exposing the inline crypto > support of the underlying device(s) through the device-mapper device. > > This works by creating a "pass

Re: [dm-devel] [RFC PATCH 0/2] dm crypt: Allow unaligned buffer lengths for skcipher devices

On Wed, Sep 23, 2020 at 09:27:32PM -0400, Mike Snitzer wrote: > You've clearly done a nice job with these changes. Looks clean. > > BUT, I'm struggling to just accept that dm-crypt needs to go to these > extra lengths purely because of one bad apple usecase. > > These alignment constraints

Re: [dm-devel] [PATCH v2 0/3] block: fix up bio_crypt_ctx allocation

On Tue, Sep 15, 2020 at 08:53:12PM -0700, Eric Biggers wrote: > This series makes allocation of encryption contexts either able to fail, > or explicitly require __GFP_DIRECT_RECLAIM (via WARN_ON_ONCE). > > This applies to linux-block/for-next. > > Changed since v1 > (http

Re: [dm-devel] [PATCH 2/3] dm: add support for passing through inline crypto support

On Thu, Sep 24, 2020 at 09:46:49AM -0400, Mike Snitzer wrote: > > > Can you help me better understand the expected consumer of this code? > > > If you have something _real_ please be explicit. It makes justifying > > > supporting niche code like this more tolerable. > > > > So the motivation for

Re: [dm-devel] [PATCH 2/3] dm: add support for passing through inline crypto support

On Thu, Sep 24, 2020 at 12:16:24PM -0400, Mike Snitzer wrote: > On Thu, Sep 24 2020 at 11:45am -0400, > Eric Biggers wrote: > > > On Thu, Sep 24, 2020 at 09:46:49AM -0400, Mike Snitzer wrote: > > > > > Can you help me better understand the expected consumer of th

Re: [dm-devel] [PATCH v2 3/4] dm: add support for passing through inline crypto support

t; A DM device's table can only be changed if the "new" inline encryption > capabilities are a superset of the "old" inline encryption capabilities. > Attempts to make changes to the table that result in some inline encryption > capability becoming no longer supported will

Re: [dm-devel] [PATCH v2 1/4] block: keyslot-manager: Introduce passthrough keyslot manager

_ksm_init() for more details about the parameters.") isn't useful and should be removed. Otherwise this patch looks fine. You can add: Reviewed-by: Eric Biggers - Eric -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel

Re: [dm-devel] [PATCH v2 4/4] dm: enable may_passthrough_inline_crypto on some targets

On Thu, Oct 15, 2020 at 09:46:32PM +, Satya Tangirala wrote: > dm-linear and dm-flakey obviously can pass through inline crypto support. > > Co-developed-by: Eric Biggers > Signed-off-by: Eric Biggers > Signed-off-by: Satya Tangirala > --- > drivers/md/dm-flakey.c |

Re: [dm-devel] [PATCH v2 3/4] dm: add support for passing through inline crypto support

On Tue, Oct 27, 2020 at 11:58:47PM +, Satya Tangirala wrote: > > > +/** > > > + * blk_ksm_update_capabilities() - Update the restrictions of a KSM to > > > those of > > > + * another KSM > > > + * @target_ksm: The KSM whose restrictions to update. > > > + *

Re: [dm-devel] [PATCH 3/4] dm crypt: switch to EBOIV crypto API template

On Mon, Oct 26, 2020 at 03:04:46PM +0200, Gilad Ben-Yossef wrote: > Replace the explicit EBOIV handling in the dm-crypt driver with calls > into the crypto API, which now possesses the capability to perform > this processing within the crypto subsystem. > > Signed-off-by: Gilad Ben-Yossef > >

Re: [dm-devel] [PATCH 1/4] crypto: add eboiv as a crypto API template

On Mon, Oct 26, 2020 at 03:04:44PM +0200, Gilad Ben-Yossef wrote: > diff --git a/crypto/eboiv.c b/crypto/eboiv.c > new file mode 100644 > index ..467833e89139 > --- /dev/null > +++ b/crypto/eboiv.c > @@ -0,0 +1,295 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * EBOIV skcipher

Re: [dm-devel] [PATCH 1/4] crypto: add eboiv as a crypto API template

On Mon, Oct 26, 2020 at 11:24:50AM -0700, Eric Biggers wrote: > > +static int eboiv_create(struct crypto_template *tmpl, struct rtattr **tb) > > +{ > > + struct crypto_attr_type *algt; > > + const char *inner_cipher_name; > > + struct skcipher_instance *skciph

Re: [dm-devel] [PATCH 3/4] dm crypt: switch to EBOIV crypto API template

On Mon, Oct 26, 2020 at 07:29:57PM +0100, Milan Broz wrote: > On 26/10/2020 18:52, Eric Biggers wrote: > > On Mon, Oct 26, 2020 at 03:04:46PM +0200, Gilad Ben-Yossef wrote: > >> Replace the explicit EBOIV handling in the dm-crypt driver with calls > >> into the cryp

Re: [dm-devel] [PATCH 1/3 v4] crypto: introduce the flag CRYPTO_ALG_ALLOCATES_MEMORY

On Tue, Jun 30, 2020 at 09:56:22AM -0400, Mikulas Patocka wrote: > Index: linux-2.6/crypto/cryptd.c > === > --- linux-2.6.orig/crypto/cryptd.c2020-06-29 16:03:07.346417000 +0200 > +++ linux-2.6/crypto/cryptd.c 2020-06-30

Re: [dm-devel] [PATCH 1/3 v4] crypto: introduce the flag CRYPTO_ALG_ALLOCATES_MEMORY

On Tue, Jun 30, 2020 at 01:01:16PM -0400, Mikulas Patocka wrote: > > diff --git a/crypto/pcrypt.c b/crypto/pcrypt.c > > index 7240e8bbdebb..643f7f1cc91c 100644 > > --- a/crypto/pcrypt.c > > +++ b/crypto/pcrypt.c > > @@ -232,12 +232,15 @@ static int pcrypt_create_aead(struct crypto_template > >

Re: [dm-devel] [PATCH 0/6] crypto: add CRYPTO_ALG_ALLOCATES_MEMORY

On Wed, Jul 01, 2020 at 03:59:10AM -0400, Mikulas Patocka wrote: > Thanks for cleaning this up. > > Mikulas Do you have any real comments on this? Are the usage restrictions okay for dm-crypt? - Eric -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel

[dm-devel] [PATCH v2 0/7] crypto: add CRYPTO_ALG_ALLOCATES_MEMORY

. - Inherit the flags in various places that were missed. - Other cleanups. Additional changes v1 => v2: - Made crypto_check_attr_type() return the mask. - Added patch that adds NEED_FALLBACK to INHERITED_FLAGS. - Added patch that removes seqiv_create(). Eric Biggers (5): crypto: ge

[dm-devel] [PATCH v2 4/7] crypto: algapi - add NEED_FALLBACK to INHERITED_FLAGS

From: Eric Biggers CRYPTO_ALG_NEED_FALLBACK is handled inconsistently. When it's requested to be clear, some templates propagate that request to child algorithms, while others don't. It's apparently desired for NEED_FALLBACK to be propagated, to avoid deadlocks where a module tries to load

[dm-devel] [PATCH v2 3/7] crypto: algapi - use common mechanism for inheriting flags

From: Eric Biggers The flag CRYPTO_ALG_ASYNC is "inherited" in the sense that when a template is instantiated, the template will have CRYPTO_ALG_ASYNC set if any of the algorithms it uses has CRYPTO_ALG_ASYNC set. We'd like to add a second flag (CRYPTO_ALG_ALLOCATES_MEMORY) that gets

[dm-devel] [PATCH v2 2/7] crypto: seqiv - remove seqiv_create()

From: Eric Biggers seqiv_create() is pointless because it just checks that the template is being instantiated as an AEAD, then calls seqiv_aead_create(). But seqiv_aead_create() does the exact same check, via aead_geniv_alloc(). Just remove seqiv_create() and use seqiv_aead_create() directly

[dm-devel] [PATCH v2 7/7] dm-crypt: don't use drivers that have CRYPTO_ALG_ALLOCATES_MEMORY

From: Mikulas Patocka Don't use crypto drivers that have the flag CRYPTO_ALG_ALLOCATES_MEMORY set. These drivers allocate memory and thus they are unsuitable for block I/O processing. Signed-off-by: Mikulas Patocka --- drivers/md/dm-crypt.c | 17 +++-- 1 file changed, 11

[dm-devel] [PATCH v2 6/7] crypto: drivers - set the flag CRYPTO_ALG_ALLOCATES_MEMORY

: __virtio_crypto_skcipher_do_req drivers/crypto/xilinx/zynqmp-aes-gcm.c: zynqmp_aes_aead_cipher Signed-off-by: Mikulas Patocka [EB: avoid overly-long lines] Signed-off-by: Eric Biggers --- .../crypto/allwinner/sun8i-ce/sun8i-ce-core.c | 12 +- .../crypto/allwinner/sun8i-ss/sun8i-ss-core.c | 12 +- drivers

[dm-devel] [PATCH v2 1/7] crypto: geniv - remove unneeded arguments from aead_geniv_alloc()

From: Eric Biggers The type and mask arguments to aead_geniv_alloc() are always 0, so remove them. Signed-off-by: Eric Biggers --- crypto/echainiv.c | 2 +- crypto/geniv.c | 7 --- crypto/seqiv.c | 2 +- include/crypto/internal/geniv.h | 2

Re: [dm-devel] [PATCH 2/6] crypto: algapi - use common mechanism for inheriting flags

On Thu, Jul 09, 2020 at 03:31:26PM +1000, Herbert Xu wrote: > Eric Biggers wrote: > > > > @@ -875,14 +873,21 @@ static void cbcmac_exit_tfm(struct crypto_tfm *tfm) > > > > static int cbcmac_create(struct crypto_template *tmpl, struct rtattr **tb) > > { > >

Re: [dm-devel] [PATCH 5/6] crypto: set the flag CRYPTO_ALG_ALLOCATES_MEMORY

On Mon, Jul 13, 2020 at 06:49:00PM +0300, Horia Geantă wrote: > On 7/1/2020 7:52 AM, Eric Biggers wrote: > > From: Mikulas Patocka > > > > Set the flag CRYPTO_ALG_ALLOCATES_MEMORY in the crypto drivers that > > allocate memory. > > > Quite a few driver

[dm-devel] [PATCH 1/6] crypto: geniv - remove unneeded arguments from aead_geniv_alloc()

From: Eric Biggers The type and mask arguments to aead_geniv_alloc() are always 0, so remove them. Signed-off-by: Eric Biggers --- crypto/echainiv.c | 2 +- crypto/geniv.c | 7 --- crypto/seqiv.c | 2 +- include/crypto/internal/geniv.h | 2

  1   2   3   >