linux-kernel - Re: [PATCH] crypto: serpent - add x86

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 29 May 2012 00:33:38 +0300
From:	Jussi Kivilinna <jussi.kivilinna@...et.fi>
To:	Johannes Goetzfried 
	<Johannes.Goetzfried@...ormatik.stud.uni-erlangen.de>
Cc:	Herbert Xu <herbert@...dor.hengli.com.au>,
	linux-kernel@...r.kernel.org, linux-crypto@...r.kernel.org,
	Tilo Müller 
	<Tilo.Mueller@...ormatik.uni-erlangen.de>
Subject: Re: [PATCH] crypto: serpent - add x86_64/avx assembler
 implementation

Quoting Johannes Goetzfried  
<Johannes.Goetzfried@...ormatik.stud.uni-erlangen.de>:

> Hello,
>
>> Should be serpent_sse2_glue.c?
>
> Yeah, same error as in the other patch :-)
>
>> >+}, {
>> >+	.cra_name		= "ecb(serpent)",
>> >+	.cra_driver_name	= "ecb-serpent-avx",
>> >+	.cra_priority		= 400,
>>
>> serpent_sse2_glue.c has priority 400 too, so you should increase
>> priority here to 500.
>
> You are right. Actually it is useless to load both modules at the  
> same time and
> so this shouldn't be a problem. But better be safe. I'll resend this patch as
> well.
>

Thing is that since both have MODULE_ALIAS(serpent), they both get  
loaded with 'modprobe serpent' etc.

>> Actually about duplicating glue code.. is it really needed? On
>> x86_64, both avx and sse2 versions process 8-blocks parallel and
>> therefore glue code could be easily shared (as is done in SHA1
>> SSSE3/AVX).
>
> I thought about doing it the way as it is done in the SHA1-Module.  
> But I don't
> think that's a good idea, because then I had to compile both  
> implementations in
> the same module and decide at runtime which one to use depending on the
> processor capabilities. This would result in an increasing object  
> size and on a
> specific processor only one implementation is used. I think it's better to
> decide statically at compile-time which implementation to use.
> I agree, the code duplication is ugly, and have a different approach. All the
> glue code shared by both implementations can be moved to a  
> serpent_common_glue.c
> file and only the module init stuff needs to be seperate. This should reduce
> the code size and keeps the possibility of compiling only one  
> implementation. I
> will send a second patch which should do the job.
>

Looks better.

Maybe later when I have time, I'll check if all glue code for 16-byte  
block-ciphers found in arch/x86/crypto could be merged in to single  
helper module.

-Jussi

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/