[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230705201205.GA866@sol.localdomain>
Date: Wed, 5 Jul 2023 13:12:05 -0700
From: Eric Biggers <ebiggers@...nel.org>
To: Giovanni Cabiddu <giovanni.cabiddu@...el.com>
Cc: herbert@...dor.apana.org.au, agk@...hat.com, snitzer@...nel.org,
linux-crypto@...r.kernel.org, dm-devel@...hat.com,
linux-kernel@...r.kernel.org, qat-linux@...el.com,
heinzm@...hat.com, meenakshi.aggarwal@....com,
horia.geanta@....com, V.Sethi@....com, pankaj.gupta@....com,
gaurav.jain@....com, davem@...emloft.net, iuliana.prodan@....com,
Fiona Trahe <fiona.trahe@...el.com>
Subject: Re: [PATCH 1/3] dm integrity: do not filter algos with
CRYPTO_ALG_ALLOCATES_MEMORY
On Wed, Jul 05, 2023 at 05:40:07PM +0100, Giovanni Cabiddu wrote:
> The flag CRYPTO_ALG_ALLOCATES_MEMORY indicates that an algorithm might
> allocate memory in the datapath and therefore sleep.
> Dm-integrity is filtering out implementations of skcipher algorithms
> that have this flag set. However, in the same function it does
> allocations with GFP_KERNEL.
Which function is the above referring to? The actual encryption/decryption
happens in crypt_journal(), and I don't see any memory allocations there.
> As dm-integrity is re-entrant and capable of handling sleeps that could
> occur during allocations with GFP_KERNEL, then it is also capable of
> using skcipher algorithm implementations that have
> CRYPTO_ALG_ALLOCATES_MEMORY set.
>
> Remove the filtering of skcipher implementations with the flag
> CRYPTO_ALG_ALLOCATES_MEMORY set.
What about the use of CRYPTO_ALG_ALLOCATES_MEMORY in get_mac()?
>
> Suggested-by: Herbert Xu <herbert@...dor.apana.org.au>
> Link: https://lore.kernel.org/linux-crypto/ZILvtASXQKLG43y9@gondor.apana.org.au/
> Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@...el.com>
> Reviewed-by: Fiona Trahe <fiona.trahe@...el.com>
This needs:
Fixes: a7a10bce8a04 ("dm integrity: don't use drivers that have CRYPTO_ALG_ALLOCATES_MEMORY")
Cc: stable@...r.kernel.org
But, are you 100% sure the explanation in commit a7a10bce8a04 was incorrect?
- Eric
Powered by blists - more mailing lists