linux-kernel - Re: [PATCH 1/3] dm integrity: do not filter algos with CRYPTO_ALG_ALLOCATES

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <b20dd7d0-2f36-4208-8dc5-f304a7bd1a1c@nxp.com>
Date: Thu, 4 Jul 2024 10:39:24 +0000
From: Horia Geanta <horia.geanta@....com>
To: Herbert Xu <herbert@...dor.apana.org.au>, Giovanni Cabiddu
	<giovanni.cabiddu@...el.com>
CC: Eric Biggers <ebiggers@...nel.org>, "agk@...hat.com" <agk@...hat.com>,
	"snitzer@...nel.org" <snitzer@...nel.org>, "linux-crypto@...r.kernel.org"
	<linux-crypto@...r.kernel.org>, "dm-devel@...hat.com" <dm-devel@...hat.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"qat-linux@...el.com" <qat-linux@...el.com>, "heinzm@...hat.com"
	<heinzm@...hat.com>, Meenakshi Aggarwal <meenakshi.aggarwal@....com>, Varun
 Sethi <V.Sethi@....com>, Pankaj Gupta <pankaj.gupta@....com>, Gaurav Jain
	<gaurav.jain@....com>, "davem@...emloft.net" <davem@...emloft.net>, Iuliana
 Prodan <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 7/6/2023 12:58 AM, Herbert Xu wrote:
> On Wed, Jul 05, 2023 at 09:57:54PM +0100, Giovanni Cabiddu wrote:
>>
>> Then we are then back to square one. We need to check how many entries
>> are present in the scatterlists encrypted by crypt_journal() before
>> adjusting the meaning of !CRYPTO_ALG_ALLOCATES_MEMORY.
> 
> Indeed.  I missed the fact that it was preallocating memory with
> GFP_KERNEL.
> 
> So perhaps the answer is to adjust our API to allow the drivers to
> pre-allocate memory.  I'll look into this.
> 
Reviving this thread, trying to reach a conclusion.

Herbert, do you have any suggestion on how to move forward?

Is preallocating memory at crypto request allocation time worth pursuing?
This would indeed require updating the crypto API, to allow users to provide,
optionally, hints to the drivers / crypto framework wrt. memory needed
(e.g. S/G sizes):
	*_request_alloc(tfm, gfp, prealloc_hint);

Taking dm-integrity as an example, quoting Mikulas
"dm-integrity allocates arbitrarily large sg-lists when encrypting the journal"
so it's unpractical for drivers to use tfm->reqsize for memory preallocation.
OTOH, the sizes of S/Gs are known at crypto request allocation time:
create_journal
	-> dm_integrity_alloc_journal_scatterlist
	-> skcipher_request_alloc

For dm-crypt, we can't use the same logic, since crypto requests are allocated
from a mempool and *_request_alloc API is not used.
Fortunately, the S/G sizes are bounded and fairly small, thus drivers
could use tfm->reqsize to cover this case.

If the user / application logic expects no memory allocation at "runtime",
then it follows it has some information wrt. resources to be used and
either allocates crypto requests early on (dm-integrity) or prepares
a mempool (dm-crypt).
This information should be propagated to the drivers / crypto framework.
It's unreasonable to expect HW-backed implementations to avoid memory
allocations without being informed about the workload to be performed.

Thanks,
Horia