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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 7/1/2020 7:52 AM, Eric Biggers wrote:
> From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
> 
> 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@xxxxxxxxxxxxxxxxxxx/

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@xxxxxxxxxxxxx
https://lore.kernel.org/linux-crypto/1426266882-31626-1-git-send-email-horia.geanta@xxxxxxxxxxxxx

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@xxxxxxxxxxxxx


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@xxxxxxxxxxxxx

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.

Thanks,
Horia



[Index of Archives]     [Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]

  Powered by Linux