[PATCH] arm64/crypto: use crypto instructions for generating AES key schedule

[Ard Biesheuvel]

On 22 October 2014 18:59, Catalin Marinas <catalin.marinas at arm.com> wrote:
> On Wed, Oct 22, 2014 at 05:31:32PM +0100, Ard Biesheuvel wrote:
>> On 22 October 2014 18:25, Catalin Marinas <catalin.marinas at arm.com> wrote:
>> > On Wed, Oct 22, 2014 at 08:15:32AM +0100, Ard Biesheuvel wrote:
>> >> This patch implements the AES key schedule generation using ARMv8
>> >> Crypto Instructions. It replaces the table based C implementation
>> >> in aes_generic.ko, which means we can drop the dependency on that
>> >> module.
>> >
>> > I don't really understand the AES stuff but there's something else I
>> > noticed: if you build a kernel with the crypto stuff and run it on an
>> > implementation that does not have the crypto extensions, there does not
>> > seem to be any check for not using these algorithms (or falling back to
>> > the generic implementation). Does the kernel end up with undef faults?
>>
>> No, that is handled by
>>
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=67bad2fdb754dbef14596c0b5d28b3a12c8dfe84
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=3be1a5c4f75989cf457f13f38ff0913dff6d4996
>>
>> and the modules use module_cpu_feature_match(), so they are only
>> installed if the corresponding hwcap bit is set.
>
> Ah, I remember that now. Does this allow to use the generic C
> implementation if the crypto extensions aren't available?
>

Yes. While CONFIG_AES is a tristate, it is effectively always =y due
to Kconfig options that depend on it, and the generic AES it controls
is installed with a low priority. So requests for the AES cipher will
be served by the generic implementation if no accelerated ones have
been installed. And even if it is only available as a module, it will
be loaded by udev if requests for 'aes' cannot be satisfied.

-- 
Ard.