* Re: [PATCH 2/4] crypto: omap-sham: Add OMAP5/AM43XX SHAM Support
From: Mark Rutland @ 2013-08-09 15:31 UTC (permalink / raw)
To: Lokesh Vutla
Cc: linux-crypto@vger.kernel.org, linux-omap@vger.kernel.org,
joelf@ti.com, rnayak@ti.com, nsekhar@ti.com,
herbert@gondor.hengli.com.au, davem@davemloft.net,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <1374821957-30141-3-git-send-email-lokeshvutla@ti.com>
On Fri, Jul 26, 2013 at 07:59:15AM +0100, Lokesh Vutla wrote:
> Add support for the OMAP5 version of the SHAM module
> that is present on OMAP5 and AM43xx SoCs.
>
> This module is very simialar to OMAP4 version of SHAM module,
> and adds SHA384 SHA512 hardware-accelerated hash functions to it.
> To handle the higher digest size of SHA512, few SHA512_DIGEST_i
> (i=1-16, and first 8 registers are duplicated from SHA_DIGEST_i
> registers) registers are added at the end of register set.
> So adding the above register offsets and module info in pdata.
>
> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
> ---
> drivers/crypto/omap-sham.c | 44 ++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 44 insertions(+)
>
> + {
> + .compatible = "ti,omap5-sham",
> + .data = &omap_sham_pdata_omap5,
> + },
No binding update?
Mark.
^ permalink raw reply
* Re: Questions about the Crypto API
From: Herbert Xu @ 2013-08-10 1:15 UTC (permalink / raw)
To: Hsieh, Che-Min
Cc: Marcelo Cerri, Garg Vakul-B16394, linux-crypto@vger.kernel.org
In-Reply-To: <A83C99F8370D4D42BEB2D2B3153A6BBC23D55A6E@NASANEXD02C.na.qualcomm.com>
On Fri, Aug 09, 2013 at 01:09:12PM +0000, Hsieh, Che-Min wrote:
> Marcelo/Herbert:
>
> I believe It is. Herbert, please correct me if I am wrong.
> A single tfm is used as a user context to crypto, so to speak. But a user is not a thread.
> Let us use ipsec as example.
> For each security association (SA), it will take up a tfm.
> Assume I have IP sec setup between my local host and remote host. I might have two SA's, one for each direction.
> Now, I might run ping. Simultaneously, I might run iperf. I might run a lot of different things between these two ip hosts.
> But only two tfm's are involved.
> I have seen this happening in our system with ipsec setup as described above.
> While an async request is outstanding in the driver, another request is issued to the same driver for the same tfm.
Yes you're absolutely right.
Unless I've misunderstood Marcelo's question is different from
what Garg was asking.
Marcelo: The tfm, be it blkcipher or ablkcipher can always be used
in parallel by the user on different CPUs. For example, IPsec may
receive two packets on two CPUs through the same SA, in which case
decryption will be carried out in parallel.
Garg: For any tfm, blkcipher or ablkcipher, they must return results
in the order they were given. For a blkcipher which is synchronous,
this is always true by definition since we return only after the
result has been completed. For an async ablkcipher, this means that
if you receive two requests on the same CPU, then the first request
must be served and completed before the second request's completion
can be initiated.
Sorry for any confusion this might have caused.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: Questions about the Crypto API
From: Herbert Xu @ 2013-08-10 1:21 UTC (permalink / raw)
To: Hsieh, Che-Min; +Cc: Marcelo Cerri, linux-crypto@vger.kernel.org
In-Reply-To: <A83C99F8370D4D42BEB2D2B3153A6BBC23D55514@NASANEXD02C.na.qualcomm.com>
On Thu, Aug 08, 2013 at 02:04:05PM +0000, Hsieh, Che-Min wrote:
> Thanks for Marcelo and Herbert for the questions and answers.
> I have a few more questions related to the same subject of API.
>
> 1. In the crypto_async_request, is the list element available to the driver to use? I see most of drivers do "crypto_enqueue_request()" to keep track of the outstanding async requests. The only exception I have seen so far is talitos driver where they implement their FIFO to keep track the outstanding async requests.
You should use your own list element since this may interfere
with the crypto API's own queueing mechanism, if any (meaning
that even if in your particular case this field is unused by
the time you see it this may change in future).
> 2. The async driver simply returns instead of sleep. The requestor of the async request, does wait_for_completion() for the completion callback from driver. Can it be wait_for_completion_interruptible() such as testmgr.c does?
> If the sleep can be interruptible, how does driver know the request has been aborted? The request can be still in the driver queue waiting for the hw to finish execution. How is driver aware to dequeue this aborted request? If not, the link list can be corrupted and cause kernel to crash potentially.
If the requester is using the async interface then in general
the requester should not be sitting around waiting for it to
complete. See for example how we handle this in IPsec.
As for an aborted wait, the user must guarantee that any memory
associated with the request is not freed until the driver has
called the completion function. IOW we don't currently provide
a kill mechanism to the user.
Do you have a particular case where a kill mechanism would be
useful (memory corruption caused by the user freeing the request
early is just a bug)?
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* RE: Questions about the Crypto API
From: Hsieh, Che-Min @ 2013-08-10 2:15 UTC (permalink / raw)
To: Herbert Xu; +Cc: Marcelo Cerri, linux-crypto@vger.kernel.org
In-Reply-To: <20130810012128.GB6549@gondor.apana.org.au>
Thanks for Herbert response to my burning questions. Please see my follow on comments. Please correct me if my comments are not correct.
>> You should use your own list element
This is the conclusion I reached when I looked into our problem. I looked at other drivers and tailtos driver. I believe the only correct implementation is to use our own list, similar way as tailtos driver. Thanks for your confirmation.
Our problem is like the following. In our current implementation, we follow most of other drivers, (or we were lazy like rest of people, and just took easy way out :-)). We use the async request list structure, and API to maintain the outstanding requests.
We also develop a set of loadable modules, as test vehicle to test our driver. Our test module modeling after tcrypt, and testmgr, it is sitting in a loop, issuing various async request, and then wait_for_completion_interruptable().
So after issuing modprobe test_module to start a test, if I hit control C, kernel panic left to right, complaining about list broken....
>> As for an aborted wait, the user must guarantee that any memory
>> associated with the request is not freed until the driver has called the >> completion function. IOW we don't currently provide a kill mechanism >> to the user.
So the correct behavior, is, driver should not be aware of the aborted request above. It should always do completion callback. That means, after it accepts an async request (return with -EINPROGRESS), the request and the resource are guaranteed to the driver until driver finishes the requests, and do the completion callback. It is the requestor's responsibility to ensure this happening.
>> See for example how we handle this in IPsec.
Can you point to me a list of kernel module names that handle this. I can easily look into it for reference.
>> . IOW we don't currently provide a kill mechanism to the user.
Good. Tcrypt.c and Testmgr is only a bad example?
>> Do you have a particular case where a kill mechanism would be useful >> (memory corruption caused by the user freeing the request early is just >>a bug)?
I don't see a need of it. As long as the responsibility of each is well understood and observed. The crypto api to the driver is like a disk i/o request from above to a disk driver. To the driver, once it is requested, it should run to its completion. However, the driver implementation should always include a timeout function to make sure HW function properly. There is no hanging somewhere. I don't see too many people doing that (including us).
Cheers,
Chemin
-----Original Message-----
From: Herbert Xu [mailto:herbert@gondor.apana.org.au]
Sent: Friday, August 09, 2013 9:21 PM
To: Hsieh, Che-Min
Cc: Marcelo Cerri; linux-crypto@vger.kernel.org
Subject: Re: Questions about the Crypto API
On Thu, Aug 08, 2013 at 02:04:05PM +0000, Hsieh, Che-Min wrote:
> Thanks for Marcelo and Herbert for the questions and answers.
> I have a few more questions related to the same subject of API.
>
> 1. In the crypto_async_request, is the list element available to the driver to use? I see most of drivers do "crypto_enqueue_request()" to keep track of the outstanding async requests. The only exception I have seen so far is talitos driver where they implement their FIFO to keep track the outstanding async requests.
You should use your own list element since this may interfere with the crypto API's own queueing mechanism, if any (meaning that even if in your particular case this field is unused by the time you see it this may change in future).
> 2. The async driver simply returns instead of sleep. The requestor of the async request, does wait_for_completion() for the completion callback from driver. Can it be wait_for_completion_interruptible() such as testmgr.c does?
> If the sleep can be interruptible, how does driver know the request has been aborted? The request can be still in the driver queue waiting for the hw to finish execution. How is driver aware to dequeue this aborted request? If not, the link list can be corrupted and cause kernel to crash potentially.
If the requester is using the async interface then in general the requester should not be sitting around waiting for it to complete. See for example how we handle this in IPsec.
As for an aborted wait, the user must guarantee that any memory associated with the request is not freed until the driver has called the completion function. IOW we don't currently provide a kill mechanism to the user.
Do you have a particular case where a kill mechanism would be useful (memory corruption caused by the user freeing the request early is just a bug)?
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: Questions about the Crypto API
From: Herbert Xu @ 2013-08-10 6:17 UTC (permalink / raw)
To: Hsieh, Che-Min; +Cc: Marcelo Cerri, linux-crypto@vger.kernel.org
In-Reply-To: <A83C99F8370D4D42BEB2D2B3153A6BBC23D55E11@NASANEXD02C.na.qualcomm.com>
On Sat, Aug 10, 2013 at 02:15:10AM +0000, Hsieh, Che-Min wrote:
>
> >> . IOW we don't currently provide a kill mechanism to the user.
>
> Good. Tcrypt.c and Testmgr is only a bad example?
Right, they can't really do anything other than waiting so they're
not a realistic example.
For a good example, check out the IPsec implementation in
net/ipv4/esp4.c.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH 2/5] crypto/camellia_generic.c: convert comma to semicolon
From: Julia Lawall @ 2013-08-10 15:40 UTC (permalink / raw)
To: Herbert Xu
Cc: kernel-janitors, David S. Miller, linux-crypto, linux-kernel,
trivial
In-Reply-To: <1376149225-3997-1-git-send-email-Julia.Lawall@lip6.fr>
From: Julia Lawall <Julia.Lawall@lip6.fr>
Replace a comma between expression statements by a semicolon.
A simplified version of the semantic patch that performs this
transformation is as follows: (http://coccinelle.lip6.fr/)
// <smpl>
@r@
expression e1,e2,e;
type T;
identifier i;
@@
e1
-,
+;
e2;
// </smpl>
This patch is separate from the others because the code appears to be
machine-generated.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
---
crypto/camellia_generic.c | 24 ++++++++++----------
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/crypto/camellia_generic.c b/crypto/camellia_generic.c
index 75efa20..125cf16 100644
--- a/crypto/camellia_generic.c
+++ b/crypto/camellia_generic.c
@@ -388,7 +388,7 @@ static void camellia_setup_tail(u32 *subkey, u32 *subL, u32 *subR, int max)
/* round 6 */
subL[7] ^= subL[1]; subR[7] ^= subR[1];
subL[1] ^= subR[1] & ~subR[9];
- dw = subL[1] & subL[9],
+ dw = subL[1] & subL[9];
subR[1] ^= rol32(dw, 1); /* modified for FLinv(kl2) */
/* round 8 */
subL[11] ^= subL[1]; subR[11] ^= subR[1];
@@ -397,7 +397,7 @@ static void camellia_setup_tail(u32 *subkey, u32 *subL, u32 *subR, int max)
/* round 12 */
subL[15] ^= subL[1]; subR[15] ^= subR[1];
subL[1] ^= subR[1] & ~subR[17];
- dw = subL[1] & subL[17],
+ dw = subL[1] & subL[17];
subR[1] ^= rol32(dw, 1); /* modified for FLinv(kl4) */
/* round 14 */
subL[19] ^= subL[1]; subR[19] ^= subR[1];
@@ -413,7 +413,7 @@ static void camellia_setup_tail(u32 *subkey, u32 *subL, u32 *subR, int max)
kw4l = subL[25]; kw4r = subR[25];
} else {
subL[1] ^= subR[1] & ~subR[25];
- dw = subL[1] & subL[25],
+ dw = subL[1] & subL[25];
subR[1] ^= rol32(dw, 1); /* modified for FLinv(kl6) */
/* round 20 */
subL[27] ^= subL[1]; subR[27] ^= subR[1];
@@ -433,7 +433,7 @@ static void camellia_setup_tail(u32 *subkey, u32 *subL, u32 *subR, int max)
/* round 19 */
subL[26] ^= kw4l; subR[26] ^= kw4r;
kw4l ^= kw4r & ~subR[24];
- dw = kw4l & subL[24],
+ dw = kw4l & subL[24];
kw4r ^= rol32(dw, 1); /* modified for FL(kl5) */
}
/* round 17 */
@@ -443,7 +443,7 @@ static void camellia_setup_tail(u32 *subkey, u32 *subL, u32 *subR, int max)
/* round 13 */
subL[18] ^= kw4l; subR[18] ^= kw4r;
kw4l ^= kw4r & ~subR[16];
- dw = kw4l & subL[16],
+ dw = kw4l & subL[16];
kw4r ^= rol32(dw, 1); /* modified for FL(kl3) */
/* round 11 */
subL[14] ^= kw4l; subR[14] ^= kw4r;
@@ -452,7 +452,7 @@ static void camellia_setup_tail(u32 *subkey, u32 *subL, u32 *subR, int max)
/* round 7 */
subL[10] ^= kw4l; subR[10] ^= kw4r;
kw4l ^= kw4r & ~subR[8];
- dw = kw4l & subL[8],
+ dw = kw4l & subL[8];
kw4r ^= rol32(dw, 1); /* modified for FL(kl1) */
/* round 5 */
subL[6] ^= kw4l; subR[6] ^= kw4r;
@@ -477,7 +477,7 @@ static void camellia_setup_tail(u32 *subkey, u32 *subL, u32 *subR, int max)
SUBKEY_L(6) = subL[5] ^ subL[7]; /* round 5 */
SUBKEY_R(6) = subR[5] ^ subR[7];
tl = subL[10] ^ (subR[10] & ~subR[8]);
- dw = tl & subL[8], /* FL(kl1) */
+ dw = tl & subL[8]; /* FL(kl1) */
tr = subR[10] ^ rol32(dw, 1);
SUBKEY_L(7) = subL[6] ^ tl; /* round 6 */
SUBKEY_R(7) = subR[6] ^ tr;
@@ -486,7 +486,7 @@ static void camellia_setup_tail(u32 *subkey, u32 *subL, u32 *subR, int max)
SUBKEY_L(9) = subL[9]; /* FLinv(kl2) */
SUBKEY_R(9) = subR[9];
tl = subL[7] ^ (subR[7] & ~subR[9]);
- dw = tl & subL[9], /* FLinv(kl2) */
+ dw = tl & subL[9]; /* FLinv(kl2) */
tr = subR[7] ^ rol32(dw, 1);
SUBKEY_L(10) = tl ^ subL[11]; /* round 7 */
SUBKEY_R(10) = tr ^ subR[11];
@@ -499,7 +499,7 @@ static void camellia_setup_tail(u32 *subkey, u32 *subL, u32 *subR, int max)
SUBKEY_L(14) = subL[13] ^ subL[15]; /* round 11 */
SUBKEY_R(14) = subR[13] ^ subR[15];
tl = subL[18] ^ (subR[18] & ~subR[16]);
- dw = tl & subL[16], /* FL(kl3) */
+ dw = tl & subL[16]; /* FL(kl3) */
tr = subR[18] ^ rol32(dw, 1);
SUBKEY_L(15) = subL[14] ^ tl; /* round 12 */
SUBKEY_R(15) = subR[14] ^ tr;
@@ -508,7 +508,7 @@ static void camellia_setup_tail(u32 *subkey, u32 *subL, u32 *subR, int max)
SUBKEY_L(17) = subL[17]; /* FLinv(kl4) */
SUBKEY_R(17) = subR[17];
tl = subL[15] ^ (subR[15] & ~subR[17]);
- dw = tl & subL[17], /* FLinv(kl4) */
+ dw = tl & subL[17]; /* FLinv(kl4) */
tr = subR[15] ^ rol32(dw, 1);
SUBKEY_L(18) = tl ^ subL[19]; /* round 13 */
SUBKEY_R(18) = tr ^ subR[19];
@@ -527,7 +527,7 @@ static void camellia_setup_tail(u32 *subkey, u32 *subL, u32 *subR, int max)
SUBKEY_R(24) = subR[24] ^ subR[23];
} else {
tl = subL[26] ^ (subR[26] & ~subR[24]);
- dw = tl & subL[24], /* FL(kl5) */
+ dw = tl & subL[24]; /* FL(kl5) */
tr = subR[26] ^ rol32(dw, 1);
SUBKEY_L(23) = subL[22] ^ tl; /* round 18 */
SUBKEY_R(23) = subR[22] ^ tr;
@@ -536,7 +536,7 @@ static void camellia_setup_tail(u32 *subkey, u32 *subL, u32 *subR, int max)
SUBKEY_L(25) = subL[25]; /* FLinv(kl6) */
SUBKEY_R(25) = subR[25];
tl = subL[23] ^ (subR[23] & ~subR[25]);
- dw = tl & subL[25], /* FLinv(kl6) */
+ dw = tl & subL[25]; /* FLinv(kl6) */
tr = subR[23] ^ rol32(dw, 1);
SUBKEY_L(26) = tl ^ subL[27]; /* round 19 */
SUBKEY_R(26) = tr ^ subR[27];
^ permalink raw reply related
* [PATCH 3/5] arch/x86/crypto/camellia_glue.c: convert comma to semicolon
From: Julia Lawall @ 2013-08-10 15:40 UTC (permalink / raw)
To: Herbert Xu
Cc: kernel-janitors, David S. Miller, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, x86, linux-crypto, linux-kernel, trivial
In-Reply-To: <1376149225-3997-1-git-send-email-Julia.Lawall@lip6.fr>
From: Julia Lawall <Julia.Lawall@lip6.fr>
Replace a comma between expression statements by a semicolon.
A simplified version of the semantic patch that performs this
transformation is as follows: (http://coccinelle.lip6.fr/)
// <smpl>
@r@
expression e1,e2,e;
type T;
identifier i;
@@
e1
-,
+;
e2;
// </smpl>
This patch is separate from the others because the source code appears to
be machine-generated.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
---
arch/x86/crypto/camellia_glue.c | 24 +++++++-------
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/x86/crypto/camellia_glue.c b/arch/x86/crypto/camellia_glue.c
index 5cb86cc..ac2b28b 100644
--- a/arch/x86/crypto/camellia_glue.c
+++ b/arch/x86/crypto/camellia_glue.c
@@ -828,7 +828,7 @@ static void camellia_setup_tail(u64 *subkey, u64 *subRL, int max)
subRL[1] ^= (subRL[1] & ~subRL[9]) << 32;
/* modified for FLinv(kl2) */
- dw = (subRL[1] & subRL[9]) >> 32,
+ dw = (subRL[1] & subRL[9]) >> 32;
subRL[1] ^= rol32(dw, 1);
/* round 8 */
@@ -840,7 +840,7 @@ static void camellia_setup_tail(u64 *subkey, u64 *subRL, int max)
subRL[1] ^= (subRL[1] & ~subRL[17]) << 32;
/* modified for FLinv(kl4) */
- dw = (subRL[1] & subRL[17]) >> 32,
+ dw = (subRL[1] & subRL[17]) >> 32;
subRL[1] ^= rol32(dw, 1);
/* round 14 */
@@ -859,7 +859,7 @@ static void camellia_setup_tail(u64 *subkey, u64 *subRL, int max)
} else {
subRL[1] ^= (subRL[1] & ~subRL[25]) << 32;
/* modified for FLinv(kl6) */
- dw = (subRL[1] & subRL[25]) >> 32,
+ dw = (subRL[1] & subRL[25]) >> 32;
subRL[1] ^= rol32(dw, 1);
/* round 20 */
@@ -882,7 +882,7 @@ static void camellia_setup_tail(u64 *subkey, u64 *subRL, int max)
kw4 ^= (kw4 & ~subRL[24]) << 32;
/* modified for FL(kl5) */
- dw = (kw4 & subRL[24]) >> 32,
+ dw = (kw4 & subRL[24]) >> 32;
kw4 ^= rol32(dw, 1);
}
@@ -895,7 +895,7 @@ static void camellia_setup_tail(u64 *subkey, u64 *subRL, int max)
kw4 ^= (kw4 & ~subRL[16]) << 32;
/* modified for FL(kl3) */
- dw = (kw4 & subRL[16]) >> 32,
+ dw = (kw4 & subRL[16]) >> 32;
kw4 ^= rol32(dw, 1);
/* round 11 */
@@ -907,7 +907,7 @@ static void camellia_setup_tail(u64 *subkey, u64 *subRL, int max)
kw4 ^= (kw4 & ~subRL[8]) << 32;
/* modified for FL(kl1) */
- dw = (kw4 & subRL[8]) >> 32,
+ dw = (kw4 & subRL[8]) >> 32;
kw4 ^= rol32(dw, 1);
/* round 5 */
@@ -928,7 +928,7 @@ static void camellia_setup_tail(u64 *subkey, u64 *subRL, int max)
SET_SUBKEY_LR(6, subRL[5] ^ subRL[7]); /* round 5 */
tl = (subRL[10] >> 32) ^ (subRL[10] & ~subRL[8]);
- dw = tl & (subRL[8] >> 32), /* FL(kl1) */
+ dw = tl & (subRL[8] >> 32); /* FL(kl1) */
tr = subRL[10] ^ rol32(dw, 1);
tt = (tr | ((u64)tl << 32));
@@ -937,7 +937,7 @@ static void camellia_setup_tail(u64 *subkey, u64 *subRL, int max)
SET_SUBKEY_LR(9, subRL[9]); /* FLinv(kl2) */
tl = (subRL[7] >> 32) ^ (subRL[7] & ~subRL[9]);
- dw = tl & (subRL[9] >> 32), /* FLinv(kl2) */
+ dw = tl & (subRL[9] >> 32); /* FLinv(kl2) */
tr = subRL[7] ^ rol32(dw, 1);
tt = (tr | ((u64)tl << 32));
@@ -948,7 +948,7 @@ static void camellia_setup_tail(u64 *subkey, u64 *subRL, int max)
SET_SUBKEY_LR(14, subRL[13] ^ subRL[15]); /* round 11 */
tl = (subRL[18] >> 32) ^ (subRL[18] & ~subRL[16]);
- dw = tl & (subRL[16] >> 32), /* FL(kl3) */
+ dw = tl & (subRL[16] >> 32); /* FL(kl3) */
tr = subRL[18] ^ rol32(dw, 1);
tt = (tr | ((u64)tl << 32));
@@ -957,7 +957,7 @@ static void camellia_setup_tail(u64 *subkey, u64 *subRL, int max)
SET_SUBKEY_LR(17, subRL[17]); /* FLinv(kl4) */
tl = (subRL[15] >> 32) ^ (subRL[15] & ~subRL[17]);
- dw = tl & (subRL[17] >> 32), /* FLinv(kl4) */
+ dw = tl & (subRL[17] >> 32); /* FLinv(kl4) */
tr = subRL[15] ^ rol32(dw, 1);
tt = (tr | ((u64)tl << 32));
@@ -972,7 +972,7 @@ static void camellia_setup_tail(u64 *subkey, u64 *subRL, int max)
SET_SUBKEY_LR(24, subRL[24] ^ subRL[23]); /* kw3 */
} else {
tl = (subRL[26] >> 32) ^ (subRL[26] & ~subRL[24]);
- dw = tl & (subRL[24] >> 32), /* FL(kl5) */
+ dw = tl & (subRL[24] >> 32); /* FL(kl5) */
tr = subRL[26] ^ rol32(dw, 1);
tt = (tr | ((u64)tl << 32));
@@ -981,7 +981,7 @@ static void camellia_setup_tail(u64 *subkey, u64 *subRL, int max)
SET_SUBKEY_LR(25, subRL[25]); /* FLinv(kl6) */
tl = (subRL[23] >> 32) ^ (subRL[23] & ~subRL[25]);
- dw = tl & (subRL[25] >> 32), /* FLinv(kl6) */
+ dw = tl & (subRL[25] >> 32); /* FLinv(kl6) */
tr = subRL[23] ^ rol32(dw, 1);
tt = (tr | ((u64)tl << 32));
^ permalink raw reply related
* Re: [PATCH 2/5] crypto/camellia_generic.c: convert comma to semicolon
From: Joe Perches @ 2013-08-10 16:19 UTC (permalink / raw)
To: Julia Lawall
Cc: Herbert Xu, kernel-janitors, David S. Miller, linux-crypto,
linux-kernel, trivial
In-Reply-To: <1376149225-3997-3-git-send-email-Julia.Lawall@lip6.fr>
On Sat, 2013-08-10 at 17:40 +0200, Julia Lawall wrote:
> Replace a comma between expression statements by a semicolon.
[]
> This patch is separate from the others because the code appears to be
> machine-generated.
It may have once been machine generated, but it's not now.
It's been modified several times by human generated patches.
> diff --git a/crypto/camellia_generic.c b/crypto/camellia_generic.c
[]
> @@ -388,7 +388,7 @@ static void camellia_setup_tail(u32 *subkey, u32 *subL, u32 *subR, int max)
[]
> - dw = subL[1] & subL[9],
> + dw = subL[1] & subL[9];
> subR[1] ^= rol32(dw, 1); /* modified for FLinv(kl2) */
Perhaps you can (auto?) fix the indentation
on the next line too?
> @@ -397,7 +397,7 @@ static void camellia_setup_tail(u32 *subkey, u32 *subL, u32 *subR, int max)
[]
> - dw = subL[1] & subL[17],
> + dw = subL[1] & subL[17];
> subR[1] ^= rol32(dw, 1); /* modified for FLinv(kl4) */
etc...
^ permalink raw reply
* Re: [PATCH 2/5] crypto/camellia_generic.c: convert comma to semicolon
From: Julia Lawall @ 2013-08-10 16:25 UTC (permalink / raw)
To: Joe Perches
Cc: Julia Lawall, Herbert Xu, kernel-janitors, David S. Miller,
linux-crypto, linux-kernel, trivial
In-Reply-To: <1376151557.2083.35.camel@joe-AO722>
On Sat, 10 Aug 2013, Joe Perches wrote:
> On Sat, 2013-08-10 at 17:40 +0200, Julia Lawall wrote:
> > Replace a comma between expression statements by a semicolon.
> []
> > This patch is separate from the others because the code appears to be
> > machine-generated.
>
> It may have once been machine generated, but it's not now.
> It's been modified several times by human generated patches.
>
> > diff --git a/crypto/camellia_generic.c b/crypto/camellia_generic.c
> []
> > @@ -388,7 +388,7 @@ static void camellia_setup_tail(u32 *subkey, u32 *subL, u32 *subR, int max)
> []
> > - dw = subL[1] & subL[9],
> > + dw = subL[1] & subL[9];
> > subR[1] ^= rol32(dw, 1); /* modified for FLinv(kl2) */
>
> Perhaps you can (auto?) fix the indentation
> on the next line too?
OK, I'll take care of it.
julia
^ permalink raw reply
* [PATCH 1/2] arch/x86/crypto/camellia_glue.c: adjust code alignment
From: Julia Lawall @ 2013-08-10 17:34 UTC (permalink / raw)
To: Herbert Xu
Cc: kernel-janitors, David S. Miller, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, x86, linux-crypto, linux-kernel, trivial
In-Reply-To: <1376156077-6208-1-git-send-email-Julia.Lawall@lip6.fr>
From: Julia Lawall <Julia.Lawall@lip6.fr>
Adjust alignment in automatically generated code. If this code
will not be regenerated in the future, it may as well look nice.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
---
This patch was generated from the result of the previous one, which
replaced commas by semicolons.
arch/x86/crypto/camellia_glue.c | 24 ++++++++++++------------
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/x86/crypto/camellia_glue.c b/arch/x86/crypto/camellia_glue.c
index ac2b28b..39aebea 100644
--- a/arch/x86/crypto/camellia_glue.c
+++ b/arch/x86/crypto/camellia_glue.c
@@ -829,7 +829,7 @@ static void camellia_setup_tail(u64 *subkey, u64 *subRL, int max)
subRL[1] ^= (subRL[1] & ~subRL[9]) << 32;
/* modified for FLinv(kl2) */
dw = (subRL[1] & subRL[9]) >> 32;
- subRL[1] ^= rol32(dw, 1);
+ subRL[1] ^= rol32(dw, 1);
/* round 8 */
subRL[11] ^= subRL[1];
@@ -841,7 +841,7 @@ static void camellia_setup_tail(u64 *subkey, u64 *subRL, int max)
subRL[1] ^= (subRL[1] & ~subRL[17]) << 32;
/* modified for FLinv(kl4) */
dw = (subRL[1] & subRL[17]) >> 32;
- subRL[1] ^= rol32(dw, 1);
+ subRL[1] ^= rol32(dw, 1);
/* round 14 */
subRL[19] ^= subRL[1];
@@ -860,7 +860,7 @@ static void camellia_setup_tail(u64 *subkey, u64 *subRL, int max)
subRL[1] ^= (subRL[1] & ~subRL[25]) << 32;
/* modified for FLinv(kl6) */
dw = (subRL[1] & subRL[25]) >> 32;
- subRL[1] ^= rol32(dw, 1);
+ subRL[1] ^= rol32(dw, 1);
/* round 20 */
subRL[27] ^= subRL[1];
@@ -883,7 +883,7 @@ static void camellia_setup_tail(u64 *subkey, u64 *subRL, int max)
kw4 ^= (kw4 & ~subRL[24]) << 32;
/* modified for FL(kl5) */
dw = (kw4 & subRL[24]) >> 32;
- kw4 ^= rol32(dw, 1);
+ kw4 ^= rol32(dw, 1);
}
/* round 17 */
@@ -896,7 +896,7 @@ static void camellia_setup_tail(u64 *subkey, u64 *subRL, int max)
kw4 ^= (kw4 & ~subRL[16]) << 32;
/* modified for FL(kl3) */
dw = (kw4 & subRL[16]) >> 32;
- kw4 ^= rol32(dw, 1);
+ kw4 ^= rol32(dw, 1);
/* round 11 */
subRL[14] ^= kw4;
@@ -908,7 +908,7 @@ static void camellia_setup_tail(u64 *subkey, u64 *subRL, int max)
kw4 ^= (kw4 & ~subRL[8]) << 32;
/* modified for FL(kl1) */
dw = (kw4 & subRL[8]) >> 32;
- kw4 ^= rol32(dw, 1);
+ kw4 ^= rol32(dw, 1);
/* round 5 */
subRL[6] ^= kw4;
@@ -929,7 +929,7 @@ static void camellia_setup_tail(u64 *subkey, u64 *subRL, int max)
tl = (subRL[10] >> 32) ^ (subRL[10] & ~subRL[8]);
dw = tl & (subRL[8] >> 32); /* FL(kl1) */
- tr = subRL[10] ^ rol32(dw, 1);
+ tr = subRL[10] ^ rol32(dw, 1);
tt = (tr | ((u64)tl << 32));
SET_SUBKEY_LR(7, subRL[6] ^ tt); /* round 6 */
@@ -938,7 +938,7 @@ static void camellia_setup_tail(u64 *subkey, u64 *subRL, int max)
tl = (subRL[7] >> 32) ^ (subRL[7] & ~subRL[9]);
dw = tl & (subRL[9] >> 32); /* FLinv(kl2) */
- tr = subRL[7] ^ rol32(dw, 1);
+ tr = subRL[7] ^ rol32(dw, 1);
tt = (tr | ((u64)tl << 32));
SET_SUBKEY_LR(10, subRL[11] ^ tt); /* round 7 */
@@ -949,7 +949,7 @@ static void camellia_setup_tail(u64 *subkey, u64 *subRL, int max)
tl = (subRL[18] >> 32) ^ (subRL[18] & ~subRL[16]);
dw = tl & (subRL[16] >> 32); /* FL(kl3) */
- tr = subRL[18] ^ rol32(dw, 1);
+ tr = subRL[18] ^ rol32(dw, 1);
tt = (tr | ((u64)tl << 32));
SET_SUBKEY_LR(15, subRL[14] ^ tt); /* round 12 */
@@ -958,7 +958,7 @@ static void camellia_setup_tail(u64 *subkey, u64 *subRL, int max)
tl = (subRL[15] >> 32) ^ (subRL[15] & ~subRL[17]);
dw = tl & (subRL[17] >> 32); /* FLinv(kl4) */
- tr = subRL[15] ^ rol32(dw, 1);
+ tr = subRL[15] ^ rol32(dw, 1);
tt = (tr | ((u64)tl << 32));
SET_SUBKEY_LR(18, subRL[19] ^ tt); /* round 13 */
@@ -973,7 +973,7 @@ static void camellia_setup_tail(u64 *subkey, u64 *subRL, int max)
} else {
tl = (subRL[26] >> 32) ^ (subRL[26] & ~subRL[24]);
dw = tl & (subRL[24] >> 32); /* FL(kl5) */
- tr = subRL[26] ^ rol32(dw, 1);
+ tr = subRL[26] ^ rol32(dw, 1);
tt = (tr | ((u64)tl << 32));
SET_SUBKEY_LR(23, subRL[22] ^ tt); /* round 18 */
@@ -982,7 +982,7 @@ static void camellia_setup_tail(u64 *subkey, u64 *subRL, int max)
tl = (subRL[23] >> 32) ^ (subRL[23] & ~subRL[25]);
dw = tl & (subRL[25] >> 32); /* FLinv(kl6) */
- tr = subRL[23] ^ rol32(dw, 1);
+ tr = subRL[23] ^ rol32(dw, 1);
tt = (tr | ((u64)tl << 32));
SET_SUBKEY_LR(26, subRL[27] ^ tt); /* round 19 */
^ permalink raw reply related
* [PATCH 2/2] crypto/camellia_generic.c: adjust code alignment
From: Julia Lawall @ 2013-08-10 17:34 UTC (permalink / raw)
To: Herbert Xu
Cc: kernel-janitors, David S. Miller, linux-crypto, linux-kernel,
trivial
In-Reply-To: <1376156077-6208-1-git-send-email-Julia.Lawall@lip6.fr>
From: Julia Lawall <Julia.Lawall@lip6.fr>
Adjust alignment in automatically generated code. If this code
will not be regenerated in the future, it may as well look nice.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
---
This patch was generated from the result of the previous one, which
replaced commas by semicolons.
crypto/camellia_generic.c | 24 ++++++++++++------------
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/crypto/camellia_generic.c b/crypto/camellia_generic.c
index 125cf16..26bcd7a 100644
--- a/crypto/camellia_generic.c
+++ b/crypto/camellia_generic.c
@@ -389,7 +389,7 @@ static void camellia_setup_tail(u32 *subkey, u32 *subL, u32 *subR, int max)
subL[7] ^= subL[1]; subR[7] ^= subR[1];
subL[1] ^= subR[1] & ~subR[9];
dw = subL[1] & subL[9];
- subR[1] ^= rol32(dw, 1); /* modified for FLinv(kl2) */
+ subR[1] ^= rol32(dw, 1); /* modified for FLinv(kl2) */
/* round 8 */
subL[11] ^= subL[1]; subR[11] ^= subR[1];
/* round 10 */
@@ -398,7 +398,7 @@ static void camellia_setup_tail(u32 *subkey, u32 *subL, u32 *subR, int max)
subL[15] ^= subL[1]; subR[15] ^= subR[1];
subL[1] ^= subR[1] & ~subR[17];
dw = subL[1] & subL[17];
- subR[1] ^= rol32(dw, 1); /* modified for FLinv(kl4) */
+ subR[1] ^= rol32(dw, 1); /* modified for FLinv(kl4) */
/* round 14 */
subL[19] ^= subL[1]; subR[19] ^= subR[1];
/* round 16 */
@@ -414,7 +414,7 @@ static void camellia_setup_tail(u32 *subkey, u32 *subL, u32 *subR, int max)
} else {
subL[1] ^= subR[1] & ~subR[25];
dw = subL[1] & subL[25];
- subR[1] ^= rol32(dw, 1); /* modified for FLinv(kl6) */
+ subR[1] ^= rol32(dw, 1); /* modified for FLinv(kl6) */
/* round 20 */
subL[27] ^= subL[1]; subR[27] ^= subR[1];
/* round 22 */
@@ -434,7 +434,7 @@ static void camellia_setup_tail(u32 *subkey, u32 *subL, u32 *subR, int max)
subL[26] ^= kw4l; subR[26] ^= kw4r;
kw4l ^= kw4r & ~subR[24];
dw = kw4l & subL[24];
- kw4r ^= rol32(dw, 1); /* modified for FL(kl5) */
+ kw4r ^= rol32(dw, 1); /* modified for FL(kl5) */
}
/* round 17 */
subL[22] ^= kw4l; subR[22] ^= kw4r;
@@ -444,7 +444,7 @@ static void camellia_setup_tail(u32 *subkey, u32 *subL, u32 *subR, int max)
subL[18] ^= kw4l; subR[18] ^= kw4r;
kw4l ^= kw4r & ~subR[16];
dw = kw4l & subL[16];
- kw4r ^= rol32(dw, 1); /* modified for FL(kl3) */
+ kw4r ^= rol32(dw, 1); /* modified for FL(kl3) */
/* round 11 */
subL[14] ^= kw4l; subR[14] ^= kw4r;
/* round 9 */
@@ -453,7 +453,7 @@ static void camellia_setup_tail(u32 *subkey, u32 *subL, u32 *subR, int max)
subL[10] ^= kw4l; subR[10] ^= kw4r;
kw4l ^= kw4r & ~subR[8];
dw = kw4l & subL[8];
- kw4r ^= rol32(dw, 1); /* modified for FL(kl1) */
+ kw4r ^= rol32(dw, 1); /* modified for FL(kl1) */
/* round 5 */
subL[6] ^= kw4l; subR[6] ^= kw4r;
/* round 3 */
@@ -478,7 +478,7 @@ static void camellia_setup_tail(u32 *subkey, u32 *subL, u32 *subR, int max)
SUBKEY_R(6) = subR[5] ^ subR[7];
tl = subL[10] ^ (subR[10] & ~subR[8]);
dw = tl & subL[8]; /* FL(kl1) */
- tr = subR[10] ^ rol32(dw, 1);
+ tr = subR[10] ^ rol32(dw, 1);
SUBKEY_L(7) = subL[6] ^ tl; /* round 6 */
SUBKEY_R(7) = subR[6] ^ tr;
SUBKEY_L(8) = subL[8]; /* FL(kl1) */
@@ -487,7 +487,7 @@ static void camellia_setup_tail(u32 *subkey, u32 *subL, u32 *subR, int max)
SUBKEY_R(9) = subR[9];
tl = subL[7] ^ (subR[7] & ~subR[9]);
dw = tl & subL[9]; /* FLinv(kl2) */
- tr = subR[7] ^ rol32(dw, 1);
+ tr = subR[7] ^ rol32(dw, 1);
SUBKEY_L(10) = tl ^ subL[11]; /* round 7 */
SUBKEY_R(10) = tr ^ subR[11];
SUBKEY_L(11) = subL[10] ^ subL[12]; /* round 8 */
@@ -500,7 +500,7 @@ static void camellia_setup_tail(u32 *subkey, u32 *subL, u32 *subR, int max)
SUBKEY_R(14) = subR[13] ^ subR[15];
tl = subL[18] ^ (subR[18] & ~subR[16]);
dw = tl & subL[16]; /* FL(kl3) */
- tr = subR[18] ^ rol32(dw, 1);
+ tr = subR[18] ^ rol32(dw, 1);
SUBKEY_L(15) = subL[14] ^ tl; /* round 12 */
SUBKEY_R(15) = subR[14] ^ tr;
SUBKEY_L(16) = subL[16]; /* FL(kl3) */
@@ -509,7 +509,7 @@ static void camellia_setup_tail(u32 *subkey, u32 *subL, u32 *subR, int max)
SUBKEY_R(17) = subR[17];
tl = subL[15] ^ (subR[15] & ~subR[17]);
dw = tl & subL[17]; /* FLinv(kl4) */
- tr = subR[15] ^ rol32(dw, 1);
+ tr = subR[15] ^ rol32(dw, 1);
SUBKEY_L(18) = tl ^ subL[19]; /* round 13 */
SUBKEY_R(18) = tr ^ subR[19];
SUBKEY_L(19) = subL[18] ^ subL[20]; /* round 14 */
@@ -528,7 +528,7 @@ static void camellia_setup_tail(u32 *subkey, u32 *subL, u32 *subR, int max)
} else {
tl = subL[26] ^ (subR[26] & ~subR[24]);
dw = tl & subL[24]; /* FL(kl5) */
- tr = subR[26] ^ rol32(dw, 1);
+ tr = subR[26] ^ rol32(dw, 1);
SUBKEY_L(23) = subL[22] ^ tl; /* round 18 */
SUBKEY_R(23) = subR[22] ^ tr;
SUBKEY_L(24) = subL[24]; /* FL(kl5) */
@@ -537,7 +537,7 @@ static void camellia_setup_tail(u32 *subkey, u32 *subL, u32 *subR, int max)
SUBKEY_R(25) = subR[25];
tl = subL[23] ^ (subR[23] & ~subR[25]);
dw = tl & subL[25]; /* FLinv(kl6) */
- tr = subR[23] ^ rol32(dw, 1);
+ tr = subR[23] ^ rol32(dw, 1);
SUBKEY_L(26) = tl ^ subL[27]; /* round 19 */
SUBKEY_R(26) = tr ^ subR[27];
SUBKEY_L(27) = subL[26] ^ subL[28]; /* round 20 */
^ permalink raw reply related
* [PATCH] crypto: make tables used from assembler __visible
From: Andi Kleen @ 2013-08-11 1:01 UTC (permalink / raw)
To: herbert; +Cc: linux-crypto, Andi Kleen
From: Andi Kleen <ak@linux.intel.com>
Tables used from assembler should be marked __visible to let
the compiler know.
Signed-off-by: Andi Kleen <ak@linux.intel.com>
---
arch/x86/crypto/camellia_glue.c | 16 ++++++++--------
crypto/aes_generic.c | 8 ++++----
crypto/cast_common.c | 8 ++++----
3 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/arch/x86/crypto/camellia_glue.c b/arch/x86/crypto/camellia_glue.c
index 5cb86cc..fa4c1b9 100644
--- a/arch/x86/crypto/camellia_glue.c
+++ b/arch/x86/crypto/camellia_glue.c
@@ -62,7 +62,7 @@ static void camellia_decrypt(struct crypto_tfm *tfm, u8 *dst, const u8 *src)
}
/* camellia sboxes */
-const u64 camellia_sp10011110[256] = {
+__visible const u64 camellia_sp10011110[256] = {
0x7000007070707000ULL, 0x8200008282828200ULL, 0x2c00002c2c2c2c00ULL,
0xec0000ecececec00ULL, 0xb30000b3b3b3b300ULL, 0x2700002727272700ULL,
0xc00000c0c0c0c000ULL, 0xe50000e5e5e5e500ULL, 0xe40000e4e4e4e400ULL,
@@ -151,7 +151,7 @@ const u64 camellia_sp10011110[256] = {
0x9e00009e9e9e9e00ULL,
};
-const u64 camellia_sp22000222[256] = {
+__visible const u64 camellia_sp22000222[256] = {
0xe0e0000000e0e0e0ULL, 0x0505000000050505ULL, 0x5858000000585858ULL,
0xd9d9000000d9d9d9ULL, 0x6767000000676767ULL, 0x4e4e0000004e4e4eULL,
0x8181000000818181ULL, 0xcbcb000000cbcbcbULL, 0xc9c9000000c9c9c9ULL,
@@ -240,7 +240,7 @@ const u64 camellia_sp22000222[256] = {
0x3d3d0000003d3d3dULL,
};
-const u64 camellia_sp03303033[256] = {
+__visible const u64 camellia_sp03303033[256] = {
0x0038380038003838ULL, 0x0041410041004141ULL, 0x0016160016001616ULL,
0x0076760076007676ULL, 0x00d9d900d900d9d9ULL, 0x0093930093009393ULL,
0x0060600060006060ULL, 0x00f2f200f200f2f2ULL, 0x0072720072007272ULL,
@@ -329,7 +329,7 @@ const u64 camellia_sp03303033[256] = {
0x004f4f004f004f4fULL,
};
-const u64 camellia_sp00444404[256] = {
+__visible const u64 camellia_sp00444404[256] = {
0x0000707070700070ULL, 0x00002c2c2c2c002cULL, 0x0000b3b3b3b300b3ULL,
0x0000c0c0c0c000c0ULL, 0x0000e4e4e4e400e4ULL, 0x0000575757570057ULL,
0x0000eaeaeaea00eaULL, 0x0000aeaeaeae00aeULL, 0x0000232323230023ULL,
@@ -418,7 +418,7 @@ const u64 camellia_sp00444404[256] = {
0x00009e9e9e9e009eULL,
};
-const u64 camellia_sp02220222[256] = {
+__visible const u64 camellia_sp02220222[256] = {
0x00e0e0e000e0e0e0ULL, 0x0005050500050505ULL, 0x0058585800585858ULL,
0x00d9d9d900d9d9d9ULL, 0x0067676700676767ULL, 0x004e4e4e004e4e4eULL,
0x0081818100818181ULL, 0x00cbcbcb00cbcbcbULL, 0x00c9c9c900c9c9c9ULL,
@@ -507,7 +507,7 @@ const u64 camellia_sp02220222[256] = {
0x003d3d3d003d3d3dULL,
};
-const u64 camellia_sp30333033[256] = {
+__visible const u64 camellia_sp30333033[256] = {
0x3800383838003838ULL, 0x4100414141004141ULL, 0x1600161616001616ULL,
0x7600767676007676ULL, 0xd900d9d9d900d9d9ULL, 0x9300939393009393ULL,
0x6000606060006060ULL, 0xf200f2f2f200f2f2ULL, 0x7200727272007272ULL,
@@ -596,7 +596,7 @@ const u64 camellia_sp30333033[256] = {
0x4f004f4f4f004f4fULL,
};
-const u64 camellia_sp44044404[256] = {
+__visible const u64 camellia_sp44044404[256] = {
0x7070007070700070ULL, 0x2c2c002c2c2c002cULL, 0xb3b300b3b3b300b3ULL,
0xc0c000c0c0c000c0ULL, 0xe4e400e4e4e400e4ULL, 0x5757005757570057ULL,
0xeaea00eaeaea00eaULL, 0xaeae00aeaeae00aeULL, 0x2323002323230023ULL,
@@ -685,7 +685,7 @@ const u64 camellia_sp44044404[256] = {
0x9e9e009e9e9e009eULL,
};
-const u64 camellia_sp11101110[256] = {
+__visible const u64 camellia_sp11101110[256] = {
0x7070700070707000ULL, 0x8282820082828200ULL, 0x2c2c2c002c2c2c00ULL,
0xececec00ececec00ULL, 0xb3b3b300b3b3b300ULL, 0x2727270027272700ULL,
0xc0c0c000c0c0c000ULL, 0xe5e5e500e5e5e500ULL, 0xe4e4e400e4e4e400ULL,
diff --git a/crypto/aes_generic.c b/crypto/aes_generic.c
index 47f2e5c..fd0d6b4 100644
--- a/crypto/aes_generic.c
+++ b/crypto/aes_generic.c
@@ -62,7 +62,7 @@ static inline u8 byte(const u32 x, const unsigned n)
static const u32 rco_tab[10] = { 1, 2, 4, 8, 16, 32, 64, 128, 27, 54 };
-const u32 crypto_ft_tab[4][256] = {
+__visible const u32 crypto_ft_tab[4][256] = {
{
0xa56363c6, 0x847c7cf8, 0x997777ee, 0x8d7b7bf6,
0x0df2f2ff, 0xbd6b6bd6, 0xb16f6fde, 0x54c5c591,
@@ -326,7 +326,7 @@ const u32 crypto_ft_tab[4][256] = {
}
};
-const u32 crypto_fl_tab[4][256] = {
+__visible const u32 crypto_fl_tab[4][256] = {
{
0x00000063, 0x0000007c, 0x00000077, 0x0000007b,
0x000000f2, 0x0000006b, 0x0000006f, 0x000000c5,
@@ -590,7 +590,7 @@ const u32 crypto_fl_tab[4][256] = {
}
};
-const u32 crypto_it_tab[4][256] = {
+__visible const u32 crypto_it_tab[4][256] = {
{
0x50a7f451, 0x5365417e, 0xc3a4171a, 0x965e273a,
0xcb6bab3b, 0xf1459d1f, 0xab58faac, 0x9303e34b,
@@ -854,7 +854,7 @@ const u32 crypto_it_tab[4][256] = {
}
};
-const u32 crypto_il_tab[4][256] = {
+__visible const u32 crypto_il_tab[4][256] = {
{
0x00000052, 0x00000009, 0x0000006a, 0x000000d5,
0x00000030, 0x00000036, 0x000000a5, 0x00000038,
diff --git a/crypto/cast_common.c b/crypto/cast_common.c
index a15f523..117dd82 100644
--- a/crypto/cast_common.c
+++ b/crypto/cast_common.c
@@ -15,7 +15,7 @@
#include <linux/module.h>
#include <crypto/cast_common.h>
-const u32 cast_s1[256] = {
+__visible const u32 cast_s1[256] = {
0x30fb40d4, 0x9fa0ff0b, 0x6beccd2f, 0x3f258c7a, 0x1e213f2f,
0x9c004dd3, 0x6003e540, 0xcf9fc949,
0xbfd4af27, 0x88bbbdb5, 0xe2034090, 0x98d09675, 0x6e63a0e0,
@@ -83,7 +83,7 @@ const u32 cast_s1[256] = {
};
EXPORT_SYMBOL_GPL(cast_s1);
-const u32 cast_s2[256] = {
+__visible const u32 cast_s2[256] = {
0x1f201094, 0xef0ba75b, 0x69e3cf7e, 0x393f4380, 0xfe61cf7a,
0xeec5207a, 0x55889c94, 0x72fc0651,
0xada7ef79, 0x4e1d7235, 0xd55a63ce, 0xde0436ba, 0x99c430ef,
@@ -151,7 +151,7 @@ const u32 cast_s2[256] = {
};
EXPORT_SYMBOL_GPL(cast_s2);
-const u32 cast_s3[256] = {
+__visible const u32 cast_s3[256] = {
0x8defc240, 0x25fa5d9f, 0xeb903dbf, 0xe810c907, 0x47607fff,
0x369fe44b, 0x8c1fc644, 0xaececa90,
0xbeb1f9bf, 0xeefbcaea, 0xe8cf1950, 0x51df07ae, 0x920e8806,
@@ -219,7 +219,7 @@ const u32 cast_s3[256] = {
};
EXPORT_SYMBOL_GPL(cast_s3);
-const u32 cast_s4[256] = {
+__visible const u32 cast_s4[256] = {
0x9db30420, 0x1fb6e9de, 0xa7be7bef, 0xd273a298, 0x4a4f7bdb,
0x64ad8c57, 0x85510443, 0xfa020ed1,
0x7e287aff, 0xe60fb663, 0x095f35a1, 0x79ebf120, 0xfd059d43,
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH 1/3] ARM: dts: mxs: set dcp to "disabled" by default
From: Shawn Guo @ 2013-08-12 11:05 UTC (permalink / raw)
To: Lothar Waßmann
Cc: devicetree, Stephen Warren, Rob Herring, linux-crypto,
Tobias Rauter, linux-arm-kernel
In-Reply-To: <1375968629-10091-2-git-send-email-LW@KARO-electronics.de>
On Thu, Aug 08, 2013 at 03:30:27PM +0200, Lothar Waßmann wrote:
> Reintroduce 'status = "disabled"' for the dcp node that was dropped by
> commit 519d8b1a "Added support for Freescale's DCP co-processor".
For IP blocks that do not have pins to be routed on boards, it should be
fine to have it enabled in <soc>.dtsi.
Shawn
>
> Explicitly enable it in imx28-evk which is referenced in the commit
> message of that commit.
>
> Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
> ---
> arch/arm/boot/dts/imx28-evk.dts | 4 ++++
> arch/arm/boot/dts/imx28.dtsi | 3 ++-
> 2 files changed, 6 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/boot/dts/imx28-evk.dts b/arch/arm/boot/dts/imx28-evk.dts
> index dff2279..ac790bb 100644
> --- a/arch/arm/boot/dts/imx28-evk.dts
> +++ b/arch/arm/boot/dts/imx28-evk.dts
> @@ -361,3 +361,7 @@
> default-brightness-level = <6>;
> };
> };
> +
> +&dcp {
> + status = "okay";
> +};
> diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
> index e459d63..ea99d09 100644
> --- a/arch/arm/boot/dts/imx28.dtsi
> +++ b/arch/arm/boot/dts/imx28.dtsi
> @@ -794,9 +794,10 @@
> };
>
> dcp: dcp@80028000 {
> + compatible = "fsl-dcp";
> reg = <0x80028000 0x2000>;
> interrupts = <52 53 54>;
> - compatible = "fsl-dcp";
> + status = "disabled";
> };
>
> pxp: pxp@8002a000 {
> --
> 1.7.2.5
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/3] ARM: dts: mxs: set dcp to "disabled" by default
From: Lothar Waßmann @ 2013-08-12 12:05 UTC (permalink / raw)
To: Shawn Guo
Cc: devicetree, Stephen Warren, Rob Herring, linux-crypto,
Tobias Rauter, linux-arm-kernel
In-Reply-To: <20130812110523.GD25292@S2101-09.ap.freescale.net>
Hi,
Shawn Guo writes:
> On Thu, Aug 08, 2013 at 03:30:27PM +0200, Lothar Waßmann wrote:
> > Reintroduce 'status = "disabled"' for the dcp node that was dropped by
> > commit 519d8b1a "Added support for Freescale's DCP co-processor".
>
> For IP blocks that do not have pins to be routed on boards, it should be
> fine to have it enabled in <soc>.dtsi.
>
That means that when a new driver is added, it will start wasting
resources on all board using that SoC unless the board maintainers
explicitly disable that driver in DTB.
I would prefer things to be the other way:
New drivers (no matter whether for chip-internal or external hardware)
should require to be explicitly enabled for those platforms on which
they are being used.
Lothar Waßmann
--
___________________________________________________________
Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Geschäftsführer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
www.karo-electronics.de | info@karo-electronics.de
___________________________________________________________
^ permalink raw reply
* Re: Questions about the Crypto API
From: Marcelo Cerri @ 2013-08-12 13:49 UTC (permalink / raw)
To: Herbert Xu
Cc: Hsieh, Che-Min, Garg Vakul-B16394, linux-crypto@vger.kernel.org
In-Reply-To: <20130810011541.GA6549@gondor.apana.org.au>
On Sat, Aug 10, 2013 at 11:15:41AM +1000, Herbert Xu wrote:
> On Fri, Aug 09, 2013 at 01:09:12PM +0000, Hsieh, Che-Min wrote:
> > Marcelo/Herbert:
> >
> > I believe It is. Herbert, please correct me if I am wrong.
> > A single tfm is used as a user context to crypto, so to speak. But a user is not a thread.
> > Let us use ipsec as example.
> > For each security association (SA), it will take up a tfm.
> > Assume I have IP sec setup between my local host and remote host. I might have two SA's, one for each direction.
> > Now, I might run ping. Simultaneously, I might run iperf. I might run a lot of different things between these two ip hosts.
> > But only two tfm's are involved.
> > I have seen this happening in our system with ipsec setup as described above.
> > While an async request is outstanding in the driver, another request is issued to the same driver for the same tfm.
>
> Yes you're absolutely right.
>
> Unless I've misunderstood Marcelo's question is different from
> what Garg was asking.
>
> Marcelo: The tfm, be it blkcipher or ablkcipher can always be used
> in parallel by the user on different CPUs. For example, IPsec may
> receive two packets on two CPUs through the same SA, in which case
> decryption will be carried out in parallel.
So does that means that it's possible to keep data in the tfm's context
that is the same for a single SA, such as the AES expanded key, but it's
not possible to keep data that is specific for the current operation,
such as an operation state that the driver might require?
Actually I think that probably I have misunderstood the blkcipher
interface, so here it is another question: is each encrypt/decrypt call
a complete operation? I mean, I'm considering that I could always chain
a series of calls to encrypt data in separated chunks, in a similar way
that is done for the hash interface and because that I'm assuming that I
would have to keep state between those calls if the device requires
that.
>
> Garg: For any tfm, blkcipher or ablkcipher, they must return results
> in the order they were given. For a blkcipher which is synchronous,
> this is always true by definition since we return only after the
> result has been completed. For an async ablkcipher, this means that
> if you receive two requests on the same CPU, then the first request
> must be served and completed before the second request's completion
> can be initiated.
>
> Sorry for any confusion this might have caused.
>
> Cheers,
> --
> Email: Herbert Xu <herbert@gondor.apana.org.au>
> 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 majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH 1/3] ARM: dts: mxs: set dcp to "disabled" by default
From: Kumar Gala @ 2013-08-12 14:17 UTC (permalink / raw)
To: Lothar Waßmann
Cc: Shawn Guo, devicetree, Stephen Warren, Rob Herring, linux-crypto,
Tobias Rauter, linux-arm-kernel
In-Reply-To: <21000.53151.841177.378797@ipc1.ka-ro>
On Aug 12, 2013, at 7:05 AM, Lothar Waßmann wrote:
> Hi,
>
> Shawn Guo writes:
>> On Thu, Aug 08, 2013 at 03:30:27PM +0200, Lothar Waßmann wrote:
>>> Reintroduce 'status = "disabled"' for the dcp node that was dropped by
>>> commit 519d8b1a "Added support for Freescale's DCP co-processor".
>>
>> For IP blocks that do not have pins to be routed on boards, it should be
>> fine to have it enabled in <soc>.dtsi.
>>
> That means that when a new driver is added, it will start wasting
> resources on all board using that SoC unless the board maintainers
> explicitly disable that driver in DTB.
>
> I would prefer things to be the other way:
> New drivers (no matter whether for chip-internal or external hardware)
> should require to be explicitly enabled for those platforms on which
> they are being used.
But that enablement should be in the kernel and not the device tree. The device tree is describing the HW, if the DCP exists and is usable w/o an external IO than by default it should be enabled in the SoC .dts
- k
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply
* [PATCH] crypto: nx - fix concurrency issue
From: Marcelo Cerri @ 2013-08-12 21:49 UTC (permalink / raw)
To: herbert; +Cc: Marcelo Cerri, linuxppc-dev, linux-kernel, linux-crypto
The NX driver uses the transformation context to store several fields
containing data related to the state of the operations in progress.
Since a single tfm can be used by different kernel threads at the same
time, we need to protect the data stored into the context.
This patch makes use of spin locks to protect the data where a race
condition can happen.
Reviewed-by: Fionnuala Gunter <fin@linux.vnet.ibm.com>
Reviewed-by: Joy Latten <jmlatten@linux.vnet.ibm.com>
Signed-off-by: Marcelo Cerri <mhcerri@linux.vnet.ibm.com>
---
drivers/crypto/nx/nx-aes-cbc.c | 10 ++++++++--
drivers/crypto/nx/nx-aes-ccm.c | 20 ++++++++++++++++----
drivers/crypto/nx/nx-aes-ctr.c | 10 ++++++++--
drivers/crypto/nx/nx-aes-ecb.c | 10 ++++++++--
drivers/crypto/nx/nx-aes-gcm.c | 4 ++++
drivers/crypto/nx/nx-aes-xcbc.c | 8 ++++++++
drivers/crypto/nx/nx-sha256.c | 16 ++++++++++++++++
drivers/crypto/nx/nx-sha512.c | 16 ++++++++++++++++
drivers/crypto/nx/nx.c | 4 ++--
drivers/crypto/nx/nx.h | 1 +
10 files changed, 87 insertions(+), 12 deletions(-)
diff --git a/drivers/crypto/nx/nx-aes-cbc.c b/drivers/crypto/nx/nx-aes-cbc.c
index 6d90808..9310982 100644
--- a/drivers/crypto/nx/nx-aes-cbc.c
+++ b/drivers/crypto/nx/nx-aes-cbc.c
@@ -70,10 +70,15 @@ static int cbc_aes_nx_crypt(struct blkcipher_desc *desc,
{
struct nx_crypto_ctx *nx_ctx = crypto_blkcipher_ctx(desc->tfm);
struct nx_csbcpb *csbcpb = nx_ctx->csbcpb;
+ unsigned long irq_flags;
int rc;
- if (nbytes > nx_ctx->ap->databytelen)
- return -EINVAL;
+ spin_lock_irqsave(&nx_ctx->lock, irq_flags);
+
+ if (nbytes > nx_ctx->ap->databytelen) {
+ rc = -EINVAL;
+ goto out;
+ }
if (enc)
NX_CPB_FDM(csbcpb) |= NX_FDM_ENDE_ENCRYPT;
@@ -101,6 +106,7 @@ static int cbc_aes_nx_crypt(struct blkcipher_desc *desc,
atomic64_add(csbcpb->csb.processed_byte_count,
&(nx_ctx->stats->aes_bytes));
out:
+ spin_unlock_irqrestore(&nx_ctx->lock, irq_flags);
return rc;
}
diff --git a/drivers/crypto/nx/nx-aes-ccm.c b/drivers/crypto/nx/nx-aes-ccm.c
index ef5eae6..39d4224 100644
--- a/drivers/crypto/nx/nx-aes-ccm.c
+++ b/drivers/crypto/nx/nx-aes-ccm.c
@@ -271,10 +271,15 @@ static int ccm_nx_decrypt(struct aead_request *req,
unsigned int nbytes = req->cryptlen;
unsigned int authsize = crypto_aead_authsize(crypto_aead_reqtfm(req));
struct nx_ccm_priv *priv = &nx_ctx->priv.ccm;
+ unsigned long irq_flags;
int rc = -1;
- if (nbytes > nx_ctx->ap->databytelen)
- return -EINVAL;
+ spin_lock_irqsave(&nx_ctx->lock, irq_flags);
+
+ if (nbytes > nx_ctx->ap->databytelen) {
+ rc = -EINVAL;
+ goto out;
+ }
nbytes -= authsize;
@@ -308,6 +313,7 @@ static int ccm_nx_decrypt(struct aead_request *req,
rc = memcmp(csbcpb->cpb.aes_ccm.out_pat_or_mac, priv->oauth_tag,
authsize) ? -EBADMSG : 0;
out:
+ spin_unlock_irqrestore(&nx_ctx->lock, irq_flags);
return rc;
}
@@ -318,10 +324,15 @@ static int ccm_nx_encrypt(struct aead_request *req,
struct nx_csbcpb *csbcpb = nx_ctx->csbcpb;
unsigned int nbytes = req->cryptlen;
unsigned int authsize = crypto_aead_authsize(crypto_aead_reqtfm(req));
+ unsigned long irq_flags;
int rc = -1;
- if (nbytes > nx_ctx->ap->databytelen)
- return -EINVAL;
+ spin_lock_irqsave(&nx_ctx->lock, irq_flags);
+
+ if (nbytes > nx_ctx->ap->databytelen) {
+ rc = -EINVAL;
+ goto out;
+ }
rc = generate_pat(desc->info, req, nx_ctx, authsize, nbytes,
csbcpb->cpb.aes_ccm.in_pat_or_b0);
@@ -350,6 +361,7 @@ static int ccm_nx_encrypt(struct aead_request *req,
req->dst, nbytes, authsize,
SCATTERWALK_TO_SG);
out:
+ spin_unlock_irqrestore(&nx_ctx->lock, irq_flags);
return rc;
}
diff --git a/drivers/crypto/nx/nx-aes-ctr.c b/drivers/crypto/nx/nx-aes-ctr.c
index b6286f1..762611b 100644
--- a/drivers/crypto/nx/nx-aes-ctr.c
+++ b/drivers/crypto/nx/nx-aes-ctr.c
@@ -88,10 +88,15 @@ static int ctr_aes_nx_crypt(struct blkcipher_desc *desc,
{
struct nx_crypto_ctx *nx_ctx = crypto_blkcipher_ctx(desc->tfm);
struct nx_csbcpb *csbcpb = nx_ctx->csbcpb;
+ unsigned long irq_flags;
int rc;
- if (nbytes > nx_ctx->ap->databytelen)
- return -EINVAL;
+ spin_lock_irqsave(&nx_ctx->lock, irq_flags);
+
+ if (nbytes > nx_ctx->ap->databytelen) {
+ rc = -EINVAL;
+ goto out;
+ }
rc = nx_build_sg_lists(nx_ctx, desc, dst, src, nbytes,
csbcpb->cpb.aes_ctr.iv);
@@ -112,6 +117,7 @@ static int ctr_aes_nx_crypt(struct blkcipher_desc *desc,
atomic64_add(csbcpb->csb.processed_byte_count,
&(nx_ctx->stats->aes_bytes));
out:
+ spin_unlock_irqrestore(&nx_ctx->lock, irq_flags);
return rc;
}
diff --git a/drivers/crypto/nx/nx-aes-ecb.c b/drivers/crypto/nx/nx-aes-ecb.c
index 7bbc9a8..77dbe08 100644
--- a/drivers/crypto/nx/nx-aes-ecb.c
+++ b/drivers/crypto/nx/nx-aes-ecb.c
@@ -70,10 +70,15 @@ static int ecb_aes_nx_crypt(struct blkcipher_desc *desc,
{
struct nx_crypto_ctx *nx_ctx = crypto_blkcipher_ctx(desc->tfm);
struct nx_csbcpb *csbcpb = nx_ctx->csbcpb;
+ unsigned long irq_flags;
int rc;
- if (nbytes > nx_ctx->ap->databytelen)
- return -EINVAL;
+ spin_lock_irqsave(&nx_ctx->lock, irq_flags);
+
+ if (nbytes > nx_ctx->ap->databytelen) {
+ rc = -EINVAL;
+ goto out;
+ }
if (enc)
NX_CPB_FDM(csbcpb) |= NX_FDM_ENDE_ENCRYPT;
@@ -98,6 +103,7 @@ static int ecb_aes_nx_crypt(struct blkcipher_desc *desc,
atomic64_add(csbcpb->csb.processed_byte_count,
&(nx_ctx->stats->aes_bytes));
out:
+ spin_unlock_irqrestore(&nx_ctx->lock, irq_flags);
return rc;
}
diff --git a/drivers/crypto/nx/nx-aes-gcm.c b/drivers/crypto/nx/nx-aes-gcm.c
index 6cca6c3..df90d03 100644
--- a/drivers/crypto/nx/nx-aes-gcm.c
+++ b/drivers/crypto/nx/nx-aes-gcm.c
@@ -166,8 +166,11 @@ static int gcm_aes_nx_crypt(struct aead_request *req, int enc)
struct nx_csbcpb *csbcpb = nx_ctx->csbcpb;
struct blkcipher_desc desc;
unsigned int nbytes = req->cryptlen;
+ unsigned long irq_flags;
int rc = -EINVAL;
+ spin_lock_irqsave(&nx_ctx->lock, irq_flags);
+
if (nbytes > nx_ctx->ap->databytelen)
goto out;
@@ -255,6 +258,7 @@ static int gcm_aes_nx_crypt(struct aead_request *req, int enc)
-EBADMSG : 0;
}
out:
+ spin_unlock_irqrestore(&nx_ctx->lock, irq_flags);
return rc;
}
diff --git a/drivers/crypto/nx/nx-aes-xcbc.c b/drivers/crypto/nx/nx-aes-xcbc.c
index 93923e4..658da0f 100644
--- a/drivers/crypto/nx/nx-aes-xcbc.c
+++ b/drivers/crypto/nx/nx-aes-xcbc.c
@@ -89,8 +89,11 @@ static int nx_xcbc_update(struct shash_desc *desc,
struct nx_csbcpb *csbcpb = nx_ctx->csbcpb;
struct nx_sg *in_sg;
u32 to_process, leftover;
+ unsigned long irq_flags;
int rc = 0;
+ spin_lock_irqsave(&nx_ctx->lock, irq_flags);
+
if (NX_CPB_FDM(csbcpb) & NX_FDM_CONTINUATION) {
/* we've hit the nx chip previously and we're updating again,
* so copy over the partial digest */
@@ -158,6 +161,7 @@ static int nx_xcbc_update(struct shash_desc *desc,
/* everything after the first update is continuation */
NX_CPB_FDM(csbcpb) |= NX_FDM_CONTINUATION;
out:
+ spin_unlock_irqrestore(&nx_ctx->lock, irq_flags);
return rc;
}
@@ -167,8 +171,11 @@ static int nx_xcbc_final(struct shash_desc *desc, u8 *out)
struct nx_crypto_ctx *nx_ctx = crypto_tfm_ctx(&desc->tfm->base);
struct nx_csbcpb *csbcpb = nx_ctx->csbcpb;
struct nx_sg *in_sg, *out_sg;
+ unsigned long irq_flags;
int rc = 0;
+ spin_lock_irqsave(&nx_ctx->lock, irq_flags);
+
if (NX_CPB_FDM(csbcpb) & NX_FDM_CONTINUATION) {
/* we've hit the nx chip previously, now we're finalizing,
* so copy over the partial digest */
@@ -211,6 +218,7 @@ static int nx_xcbc_final(struct shash_desc *desc, u8 *out)
memcpy(out, csbcpb->cpb.aes_xcbc.out_cv_mac, AES_BLOCK_SIZE);
out:
+ spin_unlock_irqrestore(&nx_ctx->lock, irq_flags);
return rc;
}
diff --git a/drivers/crypto/nx/nx-sha256.c b/drivers/crypto/nx/nx-sha256.c
index 254b01a..6547a71 100644
--- a/drivers/crypto/nx/nx-sha256.c
+++ b/drivers/crypto/nx/nx-sha256.c
@@ -57,8 +57,11 @@ static int nx_sha256_update(struct shash_desc *desc, const u8 *data,
struct nx_sg *in_sg;
u64 to_process, leftover, total;
u32 max_sg_len;
+ unsigned long irq_flags;
int rc = 0;
+ spin_lock_irqsave(&nx_ctx->lock, irq_flags);
+
/* 2 cases for total data len:
* 1: < SHA256_BLOCK_SIZE: copy into state, return 0
* 2: >= SHA256_BLOCK_SIZE: process X blocks, copy in leftover
@@ -136,6 +139,7 @@ static int nx_sha256_update(struct shash_desc *desc, const u8 *data,
memcpy(sctx->buf, data, leftover);
sctx->count = leftover;
out:
+ spin_unlock_irqrestore(&nx_ctx->lock, irq_flags);
return rc;
}
@@ -146,8 +150,11 @@ static int nx_sha256_final(struct shash_desc *desc, u8 *out)
struct nx_csbcpb *csbcpb = (struct nx_csbcpb *)nx_ctx->csbcpb;
struct nx_sg *in_sg, *out_sg;
u32 max_sg_len;
+ unsigned long irq_flags;
int rc;
+ spin_lock_irqsave(&nx_ctx->lock, irq_flags);
+
max_sg_len = min_t(u32, nx_driver.of.max_sg_len, nx_ctx->ap->sglen);
if (NX_CPB_FDM(csbcpb) & NX_FDM_CONTINUATION) {
@@ -186,6 +193,7 @@ static int nx_sha256_final(struct shash_desc *desc, u8 *out)
&(nx_ctx->stats->sha256_bytes));
memcpy(out, csbcpb->cpb.sha256.message_digest, SHA256_DIGEST_SIZE);
out:
+ spin_unlock_irqrestore(&nx_ctx->lock, irq_flags);
return rc;
}
@@ -195,6 +203,9 @@ static int nx_sha256_export(struct shash_desc *desc, void *out)
struct nx_crypto_ctx *nx_ctx = crypto_tfm_ctx(&desc->tfm->base);
struct nx_csbcpb *csbcpb = (struct nx_csbcpb *)nx_ctx->csbcpb;
struct sha256_state *octx = out;
+ unsigned long irq_flags;
+
+ spin_lock_irqsave(&nx_ctx->lock, irq_flags);
octx->count = sctx->count +
(csbcpb->cpb.sha256.message_bit_length / 8);
@@ -217,6 +228,7 @@ static int nx_sha256_export(struct shash_desc *desc, void *out)
octx->state[7] = SHA256_H7;
}
+ spin_unlock_irqrestore(&nx_ctx->lock, irq_flags);
return 0;
}
@@ -226,6 +238,9 @@ static int nx_sha256_import(struct shash_desc *desc, const void *in)
struct nx_crypto_ctx *nx_ctx = crypto_tfm_ctx(&desc->tfm->base);
struct nx_csbcpb *csbcpb = (struct nx_csbcpb *)nx_ctx->csbcpb;
const struct sha256_state *ictx = in;
+ unsigned long irq_flags;
+
+ spin_lock_irqsave(&nx_ctx->lock, irq_flags);
memcpy(sctx->buf, ictx->buf, sizeof(ictx->buf));
@@ -240,6 +255,7 @@ static int nx_sha256_import(struct shash_desc *desc, const void *in)
NX_CPB_FDM(csbcpb) |= NX_FDM_INTERMEDIATE;
}
+ spin_unlock_irqrestore(&nx_ctx->lock, irq_flags);
return 0;
}
diff --git a/drivers/crypto/nx/nx-sha512.c b/drivers/crypto/nx/nx-sha512.c
index 2d6d913..236e6af 100644
--- a/drivers/crypto/nx/nx-sha512.c
+++ b/drivers/crypto/nx/nx-sha512.c
@@ -57,8 +57,11 @@ static int nx_sha512_update(struct shash_desc *desc, const u8 *data,
struct nx_sg *in_sg;
u64 to_process, leftover, total, spbc_bits;
u32 max_sg_len;
+ unsigned long irq_flags;
int rc = 0;
+ spin_lock_irqsave(&nx_ctx->lock, irq_flags);
+
/* 2 cases for total data len:
* 1: < SHA512_BLOCK_SIZE: copy into state, return 0
* 2: >= SHA512_BLOCK_SIZE: process X blocks, copy in leftover
@@ -138,6 +141,7 @@ static int nx_sha512_update(struct shash_desc *desc, const u8 *data,
memcpy(sctx->buf, data, leftover);
sctx->count[0] = leftover;
out:
+ spin_unlock_irqrestore(&nx_ctx->lock, irq_flags);
return rc;
}
@@ -149,8 +153,11 @@ static int nx_sha512_final(struct shash_desc *desc, u8 *out)
struct nx_sg *in_sg, *out_sg;
u32 max_sg_len;
u64 count0;
+ unsigned long irq_flags;
int rc;
+ spin_lock_irqsave(&nx_ctx->lock, irq_flags);
+
max_sg_len = min_t(u32, nx_driver.of.max_sg_len, nx_ctx->ap->sglen);
if (NX_CPB_FDM(csbcpb) & NX_FDM_CONTINUATION) {
@@ -193,6 +200,7 @@ static int nx_sha512_final(struct shash_desc *desc, u8 *out)
memcpy(out, csbcpb->cpb.sha512.message_digest, SHA512_DIGEST_SIZE);
out:
+ spin_unlock_irqrestore(&nx_ctx->lock, irq_flags);
return rc;
}
@@ -202,6 +210,9 @@ static int nx_sha512_export(struct shash_desc *desc, void *out)
struct nx_crypto_ctx *nx_ctx = crypto_tfm_ctx(&desc->tfm->base);
struct nx_csbcpb *csbcpb = (struct nx_csbcpb *)nx_ctx->csbcpb;
struct sha512_state *octx = out;
+ unsigned long irq_flags;
+
+ spin_lock_irqsave(&nx_ctx->lock, irq_flags);
/* move message_bit_length (128 bits) into count and convert its value
* to bytes */
@@ -233,6 +244,7 @@ static int nx_sha512_export(struct shash_desc *desc, void *out)
octx->state[7] = SHA512_H7;
}
+ spin_unlock_irqrestore(&nx_ctx->lock, irq_flags);
return 0;
}
@@ -242,6 +254,9 @@ static int nx_sha512_import(struct shash_desc *desc, const void *in)
struct nx_crypto_ctx *nx_ctx = crypto_tfm_ctx(&desc->tfm->base);
struct nx_csbcpb *csbcpb = (struct nx_csbcpb *)nx_ctx->csbcpb;
const struct sha512_state *ictx = in;
+ unsigned long irq_flags;
+
+ spin_lock_irqsave(&nx_ctx->lock, irq_flags);
memcpy(sctx->buf, ictx->buf, sizeof(ictx->buf));
sctx->count[0] = ictx->count[0] & 0x3f;
@@ -259,6 +274,7 @@ static int nx_sha512_import(struct shash_desc *desc, const void *in)
NX_CPB_FDM(csbcpb) |= NX_FDM_INTERMEDIATE;
}
+ spin_unlock_irqrestore(&nx_ctx->lock, irq_flags);
return 0;
}
diff --git a/drivers/crypto/nx/nx.c b/drivers/crypto/nx/nx.c
index ad07dc6..bdf4990 100644
--- a/drivers/crypto/nx/nx.c
+++ b/drivers/crypto/nx/nx.c
@@ -61,8 +61,7 @@ int nx_hcall_sync(struct nx_crypto_ctx *nx_ctx,
do {
rc = vio_h_cop_sync(viodev, op);
- } while ((rc == -EBUSY && !may_sleep && retries--) ||
- (rc == -EBUSY && may_sleep && cond_resched()));
+ } while (rc == -EBUSY && !may_sleep && retries--);
if (rc) {
dev_dbg(&viodev->dev, "vio_h_cop_sync failed: rc: %d "
@@ -251,6 +250,7 @@ int nx_build_sg_lists(struct nx_crypto_ctx *nx_ctx,
*/
void nx_ctx_init(struct nx_crypto_ctx *nx_ctx, unsigned int function)
{
+ spin_lock_init(&nx_ctx->lock);
memset(nx_ctx->kmem, 0, nx_ctx->kmem_len);
nx_ctx->csbcpb->csb.valid |= NX_CSB_VALID_BIT;
diff --git a/drivers/crypto/nx/nx.h b/drivers/crypto/nx/nx.h
index 3232b18..14bb97f 100644
--- a/drivers/crypto/nx/nx.h
+++ b/drivers/crypto/nx/nx.h
@@ -117,6 +117,7 @@ struct nx_ctr_priv {
};
struct nx_crypto_ctx {
+ spinlock_t lock; /* synchronize access to the context */
void *kmem; /* unaligned, kmalloc'd buffer */
size_t kmem_len; /* length of kmem */
struct nx_csbcpb *csbcpb; /* aligned page given to phyp @ hcall time */
--
1.7.12
^ permalink raw reply related
* RE: Questions about the Crypto API
From: Hsieh, Che-Min @ 2013-08-13 19:25 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-crypto@vger.kernel.org
In-Reply-To: <20130812134913.GA5173@oc8526070481.ibm.com>
> Garg: For any tfm, blkcipher or ablkcipher, they must return results
> in the order they were given. For a blkcipher which is synchronous,
> this is always true by definition since we return only after the
> result has been completed. For an async ablkcipher, this means that
> if you receive two requests on the same CPU, then the first request
> must be served and completed before the second request's completion
> can be initiated.
Herbert, can you give further clarification:
(*) This ordering of result is also true for others, such as aead and hashing, right?
Can you confirm, or correct the following statements:
(*)To perform hashing on a long data stream, it may come in multiple requests to the driver; in a sequence of one .init request, one or more than one .update requests, and lastly one .final request. In this sequence, a request has to be complete, before next one to be issued to the driver. Those requests should always come in the same struct crypto_async_request.
Is this correct?
If driver needs to maintain state variables for such (init, update, final), the state variables can be maintained in the request implementation context, instead of tfm context. Right?
Thanks.
Chemin
-----Original Message-----
From: linux-crypto-owner@vger.kernel.org [mailto:linux-crypto-owner@vger.kernel.org] On Behalf Of Marcelo Cerri
Sent: Monday, August 12, 2013 9:49 AM
To: Herbert Xu
Cc: Hsieh, Che-Min; Garg Vakul-B16394; linux-crypto@vger.kernel.org
Subject: Re: Questions about the Crypto API
On Sat, Aug 10, 2013 at 11:15:41AM +1000, Herbert Xu wrote:
> On Fri, Aug 09, 2013 at 01:09:12PM +0000, Hsieh, Che-Min wrote:
> > Marcelo/Herbert:
> >
> > I believe It is. Herbert, please correct me if I am wrong.
> > A single tfm is used as a user context to crypto, so to speak. But a user is not a thread.
> > Let us use ipsec as example.
> > For each security association (SA), it will take up a tfm.
> > Assume I have IP sec setup between my local host and remote host. I might have two SA's, one for each direction.
> > Now, I might run ping. Simultaneously, I might run iperf. I might run a lot of different things between these two ip hosts.
> > But only two tfm's are involved.
> > I have seen this happening in our system with ipsec setup as described above.
> > While an async request is outstanding in the driver, another request is issued to the same driver for the same tfm.
>
> Yes you're absolutely right.
>
> Unless I've misunderstood Marcelo's question is different from what
> Garg was asking.
>
> Marcelo: The tfm, be it blkcipher or ablkcipher can always be used in
> parallel by the user on different CPUs. For example, IPsec may
> receive two packets on two CPUs through the same SA, in which case
> decryption will be carried out in parallel.
So does that means that it's possible to keep data in the tfm's context that is the same for a single SA, such as the AES expanded key, but it's not possible to keep data that is specific for the current operation, such as an operation state that the driver might require?
Actually I think that probably I have misunderstood the blkcipher interface, so here it is another question: is each encrypt/decrypt call a complete operation? I mean, I'm considering that I could always chain a series of calls to encrypt data in separated chunks, in a similar way that is done for the hash interface and because that I'm assuming that I would have to keep state between those calls if the device requires that.
>
> Garg: For any tfm, blkcipher or ablkcipher, they must return results
> in the order they were given. For a blkcipher which is synchronous,
> this is always true by definition since we return only after the
> result has been completed. For an async ablkcipher, this means that
> if you receive two requests on the same CPU, then the first request
> must be served and completed before the second request's completion
> can be initiated.
>
> Sorry for any confusion this might have caused.
>
> Cheers,
> --
> Email: Herbert Xu <herbert@gondor.apana.org.au> 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 majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
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
^ permalink raw reply
* Re: [PATCH 1/2] arch/x86/crypto/camellia_glue.c: adjust code alignment
From: Herbert Xu @ 2013-08-14 10:41 UTC (permalink / raw)
To: Julia Lawall
Cc: kernel-janitors, David S. Miller, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, x86, linux-crypto, linux-kernel, trivial
In-Reply-To: <1376156077-6208-2-git-send-email-Julia.Lawall@lip6.fr>
On Sat, Aug 10, 2013 at 07:34:36PM +0200, Julia Lawall wrote:
> From: Julia Lawall <Julia.Lawall@lip6.fr>
>
> Adjust alignment in automatically generated code. If this code
> will not be regenerated in the future, it may as well look nice.
>
> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
>
> ---
> This patch was generated from the result of the previous one, which
> replaced commas by semicolons.
Please fold this patch into the original one.
Thanks!
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 1/2] arch/x86/crypto/camellia_glue.c: adjust code alignment
From: Julia Lawall @ 2013-08-14 10:44 UTC (permalink / raw)
To: Herbert Xu
Cc: Julia Lawall, kernel-janitors, David S. Miller, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin, x86, linux-crypto, linux-kernel,
trivial
In-Reply-To: <20130814104122.GA12970@gondor.apana.org.au>
On Wed, 14 Aug 2013, Herbert Xu wrote:
> On Sat, Aug 10, 2013 at 07:34:36PM +0200, Julia Lawall wrote:
> > From: Julia Lawall <Julia.Lawall@lip6.fr>
> >
> > Adjust alignment in automatically generated code. If this code
> > will not be regenerated in the future, it may as well look nice.
> >
> > Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
> >
> > ---
> > This patch was generated from the result of the previous one, which
> > replaced commas by semicolons.
>
> Please fold this patch into the original one.
OK, I will do that. There is a second patch for another camellia file
that is in the same situation. I will send new versions of both.
thanks,
julia
^ permalink raw reply
* Re: [PATCH 1/2] crypto: sahara - Staticize local symbol
From: Herbert Xu @ 2013-08-14 10:49 UTC (permalink / raw)
To: Jingoo Han; +Cc: David S. Miller, linux-crypto, 'Javier Martin'
In-Reply-To: <000801ce94d6$24377710$6ca66530$@samsung.com>
On Fri, Aug 09, 2013 at 04:57:48PM +0900, Jingoo Han wrote:
> This local symbol is used only in this file.
> Fix the following sparse warnings:
>
> drivers/crypto/sahara.c:420:6: warning: symbol 'sahara_watchdog' was not declared. Should it be static?
>
> Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Both patches applied.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: make tables used from assembler __visible
From: Herbert Xu @ 2013-08-14 10:49 UTC (permalink / raw)
To: Andi Kleen; +Cc: linux-crypto, Andi Kleen
In-Reply-To: <1376182871-17690-1-git-send-email-andi@firstfloor.org>
On Sat, Aug 10, 2013 at 06:01:11PM -0700, Andi Kleen wrote:
> From: Andi Kleen <ak@linux.intel.com>
>
> Tables used from assembler should be marked __visible to let
> the compiler know.
>
> Signed-off-by: Andi Kleen <ak@linux.intel.com>
Patch applied. Thanks Andi.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: nx - fix concurrency issue
From: Herbert Xu @ 2013-08-14 10:49 UTC (permalink / raw)
To: Marcelo Cerri; +Cc: benh, linux-kernel, linux-crypto, linuxppc-dev
In-Reply-To: <1376344177-7205-1-git-send-email-mhcerri@linux.vnet.ibm.com>
On Mon, Aug 12, 2013 at 06:49:37PM -0300, Marcelo Cerri wrote:
> The NX driver uses the transformation context to store several fields
> containing data related to the state of the operations in progress.
> Since a single tfm can be used by different kernel threads at the same
> time, we need to protect the data stored into the context.
>
> This patch makes use of spin locks to protect the data where a race
> condition can happen.
>
> Reviewed-by: Fionnuala Gunter <fin@linux.vnet.ibm.com>
> Reviewed-by: Joy Latten <jmlatten@linux.vnet.ibm.com>
> Signed-off-by: Marcelo Cerri <mhcerri@linux.vnet.ibm.com>
Patch applied. Thanks a lot!
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH 1/2] arch/x86/crypto/camellia_glue.c: replace commas by semicolons and adjust code alignment
From: Julia Lawall @ 2013-08-14 13:52 UTC (permalink / raw)
To: Herbert Xu
Cc: kernel-janitors, David S. Miller, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, x86, linux-crypto, linux-kernel
From: Julia Lawall <Julia.Lawall@lip6.fr>
Adjust alignment and replace commas by semicolons in automatically
generated code.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
---
arch/x86/crypto/camellia_glue.c | 48 ++++++++++++++++++++--------------------
1 file changed, 24 insertions(+), 24 deletions(-)
diff --git a/arch/x86/crypto/camellia_glue.c b/arch/x86/crypto/camellia_glue.c
index 5cb86cc..39aebea 100644
--- a/arch/x86/crypto/camellia_glue.c
+++ b/arch/x86/crypto/camellia_glue.c
@@ -828,8 +828,8 @@ static void camellia_setup_tail(u64 *subkey, u64 *subRL, int max)
subRL[1] ^= (subRL[1] & ~subRL[9]) << 32;
/* modified for FLinv(kl2) */
- dw = (subRL[1] & subRL[9]) >> 32,
- subRL[1] ^= rol32(dw, 1);
+ dw = (subRL[1] & subRL[9]) >> 32;
+ subRL[1] ^= rol32(dw, 1);
/* round 8 */
subRL[11] ^= subRL[1];
@@ -840,8 +840,8 @@ static void camellia_setup_tail(u64 *subkey, u64 *subRL, int max)
subRL[1] ^= (subRL[1] & ~subRL[17]) << 32;
/* modified for FLinv(kl4) */
- dw = (subRL[1] & subRL[17]) >> 32,
- subRL[1] ^= rol32(dw, 1);
+ dw = (subRL[1] & subRL[17]) >> 32;
+ subRL[1] ^= rol32(dw, 1);
/* round 14 */
subRL[19] ^= subRL[1];
@@ -859,8 +859,8 @@ static void camellia_setup_tail(u64 *subkey, u64 *subRL, int max)
} else {
subRL[1] ^= (subRL[1] & ~subRL[25]) << 32;
/* modified for FLinv(kl6) */
- dw = (subRL[1] & subRL[25]) >> 32,
- subRL[1] ^= rol32(dw, 1);
+ dw = (subRL[1] & subRL[25]) >> 32;
+ subRL[1] ^= rol32(dw, 1);
/* round 20 */
subRL[27] ^= subRL[1];
@@ -882,8 +882,8 @@ static void camellia_setup_tail(u64 *subkey, u64 *subRL, int max)
kw4 ^= (kw4 & ~subRL[24]) << 32;
/* modified for FL(kl5) */
- dw = (kw4 & subRL[24]) >> 32,
- kw4 ^= rol32(dw, 1);
+ dw = (kw4 & subRL[24]) >> 32;
+ kw4 ^= rol32(dw, 1);
}
/* round 17 */
@@ -895,8 +895,8 @@ static void camellia_setup_tail(u64 *subkey, u64 *subRL, int max)
kw4 ^= (kw4 & ~subRL[16]) << 32;
/* modified for FL(kl3) */
- dw = (kw4 & subRL[16]) >> 32,
- kw4 ^= rol32(dw, 1);
+ dw = (kw4 & subRL[16]) >> 32;
+ kw4 ^= rol32(dw, 1);
/* round 11 */
subRL[14] ^= kw4;
@@ -907,8 +907,8 @@ static void camellia_setup_tail(u64 *subkey, u64 *subRL, int max)
kw4 ^= (kw4 & ~subRL[8]) << 32;
/* modified for FL(kl1) */
- dw = (kw4 & subRL[8]) >> 32,
- kw4 ^= rol32(dw, 1);
+ dw = (kw4 & subRL[8]) >> 32;
+ kw4 ^= rol32(dw, 1);
/* round 5 */
subRL[6] ^= kw4;
@@ -928,8 +928,8 @@ static void camellia_setup_tail(u64 *subkey, u64 *subRL, int max)
SET_SUBKEY_LR(6, subRL[5] ^ subRL[7]); /* round 5 */
tl = (subRL[10] >> 32) ^ (subRL[10] & ~subRL[8]);
- dw = tl & (subRL[8] >> 32), /* FL(kl1) */
- tr = subRL[10] ^ rol32(dw, 1);
+ dw = tl & (subRL[8] >> 32); /* FL(kl1) */
+ tr = subRL[10] ^ rol32(dw, 1);
tt = (tr | ((u64)tl << 32));
SET_SUBKEY_LR(7, subRL[6] ^ tt); /* round 6 */
@@ -937,8 +937,8 @@ static void camellia_setup_tail(u64 *subkey, u64 *subRL, int max)
SET_SUBKEY_LR(9, subRL[9]); /* FLinv(kl2) */
tl = (subRL[7] >> 32) ^ (subRL[7] & ~subRL[9]);
- dw = tl & (subRL[9] >> 32), /* FLinv(kl2) */
- tr = subRL[7] ^ rol32(dw, 1);
+ dw = tl & (subRL[9] >> 32); /* FLinv(kl2) */
+ tr = subRL[7] ^ rol32(dw, 1);
tt = (tr | ((u64)tl << 32));
SET_SUBKEY_LR(10, subRL[11] ^ tt); /* round 7 */
@@ -948,8 +948,8 @@ static void camellia_setup_tail(u64 *subkey, u64 *subRL, int max)
SET_SUBKEY_LR(14, subRL[13] ^ subRL[15]); /* round 11 */
tl = (subRL[18] >> 32) ^ (subRL[18] & ~subRL[16]);
- dw = tl & (subRL[16] >> 32), /* FL(kl3) */
- tr = subRL[18] ^ rol32(dw, 1);
+ dw = tl & (subRL[16] >> 32); /* FL(kl3) */
+ tr = subRL[18] ^ rol32(dw, 1);
tt = (tr | ((u64)tl << 32));
SET_SUBKEY_LR(15, subRL[14] ^ tt); /* round 12 */
@@ -957,8 +957,8 @@ static void camellia_setup_tail(u64 *subkey, u64 *subRL, int max)
SET_SUBKEY_LR(17, subRL[17]); /* FLinv(kl4) */
tl = (subRL[15] >> 32) ^ (subRL[15] & ~subRL[17]);
- dw = tl & (subRL[17] >> 32), /* FLinv(kl4) */
- tr = subRL[15] ^ rol32(dw, 1);
+ dw = tl & (subRL[17] >> 32); /* FLinv(kl4) */
+ tr = subRL[15] ^ rol32(dw, 1);
tt = (tr | ((u64)tl << 32));
SET_SUBKEY_LR(18, subRL[19] ^ tt); /* round 13 */
@@ -972,8 +972,8 @@ static void camellia_setup_tail(u64 *subkey, u64 *subRL, int max)
SET_SUBKEY_LR(24, subRL[24] ^ subRL[23]); /* kw3 */
} else {
tl = (subRL[26] >> 32) ^ (subRL[26] & ~subRL[24]);
- dw = tl & (subRL[24] >> 32), /* FL(kl5) */
- tr = subRL[26] ^ rol32(dw, 1);
+ dw = tl & (subRL[24] >> 32); /* FL(kl5) */
+ tr = subRL[26] ^ rol32(dw, 1);
tt = (tr | ((u64)tl << 32));
SET_SUBKEY_LR(23, subRL[22] ^ tt); /* round 18 */
@@ -981,8 +981,8 @@ static void camellia_setup_tail(u64 *subkey, u64 *subRL, int max)
SET_SUBKEY_LR(25, subRL[25]); /* FLinv(kl6) */
tl = (subRL[23] >> 32) ^ (subRL[23] & ~subRL[25]);
- dw = tl & (subRL[25] >> 32), /* FLinv(kl6) */
- tr = subRL[23] ^ rol32(dw, 1);
+ dw = tl & (subRL[25] >> 32); /* FLinv(kl6) */
+ tr = subRL[23] ^ rol32(dw, 1);
tt = (tr | ((u64)tl << 32));
SET_SUBKEY_LR(26, subRL[27] ^ tt); /* round 19 */
^ permalink raw reply related
* [PATCH 2/2] crypto/camellia_generic.c: replace commas by semicolons and adjust code alignment
From: Julia Lawall @ 2013-08-14 13:52 UTC (permalink / raw)
To: Herbert Xu; +Cc: kernel-janitors, David S. Miller, linux-crypto, linux-kernel
From: Julia Lawall <Julia.Lawall@lip6.fr>
Adjust alignment and replace commas by semicolons in automatically
generated code.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
---
crypto/camellia_generic.c | 48 +++++++++++++++++++++++-----------------------
1 file changed, 24 insertions(+), 24 deletions(-)
diff --git a/crypto/camellia_generic.c b/crypto/camellia_generic.c
index 75efa20..26bcd7a 100644
--- a/crypto/camellia_generic.c
+++ b/crypto/camellia_generic.c
@@ -388,8 +388,8 @@ static void camellia_setup_tail(u32 *subkey, u32 *subL, u32 *subR, int max)
/* round 6 */
subL[7] ^= subL[1]; subR[7] ^= subR[1];
subL[1] ^= subR[1] & ~subR[9];
- dw = subL[1] & subL[9],
- subR[1] ^= rol32(dw, 1); /* modified for FLinv(kl2) */
+ dw = subL[1] & subL[9];
+ subR[1] ^= rol32(dw, 1); /* modified for FLinv(kl2) */
/* round 8 */
subL[11] ^= subL[1]; subR[11] ^= subR[1];
/* round 10 */
@@ -397,8 +397,8 @@ static void camellia_setup_tail(u32 *subkey, u32 *subL, u32 *subR, int max)
/* round 12 */
subL[15] ^= subL[1]; subR[15] ^= subR[1];
subL[1] ^= subR[1] & ~subR[17];
- dw = subL[1] & subL[17],
- subR[1] ^= rol32(dw, 1); /* modified for FLinv(kl4) */
+ dw = subL[1] & subL[17];
+ subR[1] ^= rol32(dw, 1); /* modified for FLinv(kl4) */
/* round 14 */
subL[19] ^= subL[1]; subR[19] ^= subR[1];
/* round 16 */
@@ -413,8 +413,8 @@ static void camellia_setup_tail(u32 *subkey, u32 *subL, u32 *subR, int max)
kw4l = subL[25]; kw4r = subR[25];
} else {
subL[1] ^= subR[1] & ~subR[25];
- dw = subL[1] & subL[25],
- subR[1] ^= rol32(dw, 1); /* modified for FLinv(kl6) */
+ dw = subL[1] & subL[25];
+ subR[1] ^= rol32(dw, 1); /* modified for FLinv(kl6) */
/* round 20 */
subL[27] ^= subL[1]; subR[27] ^= subR[1];
/* round 22 */
@@ -433,8 +433,8 @@ static void camellia_setup_tail(u32 *subkey, u32 *subL, u32 *subR, int max)
/* round 19 */
subL[26] ^= kw4l; subR[26] ^= kw4r;
kw4l ^= kw4r & ~subR[24];
- dw = kw4l & subL[24],
- kw4r ^= rol32(dw, 1); /* modified for FL(kl5) */
+ dw = kw4l & subL[24];
+ kw4r ^= rol32(dw, 1); /* modified for FL(kl5) */
}
/* round 17 */
subL[22] ^= kw4l; subR[22] ^= kw4r;
@@ -443,8 +443,8 @@ static void camellia_setup_tail(u32 *subkey, u32 *subL, u32 *subR, int max)
/* round 13 */
subL[18] ^= kw4l; subR[18] ^= kw4r;
kw4l ^= kw4r & ~subR[16];
- dw = kw4l & subL[16],
- kw4r ^= rol32(dw, 1); /* modified for FL(kl3) */
+ dw = kw4l & subL[16];
+ kw4r ^= rol32(dw, 1); /* modified for FL(kl3) */
/* round 11 */
subL[14] ^= kw4l; subR[14] ^= kw4r;
/* round 9 */
@@ -452,8 +452,8 @@ static void camellia_setup_tail(u32 *subkey, u32 *subL, u32 *subR, int max)
/* round 7 */
subL[10] ^= kw4l; subR[10] ^= kw4r;
kw4l ^= kw4r & ~subR[8];
- dw = kw4l & subL[8],
- kw4r ^= rol32(dw, 1); /* modified for FL(kl1) */
+ dw = kw4l & subL[8];
+ kw4r ^= rol32(dw, 1); /* modified for FL(kl1) */
/* round 5 */
subL[6] ^= kw4l; subR[6] ^= kw4r;
/* round 3 */
@@ -477,8 +477,8 @@ static void camellia_setup_tail(u32 *subkey, u32 *subL, u32 *subR, int max)
SUBKEY_L(6) = subL[5] ^ subL[7]; /* round 5 */
SUBKEY_R(6) = subR[5] ^ subR[7];
tl = subL[10] ^ (subR[10] & ~subR[8]);
- dw = tl & subL[8], /* FL(kl1) */
- tr = subR[10] ^ rol32(dw, 1);
+ dw = tl & subL[8]; /* FL(kl1) */
+ tr = subR[10] ^ rol32(dw, 1);
SUBKEY_L(7) = subL[6] ^ tl; /* round 6 */
SUBKEY_R(7) = subR[6] ^ tr;
SUBKEY_L(8) = subL[8]; /* FL(kl1) */
@@ -486,8 +486,8 @@ static void camellia_setup_tail(u32 *subkey, u32 *subL, u32 *subR, int max)
SUBKEY_L(9) = subL[9]; /* FLinv(kl2) */
SUBKEY_R(9) = subR[9];
tl = subL[7] ^ (subR[7] & ~subR[9]);
- dw = tl & subL[9], /* FLinv(kl2) */
- tr = subR[7] ^ rol32(dw, 1);
+ dw = tl & subL[9]; /* FLinv(kl2) */
+ tr = subR[7] ^ rol32(dw, 1);
SUBKEY_L(10) = tl ^ subL[11]; /* round 7 */
SUBKEY_R(10) = tr ^ subR[11];
SUBKEY_L(11) = subL[10] ^ subL[12]; /* round 8 */
@@ -499,8 +499,8 @@ static void camellia_setup_tail(u32 *subkey, u32 *subL, u32 *subR, int max)
SUBKEY_L(14) = subL[13] ^ subL[15]; /* round 11 */
SUBKEY_R(14) = subR[13] ^ subR[15];
tl = subL[18] ^ (subR[18] & ~subR[16]);
- dw = tl & subL[16], /* FL(kl3) */
- tr = subR[18] ^ rol32(dw, 1);
+ dw = tl & subL[16]; /* FL(kl3) */
+ tr = subR[18] ^ rol32(dw, 1);
SUBKEY_L(15) = subL[14] ^ tl; /* round 12 */
SUBKEY_R(15) = subR[14] ^ tr;
SUBKEY_L(16) = subL[16]; /* FL(kl3) */
@@ -508,8 +508,8 @@ static void camellia_setup_tail(u32 *subkey, u32 *subL, u32 *subR, int max)
SUBKEY_L(17) = subL[17]; /* FLinv(kl4) */
SUBKEY_R(17) = subR[17];
tl = subL[15] ^ (subR[15] & ~subR[17]);
- dw = tl & subL[17], /* FLinv(kl4) */
- tr = subR[15] ^ rol32(dw, 1);
+ dw = tl & subL[17]; /* FLinv(kl4) */
+ tr = subR[15] ^ rol32(dw, 1);
SUBKEY_L(18) = tl ^ subL[19]; /* round 13 */
SUBKEY_R(18) = tr ^ subR[19];
SUBKEY_L(19) = subL[18] ^ subL[20]; /* round 14 */
@@ -527,8 +527,8 @@ static void camellia_setup_tail(u32 *subkey, u32 *subL, u32 *subR, int max)
SUBKEY_R(24) = subR[24] ^ subR[23];
} else {
tl = subL[26] ^ (subR[26] & ~subR[24]);
- dw = tl & subL[24], /* FL(kl5) */
- tr = subR[26] ^ rol32(dw, 1);
+ dw = tl & subL[24]; /* FL(kl5) */
+ tr = subR[26] ^ rol32(dw, 1);
SUBKEY_L(23) = subL[22] ^ tl; /* round 18 */
SUBKEY_R(23) = subR[22] ^ tr;
SUBKEY_L(24) = subL[24]; /* FL(kl5) */
@@ -536,8 +536,8 @@ static void camellia_setup_tail(u32 *subkey, u32 *subL, u32 *subR, int max)
SUBKEY_L(25) = subL[25]; /* FLinv(kl6) */
SUBKEY_R(25) = subR[25];
tl = subL[23] ^ (subR[23] & ~subR[25]);
- dw = tl & subL[25], /* FLinv(kl6) */
- tr = subR[23] ^ rol32(dw, 1);
+ dw = tl & subL[25]; /* FLinv(kl6) */
+ tr = subR[23] ^ rol32(dw, 1);
SUBKEY_L(26) = tl ^ subL[27]; /* round 19 */
SUBKEY_R(26) = tr ^ subR[27];
SUBKEY_L(27) = subL[26] ^ subL[28]; /* round 20 */
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox