Re: [PATCH v2 1/4] scatterlist: Introduce some helper functions

2016-04-05 Thread Baolin Wang
Hi Robert,

Sorry for the late reply.

On 2 April 2016 at 23:00, Robert Jarzmik  wrote:
> Baolin Wang  writes:
>
>> +/**
>> + * sg_is_contiguous - Check if the scatterlists are contiguous
>> + * @sga: SG entry
>> + * @sgb: SG entry
>> + *
>> + * Description:
>> + *   If the sga scatterlist is contiguous with the sgb scatterlist,
>> + *   that means they can be merged together.
>> + *
>> + **/
>> +static inline bool sg_is_contiguous(struct scatterlist *sga,
>> + struct scatterlist *sgb)
>> +{
>> + return *(unsigned long *)sg_virt(sga) + sga->length ==
>> + *(unsigned long *)sg_virt(sgb);
> As I already said, I don't like casts.

OK. Could you give me a good example. Thanks.

>
> But let's take some height : you're needing this function to decide to merge
> scatterlists. That means that you think the probability of having 2 
> scatterlist
> mergeable is not meaningless, ie. 50% or more.
>
> I suppose your scatterlists are allocated through kmalloc(). I'd like to know,
> through your testing, what is the success rate of sg_is_contiguous(), ie. I'd
> like to know how many times sg_is_contiguous() was called, and amongst these
> calls how many times it returned true.
>
> That will tell me how "worth" is this optimization.

I think this is just one useful API for users, If the rate is only 1%,
we also need to check if they are contiguous to decide if they can be
coalesced.

>
>> + * sg_add_sg_to_table - Add one scatterlist into sg table
>> + * @sgt: The sg table header to use
>> + * @src: The sg need to be added into sg table
>> + *
>> + * Description:
>> + *   The 'nents' member indicates how many mapped scatterlists has been 
>> added
>> + *   in the dynamic sg table. The 'orig_nents' member indicates the size of 
>> the
>> + *   dynamic sg table.
>> + *
>> + *   Copy one mapped @src@ scatterlist into the dynamic sg table and 
>> increase
>> + *   'nents' member.
>> + *
>> + **/
> Okay, I still believe this one is wrong, because we don't understand each 
> other.
> So let's take an example :
> sg_table = {
>  .sgl = {
> {
> .page_link = PAGE_48,
> .offset = 0,
> .length = 2048,
> .dma_address = 0x3,
> .dma_length = 4096,
> },
> {
> .page_link = PAGE_48 | 0x02,
> .offset = 2048,
> .length = 2048,
> .dma_address = 0,
> .dma_length = 0,
> },
> },
>  .nents = 1,
>  .orig_nents = 2,
> };
>
> In this example, by sheer luck the 2 scatterlist entries were physically
> contiguous, and the mapping function coallesced the 2 entries into only one
> (dma_address, dma_length) entry. That could also happen with an IOMMU by the
> way.  Therefore, sg_table.nents = 1.
>
> If I understand your function correctly, it will erase sg_table.sgl[1], and 
> that
> looks incorrect to me. This is why I can't understand how your code can be
> correct, and why I say you add a new "meaning" to sg_table->nents, which is 
> not
> consistent with the meaning I understand.

I think you misunderstood my point. The 'sg_add_sg_to_table()'
function is used to add one mapped scatterlist into the dynamic sg
table. For example:
1. How to add one mapped sg into dynamic sg table
(1) If we allocate one dynamic sg table with 3 (small size can be
showed easily) empty scatterlists.:
sg_table = {
  .sgl = {
 {
 .page_link = 0,
 .offset = 0,
 .length = 0,
 },
 {
 .page_link = 0,
 .offset = 0,
 .length = 0,
 },
 {
 .page_link = 0 | 0x02,
 .offset = 0,
 .length = 0,
 },
 },
  .nents = 0,
  .orig_nents = 3,
 };

(2) If some module (like dm-crypt module) always sends one mapped
scatterlist (size is always 512bytes) to another module (crypto
driver) to handle the mapped scatterlist at one time. But we want to
collect the mapped scatterlist into one dynamic sg table to manage
them together, means we can send multiple mapped scatterlists (from
sg_table->sgl) to the crypto driver to handle them together to improve
its efficiency. So we add one mapped scatterlists into the dynamic sg
table.
mapped sg = {
  .page_link = PAGE_20,
  .offset = 0,
  .length = 512,
},

Add into synamic sg table --->
sg_table = {
  .sgl = {
 {
 .page_link = PAGE_20 | 0x02,
 .offset = 0,
 .length = 512,
 },
 {
   

RE: gcm.c:undefined reference to `crypto_aead_setauthsize'

2016-04-05 Thread Li, Philip


> -Original Message-
> From: Herbert Xu [mailto:herb...@gondor.apana.org.au]
> Sent: Monday, April 4, 2016 10:00 PM
> To: Wu, Fengguang 
> Cc: Sabrina Dubroca ; kbuild-...@01.org;
> linux-ker...@vger.kernel.org; Hannes Frederic Sowa
> ; Linux Crypto Mailing List
> 
> Subject: Re: gcm.c:undefined reference to `crypto_aead_setauthsize'
> 
> On Fri, Apr 01, 2016 at 03:02:30PM +, kbuild test robot wrote:
> > tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> master
> > head:   6ddf37da05cd71bf9e43349d607e810b43c9008a
> > commit: c09440f7dcb304002dfced8c0fea289eb25f2da0 macsec: introduce
> IEEE 802.1AE driver
> > date:   3 weeks ago
> > config: x86_64-randconfig-s3-04012139 (attached as .config)
> > reproduce:
> > git checkout c09440f7dcb304002dfced8c0fea289eb25f2da0
> > # save the attached .config to linux build tree
> > make ARCH=x86_64
> >
> > All errors (new ones prefixed by >>):
> >
> >crypto/built-in.o: In function `gcm_enc_copy_hash':
> > >> gcm.c:(.text+0x278): undefined reference to `crypto_xor'
> 
> GCM is y but AEAD is only m, yet GCM selects AEAD.  Perhaps a kbuild bug?
Thanks Herbert, currently we use make randconfig to generate this kconfig file, 
is it possible this is still a valid settings?

> 
> Cheers,
> --
> Email: Herbert Xu  Home Page:
> http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: gcm.c:undefined reference to `crypto_aead_setauthsize'

2016-04-05 Thread Herbert Xu
On Tue, Apr 05, 2016 at 07:15:21AM +, Li, Philip wrote:
> 
> 
> > -Original Message-
> > From: Herbert Xu [mailto:herb...@gondor.apana.org.au]
> > Sent: Monday, April 4, 2016 10:00 PM
> > To: Wu, Fengguang 
> > Cc: Sabrina Dubroca ; kbuild-...@01.org;
> > linux-ker...@vger.kernel.org; Hannes Frederic Sowa
> > ; Linux Crypto Mailing List
> > 
> > Subject: Re: gcm.c:undefined reference to `crypto_aead_setauthsize'
> > 
> > On Fri, Apr 01, 2016 at 03:02:30PM +, kbuild test robot wrote:
> > > tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> > master
> > > head:   6ddf37da05cd71bf9e43349d607e810b43c9008a
> > > commit: c09440f7dcb304002dfced8c0fea289eb25f2da0 macsec: introduce
> > IEEE 802.1AE driver
> > > date:   3 weeks ago
> > > config: x86_64-randconfig-s3-04012139 (attached as .config)
> > > reproduce:
> > > git checkout c09440f7dcb304002dfced8c0fea289eb25f2da0
> > > # save the attached .config to linux build tree
> > > make ARCH=x86_64
> > >
> > > All errors (new ones prefixed by >>):
> > >
> > >crypto/built-in.o: In function `gcm_enc_copy_hash':
> > > >> gcm.c:(.text+0x278): undefined reference to `crypto_xor'
> > 
> > GCM is y but AEAD is only m, yet GCM selects AEAD.  Perhaps a kbuild bug?
> Thanks Herbert, currently we use make randconfig to generate this kconfig 
> file, is it possible this is still a valid settings?

Sorry I didn't mean kbuild as in your build system, but kbuild as in
the kernel kbuild subsystem.

AFAICS, the Kconfig rules should forbid the situation in your
config file where GCM=y but AEAD=m because GCM selects AEAD.  So
the fact that it happened either means that there is something
that I am missing or that the kbuild subsystem is buggy.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH V2] crypto: implement DH primitives under akcipher API

2016-04-05 Thread Herbert Xu
On Thu, Mar 03, 2016 at 08:23:48AM -0800, Marcel Holtmann wrote:
> Hi Salvatore,
> 
> > Implement Diffie-Hellman primitives required by the scheme under the
> > akcipher API. Here is how it works.
> > 1) Call set_pub_key() by passing DH parameters (p,g) in PKCS3 format
> > 2) Call set_priv_key() to set your own private key (xa) in raw format
> > 3) Call decrypt() without passing any data as input to get back the
> >   public part which will be computed as g^xa mod p
> > 4) Call encrypt() by passing the counter part public key (yb) in raw format
> >   as input to get back the shared secret calculated as zz = yb^xa mod p
> 
> I am still not convinced that akcipher is good match for key exchange 
> methods. I think we should try to introduce a new abstraction here.
> 
> Overloading set_pub_key() with DH params and using decrypt() for 
> private/public key pair generation seems not a good fit. It does not really 
> match.
> 
> And as I said before, we know for certain that ECDH has to happen as well. So 
> we need to forward look into making that fit as well.

