On Mon, 13 Jul 2020, Horia Geantă wrote:
> On 7/13/2020 7:01 PM, Eric Biggers wrote:
> > 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
> >>>
> >>>
On Mon, 6 Jul 2020, Eric Biggers wrote:
> 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?
>
nts from aead_geniv_alloc()
> crypto: algapi - use common mechanism for inheriting flags
> crypto: algapi - introduce the flag CRYPTO_ALG_ALLOCATES_MEMORY
> crypto: algapi - remove crypto_check_attr_type()
>
> Mikulas Patocka (2):
> crypto: set the flag CRYPTO_ALG_A
GFP_KERNEL allocation can recurse into the block layer, causing a
deadlock.
Pass the flag CRYPTO_ALG_ALLOCATES_MEMORY down through the crypto API.
Signed-off-by: Mikulas Patocka
---
crypto/adiantum.c |8 +---
crypto/authenc.c |7 ---
crypto/authencesn.c
On Tue, 30 Jun 2020, Eric Biggers wrote:
> 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/c
GFP_KERNEL allocation can recurse into the block layer, causing a
deadlock.
Pass the flag CRYPTO_ALG_ALLOCATES_MEMORY down through the crypto API.
Signed-off-by: Mikulas Patocka
---
crypto/adiantum.c |8 +---
crypto/authenc.c |7 ---
crypto/authencesn.c
On Tue, 30 Jun 2020, Eric Biggers wrote:
> 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.c 2020-06-29 16:
On Sun, 28 Jun 2020, Eric Biggers wrote:
> On Sun, Jun 28, 2020 at 03:07:49PM -0400, Mikulas Patocka wrote:
> >
> > > Also, "seqiv" instances can be created without
> > > CRYPTO_ALG_ALLOCATES_MEMORY set,
> > > despite seqiv_aead_encrypt() allo
GFP_KERNEL allocation can recurse into the block layer, causing a
deadlock.
Pass the flag CRYPTO_ALG_ALLOCATES_MEMORY down through the crypto API.
Signed-off-by: Mikulas Patocka
---
crypto/adiantum.c |2 +-
crypto/authenc.c |7 ---
crypto/authencesn.c |7
On Mon, 29 Jun 2020, Mikulas Patocka wrote:
> On Sun, 28 Jun 2020, Eric Biggers wrote:
>
> > On Sun, Jun 28, 2020 at 03:07:49PM -0400, Mikulas Patocka wrote:
> > > >
> > > > cryptd_create_skcipher(), cryptd_create_hash(), cryptd_create_aead(),
> > &
On Sun, 28 Jun 2020, Eric Biggers wrote:
> On Sun, Jun 28, 2020 at 03:07:49PM -0400, Mikulas Patocka wrote:
> > >
> > > cryptd_create_skcipher(), cryptd_create_hash(), cryptd_create_aead(), and
> > > crypto_rfc4309_create() are also missing setting the mask.
&
On Fri, 26 Jun 2020, Eric Biggers wrote:
> On Fri, Jun 26, 2020 at 09:46:17AM -0700, Eric Biggers wrote:
> > On Fri, Jun 26, 2020 at 12:16:33PM -0400, Mikulas Patocka wrote:
> > > +/*
> > > + * Pass these flags down through the crypto API.
> > > + */
>
GFP_KERNEL allocation can recurse into the block layer, causing a
deadlock.
Pass the flag CRYPTO_ALG_ALLOCATES_MEMORY down through the crypto API.
Signed-off-by: Mikulas Patocka
---
crypto/adiantum.c |2 +-
crypto/authenc.c |4 ++--
crypto/authencesn.c |4
On Fri, 26 Jun 2020, Eric Biggers wrote:
> On Fri, Jun 26, 2020 at 12:16:33PM -0400, Mikulas Patocka wrote:
> > +/*
> > + * Pass these flags down through the crypto API.
> > + */
> > +#define CRYPTO_ALG_INHERITED_FLAGS (CRYPTO_ALG_ASYNC |
> > CRYPTO_ALG_ALLOC
GFP_KERNEL allocation can recurse into the block layer, causing a
deadlock.
Pass the flag CRYPTO_ALG_ALLOCATES_MEMORY down through the crypto API.
Signed-off-by: Mikulas Patocka
---
crypto/adiantum.c |3 ++-
crypto/authenc.c |5 +++--
crypto/authencesn.c |5
On Fri, 26 Jun 2020, Herbert Xu wrote:
> On Wed, Jun 17, 2020 at 11:09:28AM -0400, Mikulas Patocka wrote:
> >
> > Index: linux-2.6/include/linux/crypto.h
> > ===
> > --- linux-2.6.orig/include/linux
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 insertions(+), 6 dele
drivers/crypto/xilinx/zynqmp-aes-gcm.c: zynqmp_aes_aead_cipher
Signed-off-by: Mikulas Patocka
---
drivers/crypto/allwinner/sun8i-ce/sun8i-ce-core.c |8 +-
drivers/crypto/allwinner/sun8i-ss/sun8i-ss-core.c |8 +-
drivers/crypto/amlogic/amlogic-gxl-core.c |4 -
drivers/crypto/axis
GFP_KERNEL allocation can recurse into the block layer, causing a
deadlock.
Signed-off-by: Mikulas Patocka
---
crypto/adiantum.c |3 ++-
crypto/authenc.c |5 +++--
crypto/authencesn.c |5 +++--
crypto/ccm.c |7 ---
crypto/chacha20poly1305.c
I'm resending the patches with your comments resolved...
Mikulas
On Tue, 16 Jun 2020, Eric Biggers wrote:
> On Tue, Jun 16, 2020 at 11:01:31AM -0400, Mikulas Patocka wrote:
> > Introduce a new flag CRYPTO_ALG_ALLOCATES_MEMORY and modify dm-crypt, so
> > that it uses only
There is this call chain:
sec_alg_skcipher_encrypt -> sec_alg_skcipher_crypto ->
sec_alg_alloc_and_calc_split_sizes -> kcalloc
where we call sleeping allocator function even if CRYPTO_TFM_REQ_MAY_SLEEP
was not specified.
Signed-off-by: Mikulas Patocka
Cc: sta...@vger.kernel.org
There is this call chain:
cvm_encrypt -> cvm_enc_dec -> cptvf_do_request -> process_request -> kzalloc
where we call sleeping allocator function even if CRYPTO_TFM_REQ_MAY_SLEEP
was not specified.
Signed-off-by: Mikulas Patocka
Cc: sta...@vger.kernel.org # v4.11+
Fixes:
On Tue, 16 Jun 2020, Eric Biggers wrote:
> On Tue, Jun 16, 2020 at 02:18:17PM -0400, Mikulas Patocka wrote:
> >
> >
> > On Tue, 16 Jun 2020, Eric Biggers wrote:
> >
> > > On Tue, Jun 16, 2020 at 11:02:50AM -0400, Mikulas Patocka wrote:
> > >
On Tue, 16 Jun 2020, Eric Biggers wrote:
> On Tue, Jun 16, 2020 at 11:02:50AM -0400, Mikulas Patocka wrote:
> > Fix the crypto drivers that don't respect CRYPTO_TFM_REQ_MAY_SLEEP. If
> > CRYPTO_TFM_REQ_MAY_SLEEP is not set, the driver must not do allocation
> > that s
Set the flag CRYPTO_ALG_ALLOCATES_MEMORY in the crypto drivers that
allocate memory.
Signed-off-by: Mikulas Patocka
---
drivers/crypto/allwinner/sun8i-ce/sun8i-ce-core.c |8 +-
drivers/crypto/allwinner/sun8i-ss/sun8i-ss-core.c |8 +-
drivers/crypto/amlogic/amlogic-gxl-core.c
Fix the crypto drivers that don't respect CRYPTO_TFM_REQ_MAY_SLEEP. If
CRYPTO_TFM_REQ_MAY_SLEEP is not set, the driver must not do allocation
that sleeps.
Signed-off-by: Mikulas Patocka
---
drivers/crypto/amlogic/amlogic-gxl-cipher.c |5 ++-
drivers/crypto/cavium/cpt/cptvf_a
Pass the flag CRYPTO_ALG_ALLOCATES_MEMORY down through the crypto API.
Signed-off-by: Mikulas Patocka
---
crypto/adiantum.c |3 ++-
crypto/authenc.c |5 +++--
crypto/authencesn.c |5 +++--
crypto/ccm.c |7 ---
crypto/chacha20poly1305.c
anytime (causing random I/O errors) and
GFP_KERNEL allocation can recurse into the block layer, causing a
deadlock.
Signed-off-by: Mikulas Patocka
Index: linux-2.6/include/linux/crypto.h
===
--- linux-2.6.orig/include/linux/crypto.h
On Wed, 10 Jun 2020, Herbert Xu wrote:
> On Wed, Jun 10, 2020 at 08:02:23AM -0400, Mikulas Patocka wrote:
> >
> > Yes, fixing the drivers would be the best - but you can hardly find any
> > person who has all the crypto hardware and who is willing to rewrite all
&
On Wed, 10 Jun 2020, Herbert Xu wrote:
> On Tue, Jun 09, 2020 at 01:11:05PM -0400, Mikulas Patocka wrote:
> >
> > Do you have another idea how to solve this problem?
>
> I think the better approach would be to modify the drivers to not
> allocate any memory. In gener
Hi
I've found out that a lot of hardware crypto drivers use GFP_ATOMIC. Some
of them switch between GFP_ATOMIC and GFP_KERNEL based on the flag
CRYPTO_TFM_REQ_MAY_SLEEP.
dm-crypt and dm-integrity don't use CRYPTO_TFM_REQ_MAY_SLEEP (because
GFP_KERNEL allocation requests can recurse back to the
On Wed, 3 Jun 2020, Giovanni Cabiddu wrote:
> > > > +bool adf_should_back_off(struct adf_etr_ring_data *ring)
> > > > +{
> > > > + return atomic_read(ring->inflights) >
> > > > ADF_MAX_INFLIGHTS(ring->ring_size, ring->msg_size) * 15 / 16;
> > > How did you came up with 15/16?
> >
> > I
On Tue, 2 Jun 2020, Giovanni Cabiddu wrote:
> Hi Mikulas,
>
> thanks for your patch. See below.
>
> > + qat_req->backed_off = backed_off =
> > adf_should_back_off(ctx->inst->sym_tx);
> > +again:
> > + ret = adf_send_message(ctx->inst->sym_tx, (uint32_t *)msg);
> > if (ret == -EAGAIN)
cause I/O
errors. So, we sleep and retry.
Signed-off-by: Mikulas Patocka
Cc: sta...@vger.kernel.org
---
drivers/md/dm-integrity.c |5 +
1 file changed, 5 insertions(+)
Index: linux-2.6/drivers/md/dm-integrity.c
===
--- linux
Use GFP_KERNEL when the flag CRYPTO_TFM_REQ_MAY_SLEEP is present.
Also, use GFP_KERNEL when setting a key.
Signed-off-by: Mikulas Patocka
Cc: sta...@vger.kernel.org
Index: linux-2.6/drivers/crypto/qat/qat_common/qat_algs.c
iable backed_off) and
if we finish the request, we return -EINPROGRESS to indicate that the user
can send more requests.
Signed-off-by: Mikulas Patocka
Cc: sta...@vger.kernel.org
Index: linux-2.6/drivers/crypto/qat/qat_common/qat_a
Hi
These patches fix bugs in the Intel QAT driver.
https://bugzilla.redhat.com/show_bug.cgi?id=1813394
Mikulas
retry.
Signed-off-by: Mikulas Patocka
Cc: sta...@vger.kernel.org
Index: linux-2.6/drivers/md/dm-crypt.c
===
--- linux-2.6.orig/drivers/md/dm-crypt.c
+++ linux-2.6/drivers/md/dm-crypt.c
@@ -1534,6 +1534,7 @@ static blk_status_t
the caller should stop sending more requests.
When the request is returned with -EINPROGRESS, the caller can send more
requests.
Signed-off-by: Mikulas Patocka
Cc: sta...@vger.kernel.org
Index: linux-2.6/drivers/crypto/qat/qat_common/qat_asym_algs.c
t_by_sg is using GFP_ATOMIC allocation that can
fail anytime. This patch fixes the logic so that it won't attempt the
failing allocation if the data doesn't cross a page boundary.
Signed-off-by: Mikulas Patocka
Cc: sta...@vger.kernel.org
---
arch/x86/crypto/aesni-intel_glue.c |2 +
m/archives/dm-devel/2018-August/msg00195.html )
Signed-off-by: Mikulas Patocka
Cc: sta...@vger.kernel.org
---
drivers/md/dm-crypt.c | 10 +-
drivers/md/dm-integrity.c |4 ++--
2 files changed, 7 insertions(+), 7 deletions(-)
Index: linux-2.6/drivers/md/
On Fri, 24 Aug 2018, Mikulas Patocka wrote:
>
>
> On Fri, 24 Aug 2018, Herbert Xu wrote:
>
> > On Fri, Aug 24, 2018 at 07:06:32AM -0400, Mikulas Patocka wrote:
> > >
> > > A quick search through the crypto code shows that ahash_save_req and
>
On Fri, 24 Aug 2018, Herbert Xu wrote:
> On Fri, Aug 24, 2018 at 07:06:32AM -0400, Mikulas Patocka wrote:
> >
> > A quick search through the crypto code shows that ahash_save_req and
> > seqiv_aead_encrypt return -ENOMEM.
> >
> > Will you fix them?
>
On Fri, 24 Aug 2018, Mikulas Patocka wrote:
>
>
> On Fri, 24 Aug 2018, Herbert Xu wrote:
>
> > On Thu, Aug 23, 2018 at 04:39:23PM -0400, Mikulas Patocka wrote:
> > >
> > > 1. don't set CRYPTO_TFM_REQ_MAY_SLEEP in dm-crypt
> > > ===
On Fri, 24 Aug 2018, Herbert Xu wrote:
> On Thu, Aug 23, 2018 at 04:39:23PM -0400, Mikulas Patocka wrote:
> >
> > 1. don't set CRYPTO_TFM_REQ_MAY_SLEEP in dm-crypt
> > =
> > If we don't set it, dm-crypt will u
Hi
There's a deadlock reported here:
https://bugzilla.kernel.org/show_bug.cgi?id=200835
* dm-crypt calls crypt_convert in xts mode
* init_crypt from xts.c calls kmalloc(GFP_KERNEL)
* kmalloc(GFP_KERNEL) recurses into the XFS filesystem, the filesystem
tries to submit some bios and wait
QUEST_ON_STACK is only meant for
> sync algorithms and this code needs to be changed to either do the
> proper request allocation or switch over to allocating sync
> algorithms.
>
> Cheers,
Hi
Here I send a patch that moves those allocations to the heap.
Mikulas
From: Mikula
. If
we use a call instruction and pop the return address, it desynchronizes
the return stack and causes branch prediction misses.
This patch also moves the data to the .rodata section.
Signed-off-by: Mikulas Patocka
---
arch/x86/crypto/crc32-pclmul_asm.S | 17 ++---
1 file
On Mon, 14 Aug 2017, Gilad Ben-Yossef wrote:
> dm-verity is starting async. crypto ops and waiting for them to complete.
> Move it over to generic code doing the same.
>
> This also fixes a possible data coruption bug created by the
> use of wait_for_completion_interruptible() without dealing
>
ng an algorithm.
>
> Link: http://marc.info/?l=linux-crypto-vger&m=148063683310477&w=2
> Cc: sta...@vger.kernel.org
> Reported-by: Mikulas Patocka
> Signed-off-by: Tim Chen
> ---
> crypto/mcryptd.c | 19 ---
> 1 file changed, 12 insertions(+), 7 del
Hi
There is a bug in mcryptd initialization.
This is a test module that tries various hash algorithms. When you load
the module with "insmod test.ko 'alg=mcryptd(md5)'", the machine crashes.
Mikulas
#include
#include
#include
static char *alg = "md5";
module_param_named(alg, alg, charp,
On Sat, 26 Jul 2014, Ard Biesheuvel wrote:
> On 26 July 2014 15:13, Ard Biesheuvel wrote:
> > On 26 July 2014 01:40, Mikulas Patocka wrote:
> >> cryptsetup fails on arm64 when using kernel encryption via AF_ALG socket.
> >> See https://bugzilla.redhat.com/show_bug.c
Fix the same alignment bug as in arm64 - we need to pass residue
unprocessed bytes as the last argument to blkcipher_walk_done.
Signed-off-by: Mikulas Patocka
Cc: sta...@vger.kernel.org # 3.13+
Index: linux-3.16.0-0.rc6.git1.1.fc21.aarch64/arch/arm/crypto/aesbs-glue.c
-off-by: Mikulas Patocka
Index: linux-3.16.0-0.rc6.git1.1.fc21.aarch64/arch/arm64/crypto/aes-glue.c
===
--- linux-3.16.0-0.rc6.git1.1.fc21.aarch64.orig/arch/arm64/crypto/aes-glue.c
+++ linux-3.16.0-0.rc6.git1.1.fc21.aarch64/arch/arm64
On Tue, 16 Feb 2010, Herbert Xu wrote:
> On Fri, Feb 12, 2010 at 09:42:28AM +0100, Sebastian Andrzej Siewior wrote:
> >
> > -static void arc4_crypt(struct crypto_tfm *tfm, u8 *out, const u8 *in)
> > +static void arc4_ivsetup(struct arc4_ctx *ctx, u8 *iv)
> > {
> > - struct arc4_ctx *ctx = cry
On Tue, 9 Feb 2010, Herbert Xu wrote:
> Mikulas Patocka wrote:
> >
> > You should rather add a flag CRYPTO_ALG_CHANGES_STATE to determine that a
> > cipher can't be used to encrypt disks.
>
> No, please see my reply in the previous thread. What we should
>
On Tue, 26 Jan 2010, Sebastian Andrzej Siewior wrote:
> * Mikulas Patocka | 2010-01-26 07:27:18 [-0500]:
>
> >> yes, I think it is better.
> >> (...and I just forgot to add that test to dm-crypt after that suggestion.)
> >>
> >> Milan
> >
> &
> >>> This patch disables the use of arc4 on block devices.
> >>
> >> arc4 again. it is simply not a block cipher:-)
> >>
> >> This should be solved inside cryptoAPI and not blacklist it in dm-crypt,
> >> see that thread
> >> http://article.gmane.org/gmane.linux.kernel.cryptoapi/3441
> >
> > I som
BTW. I created a script that tests all possible ciphers, keysizes,
chaining modes and iv modes for dm-crypt. arc4 is the only one that fails.
You can add it your regression testsuite if you want.
Mikulas#!/bin/sh
dmsetup remove cr0
set -e
cipher="$@"
cryptsetup -d key $cipher create cr0 /dev/ram
liminating the cipher and getting two xored plaintexts.
Signed-off-by: Mikulas Patocka
---
drivers/md/dm-crypt.c |5 +
1 file changed, 5 insertions(+)
Index: linux-2.6.32-devel/drivers/md/dm-crypt.c
===
--- linux-2.6.32-devel.o
If you want to negate the meaning of the flag, then you have to write it
yourself. I, as non-developer of crypto code, can prove that on given path
the input data are read only once --- but I can't prove that on all paths
and all possible chaining modes of algorithms the data are read once,
becaus
On Thu, May 22, 2008 at 08:32:45AM -0400, Mikulas Patocka wrote:
There may be external modules.
Sorry but we don't support external modules. They should be merged
upstream rather than distributed in the wild.
Cheers,
If you want to negate the meaning of the flag, then you have to wri
All the ciphers comply, so the bug is only a theroretical issue (but I
didn't check assembler versions --- they should be checked by the person
who wrote them, assembler is write-only language).
Since every current algorithm sets the flag could you invert
its sense? Sorry to have to do this to y
On Wed, 14 May 2008, Herbert Xu wrote:
On Tue, May 13, 2008 at 04:35:03PM -0400, Mikulas Patocka wrote:
And where would you propose to place this bit?
One possibility would be struct crypto_tfm->crt_flags
Another possibility is struct crypto_alg->cra_flags
The latter definitely b
On Tue, 13 May 2008, Herbert Xu wrote:
On Mon, May 12, 2008 at 11:28:44PM -0400, Mikulas Patocka wrote:
Or do you thint it would be useless (all major disk-encryption algorithms
read input buffer more times?) or it would create too much code
complexity?
I'm open to this approach. As
On Tue, 6 May 2008, Mikulas Patocka wrote:
On Tue, 6 May 2008, Herbert Xu wrote:
Mikulas Patocka <[EMAIL PROTECTED]> wrote:
BTW: is it guaranteed for crypto functions that they read the source data
only once?
There is no such guarantee.
Cheers,
So we'll have to copy th
On Tue, 6 May 2008, Herbert Xu wrote:
Mikulas Patocka <[EMAIL PROTECTED]> wrote:
BTW: is it guaranteed for crypto functions that they read the source data
only once?
There is no such guarantee.
Cheers,
So we'll have to copy the sector to temporary space before encrypting it.
On Mon, 7 Apr 2008, Martin K. Petersen wrote:
"Malahal" == malahal <[EMAIL PROTECTED]> writes:
[I sent this last week but it never made it to the list]
Malahal> Very few drivers require it, so how about an interface to
Malahal> lock the pages of an I/O available to drivers. Only needed
Mal
68 matches
Mail list logo
