On Sat, 11 Mar 2023 at 09:47, Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> wrote: > > On Sat, Mar 11, 2023 at 09:42:06AM +0100, Ard Biesheuvel wrote: > > > > Every call to crypto_skcipher_set_reqsize(), no? > > We'd only convert the software implementations. But you're right > there does seem to be a few users such as aria that demand a large > amount of temp space. I'd be tempted to just leave them on skcipher. > > In other cases such as ctr we can easily put the IV on the stack. > But why can't we make skcipher just a hybrid? - make the scatterlist members in skcipher_request unions with virtual src and dst alternatives - add an API that assigns those alternative members and checks that the tfm is not ALG_ASYNC - make the existing skcipher_en/decrypt() implementations check the request type, and hand off to a 'sync' alternative that allocates the request ctx on the stack, and make the accessor return the stack version instead of the heap version - update skcipher_walk_xxx() to return the virtually addressable dst and src if the sync request type is encountered. That way, the skcipher implementations can remain as they are, and the callers can just put a struct skcipher_request on the stack (without the padding and ctx overhead) and call the new interface with virtual addresses. That way, all the SYNC_SKCIPHER hacks can go, and we don't need yet another algo type. That way, the implementations can remain the same,
