On 22 October 2014 18:59, Catalin Marinas <catalin.marinas@xxxxxxx> wrote: > On Wed, Oct 22, 2014 at 05:31:32PM +0100, Ard Biesheuvel wrote: >> On 22 October 2014 18:25, Catalin Marinas <catalin.marinas@xxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
