| Message ID | CAKv+Gu8fmBYwfrMKRqhA5KhU1HNjMP1cLtpmgCmp78R4CUw3fg@mail.gmail.com (mailing list archive) |
|---|---|
| State | Not Applicable |
| Delegated to: | Herbert Xu |
| Headers | show |
Hi, >>> Have you tested this code with the tcrypt.ko module? >> >> I have not, but I can look into it. >> >>> Did you talk to Andy about the license? I don't think this is >>> permissible for the kernel as-is. >> >> Unless I have misunderstood something, the license at the Cryptogams >> website includes an option to license the code under the GNU GPL. >> >> However, I can certainly contact Andy to clarify his intentions. I have no problems with reusing assembly modules in kernel context. The whole idea behind cryptogams initiative was exactly to reuse code in different contexts. But I'd prefer if it's more of cooperative effort, when we help each other to improve code, test on and tune for more platforms single developer might have access to, cross-report problems, etc. For this reason I'd prefer if it can be arranged in way similar to bsaes-armv7 module, i.e. we work together on shared copy of module that generates assembly that can be then compiled for OpenSSL or kernel. Is it sensible? BTW, why stop at SHA256? There is SHA512 and NEON SHA1... As for practicalities. In order to spare brain capacity for list subscribers, it would probably be appropriate to work out details such as naming of entry points in smaller group and present result when it's ready to go and tests. I'll start by looking at Thumb-ification... Cheers. -- 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
On Tue, Mar 17, 2015 at 04:09:40PM +0100, Andy Polyakov wrote: > I have no problems with reusing assembly modules in kernel context. Awesome, thank you for clarifying this. > I'd prefer if it can be arranged in way similar to bsaes-armv7 module, > i.e. we work together on shared copy of module that generates assembly > that can be then compiled for OpenSSL or kernel. Is it sensible? Sure, that sounds good to me. > BTW, why stop at SHA256? There is SHA512 and NEON SHA1... The kernel already has NEON SHA-1 and SHA-512, but for some reason is lacking SHA-256. I have not tested how they compare to yours though. Sami -- 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
On 17 March 2015 at 16:09, Andy Polyakov <appro@openssl.org> wrote: > Hi, > >>>> Have you tested this code with the tcrypt.ko module? >>> >>> I have not, but I can look into it. >>> >>>> Did you talk to Andy about the license? I don't think this is >>>> permissible for the kernel as-is. >>> >>> Unless I have misunderstood something, the license at the Cryptogams >>> website includes an option to license the code under the GNU GPL. >>> >>> However, I can certainly contact Andy to clarify his intentions. > > I have no problems with reusing assembly modules in kernel context. The > whole idea behind cryptogams initiative was exactly to reuse code in > different contexts. But I'd prefer if it's more of cooperative effort, > when we help each other to improve code, test on and tune for more > platforms single developer might have access to, cross-report problems, > etc. For this reason I'd prefer if it can be arranged in way similar to > bsaes-armv7 module, i.e. we work together on shared copy of module that > generates assembly that can be then compiled for OpenSSL or kernel. Is Yes, that is what I thought. @Sami, this also means we should integrate the .pl file and the generated .S. Please have a look at how I integrated Andy's bsaes-armv7.pl module. > it sensible? BTW, why stop at SHA256? There is SHA512 and NEON SHA1... > > As for practicalities. In order to spare brain capacity for list > subscribers, it would probably be appropriate to work out details such > as naming of entry points in smaller group and present result when it's > ready to go and tests. I'll start by looking at Thumb-ification... > @Andy: the core code builds without problems, but for Thumb2 there are some trivial changes to apply: - '.code 32' needs to be made conditional - use adr instead of pc arithmetic for the address of K256 - bic cannot use r13 as input/output, so it needs to go via another register - some conditional instructions need 'it' instructions added (not strictly necessary for the kernel, because it passes -mimplicit-it-thumb on the assembler command line, but nice for completeness) (see patch in other reply) I am happy to test and/or review stuff as well. Thanks, Ard. -- 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
--- a/arch/arm/crypto/sha256-armv7-neon.S +++ b/arch/arm/crypto/sha256-armv7-neon.S @@ -10,7 +10,6 @@ #include <linux/linkage.h> .text -.code 32 .fpu neon .type K256,%object @@ -44,15 +43,15 @@ ENTRY(sha256_transform_neon) * %r1: data * %r2: nblks */ - sub r3,pc,#8 @ sha256_transform_neon add r2,r1,r2,lsl#6 @ len to point at the end of inp stmdb sp!,{r4-r12,lr} mov r12,sp - sub sp,sp,#16*4+16 @ alloca - sub r14,r3,#256+32 @ K256 - bic sp,sp,#15 @ align for 128-bit stores + sub r14,sp,#16*4+16 @ alloca + bic r14,r14,#15 @ align for 128-bit stores + mov sp,r14 + adr r14,K256 vld1.8 {q0},[r1]! vld1.8 {q1},[r1]!