I agree that akcipher is poor choice for this.  If we are going
to add DH to the crypto API then it should be of its own type.

But before we even go there what does the hardware acceleration
actually look like?

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 0/3] crypto: af_alg - add TLS type encryption

2016-04-05 Thread Herbert Xu
On Sat, Mar 05, 2016 at 05:20:44PM -0800, Tadeusz Struk wrote:
> Hi,
> The following series adds TLS type authentication. To do this a new
> template, encauth, is introduced. It is derived from the existing authenc
> template and modified to work in "first auth then encrypt" mode.
> The algif interface is also changed to work with the new authentication type.

What is the point of this patch-set? Who is going to be the user?

Also you're including padding into the algorithm.  That goes against
the way we implemented IPsec.  What is the justification for doing
it in the crypto layer instead of the protocol layer?

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Asymmetric ciphers: counter measures

2016-04-05 Thread Herbert Xu
On Wed, Feb 24, 2016 at 12:27:03PM +0100, Stephan Mueller wrote:
> 
> Currently RSA does not implement anything and is even susceptible to timing 
> attacks if I see that right as the leading zeros are stripped. In addition to 

We should certainly fix this by not stripping the zeroes.

> the leading zeroes problem, blinding comes to mind. If we do blinding, what 
> type of blinding is sufficient for a fallback (base, exponent, modulus)?

