Hi Herbert,
On 7/22/2020 10:29 AM, Herbert Xu wrote:
On Fri, Jul 17, 2020 at 05:42:43PM +0300, Horia Geantă wrote:
Looks like there's no mention of a limit on src, dst scatterlists size
that crypto implementations could use when pre-allocating memory
and crypto users needing CRYPTO_ALG_ALLOCATES_MEMORY should be aware of
(for the contract to be honoured):
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Flinux-crypto%2F780cb500-2241-61bc-eb44-6f872ad567d3%40nxp.com&data=02%7C01%7Ciuliana.prodan%40nxp.com%7Ca077782ce45c4ad3458b08d82e1100ac%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637309997855351100&sdata=T9RLjA%2B4l3zpxUSkFUGTxGQFu4kWfghQAKGyfUco%2Fb8%3D&reserved=0
Good point. I think we should limit this flag only to the cases
applicable to dm-crypt, which seems to be 4 entries maximum.
Anything else should be allowed to allocate extra memory as needed.
I'm working on removing the CRYPTO_ALG_ALLOCATES_MEMORY flag from CAAM.
For memory allocation I want to use the crypto request object and set
the size needed in reqsize (as suggested by you
https://lore.kernel.org/linux-crypto/20200610010450.GA6449@xxxxxxxxxxxxxxxxxxx/).
But CAAM needs DMA-able memory and the current mechanism doesn't allow it.
I want to use Horia's solution from a couple of years ago
(https://lore.kernel.org/linux-crypto/1426266882-31626-1-git-send-email-horia.geanta@xxxxxxxxxxxxx/),
but modify request object allocation only in Crypto API.
What do you think?
Thanks,
Iulia
