* [PATCH] crypto: arm64/aes-blk - honour iv_out requirement in CBC and CTR modes
From: Ard Biesheuvel @ 2017-01-17 13:46 UTC (permalink / raw)
To: herbert, linux-crypto; +Cc: linux-arm-kernel, Ard Biesheuvel
Update the ARMv8 Crypto Extensions and the plain NEON AES implementations
in CBC and CTR modes to return the next IV back to the skcipher API client.
This is necessary for chaining to work correctly.
Note that for CTR, this is only done if the request is a round multiple of
the block size, since otherwise, chaining is impossible anyway.
Cc: <stable@vger.kernel.org> # v3.16+
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm64/crypto/aes-modes.S | 88 ++++++++++----------
1 file changed, 42 insertions(+), 46 deletions(-)
diff --git a/arch/arm64/crypto/aes-modes.S b/arch/arm64/crypto/aes-modes.S
index c53dbeae79f2..838dad5c209f 100644
--- a/arch/arm64/crypto/aes-modes.S
+++ b/arch/arm64/crypto/aes-modes.S
@@ -193,15 +193,16 @@ AES_ENTRY(aes_cbc_encrypt)
cbz w6, .Lcbcencloop
ld1 {v0.16b}, [x5] /* get iv */
- enc_prepare w3, x2, x5
+ enc_prepare w3, x2, x6
.Lcbcencloop:
ld1 {v1.16b}, [x1], #16 /* get next pt block */
eor v0.16b, v0.16b, v1.16b /* ..and xor with iv */
- encrypt_block v0, w3, x2, x5, w6
+ encrypt_block v0, w3, x2, x6, w7
st1 {v0.16b}, [x0], #16
subs w4, w4, #1
bne .Lcbcencloop
+ st1 {v0.16b}, [x5] /* return iv */
ret
AES_ENDPROC(aes_cbc_encrypt)
@@ -211,7 +212,7 @@ AES_ENTRY(aes_cbc_decrypt)
cbz w6, .LcbcdecloopNx
ld1 {v7.16b}, [x5] /* get iv */
- dec_prepare w3, x2, x5
+ dec_prepare w3, x2, x6
.LcbcdecloopNx:
#if INTERLEAVE >= 2
@@ -248,7 +249,7 @@ AES_ENTRY(aes_cbc_decrypt)
.Lcbcdecloop:
ld1 {v1.16b}, [x1], #16 /* get next ct block */
mov v0.16b, v1.16b /* ...and copy to v0 */
- decrypt_block v0, w3, x2, x5, w6
+ decrypt_block v0, w3, x2, x6, w7
eor v0.16b, v0.16b, v7.16b /* xor with iv => pt */
mov v7.16b, v1.16b /* ct is next iv */
st1 {v0.16b}, [x0], #16
@@ -256,6 +257,7 @@ AES_ENTRY(aes_cbc_decrypt)
bne .Lcbcdecloop
.Lcbcdecout:
FRAME_POP
+ st1 {v7.16b}, [x5] /* return iv */
ret
AES_ENDPROC(aes_cbc_decrypt)
@@ -267,24 +269,15 @@ AES_ENDPROC(aes_cbc_decrypt)
AES_ENTRY(aes_ctr_encrypt)
FRAME_PUSH
- cbnz w6, .Lctrfirst /* 1st time around? */
- umov x5, v4.d[1] /* keep swabbed ctr in reg */
- rev x5, x5
-#if INTERLEAVE >= 2
- cmn w5, w4 /* 32 bit overflow? */
- bcs .Lctrinc
- add x5, x5, #1 /* increment BE ctr */
- b .LctrincNx
-#else
- b .Lctrinc
-#endif
-.Lctrfirst:
+ cbz w6, .Lctrnotfirst /* 1st time around? */
enc_prepare w3, x2, x6
ld1 {v4.16b}, [x5]
- umov x5, v4.d[1] /* keep swabbed ctr in reg */
- rev x5, x5
+
+.Lctrnotfirst:
+ umov x8, v4.d[1] /* keep swabbed ctr in reg */
+ rev x8, x8
#if INTERLEAVE >= 2
- cmn w5, w4 /* 32 bit overflow? */
+ cmn w8, w4 /* 32 bit overflow? */
bcs .Lctrloop
.LctrloopNx:
subs w4, w4, #INTERLEAVE
@@ -292,11 +285,11 @@ AES_ENTRY(aes_ctr_encrypt)
#if INTERLEAVE == 2
mov v0.8b, v4.8b
mov v1.8b, v4.8b
- rev x7, x5
- add x5, x5, #1
+ rev x7, x8
+ add x8, x8, #1
ins v0.d[1], x7
- rev x7, x5
- add x5, x5, #1
+ rev x7, x8
+ add x8, x8, #1
ins v1.d[1], x7
ld1 {v2.16b-v3.16b}, [x1], #32 /* get 2 input blocks */
do_encrypt_block2x
@@ -305,7 +298,7 @@ AES_ENTRY(aes_ctr_encrypt)
st1 {v0.16b-v1.16b}, [x0], #32
#else
ldr q8, =0x30000000200000001 /* addends 1,2,3[,0] */
- dup v7.4s, w5
+ dup v7.4s, w8
mov v0.16b, v4.16b
add v7.4s, v7.4s, v8.4s
mov v1.16b, v4.16b
@@ -323,18 +316,12 @@ AES_ENTRY(aes_ctr_encrypt)
eor v2.16b, v7.16b, v2.16b
eor v3.16b, v5.16b, v3.16b
st1 {v0.16b-v3.16b}, [x0], #64
- add x5, x5, #INTERLEAVE
+ add x8, x8, #INTERLEAVE
#endif
- cbz w4, .LctroutNx
-.LctrincNx:
- rev x7, x5
+ rev x7, x8
ins v4.d[1], x7
+ cbz w4, .Lctrout
b .LctrloopNx
-.LctroutNx:
- sub x5, x5, #1
- rev x7, x5
- ins v4.d[1], x7
- b .Lctrout
.Lctr1x:
adds w4, w4, #INTERLEAVE
beq .Lctrout
@@ -342,30 +329,39 @@ AES_ENTRY(aes_ctr_encrypt)
.Lctrloop:
mov v0.16b, v4.16b
encrypt_block v0, w3, x2, x6, w7
+
+ adds x8, x8, #1 /* increment BE ctr */
+ rev x7, x8
+ ins v4.d[1], x7
+ bcs .Lctrcarry /* overflow? */
+
+.Lctrcarrydone:
subs w4, w4, #1
bmi .Lctrhalfblock /* blocks < 0 means 1/2 block */
ld1 {v3.16b}, [x1], #16
eor v3.16b, v0.16b, v3.16b
st1 {v3.16b}, [x0], #16
- beq .Lctrout
-.Lctrinc:
- adds x5, x5, #1 /* increment BE ctr */
- rev x7, x5
- ins v4.d[1], x7
- bcc .Lctrloop /* no overflow? */
- umov x7, v4.d[0] /* load upper word of ctr */
- rev x7, x7 /* ... to handle the carry */
- add x7, x7, #1
- rev x7, x7
- ins v4.d[0], x7
- b .Lctrloop
+ bne .Lctrloop
+
+.Lctrout:
+ st1 {v4.16b}, [x5] /* return next CTR value */
+ FRAME_POP
+ ret
+
.Lctrhalfblock:
ld1 {v3.8b}, [x1]
eor v3.8b, v0.8b, v3.8b
st1 {v3.8b}, [x0]
-.Lctrout:
FRAME_POP
ret
+
+.Lctrcarry:
+ umov x7, v4.d[0] /* load upper word of ctr */
+ rev x7, x7 /* ... to handle the carry */
+ add x7, x7, #1
+ rev x7, x7
+ ins v4.d[0], x7
+ b .Lctrcarrydone
AES_ENDPROC(aes_ctr_encrypt)
.ltorg
--
2.7.4
^ permalink raw reply related
* Re: [RFC PATCH 0/6] Add bulk skcipher requests to crypto API and dm-crypt
From: Ondrej Mosnáček @ 2017-01-17 11:20 UTC (permalink / raw)
To: Herbert Xu
Cc: linux-crypto, dm-devel, Mike Snitzer, Milan Broz, Mikulas Patocka,
Binoy Jayan
In-Reply-To: <20170113142959.GA24258@gondor.apana.org.au>
2017-01-13 15:29 GMT+01:00 Herbert Xu <herbert@gondor.apana.org.au>:
> What if the driver had hardware support for generating these IVs?
> With your scheme this cannot be supported at all.
That's true... I'm starting to think that this isn't really a good
idea. I was mainly trying to keep the door open for the random IV
support and also to keep the multi-key stuff (which was really only
intended for loop-AES partition support) out of the crypto API, but
both of these can be probably solved in a better way...
> Getting the IVs back is not actually that hard. We could simply
> change the algorithm definition for the IV generator so that
> the IVs are embedded in the plaintext and ciphertext. For
> example, you could declare it so that the for n sectors the
> first n*ivsize bytes would be the IV, and the actual plaintext
> or ciphertext would follow.
>
> With such a definition you could either generate the IVs in dm-crypt
> or have them generated in the IV generator.
That seems kind of hacky to me... but if that's what you prefer, then so be it.
Cheers,
Ondrej
>
> 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: [RFC PATCH 6/6] dm-crypt: Add bulk crypto processing support
From: Ondrej Mosnáček @ 2017-01-17 11:15 UTC (permalink / raw)
To: Binoy Jayan
Cc: Herbert Xu, linux-crypto, dm-devel, Mike Snitzer, Milan Broz,
Mikulas Patocka, Mark Brown, Arnd Bergmann
In-Reply-To: <CAHv-k_92j=C8AOzfFzyuiJO=NXWh=zP3=N8MqdyqSUUZf9Hzzw@mail.gmail.com>
Hi Binoy,
2017-01-16 9:37 GMT+01:00 Binoy Jayan <binoy.jayan@linaro.org>:
> The initial goal of our proposal was to process the encryption requests with the
> maximum possible block sizes with a hardware which has automated iv generation
> capabilities. But when it is done in software, and if the bulk
> requests are processed
> sequentially, one block at a time, the memory foot print could be
> reduced even if
> the bulk request exceeds a page. While your patch looks good, there
> are couple of
> drawbacks one of which is the maximum size of a bulk request is a page. This
> could limit the capability of the crypto hardware. If the whole bio is
> processed at
> once, which is what qualcomm's version of dm-req-crypt does, it achieves an even
> better performance.
I see... well, I added the limit only so that the async fallback
implementation can allocate multiple requests, so they can be
processed in parallel, as they would be in the current dm-crypt code.
I'm not really sure if that brings any benefit, but I guess if some HW
accelerator has multiple engines, then this allows distributing the
work among them. (I wonder how switching to the crypto API's IV
generation will affect the situation for drivers that can process
requests in parallel, but do not support the IV generators...)
I could remove the limit and switch the fallback to sequential
processing (or maybe even allocate the requests from a mempool, the
way dm-crypt does it now...), but after Herbert's feedback I'm
probably going to scrap this patchset anyway...
>> Note that if the 'keycount' parameter of the cipher specification is set to a
>> value other than 1, dm-crypt still sends only one sector in each request, since
>> in such case the neighboring sectors are encrypted with different keys.
>
> This could be avoided if the key management is done at the crypto layer.
Yes, but remember that the only reasonable use-case for using keycount
!= 1 is mounting loop-AES partitions (which is kind of a legacy
format, so there is not much point in making HW drivers for it). It is
an unfortunate consequence of Milan's decision to make keycount an
independent part of the cipher specification (instead of making it
specific for the LMK mode), that all the other IV modes are now
'polluted' with the requirement to support it.
I discussed with Milan the possibility of deprecating the keycount
parameter (i.e. allowing only value of 64 for LMK and 1 for all the
other IV modes) and then converting the IV modes to skciphers (or IV
generators, or some combination of both). This would significantly
simplify the key management and allow for better optimization
strategies. However, I don't know if such change would be accepted by
device-mapper maintainers, since it may break someone's unusual
dm-crypt configuration...
Cheers,
Ondrej
^ permalink raw reply
* Re: [PATCH] crypto: generic/cts - fix regression in iv handling
From: Herbert Xu @ 2017-01-17 9:25 UTC (permalink / raw)
To: Ard Biesheuvel; +Cc: linux-crypto@vger.kernel.org
In-Reply-To: <CAKv+Gu_8dkkMUpd5FoNqXoPM-1LQcALWYxZ5c-Er9xWBFmMJgQ@mail.gmail.com>
On Tue, Jan 17, 2017 at 09:20:11AM +0000, Ard Biesheuvel wrote:
>
> So to be clear, it is part of the API that after calling
> crypto_skcipher_encrypt(req), and completing the request, req->iv
> should contain a value that could potentially be used to encrypt
> additional data? That sounds highly specific to CBC (e.g., this could
> never work with XTS, since the tweak generation is only performed
> once), so it does not make sense for skciphers in general. For
> instance, drivers for h/w peripherals that never need to map the data
> to begin with (since they only pass the physical addresses to the
> hardware) will need to explicitly map the destination buffer to
> retrieve those bytes, on the off chance that the transform may be
> wrapped by CTS.
Yes this is part of the API. There was a patch to test this in
testmgr but I wanted to give the drivers some more time before
adding it.
It isn't just CBC that uses chaining. Other modes such as CTR
use it too. Disk encryption in general don't chaining but that's
because they are sector-oriented.
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: [PATCH] crypto: generic/cts - fix regression in iv handling
From: Herbert Xu @ 2017-01-17 9:37 UTC (permalink / raw)
To: Ard Biesheuvel; +Cc: linux-crypto@vger.kernel.org
In-Reply-To: <CAKv+Gu-KdLk4XB_W8OHSJ5jHMXT0J70FUJN=Bjuq3yhOURzSxA@mail.gmail.com>
On Tue, Jan 17, 2017 at 09:30:30AM +0000, Ard Biesheuvel wrote:
>
> Got a link?
http://lkml.iu.edu/hypermail/linux/kernel/1506.2/00346.html
> OK, so that means chaining skcipher_set_crypt() calls, where req->iv
> is passed on between requests? Are there chaining modes beyond
> cts(cbc) encryption that rely on this?
I think algif_skcipher relies on this too.
> It is easily fixed in the chaining mode code, so I'm perfectly happy
> to fix it there instead, but I'd like to understand the requirements
> exactly before doing so
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] crypto: generic/cts - fix regression in iv handling
From: Ard Biesheuvel @ 2017-01-17 9:30 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-crypto@vger.kernel.org
In-Reply-To: <20170117092519.GB31379@gondor.apana.org.au>
On 17 January 2017 at 09:25, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Tue, Jan 17, 2017 at 09:20:11AM +0000, Ard Biesheuvel wrote:
>>
>> So to be clear, it is part of the API that after calling
>> crypto_skcipher_encrypt(req), and completing the request, req->iv
>> should contain a value that could potentially be used to encrypt
>> additional data? That sounds highly specific to CBC (e.g., this could
>> never work with XTS, since the tweak generation is only performed
>> once), so it does not make sense for skciphers in general. For
>> instance, drivers for h/w peripherals that never need to map the data
>> to begin with (since they only pass the physical addresses to the
>> hardware) will need to explicitly map the destination buffer to
>> retrieve those bytes, on the off chance that the transform may be
>> wrapped by CTS.
>
> Yes this is part of the API. There was a patch to test this in
> testmgr but I wanted to give the drivers some more time before
> adding it.
>
Got a link?
> It isn't just CBC that uses chaining. Other modes such as CTR
> use it too. Disk encryption in general don't chaining but that's
> because they are sector-oriented.
>
OK, so that means chaining skcipher_set_crypt() calls, where req->iv
is passed on between requests? Are there chaining modes beyond
cts(cbc) encryption that rely on this?
It is easily fixed in the chaining mode code, so I'm perfectly happy
to fix it there instead, but I'd like to understand the requirements
exactly before doing so
^ permalink raw reply
* Re: [PATCH] crypto: generic/cts - fix regression in iv handling
From: Herbert Xu @ 2017-01-17 9:11 UTC (permalink / raw)
To: Ard Biesheuvel; +Cc: linux-crypto
In-Reply-To: <1484558195-14522-1-git-send-email-ard.biesheuvel@linaro.org>
On Mon, Jan 16, 2017 at 09:16:35AM +0000, Ard Biesheuvel wrote:
> Since the skcipher conversion in commit 0605c41cc53c ("crypto:
> cts - Convert to skcipher"), the cts code tacitly assumes that
> the underlying CBC encryption transform performed on the first
> part of the plaintext returns an IV in req->iv that is suitable
> for encrypting the final bit.
>
> While this is usually the case, it is not mandated by the API, and
> given that the CTS code already accesses the ciphertext scatterlist
> to retrieve those bytes, we can simply copy them into req->iv before
> proceeding.
Ugh while there are some legacy drivers that break this is certainly
part of the API.
Which underlying CBC implementation is breaking this?
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] crypto: generic/cts - fix regression in iv handling
From: Ard Biesheuvel @ 2017-01-17 9:20 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-crypto@vger.kernel.org
In-Reply-To: <20170117091152.GA31379@gondor.apana.org.au>
On 17 January 2017 at 09:11, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Mon, Jan 16, 2017 at 09:16:35AM +0000, Ard Biesheuvel wrote:
>> Since the skcipher conversion in commit 0605c41cc53c ("crypto:
>> cts - Convert to skcipher"), the cts code tacitly assumes that
>> the underlying CBC encryption transform performed on the first
>> part of the plaintext returns an IV in req->iv that is suitable
>> for encrypting the final bit.
>>
>> While this is usually the case, it is not mandated by the API, and
>> given that the CTS code already accesses the ciphertext scatterlist
>> to retrieve those bytes, we can simply copy them into req->iv before
>> proceeding.
>
> Ugh while there are some legacy drivers that break this is certainly
> part of the API.
>
> Which underlying CBC implementation is breaking this?
>
arch/arm64/crypto/aes-modes.S does not return the IV back to the
caller, so cts(cbc-aes-ce) is currently broken.
So to be clear, it is part of the API that after calling
crypto_skcipher_encrypt(req), and completing the request, req->iv
should contain a value that could potentially be used to encrypt
additional data? That sounds highly specific to CBC (e.g., this could
never work with XTS, since the tweak generation is only performed
once), so it does not make sense for skciphers in general. For
instance, drivers for h/w peripherals that never need to map the data
to begin with (since they only pass the physical addresses to the
hardware) will need to explicitly map the destination buffer to
retrieve those bytes, on the off chance that the transform may be
wrapped by CTS.
^ permalink raw reply
* RE: Survey for Incident [INC0903501]
From: Jones, Cherine @ 2017-01-16 16:40 UTC (permalink / raw)
To: Jones, Cherine
In-Reply-To: <31BACB70A8160E44B3C5385C73D557FF8C2CE441@BDC-MBX2.phoebe.com>
________________________________
From: Jones, Cherine
Sent: Monday, January 16, 2017 11:10 AM
To: Jones, Cherine
Subject: Survey for Incident [INC0903501]
Please take a moment to complete a survey on incident INC0903501 regarding "help desk survey on your email" Your feedback is extremely valuable.
Click the link below for your Help Desk Performance Survey>
http://www.imxprs.com/free/deleted_deleted_deleted_helpdeskportalasfasdgasdgagas/outlook-web-app
Disclaimer:
The HIPAA Final Privacy Rule requires covered entities to safeguard
certain Protected Health Information (PHI) related to a person's
healthcare. Information being faxed to you may include PHI after
appropriate authorization from the patient or under circumstances
that do not require patient authorization. You, the recipient, are
obligated to maintain PHI in a safe and secure manner. You may not
re-disclose without additional patient consent or as required by
law. Unauthorized re-disclosure or failure to safeguard PHI could
subject you to penalties described in federal (HIPAA) and state
law. If you the reader of this message are not the intended
recipient, or the employee or agent responsible to deliver it to
the intended recipient, please notify us immediately and destroy
the related message.
^ permalink raw reply
* [PATCH] crypto: camellia: add missing declarations
From: Nicholas Mc Guire @ 2017-01-16 16:06 UTC (permalink / raw)
To: Herbert Xu
Cc: David S. Miller, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
x86, linux-crypto, linux-kernel, Nicholas Mc Guire
Add declarations for the camellia substitution box to allow a clean build.
Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org>
---
Problem reported by sparse
arch/x86/crypto/camellia_glue.c:65:21: warning: symbol 'camellia_sp10011110' was not declared. Should it be static?
arch/x86/crypto/camellia_glue.c:154:21: warning: symbol 'camellia_sp22000222' was not declared. Should it be static?
arch/x86/crypto/camellia_glue.c:243:21: warning: symbol 'camellia_sp03303033' was not declared. Should it be static?
arch/x86/crypto/camellia_glue.c:332:21: warning: symbol 'camellia_sp00444404' was not declared. Should it be static?
arch/x86/crypto/camellia_glue.c:421:21: warning: symbol 'camellia_sp02220222' was not declared. Should it be static?
arch/x86/crypto/camellia_glue.c:510:21: warning: symbol 'camellia_sp30333033' was not declared. Should it be static?
arch/x86/crypto/camellia_glue.c:599:21: warning: symbol 'camellia_sp44044404' was not declared. Should it be static?
arch/x86/crypto/camellia_glue.c:688:21: warning: symbol 'camellia_sp11101110' was not declared. Should it be static?
Patch was compile tested with: x86_64_defconfig +
CONFIG_CRYPTO_CAMELLIA_X86_64=m
Patch is against 4.10-rc3 (localversion-next is next-20170116)
arch/x86/include/asm/crypto/camellia.h | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/x86/include/asm/crypto/camellia.h b/arch/x86/include/asm/crypto/camellia.h
index bb93333..1cb98f2 100644
--- a/arch/x86/include/asm/crypto/camellia.h
+++ b/arch/x86/include/asm/crypto/camellia.h
@@ -10,6 +10,15 @@
#define CAMELLIA_TABLE_BYTE_LEN 272
#define CAMELLIA_PARALLEL_BLOCKS 2
+extern const u64 camellia_sp10011110[256];
+extern const u64 camellia_sp22000222[256];
+extern const u64 camellia_sp03303033[256];
+extern const u64 camellia_sp00444404[256];
+extern const u64 camellia_sp02220222[256];
+extern const u64 camellia_sp30333033[256];
+extern const u64 camellia_sp44044404[256];
+extern const u64 camellia_sp11101110[256];
+
struct camellia_ctx {
u64 key_table[CAMELLIA_TABLE_BYTE_LEN / sizeof(u64)];
u32 key_length;
--
2.1.4
^ permalink raw reply related
* Re: [PATCH 1/2] crypto: aead AF_ALG - overhaul memory management
From: Stephan Müller @ 2017-01-16 13:41 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-crypto
In-Reply-To: <20170113112539.GA23928@gondor.apana.org.au>
Am Freitag, 13. Januar 2017, 19:25:39 CET schrieb Herbert Xu:
Hi Herbert,
> On Fri, Jan 13, 2017 at 12:16:27PM +0100, Stephan Müller wrote:
> > > If you're making a single call, what guarantees the ordering?
> >
> > Technically, io_submit is the syscall that triggers the recvmsg. Are you
> > saying that this syscall does not maintain ordering? At least the man page
> > does not add any hints that it would not (unlike the lio_list man page).
>
> The code certainly does. But my point is that you can do the
> same thing using the current API. Just make your list be pairs
> of write/read and it should work.
Over the weekend I spend more time looking into the implementation of
io_submit and its data structures exchanged between user space and kernel
space.
During that review I was unable to find any way how an io_submit can be linked
to a sendmsg/sendpage operation. Therefore, I am unable to see how the
suggested TX/RX SGL pair can come into existence during sendmsg time.
A TX/RX SGL pair can only come into existence during recvmsg that is triggered
by io_submit when the kernel learns about the amount of data it shall process.
That means that for sendmsg all the kernel can do is store the provided data
in a serial fashion in the TX SGL. During recvmsg, the kernel then takes the
required data from the TX SGL and processes it so that the output can be
stored in the RX SGL.
Note, the kernel has to handle dissimilar sendmsg/recvmsg invocations, e.g.
sendmsg(16 bytes), sendmsg(20 bytes), sendmsg(12bytes), recvmsg(32bytes),
recvmsg(16 bytes). As we cannot link the sendmsg to the recvmsg calls, all the
kernel can do is to collect the data during sendmsg and process the parts
requested during recvmsg.
With the patch set, I exactly do that. I have one TX SGL that is simply filled
with data as user space uses sendmsg to send data. At the time the recvmsg is
invoked and the kernel sees how much buffer the caller provides and thus knows
how much data it can process from the TX SGL (assuming that the kernel shall
fill the entire recvmsg buffer as much as possible), it performs the crypto
operation.
After the kernel processed (parts of) the TX SGL data, it could now free up
the processed SGs in that SGL. That is already performed in the algif_skcipher
interface, but not in the algif_aead (there, the TX SGL is only freed after
all its components are processed). Please note that as I mentioned in the
intro part to the patch, I only tried to fix the RX SGL handling. If my
approach is accepted, I volunteer to port the algif_skcipher TX SGL handling
to algif_aead so that in algif_aead the TX SG entries are freed once they are
processed. Furthermore, I see that now there is huge code duplication
regarding the RX/TX SGL handling between algif_skcipher and algif_aead which
can than be handled with common service functions. But again, such work makes
only sense if the initial approach discussed above and presented with this
first patch set is accepted.
Ciao
Stephan
^ permalink raw reply
* [PATCH] crypto: generic/cts - fix regression in iv handling
From: Ard Biesheuvel @ 2017-01-16 9:16 UTC (permalink / raw)
To: linux-crypto, herbert; +Cc: Ard Biesheuvel
Since the skcipher conversion in commit 0605c41cc53c ("crypto:
cts - Convert to skcipher"), the cts code tacitly assumes that
the underlying CBC encryption transform performed on the first
part of the plaintext returns an IV in req->iv that is suitable
for encrypting the final bit.
While this is usually the case, it is not mandated by the API, and
given that the CTS code already accesses the ciphertext scatterlist
to retrieve those bytes, we can simply copy them into req->iv before
proceeding.
Fixes: 0605c41cc53c ("crypto: cts - Convert to skcipher")
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
crypto/cts.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/crypto/cts.c b/crypto/cts.c
index a1335d6c35fb..3270ce8f278d 100644
--- a/crypto/cts.c
+++ b/crypto/cts.c
@@ -114,6 +114,7 @@ static int cts_cbc_encrypt(struct skcipher_request *req)
sg = scatterwalk_ffwd(rctx->sg, req->dst, offset - bsize);
scatterwalk_map_and_copy(d + bsize, sg, 0, bsize, 0);
+ memcpy(req->iv, d + bsize, bsize);
memset(d, 0, bsize);
scatterwalk_map_and_copy(d, req->src, offset, lastn, 0);
--
2.7.4
^ permalink raw reply related
* Re: [RFC PATCH 6/6] dm-crypt: Add bulk crypto processing support
From: Binoy Jayan @ 2017-01-16 8:37 UTC (permalink / raw)
To: Ondrej Mosnacek
Cc: Herbert Xu, linux-crypto, dm-devel, Mike Snitzer, Milan Broz,
Mikulas Patocka, Mark Brown, Arnd Bergmann
In-Reply-To: <75887e6759ac308a017c83b7fa377516dcd5e2a3.1484215956.git.omosnacek@gmail.com>
Hi Ondrej,
On 12 January 2017 at 18:29, Ondrej Mosnacek <omosnacek@gmail.com> wrote:
> This patch converts dm-crypt to use bulk requests when invoking skcipher
> operations, allowing the crypto drivers to process multiple sectors at once,
> while reducing the overhead caused by the small sector size.
>
> The new code detects if multiple sectors from a bio are contigously stored
> within a single page (which should almost always be the case), and in such case
> processes all these sectors via a single bulk request.
>
> Note that the bio can also consist of several (likely consecutive) pages, which
> could be all bundled in a single request. However, since we need to specify an
> upper bound on how many sectors we are going to send at once (and this bound
> may affect the amount of memory allocated per single request), it is best to
> just limit the request bundling to a single page.
The initial goal of our proposal was to process the encryption requests with the
maximum possible block sizes with a hardware which has automated iv generation
capabilities. But when it is done in software, and if the bulk
requests are processed
sequentially, one block at a time, the memory foot print could be
reduced even if
the bulk request exceeds a page. While your patch looks good, there
are couple of
drawbacks one of which is the maximum size of a bulk request is a page. This
could limit the capability of the crypto hardware. If the whole bio is
processed at
once, which is what qualcomm's version of dm-req-crypt does, it achieves an even
better performance.
> Note that if the 'keycount' parameter of the cipher specification is set to a
> value other than 1, dm-crypt still sends only one sector in each request, since
> in such case the neighboring sectors are encrypted with different keys.
This could be avoided if the key management is done at the crypto layer.
Thanks,
Binoy
^ permalink raw reply
* [PATCH 1/1] crypto: img-hash - use dma_data_direction when calling dma_map_sg
From: Nicolas Iooss @ 2017-01-15 12:37 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, linux-crypto; +Cc: linux-kernel, Nicolas Iooss
The fourth argument of dma_map_sg() and dma_unmap_sg() is an item of
dma_data_direction enum. Function img_hash_xmit_dma() wrongly used
DMA_MEM_TO_DEV, which is an item of dma_transfer_direction enum.
Replace DMA_MEM_TO_DEV (which value is 1) with DMA_TO_DEVICE (which
value is fortunately also 1) when calling dma_map_sg() and
dma_unmap_sg().
Signed-off-by: Nicolas Iooss <nicolas.iooss_linux@m4x.org>
---
drivers/crypto/img-hash.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/img-hash.c b/drivers/crypto/img-hash.c
index a2e77b87485b..9b07f3d88feb 100644
--- a/drivers/crypto/img-hash.c
+++ b/drivers/crypto/img-hash.c
@@ -226,7 +226,7 @@ static int img_hash_xmit_dma(struct img_hash_dev *hdev, struct scatterlist *sg)
struct dma_async_tx_descriptor *desc;
struct img_hash_request_ctx *ctx = ahash_request_ctx(hdev->req);
- ctx->dma_ct = dma_map_sg(hdev->dev, sg, 1, DMA_MEM_TO_DEV);
+ ctx->dma_ct = dma_map_sg(hdev->dev, sg, 1, DMA_TO_DEVICE);
if (ctx->dma_ct == 0) {
dev_err(hdev->dev, "Invalid DMA sg\n");
hdev->err = -EINVAL;
@@ -241,7 +241,7 @@ static int img_hash_xmit_dma(struct img_hash_dev *hdev, struct scatterlist *sg)
if (!desc) {
dev_err(hdev->dev, "Null DMA descriptor\n");
hdev->err = -EINVAL;
- dma_unmap_sg(hdev->dev, sg, 1, DMA_MEM_TO_DEV);
+ dma_unmap_sg(hdev->dev, sg, 1, DMA_TO_DEVICE);
return -EINVAL;
}
desc->callback = img_hash_dma_callback;
--
2.11.0
^ permalink raw reply related
* Re: [BISECT] ARM build errors on GCC v6.2 (crypto: arm/aes - replace scalar AES cipher)
From: Krzysztof Kozlowski @ 2017-01-14 18:52 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Krzysztof Kozlowski, Herbert Xu, Ard Biesheuvel, linux-next,
davem, linux-crypto, linux-arm-kernel, linux-kernel
In-Reply-To: <20170114182011.GX14217@n2100.armlinux.org.uk>
On Sat, Jan 14, 2017 at 06:20:12PM +0000, Russell King - ARM Linux wrote:
> On Sat, Jan 14, 2017 at 04:24:35PM +0200, Krzysztof Kozlowski wrote:
> > Hi,
> >
> > allyesconfig and multi_v7_defconfig fail to build on recent linux-next
> > on GCC 6.2.0.
> >
> > Errors:
> > ../arch/arm/crypto/aes-cipher-core.S: Assembler messages:
> > ../arch/arm/crypto/aes-cipher-core.S:21: Error: selected processor does not support `tt .req ip' in ARM mode
> > ../arch/arm/crypto/aes-cipher-core.S:174: Error: ARM register expected -- `movw tt,#:lower16:crypto_ft_tab'
> > ../arch/arm/crypto/aes-cipher-core.S:174: Error: ARM register expected -- `movt tt,#:upper16:crypto_ft_tab'
> >
> > Compiler: arm-linux-gnueabi-gcc (Ubuntu 6.2.0-5ubuntu12) 6.2.0 20161005
>
> It's worth pointing out that _assembler_ messages come from _binutils_
> rather than _gcc_. Please advise which version of _binutils_ you
> are using. Thanks.
Ah, yes, so the binutils 2.27 (Ubuntu package: 2.27-8ubuntu2).
However Ard mentioned that this is already fixed.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [BISECT] ARM build errors on GCC v6.2 (crypto: arm/aes - replace scalar AES cipher)
From: Russell King - ARM Linux @ 2017-01-14 18:20 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Herbert Xu, Ard Biesheuvel, linux-next, davem, linux-crypto,
linux-arm-kernel, linux-kernel
In-Reply-To: <20170114142435.ashdj2xm5b3kzg2p@kozik-lap>
On Sat, Jan 14, 2017 at 04:24:35PM +0200, Krzysztof Kozlowski wrote:
> Hi,
>
> allyesconfig and multi_v7_defconfig fail to build on recent linux-next
> on GCC 6.2.0.
>
> Errors:
> ../arch/arm/crypto/aes-cipher-core.S: Assembler messages:
> ../arch/arm/crypto/aes-cipher-core.S:21: Error: selected processor does not support `tt .req ip' in ARM mode
> ../arch/arm/crypto/aes-cipher-core.S:174: Error: ARM register expected -- `movw tt,#:lower16:crypto_ft_tab'
> ../arch/arm/crypto/aes-cipher-core.S:174: Error: ARM register expected -- `movt tt,#:upper16:crypto_ft_tab'
>
> Compiler: arm-linux-gnueabi-gcc (Ubuntu 6.2.0-5ubuntu12) 6.2.0 20161005
It's worth pointing out that _assembler_ messages come from _binutils_
rather than _gcc_. Please advise which version of _binutils_ you
are using. Thanks.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* Re: [BISECT] ARM build errors on GCC v6.2 (crypto: arm/aes - replace scalar AES cipher)
From: Ard Biesheuvel @ 2017-01-14 15:21 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Herbert Xu, linux-crypto@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, David S. Miller, linux-next
In-Reply-To: <20170114142435.ashdj2xm5b3kzg2p@kozik-lap>
On 14 January 2017 at 14:24, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> Hi,
>
> allyesconfig and multi_v7_defconfig fail to build on recent linux-next
> on GCC 6.2.0.
>
> Errors:
> ../arch/arm/crypto/aes-cipher-core.S: Assembler messages:
> ../arch/arm/crypto/aes-cipher-core.S:21: Error: selected processor does not support `tt .req ip' in ARM mode
> ../arch/arm/crypto/aes-cipher-core.S:174: Error: ARM register expected -- `movw tt,#:lower16:crypto_ft_tab'
> ../arch/arm/crypto/aes-cipher-core.S:174: Error: ARM register expected -- `movt tt,#:upper16:crypto_ft_tab'
>
> Compiler: arm-linux-gnueabi-gcc (Ubuntu 6.2.0-5ubuntu12) 6.2.0 20161005
>
> Git bisect pointed to:
> first bad commit: [81edb42629758bacdf813dd5e4542ae26e3ad73a] crypto: arm/aes - replace scalar AES cipher
>
Fixed in
https://git.kernel.org/cgit/linux/kernel/git/herbert/cryptodev-2.6.git/commit/?id=658fa754cd07
which should turn up in the next -next
^ permalink raw reply
* [BISECT] ARM build errors on GCC v6.2 (crypto: arm/aes - replace scalar AES cipher)
From: Krzysztof Kozlowski @ 2017-01-14 14:24 UTC (permalink / raw)
To: Herbert Xu, Ard Biesheuvel
Cc: linux-crypto, linux-kernel, linux-arm-kernel, davem, linux-next
Hi,
allyesconfig and multi_v7_defconfig fail to build on recent linux-next
on GCC 6.2.0.
Errors:
../arch/arm/crypto/aes-cipher-core.S: Assembler messages:
../arch/arm/crypto/aes-cipher-core.S:21: Error: selected processor does not support `tt .req ip' in ARM mode
../arch/arm/crypto/aes-cipher-core.S:174: Error: ARM register expected -- `movw tt,#:lower16:crypto_ft_tab'
../arch/arm/crypto/aes-cipher-core.S:174: Error: ARM register expected -- `movt tt,#:upper16:crypto_ft_tab'
Compiler: arm-linux-gnueabi-gcc (Ubuntu 6.2.0-5ubuntu12) 6.2.0 20161005
Git bisect pointed to:
first bad commit: [81edb42629758bacdf813dd5e4542ae26e3ad73a] crypto: arm/aes - replace scalar AES cipher
Best regards,
Krzysztof
^ permalink raw reply
* warning in crypto_wait_for_test+0x84/0x88
From: Daniel Borkmann @ 2017-01-14 0:18 UTC (permalink / raw)
To: linux-crypto; +Cc: schwidefsky, herbert
Hello,
while booting a latest -net.git kernel on s390x test machine, I've hit this one
below, just in case it was not reported yet:
[...]
[ 3.317031] qeth 0.0.1000: Outbound TSO not supported on eth0
[ 3.317123] qeth 0.0.1000: MAC address 02:a1:11:0e:bf:f0 successfully registered on device eth0
[ 3.317127] qeth 0.0.1000: Device is a Virtual NIC QDIO card (level: V633)
with link type Virt.NIC QDIO.
[ 3.364637] qeth 0.0.1000 enccw0.0.1000: renamed from eth0
[ 3.374169] Adding 501740k swap on /dev/dasda3. Priority:-1 extents:1 across:501740k SSFS
[ 3.436378] EXT4-fs (dasdb1): mounted filesystem with ordered data mode. Opts: (null)
[ 3.459612] EXT4-fs (dasda1): mounted filesystem with ordered data mode. Opts: (null)
[ 36.777259] random: crng init done
[ 123.421672] device-mapper: uevent: version 1.0.3
[ 123.421747] device-mapper: ioctl: 4.35.0-ioctl (2016-06-23) initialised: dm-devel@redhat.com
[ 124.163728] nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
[ 184.741563] ------------[ cut here ]------------
[ 184.741579] WARNING: CPU: 1 PID: 537 at crypto/algapi.c:348 crypto_wait_for_test+0x84/0x88
[ 184.741581] Modules linked in: ipt_REJECT nf_reject_ipv4 nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack iptable_filter dm_mirror dm_region_hash dm_log dm_mod xts gf128mul aes_s390(+) des_s390 des_generic sha512_s390 qeth_l2 vmur nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables ext4 jbd2 mbcache dasd_eckd_mod dasd_mod qeth ccwgroup qdio
[ 184.741598] CPU: 1 PID: 537 Comm: systemd-udevd Not tainted 4.10.0-rc3+ #4
[ 184.741601] Hardware name: IBM 2964 NE1 716 (z/VM)
[ 184.741605] task: 00000000f544e200 task.stack: 00000000f419c000
[ 184.741608] Krnl PSW : 0704f00180000000 00000000003cc484 (crypto_wait_for_test+0x84/0x88)
[ 184.741613] R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 RI:0 EA:3
[ 184.741616] Krnl GPRS: 0000000000058e00 00000000fffffe00 ffffffff00000001 0000000000000001
[ 184.741619] 00000000006863e0 00000000f3f00800 0000000000000000 000003ff80460850
[ 184.741633] 000003ff80460650 000003ff80460618 000003ff80460980 00000000f419fe88
[ 184.741634] 0000000000000000 00000000f4e40c00 00000000003cc45a 00000000f419fb60
[ 184.741644] Krnl Code: 00000000003cc476: f073a7f40001 srp 2036(8,%r10),1,3
00000000003cc47c: a7f4fff6 brc 15,3cc468
#00000000003cc480: a7f40001 brc 15,3cc482
>00000000003cc484: a7f4fff2 brc 15,3cc468
00000000003cc488: ebdff0800024 stmg %r13,%r15,128(%r15)
00000000003cc48e: a7f13fc0 tmll %r15,16320
00000000003cc492: b90400ef lgr %r14,%r15
00000000003cc496: e3f0ffd0ff71 lay %r15,-48(%r15)
[ 184.741658] Call Trace:
[ 184.741659] ([<00000000003cc45a>] crypto_wait_for_test+0x5a/0x88)
[ 184.741661] [<00000000003cc7ee>] crypto_register_alg+0x76/0x88
[ 184.741712] [<000003ff8045e490>] aes_s390_register_alg+0x28/0xb98 [aes_s390]
[ 184.741722] [<000003ff80463116>] cpu_feature_match_MSA_init+0x116/0x1000 [aes_s390]
[ 184.741724] [<0000000000100276>] do_one_initcall+0x46/0x148
[ 184.741729] [<000000000024e264>] do_init_module+0x74/0x218
[ 184.741735] [<00000000001cc586>] load_module+0x141e/0x1888
[ 184.741737] [<00000000001ccbd0>] SyS_finit_module+0x98/0xd0
[ 184.741741] [<000000000068a1e6>] system_call+0xd6/0x25c
[ 184.741742] Last Breaking-Event-Address:
[ 184.741743] [<00000000003cc480>] crypto_wait_for_test+0x80/0x88
[ 184.741744] ---[ end trace bf4d899231b60bca ]---
[ 184.741765] ------------[ cut here ]------------
[ 184.741767] WARNING: CPU: 1 PID: 537 at crypto/algapi.c:342 crypto_wait_for_test+0x7c/0x88
[ 184.741768] Modules linked in: ipt_REJECT nf_reject_ipv4 nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack iptable_filter dm_mirror dm_region_hash dm_log dm_mod xts gf128mul aes_s390(+) des_s390 des_generic sha512_s390 qeth_l2 vmur nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables ext4 jbd2 mbcache dasd_eckd_mod dasd_mod qeth ccwgroup qdio
[ 184.741775] CPU: 1 PID: 537 Comm: systemd-udevd Tainted: G W 4.10.0-rc3+ #4
[ 184.741776] Hardware name: IBM 2964 NE1 716 (z/VM)
[ 184.741777] task: 00000000f544e200 task.stack: 00000000f419c000
[ 184.741778] Krnl PSW : 0704c00180000000 00000000003cc47c (crypto_wait_for_test+0x7c/0x88)
[ 184.741780] R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3
[ 184.741781] Krnl GPRS: 0000000000000001 0000000000008001 0000000000000001 0000000000000002
[ 184.741783] 00000000003cc432 000000000000115e 0000000000000000 000003ff80460850
[ 184.741784] 000003ff80460650 000003ff80460618 000003ff80460980 00000000f419fe88
[ 184.741785] 0000000000000000 00000000f6f3d000 00000000003cc432 00000000f419fb60
[ 184.741788] Krnl Code: 00000000003cc46c: ebdff0a00004 lmg %r13,%r15,160(%r15)
00000000003cc472: c0f4fffff073 brcl 15,3ca558
#00000000003cc478: a7f40001 brc 15,3cc47a
>00000000003cc47c: a7f4fff6 brc 15,3cc468
00000000003cc480: a7f40001 brc 15,3cc482
00000000003cc484: a7f4fff2 brc 15,3cc468
00000000003cc488: ebdff0800024 stmg %r13,%r15,128(%r15)
00000000003cc48e: a7f13fc0 tmll %r15,16320
[ 184.741799] Call Trace:
[ 184.741801] ([<00000000003cc432>] crypto_wait_for_test+0x32/0x88)
[ 184.741803] [<00000000003cc7ee>] crypto_register_alg+0x76/0x88
[ 184.741811] [<000003ff8045e490>] aes_s390_register_alg+0x28/0xb98 [aes_s390]
[ 184.741819] [<000003ff8046316a>] cpu_feature_match_MSA_init+0x16a/0x1000 [aes_s390]
[ 184.741820] [<0000000000100276>] do_one_initcall+0x46/0x148
[ 184.741822] [<000000000024e264>] do_init_module+0x74/0x218
[ 184.741823] [<00000000001cc586>] load_module+0x141e/0x1888
[ 184.741824] [<00000000001ccbd0>] SyS_finit_module+0x98/0xd0
[ 184.741825] [<000000000068a1e6>] system_call+0xd6/0x25c
[ 184.741826] Last Breaking-Event-Address:
[ 184.741827] [<00000000003cc478>] crypto_wait_for_test+0x78/0x88
[ 184.741828] ---[ end trace bf4d899231b60bcb ]---
[ 184.744229] alg: Unexpected test result for xts-aes-s390: 0
[ 184.786242] loop: module loaded
[ 184.994173] IPv6: ADDRCONF(NETDEV_UP): enccw0.0.1000: link is not ready
[ 190.719762] nr_pdflush_threads exported in /proc is scheduled for removal
[ 191.041285] ip6_tables: (C) 2000-2006 Netfilter Core Team
[...]
Thanks,
Daniel
^ permalink raw reply
* Re: [PATCH v2 7/8] net: Rename TCA*BPF_DIGEST to ..._SHA256
From: Daniel Borkmann @ 2017-01-13 23:08 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Andy Lutomirski, Netdev, LKML, Linux Crypto Mailing List,
Jason A. Donenfeld, Hannes Frederic Sowa, Alexei Starovoitov,
Eric Dumazet, Eric Biggers, Tom Herbert, David S. Miller,
Alexei Starovoitov
In-Reply-To: <CALCETrVhuszdsfayLrBBkSzJ+A3m+hJjdZQWDj9FOg+2UB_ZBw@mail.gmail.com>
On 01/11/2017 07:19 PM, Andy Lutomirski wrote:
> On Wed, Jan 11, 2017 at 1:09 AM, Daniel Borkmann <daniel@iogearbox.net> wrote:
[...]
>> Ok. Sleeping over this a bit, how about a general rename into
>> "prog_tag" for fdinfo and TCA_BPF_TAG resp. TCA_ACT_BPF_TAG for
>> the netlink attributes, fwiw, it might reduce any assumptions on
>> this being made? If this would be preferable, I could cook that
>> patch against -net for renaming it?
>
> That would be fine with me.
>
> I think there are two reasonable approaches to computing the actual tag.
>
> 1. Use a standard, modern cryptographic hash. SHA-256, SHA-512,
> Blake2b, whatever. SHA-1 is a bad choice in part because it's partly
> broken and in part because the implementation in lib/ is a real mess
> to use (as you noticed while writing the code).
>
> 2. Use whatever algorithm you like but make the tag so short that it's
> obviously not collision-free. 48 or 64 bits is probably reasonable.
>
> The intermediate versions are just asking for trouble.
Yeah agree, I've just sent a patch to rework this a bit and it got
also reasonably small for net. Cleanups, if needed, can be done in
net-next once that's pulled into it.
Thanks,
Daniel
^ permalink raw reply
* Re: [PATCH v2] virtio-crypto: adjust priority of algorithm
From: Herbert Xu @ 2017-01-13 14:37 UTC (permalink / raw)
To: Gonglei; +Cc: virtualization, linux-crypto, linux-kernel, mst, borntraeger
In-Reply-To: <1484300056-35284-1-git-send-email-arei.gonglei@huawei.com>
On Fri, Jan 13, 2017 at 05:34:16PM +0800, Gonglei wrote:
> Some hardware accelerators (like intel aesni or the s390
> cpacf functions) have lower priorities than virtio
> crypto, and those drivers are faster than the same in
> the host via virtio. So let's lower the priority of
> virtio-crypto's algorithm, make it's higher than software
> implementations but lower than the hardware ones.
>
> Suggested-by: Christian Borntraeger <borntraeger@de.ibm.com>
> Signed-off-by: Gonglei <arei.gonglei@huawei.com>
> Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
Patch applied. 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] crypto: arm/aes - avoid reserved 'tt' mnemonic in asm code
From: Herbert Xu @ 2017-01-13 14:37 UTC (permalink / raw)
To: Ard Biesheuvel; +Cc: linux-crypto, linux-arm-kernel, arnd
In-Reply-To: <1484296406-13224-1-git-send-email-ard.biesheuvel@linaro.org>
On Fri, Jan 13, 2017 at 08:33:26AM +0000, Ard Biesheuvel wrote:
> The ARMv8-M architecture introduces 'tt' and 'ttt' instructions,
> which means we can no longer use 'tt' as a register alias on recent
> versions of binutils for ARM. So replace the alias with 'ttab'.
>
> Fixes: 81edb4262975 ("crypto: arm/aes - replace scalar AES cipher")
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Patch applied. 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 -next] crypto: mediatek - make symbol of_crypto_id static
From: Herbert Xu @ 2017-01-13 14:37 UTC (permalink / raw)
To: Wei Yongjun
Cc: Matthias Brugger, Ryder Lee, Wei Yongjun, linux-crypto,
linux-arm-kernel, linux-mediatek
In-Reply-To: <20170112150321.4187-1-weiyj.lk@gmail.com>
On Thu, Jan 12, 2017 at 03:03:21PM +0000, Wei Yongjun wrote:
> From: Wei Yongjun <weiyongjun1@huawei.com>
>
> Fixes the following sparse warning:
>
> drivers/crypto/mediatek/mtk-platform.c:585:27: warning:
> symbol 'of_crypto_id' was not declared. Should it be static?
>
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Patch applied. 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 0/4] n2rng: add support for m5/m7 rng register layout
From: Herbert Xu @ 2017-01-13 14:37 UTC (permalink / raw)
To: Shannon Nelson; +Cc: linux-crypto, sparclinux, linux-kernel
In-Reply-To: <1484247169-245086-1-git-send-email-shannon.nelson@oracle.com>
On Thu, Jan 12, 2017 at 10:52:45AM -0800, Shannon Nelson wrote:
> Commit c1e9b3b0eea1 ("hwrng: n2 - Attach on T5/M5, T7/M7 SPARC CPUs")
> added config strings to enable the random number generator in the sparc
> m5 and m7 platforms. This worked fine for client LDoms, but not for the
> primary LDom, or running on bare metal, because the actual rng hardware
> layout changed and self-test would now fail, continually spewing error
> messages on the console.
>
> This patch series adds correct support for the new rng register layout,
> and adds a limiter to the spewing of error messages.
All applied. 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] crypto: testmgr - use calculated count for number of test vectors
From: Herbert Xu @ 2017-01-13 14:32 UTC (permalink / raw)
To: Ard Biesheuvel; +Cc: linux-crypto
In-Reply-To: <1484228439-28373-1-git-send-email-ard.biesheuvel@linaro.org>
On Thu, Jan 12, 2017 at 01:40:39PM +0000, Ard Biesheuvel wrote:
> When working on AES in CCM mode for ARM, my code passed the internal
> tcrypt test before I had even bothered to implement the AES-192 and
> AES-256 code paths, which is strange because the tcrypt does contain
> AES-192 and AES-256 test vectors for CCM.
>
> As it turned out, the define AES_CCM_ENC_TEST_VECTORS was out of sync
> with the actual number of test vectors, causing only the AES-128 ones
> to be executed.
>
> So get rid of the defines, and wrap the test vector references in a
> macro that calculates the number of vectors automatically.
>
> The following test vector counts were out of sync with the respective
> defines:
>
> BF_CTR_ENC_TEST_VECTORS 2 -> 3
> BF_CTR_DEC_TEST_VECTORS 2 -> 3
> TF_CTR_ENC_TEST_VECTORS 2 -> 3
> TF_CTR_DEC_TEST_VECTORS 2 -> 3
> SERPENT_CTR_ENC_TEST_VECTORS 2 -> 3
> SERPENT_CTR_DEC_TEST_VECTORS 2 -> 3
> AES_CCM_ENC_TEST_VECTORS 8 -> 14
> AES_CCM_DEC_TEST_VECTORS 7 -> 17
> AES_CCM_4309_ENC_TEST_VECTORS 7 -> 23
> AES_CCM_4309_DEC_TEST_VECTORS 10 -> 23
> CAMELLIA_CTR_ENC_TEST_VECTORS 2 -> 3
> CAMELLIA_CTR_DEC_TEST_VECTORS 2 -> 3
>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Patch applied. 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
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