Hi Herbert,
On Tue, Apr 09, 2019 at 02:24:09PM +0800, Herbert Xu wrote:
>
> > BTW, I found another problem caused by allocating the generic implementation
> > during the self-tests, which is that the generic implementation will fulfill any
> > outstanding allocation requests before the other implementation has finished
> > testing. E.g. on x86_64, the first call to
> >
> > crypto_alloc_skcipher("adiantum(xchacha12,aes)", 0, 0)
> >
> > will get "adiantum(xchacha12-generic,aes-generic,nhpoly1305-generic)" rather
> > than "adiantum(xchacha12-simd,aes-aesni,nhpoly1305-avx2)" as expected. Do you
> > have any suggestion on the best way to fix this?
>
> Well this is to be expected. Normally we don't start the allocation
> until all probing is done. That is, all modules should have been
> loaded before (or rather during) the first allocation call. If it
> occurs during the first allocation call then a larval algorithm will
> hold any subsequent allocations until the testing is done.
>
> So the question is who is doing the allocation prior the registration
> of the accelerated algorithms? Is it the fuzzing test?
>
All modules are already loaded, but there's no "adiantum(xchacha12,aes)"
algorithm directly available so it has be instantiated using the template.
Then with CONFIG_CRYPTO_MANAGER_EXTRA_TESTS=y, the self-tests for the
accelerated instance will allocate a generic instance to compare it against.
This causes the generic instance to be tested and registered first, so the first
user will get the generic instance, not the accelerated one as expected.
- Eric