It's not just a fallback.  If we ever export this to user-space this
may become a primary implementation.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 2/7] crypto: sha256-mb - SHA256 multibuffer job manager and glue code

2016-04-05 Thread Herbert Xu
On Thu, Mar 24, 2016 at 01:25:58PM -0700, megha@linux.intel.com wrote:
> From: Megha Dey 
> 
> This patch introduces the multi-buffer job manager which is responsible for
> submitting scatter-gather buffers from several SHA256 jobs to the
> multi-buffer algorithm. It also contains the flush routine to that's
> called by the crypto daemon to complete the job when no new jobs arrive
> before the deadline of maximum latency of a SHA256 crypto job.
> 
> The SHA256 multi-buffer crypto algorithm is defined and initialized in
> this patch.
> 
> Signed-off-by: Megha Dey 
> Reviewed-by: Fenghua Yu 
> Reviewed-by: Tim Chen 

sha1-mb still has the same issues that I complained about for the
aes-mb submission.  In particular, I don't like the use of shash
to handle what is really an async implmentation.

So I'd like to see this fixed first before we add any more copies
of this code.

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: crash in ppc4xx-rng on canyonland

2016-04-05 Thread Herbert Xu
Christian Lamparter  wrote:
>
> The crash is caused by a bad read in ppc4xx_rng_enable [0]. From what I
> can tell, the driver is mapping the crypto control registers. The
> problem is that they are claimed by the main crypto driver: crypto4xx [1].
> 
> I'm not sure what to do in this case. In my opinion the crypto4xx driver
> should just initialize the trng [see patch]. I would like to move the
> trng into the crypto-ppc4xx, but given that this breaks some of the DTS
> out there I'm not sure.

I think you'll also need to ensure that the crypto module is
successfully loaded before the RNG is accessed.

It's probably easier to just merge the two drivers but still
maintaining the original driver names.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] hwrng: bcm63xx - fix device tree compilation

2016-04-05 Thread Herbert Xu
On Sun, Apr 03, 2016 at 02:18:22PM +0200, Álvaro Fernández Rojas wrote:
> Adds missing include that resulted in implicit device tree functions errors.
> 
> Fixes: 7b651706712b ("hwrng: bcm63xx - add device tree support")
> Signed-off-by: Álvaro Fernández Rojas 

