From: Tadeusz Struk <tadeusz.struk@intel.com>
To: "Herbert Xu" <herbert@gondor.apana.org.au>,
"Horia Geantă" <horia.geanta@freescale.com>
Cc: "Stephan Mueller" <smueller@chronox.de>,
linux-crypto@vger.kernel.org,
"Tudor Ambăruș" <tudor.ambarus@freescale.com>
Subject: Re: [PATCH 0/3] AF_ALG interface for akcipher
Date: Wed, 22 Jul 2015 22:14:30 -0700 [thread overview]
Message-ID: <55B07836.5050307@intel.com> (raw)
In-Reply-To: <20150723015303.GA9777@gondor.apana.org.au>
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.
next prev parent reply other threads:[~2015-07-23 5:15 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-21 22:12 [PATCH 0/3] AF_ALG interface for akcipher Stephan Mueller
2015-07-21 22:12 ` [PATCH 1/3] crypto: af_alg - add sig gen / verify API Stephan Mueller
2015-07-21 22:13 ` [PATCH 2/3] crypto: algif_akcipher user space interface Stephan Mueller
2015-07-22 16:01 ` Tadeusz Struk
2015-07-22 18:55 ` Stephan Mueller
2015-07-22 22:04 ` Tadeusz Struk
2015-07-22 22:29 ` Stephan Mueller
2015-07-21 22:13 ` [PATCH 3/3] crypto: algif_akcipher - enable compilation Stephan Mueller
2015-07-22 1:32 ` [PATCH 0/3] AF_ALG interface for akcipher Herbert Xu
2015-07-22 4:19 ` Tadeusz Struk
2015-07-22 4:21 ` Herbert Xu
2015-07-22 11:58 ` Horia Geantă
2015-07-23 1:53 ` Herbert Xu
2015-07-23 5:14 ` Tadeusz Struk [this message]
2015-07-23 5:19 ` Herbert Xu
2015-07-23 10:16 ` Stephan Mueller
2015-07-22 7:14 ` Stephan Mueller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55B07836.5050307@intel.com \
--to=tadeusz.struk@intel.com \
--cc=herbert@gondor.apana.org.au \
--cc=horia.geanta@freescale.com \
--cc=linux-crypto@vger.kernel.org \
--cc=smueller@chronox.de \
--cc=tudor.ambarus@freescale.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.