Subject: Re: Cannot load wireguard module

From: Michael Ellerman <[email-masked]>
Date: Thu, 21 Mar 2024 23:47:41 +1100

Michal Suchánek <[email-masked]> writes:
> On Wed, Mar 20, 2024 at 11:41:32PM +1100, Michael Ellerman wrote:
>> Michal Suchánek <[email-masked]> writes:
>> > On Mon, Mar 18, 2024 at 06:08:55PM +0100, Michal Suchánek wrote:
>> >> On Mon, Mar 18, 2024 at 10:50:49PM +1100, Michael Ellerman wrote:
>> >> > Michael Ellerman <[email-masked]> writes:
>> >> > > Michal Suchánek <[email-masked]> writes:
>> >> > >> Hello,
>> >> > >>
>> >> > >> I cannot load the wireguard module.
>> >> > >>
>> >> > >> Loading the module provides no diagnostic other than 'No such device'.
>> >> > >>
>> >> > >> Please provide maningful diagnostics for loading software-only driver,
>> >> > >> clearly there is no particular device needed.
>> >> > >
>> >> > > Presumably it's just bubbling up an -ENODEV from somewhere.
>> >> > >
>> >> > > Can you get a trace of it?
>> >> > >
>> >> > > Something like:
>> >> > >
>> >> > >   # trace-cmd record -p function_graph -F modprobe wireguard
>> >
>> > Attached.
>> 
>> Sorry :/, you need to also trace children of modprobe, with -c.
>> 
>> But, I was able to reproduce the same issue here.
>> 
>> On a P9, a kernel with CONFIG_CRYPTO_CHACHA20_P10=n everything works:
>> 
>>   $ modprobe -v wireguard
>>   insmod /lib/modules/6.8.0/kernel/net/ipv4/udp_tunnel.ko
>>   insmod /lib/modules/6.8.0/kernel/net/ipv6/ip6_udp_tunnel.ko
>>   insmod /lib/modules/6.8.0/kernel/lib/crypto/libchacha.ko
>>   insmod /lib/modules/6.8.0/kernel/lib/crypto/libchacha20poly1305.ko
>>   insmod /lib/modules/6.8.0/kernel/drivers/net/wireguard/wireguard.ko
>>   [   19.180564][  T692] wireguard: allowedips self-tests: pass
>>   [   19.185080][  T692] wireguard: nonce counter self-tests: pass
>>   [   19.310438][  T692] wireguard: ratelimiter self-tests: pass
>>   [   19.310639][  T692] wireguard: WireGuard 1.0.0 loaded. See www.wireguard.com for information.
>>   [   19.310746][  T692] wireguard: Copyright (C) 2015-2019 Jason A. Donenfeld <[email-masked]>. All Rights Reserved.
>> 
>> 
>> If I build CONFIG_CRYPTO_CHACHA20_P10 as a module then it breaks:
>> 
>>   $ modprobe -v wireguard
>>   insmod /lib/modules/6.8.0/kernel/net/ipv4/udp_tunnel.ko
>>   insmod /lib/modules/6.8.0/kernel/net/ipv6/ip6_udp_tunnel.ko
>>   insmod /lib/modules/6.8.0/kernel/lib/crypto/libchacha.ko
>>   insmod /lib/modules/6.8.0/kernel/arch/powerpc/crypto/chacha-p10-crypto.ko
>>   modprobe: ERROR: could not insert 'wireguard': No such device
>> 
>> 
>> The ENODEV is coming from module_cpu_feature_match(), which blocks the
>> driver from loading on non-p10.
>> 
>> Looking at other arches (arm64 at least) it seems like the driver should
>> instead be loading but disabling the p10 path. Which then allows
>> chacha_crypt_arch() to exist, and it has a fallback to use
>> chacha_crypt_generic().
>> 
>> I don't see how module_cpu_feature_match() can co-exist with the driver
>> also providing a fallback. Hopefully someone who knows crypto better
>> than me can explain it.
>
> Maybe it doesn't. ppc64le is the only platform that needs the fallback,
> on other platforms that have hardware-specific chacha implementation it
> seems to be using pretty common feature so the fallback is rarely if
> ever needed in practice.

Yeah you are probably right.

The arm64 NEON code was changed by Ard to behave like a library in
b3aad5bad26a ("crypto: arm64/chacha - expose arm64 ChaCha routine as
library function").

Which included this change:

@@ -179,14 +207,17 @@ static struct skcipher_alg algs[] = {
 static int __init chacha_simd_mod_init(void)
 {
        if (!cpu_have_named_feature(ASIMD))
-               return -ENODEV;
+               return 0;
+
+       static_branch_enable(&have_neon);

        return crypto_register_skciphers(algs, ARRAY_SIZE(algs));
 }

It didn't use module_cpu_feature_match(), but the above is basically the
same pattern.

I don't actually see the point of using module_cpu_feature_match() for
this code.

There's no point loading it unless someone wants to use chacha, and that
should be handled by MODULE_ALIAS_CRYPTO("chacha20") etc.

cheers