Re: [PATCH 0/3] AF_ALG interface for akcipher

[Stephan Mueller <smueller@chronox.de>]

Am Mittwoch, 22. Juli 2015, 22:14:30 schrieb Tadeusz Struk:

Hi Tadeusz,

> On 07/22/2015 06:53 PM, Herbert Xu wrote:
> > On Wed, Jul 22, 2015 at 02:58:18PM +0300, Horia Geantă wrote:
> >> OTOH, caam has SG support for all PK operations, including rsa-encrypt,
> >> rsa-decrypt primitives.
> >> We are working at upstreaming - aligning our internal caam-pkc with
> >> akcipher.
> > 
> > OK.  Then we should tweak our interface to allow SGs.  Tadeusz?
> 
> We can add a flag to akcipher_request to say if src/dst are SGs or buffers,
> but is this really necessary?
> What we have now is two implementations that don't support SGs.
> In terms of users we have one in kernel i.e module verifier which doesn't
> need SGs and proposed user space interface, which is going to copy data
> from/to user because the buffers are so small that it is cheaper to copy
> than to use the splice/vmsplice calls. To be honest I don't see any benefit
> in adding SG support.

Tadeusz, to also support your case, I would again suggest to use another 
integer akin the alignmask which indicates the requested "block size" of one 
SG entry. Simiarly to alignmask, the implementation of a cipher now has two 
code paths: one streamlined path where the caller honored the integer and only 
has one SG list entry which gives you a linear buffer. If the caller does not 
honor the flag and uses more than one SGL entry, the implementation then does 
a memcpy to get a linear buffer.

This should allow us to convert the API to SGLs and yet maintain the case 
where an implementation has linear buffers.

To reduce code duplication, maybe we can create a service function that 
converts an SGL into a linear buffer.

-- 
Ciao
Stephan