Re: [RFC PATCH] crypto: RSA padding transform

[Stephan Mueller <smueller@chronox.de>]

Am Montag, 7. September 2015, 07:31:56 schrieb Tadeusz Struk:

Hi Tadeusz,

>On 09/06/2015 07:33 AM, Andrzej Zaborowski wrote:
>> Probably yes, I also read about the decision to use iov buffers, this
>> will have a bigger effect on code.
>
>The more I think about the sgl support the more it looks to me like it wasn't
>a good idea. It will be copied into a flat buffer somewhere along the way
>anyway. Like in the example below.
>
>I have that conversion already done, and for SW it looks like the data is
>copied 4 times for a single operation:
>1 - from sgl to flat buffer, because MPI doesn't take sgls, (if the src has
>more ents) 2 - from buff to MPI, then, after operation
>3 - export from MPI to a buff and
>4 - from buff to sgl (if is the output sg it also fragmented).
>
>I can see now that with all these padding schemes there will be more buffer
>copied on top of this, so I wonder if it still make sense.
>Herbert?

When the padding stuff comes into play, I think the SGL approach avoids 
memcpy() invocations.

For example, Andrzej's approach currently is to copy the *entire* source data 
into a buffer where the padding is added.

With SGLs, Andrzej only needs a buffer with the padding (which I would think 
could even reside on the stack, provided some bounds checks are done), and 
modify the SGL by preprending the padding buffer to the SGL with the source 
data.

>
>> +     src = kmalloc(ctx->key_size,
>> 
>>>> +                     (req->base.flags & CRYPTO_TFM_REQ_MAY_SLEEP) ?
>>>> +                     GFP_KERNEL : GFP_ATOMIC);
>>>> +     if (!src)
>>>> +             return -ENOMEM;
>>>> +
>>>> +     /* Reuse output buffer, add padding in the input */
>>>> +     child_req->src = src;
>>>> +     child_req->src_len = ctx->key_size;
>>>> +     child_req->dst = req->dst;
>>>> +     child_req->dst_len = req->dst_len;
>
>--
>To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html


Ciao
Stephan