netdev - Re: Cannot load wireguard module

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87frwjzr82.fsf@mail.lhotse>
Date: Thu, 21 Mar 2024 23:47:41 +1100
From: Michael Ellerman <mpe@...erman.id.au>
To: Michal Suchánek <msuchanek@...e.de>
Cc: netdev@...r.kernel.org, "Jason A. Donenfeld" <Jason@...c4.com>,
 linuxppc-dev@...ts.ozlabs.org, wireguard@...ts.zx2c4.com,
 dtsen@...ux.ibm.com, Herbert Xu <herbert@...dor.apana.org.au>
Subject: Re: Cannot load wireguard module

Michal Suchánek <msuchanek@...e.de> writes:
> On Wed, Mar 20, 2024 at 11:41:32PM +1100, Michael Ellerman wrote:
>> Michal Suchánek <msuchanek@...e.de> 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 <mpe@...erman.id.au> writes:
>> >> > > Michal Suchánek <msuchanek@...e.de> 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 <Jason@...c4.com>. 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