Applied.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 3/4] crypto: add CONFIG_ symbol for rsa helper

2016-04-05 Thread Herbert Xu
On Wed, Mar 23, 2016 at 05:04:18PM +0200, Tudor Ambarus wrote:
> All RSA implementations can now use the key extract symbols
> by selecting CRYPTO_RSA_HELPER.
> 
> Signed-off-by: Tudor Ambarus 

Please don't.  Just keep it in the generic rsa module and have
the drivers depend on that instead.

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v3] crypto: af_alg - add async support to algif_aead

2016-04-05 Thread Herbert Xu
On Fri, Mar 11, 2016 at 11:50:33AM -0800, Tadeusz Struk wrote:
> Following the async change for algif_skcipher
> this patch adds similar async read to algif_aead.
> 
> changes in v3:
> - add call to aead_reset_ctx directly from aead_put_sgl instead of calling
>   them separatelly one after the other
> - remove wait from aead_sock_destruct function as it is not needed
>   when sock_hold is used
> 
> changes in v2:
> - change internal data structures from fixed size arrays, limited to
>   RSGL_MAX_ENTRIES, to linked list model with no artificial limitation.
> - use sock_kmalloc instead of kmalloc for memory allocation
> - use sock_hold instead of separate atomic ctr to wait for outstanding
>   request
> 
> Signed-off-by: Tadeusz Struk 

Applied.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] crypto: Improve wording for CRYPTO_DEV_OMAP_DES in Kconfig

2016-04-05 Thread Herbert Xu
On Sun, Mar 13, 2016 at 04:15:37PM +0100, Peter Meerwald wrote:
> Signed-off-by: Peter Meerwald 

Applied.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 1/4] hwrng: exynos - Runtime suspend device after init

2016-04-05 Thread Herbert Xu
On Mon, Mar 14, 2016 at 09:07:12AM +0900, Krzysztof Kozlowski wrote:
> The driver uses pm_runtime_put_noidle() after initialization so the
> device might remain in active state if the core does not read from it
> (the read callback contains regular runtime put). The put_noidle() was
> chosen probably to avoid unneeded suspend and resume cycle after the
> initialization.
> 
> However for this purpose autosuspend is enabled so it is safe to runtime
> put just after the initialization.
> 
> Signed-off-by: Krzysztof Kozlowski 

All applied.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] crypto: n2 - Remove return statement from void function

2016-04-05 Thread Herbert Xu
On Fri, Mar 18, 2016 at 07:08:48PM +0530, Amitoj Kaur Chawla wrote:
> Return statement at the end of a void function is useless.
> 
> The Coccinelle semantic patch used to make this change is as follows:
> //
> @@
> identifier f;
> expression e;
> @@
> void f(...) {
> <...
> - return
>   e;
> ...>
> }
> //
> 
> Signed-off-by: Amitoj Kaur Chawla 

Applied.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] PKCS#7: fix missing break on OID_sha224 case

2016-04-05 Thread Herbert Xu
On Fri, Mar 18, 2016 at 03:51:31PM +, Colin King wrote:
> From: Colin Ian King 
> 
> The OID_sha224 case is missing a break and it falls through
> to the -ENOPKG error default.  Since HASH_ALGO_SHA224 seems
> to be supported, this looks like an unintentional missing break.
> 
> Fixes: 07f081fb5057 ("PKCS#7: Add OIDs for sha224, sha284 and sha512 hash 
> algos and use them")
> Cc:  # 4.2+
> Signed-off-by: Colin Ian King 

Applied.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v3 1/3] crypto: s5p-sss - Minor coding cleanups

2016-04-05 Thread Herbert Xu
On Tue, Mar 22, 2016 at 10:58:23AM +0900, Krzysztof Kozlowski wrote:
> From: Krzysztof Kozlowski 
> 
> Remove unneeded inclusion of delay.h and get rid of indentation from
> labels.
> 
> Signed-off-by: Krzysztof Kozlowski 
> Acked-by: Vladimir Zapolskiy 

All applied.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [patch] crypto: marvell/cesa - remove unneeded condition

2016-04-05 Thread Herbert Xu
On Mon, Mar 21, 2016 at 12:03:43PM +0300, Dan Carpenter wrote:
> creq->cache[] is an array inside the struct, it's not a pointer and it
> can't be NULL.
> 
> Signed-off-by: Dan Carpenter 

