Commit 3d387ef08c4 (Revert "crypto: blowfish - add AVX2/x86_64 implementation
of blowfish cipher") reverted too much as it removed the 'assembler supports
AVX2' check and therefore disabled remaining AVX2 implementations of Camellia
and Serpent. Patch restores the check and enables these implementa
Commit a710f761f (crypto: sha256_ssse3 - add sha224 support) attempted to add
MODULE_ALIAS for SHA-224, but it ended up being "sha384", probably because
mix-up with previous commit 340991e30 (crypto: sha512_ssse3 - add sha384
support). Patch corrects module alias to "sha224".
Reported-by: Pierre-M
On 03.09.2013 16:01, Jussi Kivilinna wrote:
> On 03.09.2013 15:36, Pierre-Mayeul Badaire wrote:
>> Good afternoon,
>>
>> Don't you have a mistake on the MODULE_ALIAS at the last line of the commit
>> ? Shouldn't it be MODULE_ALIAS("sha224") here ?
>
> Yes, that's correct, it should be "ssh224" in
On 03.09.2013 15:36, Pierre-Mayeul Badaire wrote:
> Good afternoon,
>
> Don't you have a mistake on the MODULE_ALIAS at the last line of the commit ?
> Shouldn't it be MODULE_ALIAS("sha224") here ?
Yes, that's correct, it should be "ssh224" instead of "sha384". I'll post patch
soon.
-Jussi
>
I'm seeing a GPF when code on several CPUs calls crypto_alloc_aead at
the same time, and in order for crypto_alloc_aead to satisfy the
request, it needs to lookup a kernel module (in this case aesni_intel
and aes_x86_64).
Shouldn't the bulk of the code in crypto_alg_mod_lookup be protected by
On Thu, 22 Aug, at 07:01:49PM, Lee, Chun-Yi wrote:
> From: Matthew Garrett
>
> The firmware has a set of flags that indicate whether secure boot is enabled
> and enforcing. Use them to indicate whether the kernel should lock itself
> down. We also indicate the machine is in secure boot mode by a
