Michal Suchánek [off-list ref] writes:

On Wed, Mar 20, 2024 at 11:41:32PM +1100, Michael Ellerman wrote:

quoted

Michal Suchánek [off-list ref] writes:

quoted

On Mon, Mar 18, 2024 at 06:08:55PM +0100, Michal Suchánek wrote:

quoted

On Mon, Mar 18, 2024 at 10:50:49PM +1100, Michael Ellerman wrote:

quoted

Michael Ellerman [off-list ref] writes:

quoted

Michal Suchánek [off-list ref] writes:

quoted

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 [off-list ref]. 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