Applied.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] MAINTAINERS: Add a new maintainer for the CCP driver

2016-04-05 Thread Herbert Xu
On Mon, Mar 21, 2016 at 11:43:22AM -0500, Tom Lendacky wrote:
> Gary will be taking over future development of the CCP driver, so add
> him as a co-maintainer of the driver.
> 
> Signed-off-by: Tom Lendacky 

Applied.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v3 00/14] lib/mpi: bug fixes and cleanup

2016-04-05 Thread Herbert Xu
On Tue, Mar 22, 2016 at 01:12:34PM +0100, Nicolai Stange wrote:
> Former v2 can be found here:
> 
>   
> http://lkml.kernel.org/g/1458566775-5239-1-git-send-email-nicsta...@gmail.com
> 
> 
> This v3 series incorporates a fix to the pointer arithmetic issue in v2's
> [8/14] ("lib/mpi: mpi_read_buffer(): fix buffer overflow") spotted by
> Tadeusz Struk.
> 
> The rest, that is [1-7,9-14/14], go unchanged and have got a
> 
>   Tested-by: Tadeusz Struk 
> 
> already.
> 
> 
> Applicable to linux-next-20160322.

All applied.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] crypto: qat - make sure const_tab is 1024 bytes aligned

2016-04-05 Thread Herbert Xu
On Tue, Mar 22, 2016 at 10:45:25AM -0700, Tadeusz Struk wrote:
> FW requires the const_tab to be 1024 bytes aligned.
> 
> Signed-off-by: Tadeusz Struk 

Applied.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 0/2] crypto: qat fixes

2016-04-05 Thread Herbert Xu
On Wed, Mar 23, 2016 at 05:06:38PM +0200, Tudor Ambarus wrote:
> Initial patch set can be found here:
> http://www.mail-archive.com/linux-crypto@vger.kernel.org/msg18185.html
> 
> This patch set is no longer related to the generalized ASN.1 parser.
> Tadeusz will remove the ASN.1 parser from qat.
> 
> No changes from initial patch set.

All applied.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] crypto: qat - Remove redundant nrbg rings

2016-04-05 Thread Herbert Xu
On Tue, Mar 22, 2016 at 11:25:21AM -0700, Tadeusz Struk wrote:
> From: Ahsan Atta 
> 
> Remove redundant nrbg rings.
> 
> Signed-off-by: Ahsan Atta 
> Signed-off-by: Tadeusz Struk 

Applied.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] crypto: qat - explicitly stop all VFs first

2016-04-05 Thread Herbert Xu
On Tue, Mar 29, 2016 at 10:20:52AM -0700, Tadeusz Struk wrote:
> When stopping devices it is not enought to loop backwards.
> We need to explicitly stop all VFs first.
> 
> Signed-off-by: Tadeusz Struk 

Applied.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH RESEND] crypto: sun4i-ss: Replace spinlock_bh by spin_lock_irq{save|restore}

2016-04-05 Thread Herbert Xu
On Wed, Mar 23, 2016 at 04:11:24PM +0100, LABBE Corentin wrote:
> The current sun4i-ss driver could generate data corruption when 
> ciphering/deciphering.
> It occurs randomly on end of handled data.
> No root cause have been found and the only way to remove it is to replace
> all spin_lock_bh by their irq counterparts.
> 
> Fixes: 6298e948215f ("crypto: sunxi-ss - Add Allwinner Security System crypto 
> accelerator")
> Signed-off-by: LABBE Corentin 
> Cc: stable 

Applied.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] crypto: drbg - set HMAC key only when altered

2016-04-05 Thread Herbert Xu
On Mon, Mar 28, 2016 at 04:47:55PM +0200, Stephan Mueller wrote:
> The HMAC implementation allows setting the HMAC key independently from
> the hashing operation. Therefore, the key only needs to be set when a
> new key is generated.
> 
> This patch increases the speed of the HMAC DRBG by at least 35% depending
> on the use case.
> 
> The patch is fully CAVS tested.
> 
> Signed-off-by: Stephan Mueller 

Applied.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] crypto: qat - changed adf_dev_stop to void

2016-04-05 Thread Herbert Xu
On Tue, Mar 29, 2016 at 10:21:07AM -0700, Tadeusz Struk wrote:
> It returns always zero anyway.
> 
> Signed-off-by: Tadeusz Struk 

