linux-kernel - Re: [PATCH 0/5] crypto: caam - avoid allocating memory at crypto request runtime

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 for Android: free password hash cracker in your pocket

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

Message-ID: <d454a0da-395d-3893-9ae1-f52236bcdde8@nxp.com>
Date:   Thu, 10 Dec 2020 10:28:35 +0200
From:   Horia Geantă <horia.geanta@....com>
To:     "Iuliana Prodan (OSS)" <iuliana.prodan@....nxp.com>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        Ard Biesheuvel <ardb@...nel.org>,
        "David S. Miller" <davem@...emloft.net>
Cc:     Aymen Sghaier <aymen.sghaier@....com>,
        Silvano Di Ninno <silvano.dininno@....com>,
        Franck Lenormand <franck.lenormand@....com>,
        "linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        dl-linux-imx <linux-imx@....com>,
        Iuliana Prodan <iuliana.prodan@....com>
Subject: Re: [PATCH 0/5] crypto: caam - avoid allocating memory at crypto
 request runtime

On 12/3/2020 3:35 AM, Iuliana Prodan (OSS) wrote:
> From: Iuliana Prodan <iuliana.prodan@....com>
> 
> This series removes CRYPTO_ALG_ALLOCATES_MEMORY flag and
> allocates the memory needed by the driver, to fulfil a
> request, within the crypto request object.
> The extra size needed for base extended descriptor, hw
> descriptor commands and link tables is added to the reqsize
> field that indicates how much memory could be needed per request.
> 
> CRYPTO_ALG_ALLOCATES_MEMORY flag is limited only to
> dm-crypt use-cases, which seems to be 4 entries maximum.
> Therefore in reqsize we allocate memory for maximum 4 entries
> for src and 4 for dst, aligned.
> If the driver needs more than the 4 entries maximum, the memory
> is dynamically allocated, at runtime.
> 
Moving the memory allocations from caam driver into the generic crypto API
has the side effect of dropping the GFP_DMA allocation flag.

For cases when caam device is limited to 32-bit address space and
there's no IOMMU, this could lead to DMA API using bounce buffering.

We need to measure the performance impact of this change before deciding
what we should do next.

Thanks,
Horia