From: "Horia Geantă" <horia.geanta@nxp.com>
To: Eric Biggers <ebiggers@kernel.org>
Cc: Mikulas Patocka <mpatocka@redhat.com>,
"linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
Herbert Xu <herbert@gondor.apana.org.au>,
"dm-devel@redhat.com" <dm-devel@redhat.com>
Subject: Re: [PATCH 5/6] crypto: set the flag CRYPTO_ALG_ALLOCATES_MEMORY
Date: Mon, 13 Jul 2020 20:53:04 +0300 [thread overview]
Message-ID: <780cb500-2241-61bc-eb44-6f872ad567d3@nxp.com> (raw)
In-Reply-To: <20200713160136.GA1696@sol.localdomain>
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 <mpatocka@redhat.com>
>>>
>>> Set the flag CRYPTO_ALG_ALLOCATES_MEMORY in the crypto drivers that
>>> allocate memory.
>>>
>> Quite a few drivers are impacted.
>>
>> I wonder what's the proper way to address the memory allocation.
>>
>> Herbert mentioned setting up reqsize:
>> https://lore.kernel.org/linux-crypto/20200610010450.GA6449@gondor.apana.org.au/
>>
>> I see at least two hurdles in converting the drivers to using reqsize:
>>
>> 1. Some drivers allocate the memory using GFP_DMA
>>
>> reqsize does not allow drivers to control gfp allocation flags.
>>
>> I've tried converting talitos driver (to use reqsize) at some point,
>> and in the process adding a generic CRYPTO_TFM_REQ_DMA flag:
>> https://lore.kernel.org/linux-crypto/54FD8D3B.5040409@freescale.com
>> https://lore.kernel.org/linux-crypto/1426266882-31626-1-git-send-email-horia.geanta@freescale.com
>>
>> The flag was supposed to be transparent for the user,
>> however there were users that open-coded the request allocation,
>> for example esp_alloc_tmp() in net/ipv4/esp4.c.
>> At that time, Dave NACK-ed the change:
>> https://lore.kernel.org/linux-crypto/1426266922-31679-1-git-send-email-horia.geanta@freescale.com
>>
>>
>> 2. Memory requirements cannot be determined / are not known
>> at request allocation time
>>
>> An analysis for talitos driver is here:
>> https://lore.kernel.org/linux-crypto/54F8235B.5080301@freescale.com
>>
>> In general, drivers would be forced to ask more memory than needed,
>> to handle the "worst-case".
>> Logic will be needed to fail in case the "worst-case" isn't correctly estimated.
>>
>> However, this is still problematic.
>>
>> For example, a driver could set up reqsize to accommodate for 32 S/G entries
>> (in the HW S/G table). In case a dm-crypt encryption request would require more,
>> then driver's .encrypt callback would fail, possibly with -ENOMEM,
>> since there's not enough pre-allocated memory.
>> This brings us back to the same problem we're trying to solve,
>> since in this case the driver would be forced to either fail immediately or
>> to allocate memory at .encrypt/.decrypt time.
>>
>
> We have to place restrictions on what cases
> !(flags & CRYPTO_ALG_ALLOCATES_MEMORY) applies to anyway; see the patch that
> introduces it. If needed we could add more restrictions, like limit the number
> of scatterlist elements. If we did that, the driver could allocate memory if
> the number of scatterlist elements is large, without having to set
> CRYPTO_ALG_ALLOCATES_MEMORY.
>
This sounds reasonable.
> Also, have you considered using a mempool? A mempool allows allocations without
> a possibility of failure, at the cost of pre-allocations.
>
Thanks for the suggestion.
Would this be safe for all cases, e.g. IPsec - where .encrypt/.decrypt callbacks
execute in (soft)IRQ context?
kernel-doc for mempool_alloc() mentions it could fail when called from
"IRQ context".
Thanks,
Horia
next prev parent reply other threads:[~2020-07-13 17:53 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-01 4:52 [PATCH 0/6] crypto: add CRYPTO_ALG_ALLOCATES_MEMORY Eric Biggers
2020-07-01 4:52 ` [PATCH 1/6] crypto: geniv - remove unneeded arguments from aead_geniv_alloc() Eric Biggers
2020-07-01 4:52 ` [PATCH 2/6] crypto: algapi - use common mechanism for inheriting flags Eric Biggers
2020-07-09 5:31 ` Herbert Xu
2020-07-10 6:24 ` Eric Biggers
2020-07-10 6:37 ` Herbert Xu
2020-07-01 4:52 ` [PATCH 3/6] crypto: algapi - introduce the flag CRYPTO_ALG_ALLOCATES_MEMORY Eric Biggers
2020-07-01 4:52 ` [PATCH 4/6] crypto: algapi - remove crypto_check_attr_type() Eric Biggers
2020-07-01 4:52 ` [PATCH 5/6] crypto: set the flag CRYPTO_ALG_ALLOCATES_MEMORY Eric Biggers
2020-07-13 15:49 ` Horia Geantă
2020-07-13 16:01 ` Eric Biggers
2020-07-13 17:53 ` Horia Geantă [this message]
2020-07-14 13:38 ` Mikulas Patocka
2020-07-01 4:52 ` [PATCH 6/6] dm-crypt: don't use drivers that have CRYPTO_ALG_ALLOCATES_MEMORY Eric Biggers
2020-07-01 7:59 ` [PATCH 0/6] crypto: add CRYPTO_ALG_ALLOCATES_MEMORY Mikulas Patocka
2020-07-06 18:54 ` Eric Biggers
2020-07-07 14:58 ` Mikulas Patocka
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=780cb500-2241-61bc-eb44-6f872ad567d3@nxp.com \
--to=horia.geanta@nxp.com \
--cc=dm-devel@redhat.com \
--cc=ebiggers@kernel.org \
--cc=herbert@gondor.apana.org.au \
--cc=linux-crypto@vger.kernel.org \
--cc=mpatocka@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).