Applied.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v3 00/14] lib/mpi: bug fixes and cleanup

2016-04-05 Thread Nicolai Stange
Herbert Xu  writes:

> On Tue, Mar 22, 2016 at 01:12:34PM +0100, Nicolai Stange wrote:
>> Former v2 can be found here:
>> 
>>   
>> http://lkml.kernel.org/g/1458566775-5239-1-git-send-email-nicsta...@gmail.com
>> 
>> 
>> This v3 series incorporates a fix to the pointer arithmetic issue in v2's
>> [8/14] ("lib/mpi: mpi_read_buffer(): fix buffer overflow") spotted by
>> Tadeusz Struk.
>> 
>> The rest, that is [1-7,9-14/14], go unchanged and have got a
>> 
>>   Tested-by: Tadeusz Struk 
>> 
>> already.
>> 
>> 
>> Applicable to linux-next-20160322.
>
> All applied.

Thank you very much :)
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] hwrng: exynos - Fix misspelled Samsung address

2016-04-05 Thread Herbert Xu
On Tue, Apr 05, 2016 at 11:04:28AM +0900, Krzysztof Kozlowski wrote:
> Correct smasung.com into samsung.com.
> 
> Signed-off-by: Krzysztof Kozlowski 

Applied.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[patch] crypto,ccp: Fix RT breaking #include

2016-04-05 Thread Mike Galbraith

Direct include of rwlock_types.h breaks RT, use spinlock_types.h instead.

Fixes: 553d2374db0b crypto: ccp - Support for multiple CCPs
Signed-off-by: Mike Galbraith 
---
 drivers/crypto/ccp/ccp-dev.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/crypto/ccp/ccp-dev.c
+++ b/drivers/crypto/ccp/ccp-dev.c
@@ -16,7 +16,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] crypto: ccp - Register the CCP as a DMA resource

2016-04-05 Thread Gary R Hook



On 04/04/2016 04:47 PM, Tom Lendacky wrote:

On 04/04/2016 03:50 PM, Gary R Hook wrote:

The CCP has the ability to provide DMA services to the
kernel using pass-through mode of the device. Register
these services as general purpose DMA channels.
---

You're missing a cc: to David Miller, be sure to check who
should be included when emailing.

D'oh! Of course.

  drivers/crypto/ccp/Kconfig |1
  drivers/crypto/ccp/Makefile|6
  drivers/crypto/ccp/ccp-dev-v3.c|   13 +
  drivers/crypto/ccp/ccp-dev.h   |   49 ++
  drivers/crypto/ccp/ccp-dmaengine.c |  718 
  drivers/crypto/ccp/ccp-ops.c   |   77 
  6 files changed, 856 insertions(+), 8 deletions(-)
  create mode 100644 drivers/crypto/ccp/ccp-dmaengine.c

For some reason the diffstat is missing include/linux/ccp.h


Ack.


  
@@ -408,11 +408,19 @@ static int ccp_init(struct ccp_device *ccp)
  
  	ccp_add_device(ccp);
  
+	/* Register the DMA engine support */

+   ret = ccp_dmaengine_register(ccp);
+   if (ret)
+   goto e_hwrng;
+

This either needs to be before ccp_add_device() or you need to
remove the device in the error path.

Ack. Device registration should be the final step.

/* Enable interrupts */
iowrite32(qim, ccp->io_regs + IRQ_MASK_REG);
  
  	return 0;
  
+e_hwrng:

+   hwrng_unregister(&ccp->hwrng);
+
  e_kthread:
for (i = 0; i < ccp->cmd_q_count; i++)
if (ccp->cmd_q[i].kthread)
@@ -436,6 +444,9 @@ static void ccp_destroy(struct ccp_device *ccp)
/* Remove this device from the list of available units first */
ccp_del_device(ccp);
  
+	/* Unregister the DMA engine */

+   ccp_dmaengine_unregister(ccp);
+
/* Unregister the RNG */
hwrng_unregister(&ccp->hwrng);
  
diff --git a/drivers/crypto/ccp/ccp-dev.h b/drivers/crypto/ccp/ccp-dev.h

index 7745d0b..aa447a7 100644
--- a/drivers/crypto/ccp/ccp-dev.h
+++ b/drivers/crypto/ccp/ccp-dev.h
@@ -22,9 +22,12 @@
  #include 
  #include 
  #include 
