From: Michael Ellerman <mpe@ellerman.id.au>
To: "Michal Suchánek" <msuchanek@suse.de>
Cc: "Jason A. Donenfeld" <Jason@zx2c4.com>,
Herbert Xu <herbert@gondor.apana.org.au>,
netdev@vger.kernel.org, dtsen@linux.ibm.com,
linuxppc-dev@lists.ozlabs.org, wireguard@lists.zx2c4.com
Subject: Re: Cannot load wireguard module
Date: Thu, 21 Mar 2024 23:47:41 +1100 [thread overview]
Message-ID: <87frwjzr82.fsf@mail.lhotse> (raw)
In-Reply-To: <20240320160428.GQ20665@kitsune.suse.cz>
Michal Suchánek <msuchanek@suse.de> writes:
> On Wed, Mar 20, 2024 at 11:41:32PM +1100, Michael Ellerman wrote:
>> Michal Suchánek <msuchanek@suse.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@ellerman.id.au> writes:
>> >> > > Michal Suchánek <msuchanek@suse.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@zx2c4.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
WARNING: multiple messages have this Message-ID (diff)
From: Michael Ellerman <mpe@ellerman.id.au>
To: "Michal Suchánek" <msuchanek@suse.de>
Cc: netdev@vger.kernel.org, "Jason A. Donenfeld" <Jason@zx2c4.com>,
linuxppc-dev@lists.ozlabs.org, wireguard@lists.zx2c4.com,
dtsen@linux.ibm.com, Herbert Xu <herbert@gondor.apana.org.au>
Subject: Re: Cannot load wireguard module
Date: Thu, 21 Mar 2024 23:47:41 +1100 [thread overview]
Message-ID: <87frwjzr82.fsf@mail.lhotse> (raw)
In-Reply-To: <20240320160428.GQ20665@kitsune.suse.cz>
Michal Suchánek <msuchanek@suse.de> writes:
> On Wed, Mar 20, 2024 at 11:41:32PM +1100, Michael Ellerman wrote:
>> Michal Suchánek <msuchanek@suse.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@ellerman.id.au> writes:
>> >> > > Michal Suchánek <msuchanek@suse.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@zx2c4.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
next prev parent reply other threads:[~2024-03-21 12:48 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-15 12:20 Cannot load wireguard module Michal Suchánek
2024-03-15 12:37 ` Christophe Leroy
2024-03-15 13:05 ` Michal Suchánek
2024-03-15 13:05 ` Michal Suchánek
2024-03-15 23:44 ` Michael Ellerman
2024-03-15 23:44 ` Michael Ellerman
2024-03-18 11:50 ` Michael Ellerman
2024-03-18 11:50 ` Michael Ellerman
2024-03-18 17:08 ` Michal Suchánek
2024-03-18 17:08 ` Michal Suchánek
2024-03-19 12:47 ` Michal Suchánek
2024-03-19 12:47 ` Michal Suchánek
2024-03-20 12:41 ` Michael Ellerman
2024-03-20 12:41 ` Michael Ellerman
2024-03-20 16:04 ` Michal Suchánek
2024-03-20 16:04 ` Michal Suchánek
2024-03-21 12:47 ` Michael Ellerman [this message]
2024-03-21 12:47 ` Michael Ellerman
2024-03-22 11:33 ` Herbert Xu
2024-03-22 11:33 ` Herbert Xu
2024-03-23 0:18 ` Michael Ellerman
2024-03-23 0:18 ` Michael Ellerman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87frwjzr82.fsf@mail.lhotse \
--to=mpe@ellerman.id.au \
--cc=Jason@zx2c4.com \
--cc=dtsen@linux.ibm.com \
--cc=herbert@gondor.apana.org.au \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=msuchanek@suse.de \
--cc=netdev@vger.kernel.org \
--cc=wireguard@lists.zx2c4.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.