Hello,
running Fedora 27 on an Intel Atom C3758 CPU Supermicro system
(A2SDi-8C+-HLN4F) I've noticed that crypto selftests fail when the
qat_c3xxx module is loaded (it is loaded, by default). That means that
stuff like `modprobe dm-crypt`, `cryptsetup benchmark` and `cryptsetup
luksOpen` fail.
When I added generic-gcm-aes I didn't add a wrapper like the one
provided for rfc4106(gcm(aes)). We need to add a cryptd wrapper to fall
back on in case the FPU is not available, otherwise we might corrupt the
FPU state.
Fixes: cce2ea8d90fe ("crypto: aesni - add generic gcm(aes)")
Reported-by:
generic_gcmaes_decrypt needs to use generic_gcmaes_ctx, not
aesni_rfc4106_gcm_ctx. This is actually harmless because the fields in
struct generic_gcmaes_ctx share the layout of the same fields in
aesni_rfc4106_gcm_ctx.
Fixes: cce2ea8d90fe ("crypto: aesni - add generic gcm(aes)")
Signed-off-by:
On Wed, Dec 13, 2017 at 2:31 PM, Herbert Xu wrote:
> On Wed, Dec 13, 2017 at 11:12:10AM +0200, Gilad Ben-Yossef wrote:
>>
>> I'm sorry if I'm confused but as the cover letter stated, the patch
>> set is supposed to
>> go on top of the patch entitled "crypto: tcrypt -
On Wed, Dec 13, 2017 at 11:12:10AM +0200, Gilad Ben-Yossef wrote:
>
> I'm sorry if I'm confused but as the cover letter stated, the patch
> set is supposed to
> go on top of the patch entitled "crypto: tcrypt - fix S/G table for
> test_aead_speed()"
> which you stated will be applied
>
Hi Herbert,
On Mon, Dec 11, 2017 at 1:35 PM, Herbert Xu wrote:
> On Thu, Nov 30, 2017 at 10:09:32AM +, Gilad Ben-Yossef wrote:
>> The performance of some aead tfm providers is affected by
>> the amount of parallelism possible with the processing.
>>
>> Introduce
On Tue, Dec 12, 2017 at 5:36 PM, Łukasz Stelmach wrote:
> Reseed PRNG after reading 65 kB of randomness. Although this may reduce
> performance, in most cases the loss is not noticeable. Also the time
> based threshold for reseeding is changed to one second. Reseeding is
>
On Tue, Dec 12, 2017 at 5:36 PM, Łukasz Stelmach wrote:
> Use memcpy_fromio() instead of custom exynos_rng_copy_random() function
> to retrieve generated numbers from the registers of PRNG.
If I recall correctly, you mentioned before that it improves the
performance. If
On Tue, Dec 12, 2017 at 5:36 PM, Łukasz Stelmach wrote:
> Add support for PRNG in Exynos5250+ SoCs.
>
> Signed-off-by: Łukasz Stelmach
> ---
> .../bindings/crypto/samsung,exynos-rng4.txt| 4 +++-
> drivers/crypto/exynos-rng.c