+#include 
+#include 
+#include 
  
  #define MAX_CCP_NAME_LEN		16

-#define MAX_DMAPOOL_NAME_LEN   32
+#define MAX_DMA_NAME_LEN   40

Any reason this needed to be increased to 40? Though this change
may not be needed based on comment below.

This will be removed, per the comment below.



diff --git a/drivers/crypto/ccp/ccp-dmaengine.c 
b/drivers/crypto/ccp/ccp-dmaengine.c
new file mode 100644
index 000..241ad8a
--- /dev/null
+++ b/drivers/crypto/ccp/ccp-dmaengine.c
@@ -0,0 +1,718 @@
+/*
+ * AMD Cryptographic Coprocessor (CCP) driver
+ *
+ * Copyright (C) 2015 Advanced Micro Devices, Inc.

2016.


+ *
+ * Author: Tom Lendacky 

This should be your name.

Ack.

...


+int ccp_dmaengine_register(struct ccp_device *ccp)
+{
+   struct ccp_dma_chan *chan;
+   struct dma_device *dma_dev = &ccp->dma_dev;
+   struct dma_chan *dma_chan;
+   char dma_cache_name[MAX_DMA_NAME_LEN];

This can't be a local function variable.  You'll need to allocate
memory for the cache names and track them (or use devm_kasprintf).
While kmem_cache_create() dups the string, a path down to 
sysfs_slab_alias() shows that the pointer is saved elsewhere. 
devm_kasprintf() will be used to build the cache name string.




diff --git a/drivers/crypto/ccp/ccp-ops.c b/drivers/crypto/ccp/ccp-ops.c
index eefdf59..3467a1e 100644
--- a/drivers/crypto/ccp/ccp-ops.c
+++ b/drivers/crypto/ccp/ccp-ops.c
@@ -1311,7 +1311,7 @@ static int ccp_run_passthru_cmd(struct ccp_cmd_queue 
*cmd_q,
if (!pt->final && (pt->src_len & (CCP_PASSTHRU_BLOCKSIZE - 1)))
return -EINVAL;
  
-	if (!pt->src || !pt->dst)

+   if (!pt->src_sg || !pt->dst_sg)
No reason to change this in this patch. If you're trying to distinguish
between sg and dma addr because of the new passthru function you should
change the src and dst name in the new function - src_dma / dst_dma.

Done.


--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v2] crypto: ccp - Register the CCP as a DMA resource

2016-04-05 Thread Gary R Hook
The CCP has the ability to provide DMA services to the
kernel using pass-through mode of the device. Register
these services as general purpose DMA channels.
---
 drivers/crypto/ccp/Kconfig |1 
 drivers/crypto/ccp/Makefile|6 
 drivers/crypto/ccp/ccp-dev-v3.c|   11 +
 drivers/crypto/ccp/ccp-dev.h   |   47 ++
 drivers/crypto/ccp/ccp-dmaengine.c |  727 
 drivers/crypto/ccp/ccp-ops.c   |   69 +++
 include/linux/ccp.h|   36 ++
 7 files changed, 893 insertions(+), 4 deletions(-)
 create mode 100644 drivers/crypto/ccp/ccp-dmaengine.c

diff --git a/drivers/crypto/ccp/Kconfig b/drivers/crypto/ccp/Kconfig
index 6e37845..79cabfb 100644
--- a/drivers/crypto/ccp/Kconfig
+++ b/drivers/crypto/ccp/Kconfig
@@ -3,6 +3,7 @@ config CRYPTO_DEV_CCP_DD
depends on CRYPTO_DEV_CCP
default m
select HW_RANDOM
+   select DMA_ENGINE
select CRYPTO_SHA1
select CRYPTO_SHA256
help
diff --git a/drivers/crypto/ccp/Makefile b/drivers/crypto/ccp/Makefile
index b750592..ee4d274 100644
--- a/drivers/crypto/ccp/Makefile
+++ b/drivers/crypto/ccp/Makefile
@@ -1,5 +1,9 @@
 obj-$(CONFIG_CRYPTO_DEV_CCP_DD) += ccp.o
-ccp-objs := ccp-dev.o ccp-ops.o ccp-dev-v3.o ccp-platform.o
+ccp-objs := ccp-dev.o \
+   ccp-ops.o \
+   ccp-dev-v3.o \
+   ccp-platform.o \
+   ccp-dmaengine.o
 ccp-$(CONFIG_PCI) += ccp-pci.o
 
 obj-$(CONFIG_CRYPTO_DEV_CCP_CRYPTO) += ccp-crypto.o
diff --git a/drivers/crypto/ccp/ccp-dev-v3.c b/drivers/crypto/ccp/ccp-dev-v3.c
index 7d5eab4..597fc50 100644
--- a/drivers/crypto/ccp/ccp-dev-v3.c
+++ b/drivers/crypto/ccp/ccp-dev-v3.c
@@ -406,6 +406,11 @@ static int ccp_init(struct ccp_device *ccp)
goto e_kthread;
}
 
+   /* Register the DMA engine support */
+   ret = ccp_dmaengine_register(ccp);
+   if (ret)
+   goto e_hwrng;
+
ccp_add_device(ccp);
 
