Hi, Stephan,
On 29.05.2017 12:56, Stephan Müller wrote:
Am Montag, 29. Mai 2017, 11:47:48 CEST schrieb Tudor Ambarus:
Hi Tudor,
Hm, there should be no blocking for the DRBG to initialize.
What happens if you compile that as a module and insmod it at runtime?
We will have a nop:
#ifdef CONFIG_CRYPTO_MANAGER_DISABLE_TESTS
/* a perfect nop */
int alg_test(const char *driver, const char *alg, u32 type, u32 mask)
{
printk(KERN_ERR "no op in alg_test");
return 0;
}
#else
...
#endif
If I further mangle it and change #ifdef with #ifndef then the tests are
passing.
Can you please enable the testmgr in the kernel config and compile the DH/ECDH
code as a module. Then I would insmod the dh/ecdh kernel module to see whether
the self tests work or not.
dh/ecdh self tests are passing when I insert dh/ecdh modules.
Note, if you use the calls of crypto_get_default_rng and friends, the DRBG
must be present in the kernel at the time of calling. I.e. if you statically
compile dh/ecdh but compile the RNG support as a module, the RNG will not load
during self test. If you compile dh/ecdh as a module, the RNG can stay as a
module.
However, when the self tests are enabled and DH/ECDH code is built-in,
the kernel blocks.
I have to ensure that the drivers are loaded in the right order.
Deferring the probe or just simply changing the order of the object
files from crypto/Makefile solves the issue. I'll go with the second
approach.
Thanks,
ta
