Re: {twofish,aes}-{x86_64,i586} versus C implementations

[Sebastian Siewior <linux-crypto@ml.breakpoint.cc>]

* Andi Kleen | 2007-08-20 12:16:18 [+0200]:

>> Are you sure you get the C version when both are built-in
>> or loaded as modules? If so then we have a bug in the priority
>> code.
>
>The usual use case is: Somebody -- either admin or some command 
>implicitely -- executes modprobe aes because some text file
>specifies the aes cipher. At least on my system that loads
>the C version when both are enabled. modprobe will not load
>multiple modules in this case.
>
>I don't think modprobe knows anything about these priorities.

Not modprobe, but the crypto subsystem. If you have the generic C code
and the assembly variant it picks the assembly over C. The selection is
done before the particular subsystem, dm-crypt for instance, requests
the algorithm / module. It makes no sense to load the AES-i586 module
_after_ it is in use (dm-crypt loaded the encrypted root partition).
However, further requests will get the assembly variant.

>> We don't, but the system is meant to allow multiple
>> implementations to coexist and picking the best one
>> at run-time.
>
>But that would require teaching the module loading user space
>about all this first, right?

In that case yes. Would it help to add MODULE_ALIAS("aes") to the
assembly version in order to load it (atleast both)?

>Also if one implementation is always better than the other
>then I see little reason to ever have both.

If you are sure that nobody needs aes on machnies prio i586 than you
could disable the generic version on i386. Also on x86_64 the generic
version isn't required since an assembly optimized version is provided.
BUT: you might get into some trouble if you remove it from selections
because some modules select it automaticly, IEEE80211_CRYPT_CCMP for
instance.

>-Andi

Sebastian