/* Enable interrupts */
@@ -413,6 +418,9 @@ static int ccp_init(struct ccp_device *ccp)
 
return 0;
 
+e_hwrng:
+   hwrng_unregister(&ccp->hwrng);
+
 e_kthread:
for (i = 0; i < ccp->cmd_q_count; i++)
if (ccp->cmd_q[i].kthread)
@@ -436,6 +444,9 @@ static void ccp_destroy(struct ccp_device *ccp)
/* Remove this device from the list of available units first */
ccp_del_device(ccp);
 
+   /* Unregister the DMA engine */
+   ccp_dmaengine_unregister(ccp);
+
/* Unregister the RNG */
hwrng_unregister(&ccp->hwrng);
 
diff --git a/drivers/crypto/ccp/ccp-dev.h b/drivers/crypto/ccp/ccp-dev.h
index 7745d0b..5d986c9 100644
--- a/drivers/crypto/ccp/ccp-dev.h
+++ b/drivers/crypto/ccp/ccp-dev.h
@@ -22,6 +22,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 
 #define MAX_CCP_NAME_LEN   16
 #define MAX_DMAPOOL_NAME_LEN   32
@@ -167,6 +170,39 @@ extern struct ccp_vdata ccpv3;
 struct ccp_device;
 struct ccp_cmd;
 
+struct ccp_dma_cmd {
+   struct list_head entry;
+
+   struct ccp_cmd ccp_cmd;
+};
+
+struct ccp_dma_desc {
+   struct list_head entry;
+
+   struct ccp_device *ccp;
+
+   struct list_head pending;
+   struct list_head active;
+
+   enum dma_status status;
+   struct dma_async_tx_descriptor tx_desc;
+   size_t len;
+};
+
+struct ccp_dma_chan {
+   struct ccp_device *ccp;
+
+   spinlock_t lock;
+   struct list_head pending;
+   struct list_head active;
+   struct list_head complete;
+
+   struct tasklet_struct cleanup_tasklet;
+
+   enum dma_status status;
+   struct dma_chan dma_chan;
+};
+
 struct ccp_cmd_queue {
struct ccp_device *ccp;
 
@@ -261,6 +297,14 @@ struct ccp_device {
unsigned int hwrng_retries;
 
/*
+* Support for the CCP DMA capabilities
+*/
+   struct dma_device dma_dev;
+   struct ccp_dma_chan *ccp_dma_chan;
+   struct kmem_cache *dma_cmd_cache;
+   struct kmem_cache *dma_desc_cache;
+
+   /*
 * A counter used to generate job-ids for cmds submitted to the CCP
 */
atomic_t current_id cacheline_aligned;
@@ -418,4 +462,7 @@ int ccp_cmd_queue_thread(void *data);
 
 int ccp_run_cmd(struct ccp_cmd_queue *cmd_q, struct ccp_cmd *cmd);
 
+int ccp_dmaengine_register(struct ccp_device *ccp);
+void ccp_dmaengine_unregister(struct ccp_device *ccp);
+
 #endif
diff --git a/drivers/crypto/ccp/ccp-dmaengine.c 
b/drivers/crypto/ccp/ccp-dmaengine.c
new file mode 100644
index 000..94f77b0
--- /dev/null
+++ b/drivers/crypto/ccp/ccp-dmaengine.c
@@ -0,0 +1,727 @@
+/*
+ * AMD Cryptographic Coprocessor (CCP) driver
+ *
+ * Copyright (C) 2016 Advanced Micro Devices, Inc.
+ *
+ * Author: Gary R Hook 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#inc