From gregkh at linuxfoundation.org  Fri Jul  1 08:38:30 2022
From: gregkh at linuxfoundation.org (Greg KH)
Date: Fri, 1 Jul 2022 10:38:30 +0200
Subject: [PATCH] pm/sleep: Add PM_USERSPACE_AUTOSLEEP Kconfig
In-Reply-To: <Yr3+RLhpp3g9A7vb@zx2c4.com>
References: <20220630191230.235306-1-kaleshsingh@google.com>
 <Yr3+RLhpp3g9A7vb@zx2c4.com>
Message-ID: <Yr6yhnZNkCDgde9z@kroah.com>

On Thu, Jun 30, 2022 at 09:49:24PM +0200, Jason A. Donenfeld wrote:
> Hi Kalesh,
> 
> On Thu, Jun 30, 2022 at 07:12:29PM +0000, Kalesh Singh wrote:
> > Systems that initiate frequent suspend/resume from userspace
> > can make the kernel aware by enabling PM_USERSPACE_AUTOSLEEP
> > config.
> > 
> > This allows for certain sleep-sensitive code (wireguard/rng) to
> > decide on what preparatory work should be performed (or not) in
> > their pm_notification callbacks.
> > 
> > This patch was prompted by the discussion at [1] which attempts
> > to remove CONFIG_ANDROID that currently guards these code paths.
> > 
> > [1] https://lore.kernel.org/r/20220629150102.1582425-1-hch at lst.de/
> > 
> > Suggested-by: Jason A. Donenfeld <Jason at zx2c4.com>
> > Signed-off-by: Kalesh Singh <kaleshsingh at google.com>
> 
> Thanks, looks good to me. Do you have a corresponding Gerrit link to the
> change adding this to the base Android kernel config? If so, have my
> Ack:
> 
>     Acked-by: Jason A. Donenfeld <Jason at zx2c4.com>

Cool, I'll queue this up and also the CONFIG_ANDROID removal into my
tree now, thanks all for working it out!

greg k-h

From Jason at zx2c4.com  Fri Jul  1 20:53:36 2022
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Fri, 1 Jul 2022 22:53:36 +0200
Subject: [PATCH] remove CONFIG_ANDROID
In-Reply-To: <87a69slh0x.fsf@meer.lwn.net>
References: <20220629163007.GA25279@lst.de> <Yrx/8UOY+J8Ao3Bd@zx2c4.com>
 <YryNQvWGVwCjJYmB@zx2c4.com> <Yryic4YG9X2/DJiX@google.com>
 <Yry6XvOGge2xKx/n@zx2c4.com>
 <CAC_TJve_Jk0+XD7VeSJVvJq4D9ZofnH69B4QZv2LPT4X3KNfeg@mail.gmail.com>
 <YrzaCRl9rwy9DgOC@zx2c4.com>
 <CANDhNCpRzzULaGmEGCbbJgVinA0pJJB-gOP9AY0Hy488n9ZStA@mail.gmail.com>
 <YrztOqBBll66C2/n@zx2c4.com> <87a69slh0x.fsf@meer.lwn.net>
Message-ID: <Yr9e0JnUbu93Qq1p@zx2c4.com>

Hi Jon,

On Fri, Jul 01, 2022 at 02:22:38PM -0600, Jonathan Corbet wrote:
> So please forgive the noise from the peanut gallery

Yuh oh, I sure hope this isn't newsworthy for LWN. This has already
consumed me for two days...

> myself wondering...do you really need a knob for this?  The kernel
> itself can observe how often (and for how long) the system is suspended,
> and might well be able to do the right thing without explicit input from
> user space.  If it works it would eliminate a potential configuration
> problem and also perhaps respond correctly to changing workloads.
> 
> For example, rather than testing a knob, avoid resetting keys on resume
> if the suspend time is less than (say) 30s?
> 
> Educate me on what I'm missing here, please :)

What you're missing is that wireguard needs to do this before going to
sleep, not when waking up, because one of the objectives is forward
secrecy. See
https://git.zx2c4.com/wireguard-linux/tree/drivers/net/wireguard/device.c#n63

	if (IS_ENABLED(CONFIG_PM_AUTOSLEEP) || IS_ENABLED(CONFIG_ANDROID))
		return 0;
	if (action != PM_HIBERNATION_PREPARE && action != PM_SUSPEND_PREPARE)
		return 0;
	[...]
	wg_noise_handshake_clear(&peer->handshake);
	wg_noise_keypairs_clear(&peer->keypairs);

Somebody asked the same question on wgml here -
https://lore.kernel.org/wireguard/CAHmME9p2OYSTX2C5M0faKtw2N8jiyohvRqnAPKa=e7BWynF7fQ at mail.gmail.com/T/
- and then eventually suggested that I should wake up computers from
sleep to clear that memory. No way jose.

Anyway, this matter has been resolved in this thread here:
https://lore.kernel.org/lkml/20220630191230.235306-1-kaleshsingh at google.com/T/
And this Android change:
https://android-review.googlesource.com/c/kernel/common/+/2142693/1
Resulting in these two commits landing in Greg's tree:
https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git/commit/?id=261e224d6a5c43e2bb8a07b7662f9b4ec425cfec
https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git/commit/?id=1045a06724f322ed61f1ffb994427c7bdbe64647
So hopefully this thread can come to an end and I can get back to work.

Jason

From corbet at lwn.net  Fri Jul  1 20:22:38 2022
From: corbet at lwn.net (Jonathan Corbet)
Date: Fri, 01 Jul 2022 14:22:38 -0600
Subject: [PATCH] remove CONFIG_ANDROID
In-Reply-To: <YrztOqBBll66C2/n@zx2c4.com>
References: <20220629161527.GA24978@lst.de> <Yrx8/Fyx15CTi2zq@zx2c4.com>
 <20220629163007.GA25279@lst.de> <Yrx/8UOY+J8Ao3Bd@zx2c4.com>
 <YryNQvWGVwCjJYmB@zx2c4.com> <Yryic4YG9X2/DJiX@google.com>
 <Yry6XvOGge2xKx/n@zx2c4.com>
 <CAC_TJve_Jk0+XD7VeSJVvJq4D9ZofnH69B4QZv2LPT4X3KNfeg@mail.gmail.com>
 <YrzaCRl9rwy9DgOC@zx2c4.com>
 <CANDhNCpRzzULaGmEGCbbJgVinA0pJJB-gOP9AY0Hy488n9ZStA@mail.gmail.com>
 <YrztOqBBll66C2/n@zx2c4.com>
Message-ID: <87a69slh0x.fsf@meer.lwn.net>

"Jason A. Donenfeld" <Jason at zx2c4.com> writes:

> I guess what I have in mind is the answer to these being "yes":
> - "Is it very common to be asleep for only 2 seconds before being woken?"
> - "Is it very common to be awake for only 2 seconds before sleeping?"
>
> I think it'd be easiest to have a knob somewhere (compiletime,
> runtime, wherever) that describes a device that exhibits those
> properties. Then wireguard and other things will make a decision on how
> to handle the crypto during relevant events.

So please forgive the noise from the peanut gallery, but I do find
myself wondering...do you really need a knob for this?  The kernel
itself can observe how often (and for how long) the system is suspended,
and might well be able to do the right thing without explicit input from
user space.  If it works it would eliminate a potential configuration
problem and also perhaps respond correctly to changing workloads.

For example, rather than testing a knob, avoid resetting keys on resume
if the suspend time is less than (say) 30s?

Educate me on what I'm missing here, please :)

Thanks,

jon

From david at bamsoftware.com  Sat Jul  2 23:21:07 2022
From: david at bamsoftware.com (David Fifield)
Date: Sat, 2 Jul 2022 19:21:07 -0400
Subject: WireGuard protocol blocking in China, swgp-go (userspace
 obfuscation proxy)
In-Reply-To: <87pmjbpele.fsf@ungleich.ch>
References: <20220609220522.kwqa4uvuc3sijlka@bamsoftware.com>
 <87pmjbpele.fsf@ungleich.ch>
Message-ID: <20220702232107.ofaioenh3twoqdfd@bamsoftware.com>

On Tue, Jun 14, 2022 at 03:13:11PM +0200, Nico Schottelius wrote:
> > I am forwarding some information about WireGuard blocking and
> > anti-blocking that was posted to a censorship circumvention forum.
> 
> In regards to this topic I was wondering if it makes sense to have a
> more generic obfuscation proxy that can carry tcp/udp payload?
> 
> Maybe this already exists, but I would think that something that hops
> protocols (IPv6, IPv4 endpoints, tcp/udp encapsolution), changes ports
> and uses envelope based tunneling (http, https, smtp, imap - worst case
> DNS) would make it easier to sustain communication even in more serious
> filtering scenarios.
> 
> Given such a "generic obfuscator", it could be combined with "protocol"
> modes, i.e. enhancing protocols such as wireguard with the presented
> algorithm, making it even harder to predict the content.
> 
> I'd assume some performance regressions using such an obfuscator, but
> maybe it could even "learn" the proper obfuscation by detecting blocks
> on easier to detect obfuscation and then switching to a stronger, but
> less efficient obfuscation.

There are many designs for anti-censorship protocol obfuscation proxies,
including multi-modal ones like you suggest, more or less fanciful, more
or less realized. You can get a list of some of the more popular and
practical ones under the "censorship-circumvention" topic on GitHub:
	https://github.com/topics/censorship-circumvention
There's plenty of research on the topic as well, sometimes leading to
practical systems. CensorBib has the most important papers:
	https://censorbib.nymity.ch/
For an introduction and survey of ideas that have been proposed, I
recommend reading "Making Sense of Censorship Resistance Systems"
( https://censorbib.nymity.ch/#Khattak2016a ) and "Towards Grounding
Censorship Circumvention in Empiricism" ( https://censorbib.nymity.ch/#Tschantz2016a ).
There are summaries of recent research papers on censorship at
https://github.com/net4people/bbs/issues?q=label%3A%22reading+group%22 .
The idea of pluggable obfuscation modules is fairly ubiquitous, and has
been systematized in various ways:
	https://www.pluggabletransports.info/
	https://shadowsocks.org/guide/sip003.html
	https://guide.v2fly.org/en_US/advanced/advanced.html
	
Let me suggest, however, that it is a mistake to focus too narrowly on
protocol obfuscation. It is a necessary element, but not the most
important one nor the one that's hardest to get right. There's no
shortage of obfuscators, and even naive protocol obfuscation usually
works even against well-resourced censors like the GFW. The weak link of
circumvention systems tends not to be what cover protocols they use, but
the particulars of their connection establishment. (This point is made
in the two SoK papers I linked above.) Empirically, censors prefer to
disrupt communications during the early stages, when the connection is
being first set up. It is faster, cheaper, and overall more effective
than long-term steady-state protocol processing.

Take HTTP for example. It's not hard to obfsucate a network tunnel so
that it resembles HTTP at some degree of fidelity. One might think that
to in order to block such a tunnel, a censor needs to somehow
distinguish tunnel HTTP from "real" HTTP. But most real-world censors
will never go that far: instead they will look at the destination IP
address or Host header of HTTP requests, or send their own probes to
suspected servers to see how they respond; but in any case they'll add
the server's IP address to a firewall block list, and call it a day. The
hard part of obfuscating a tunnel as HTTP is not faithfully implementing
HTTP; it's protecting the server's address from being blocked for
reasons unrelated to HTTP. Protocol obfuscation cannot help when it is
not the protocol that is being attacked.

Having the tunnel hop across different endpoints is not a bad idea, but
consider: how does a legitimate user learn what endpoints to use,
without a censor learning them also? There are ways to protect
circumvention endpoints, from single-user servers (which I believe is
the model swgp-go intends), to strategic distribution of endpoint
addresses, to colocating proxy servers with other network services, but
these go beyond the realm of protocol obfuscation.

What I like about swgp-go is that it has a narrowly targeted goal (to
hide the most salient distinguishers of WireGuard, with low overhead)
and it is designed for a realistic and informed threat model. The
protocol obfuscation is re-encryption and padding, but it doesn't have
to be more than that.

From alexey.ponkin at gmail.com  Mon Jul  4 07:32:37 2022
From: alexey.ponkin at gmail.com (Alexey Ponkin)
Date: Mon, 4 Jul 2022 09:32:37 +0200
Subject: wireguard-apple: Unaligned pointer(s) for architecture arm64
Message-ID: <CA+QYBN=7FjHRVk+wox36iaG1i3-ZSF59qv_-yQ6UOdZ9WPLuKw@mail.gmail.com>

Hi guys,

I'm trying to use wireguard-apple in my app.
Following this guide -
https://git.zx2c4.com/wireguard-apple/about/#wireguardkit-integration
with small changes.
WireGuardBridgeiOS seems to be compiling but when I tried to run my
app(on physical device) I have lots of warnings like this - "
Pointer not aligned at address 0x1001F8A97 ('_type.*' + 232087 from
/Users/aponkin/Library/Developer/Xcode/DerivedData/MyApp-ffqwdheqjdaauedstuhrauhjkdcb/Build/Products/Debug-iphoneos/libwg-go.a(go.o))"
And the build is failed with - 'Unaligned pointer(s) for architecture
arm64' error message

Using XCode 14 Beta
go version go1.18.3 darwin/arm64
Any clues on how to fix that?

From vdronov at redhat.com  Mon Jul  4 19:15:35 2022
From: vdronov at redhat.com (Vladis Dronov)
Date: Mon,  4 Jul 2022 21:15:35 +0200
Subject: [PATCH] wireguard: Kconfig: select CRYPTO_CHACHA_S390
Message-ID: <20220704191535.76006-1-vdronov@redhat.com>

Select the new implementation of CHACHA20 for S390 when available,
it is faster than the generic software implementation.

Reported-by: kernel test robot <lkp at intel.com>
Link: https://lore.kernel.org/linux-kernel/202207030630.6SZVkrWf-lkp at intel.com/
Signed-off-by: Vladis Dronov <vdronov at redhat.com>
---
 drivers/net/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index b2a4f998c180..8c1eeb5a8db8 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -94,6 +94,7 @@ config WIREGUARD
 	select CRYPTO_CURVE25519_NEON if ARM && KERNEL_MODE_NEON
 	select CRYPTO_CHACHA_MIPS if CPU_MIPS32_R2
 	select CRYPTO_POLY1305_MIPS if MIPS
+	select CRYPTO_CHACHA_S390 if S390
 	help
 	  WireGuard is a secure, fast, and easy to use replacement for IPSec
 	  that uses modern cryptography and clever networking tricks. It's
-- 
2.36.1


From christian.koenig at amd.com  Mon Jul  4 11:30:50 2022
From: christian.koenig at amd.com (=?UTF-8?Q?Christian_K=c3=b6nig?=)
Date: Mon, 4 Jul 2022 13:30:50 +0200
Subject: CONFIG_ANDROID (was: rcu_sched detected expedited stalls in
 amdgpu after suspend)
In-Reply-To: <YrtgeSmwLmpzN/zw@pc638>
References: <1656357116.rhe0mufk6a.none.ref@localhost>
 <1656357116.rhe0mufk6a.none@localhost>
 <20220627204139.GL1790663@paulmck-ThinkPad-P17-Gen-1>
 <1656379893.q9yb069erk.none@localhost>
 <20220628041252.GV1790663@paulmck-ThinkPad-P17-Gen-1>
 <1656421946.ic03168yc3.none@localhost>
 <20220628185437.GA1790663@paulmck-ThinkPad-P17-Gen-1>
 <1656443915.mdjoauhqe0.none@localhost> <YrtgeSmwLmpzN/zw@pc638>
Message-ID: <79c6ad70-47d9-47fe-4bb4-33fcf356dd37@amd.com>

Hi guys,

Am 28.06.22 um 22:11 schrieb Uladzislau Rezki:
>> Excerpts from Paul E. McKenney's message of June 28, 2022 2:54 pm:
>>> All you need to do to get the previous behavior is to add something like
>>> this to your defconfig file:
>>>
>>> CONFIG_RCU_EXP_CPU_STALL_TIMEOUT=21000
>>>
>>> Any reason why this will not work for you?

sorry for jumping in so later, I was on vacation for a week.

Well when any RCU period is longer than 20ms and amdgpu in the backtrace 
my educated guess is that we messed up some timeout waiting for the hw.

We usually do wait a few us, but it can be that somebody is waiting for 
ms instead.

So there are some todos here as far as I can see and It would be helpful 
to get a cleaner backtrace if possible.

Regards,
Christian.


From Jason at zx2c4.com  Tue Jul  5 00:49:19 2022
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Tue, 5 Jul 2022 02:49:19 +0200
Subject: [PATCH] wireguard: Kconfig: select CRYPTO_CHACHA_S390
In-Reply-To: <20220704191535.76006-1-vdronov@redhat.com>
References: <20220704191535.76006-1-vdronov@redhat.com>
Message-ID: <YsOKj/GE2Mb2UsYa@zx2c4.com>

Hi Vladis,

On Mon, Jul 04, 2022 at 09:15:35PM +0200, Vladis Dronov wrote:
> Select the new implementation of CHACHA20 for S390 when available,
> it is faster than the generic software implementation.
> 
> Reported-by: kernel test robot <lkp at intel.com>
> Link: https://lore.kernel.org/linux-kernel/202207030630.6SZVkrWf-lkp at intel.com/
> Signed-off-by: Vladis Dronov <vdronov at redhat.com>
> ---
>  drivers/net/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> index b2a4f998c180..8c1eeb5a8db8 100644
> --- a/drivers/net/Kconfig
> +++ b/drivers/net/Kconfig
> @@ -94,6 +94,7 @@ config WIREGUARD
>  	select CRYPTO_CURVE25519_NEON if ARM && KERNEL_MODE_NEON
>  	select CRYPTO_CHACHA_MIPS if CPU_MIPS32_R2
>  	select CRYPTO_POLY1305_MIPS if MIPS
> +	select CRYPTO_CHACHA_S390 if S390
>  	help
>  	  WireGuard is a secure, fast, and easy to use replacement for IPSec
>  	  that uses modern cryptography and clever networking tricks. It's
> -- 
> 2.36.1

Thanks for the patch. Queued up as:
https://git.zx2c4.com/wireguard-linux/commit/?id=1b4ab028730cd00c144eaa51160865504b780961

I'll include this in my series to net.git soon.

Regards,
Jason

From Jason at zx2c4.com  Tue Jul  5 01:50:53 2022
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Tue, 5 Jul 2022 03:50:53 +0200
Subject: [PATCH] wireguard: Kconfig: select CRYPTO_CHACHA_S390
In-Reply-To: <YsOKj/GE2Mb2UsYa@zx2c4.com>
References: <20220704191535.76006-1-vdronov@redhat.com>
 <YsOKj/GE2Mb2UsYa@zx2c4.com>
Message-ID: <YsOY/eWq7gRjXJK1@zx2c4.com>

On Tue, Jul 05, 2022 at 02:49:19AM +0200, Jason A. Donenfeld wrote:
> Hi Vladis,
> 
> On Mon, Jul 04, 2022 at 09:15:35PM +0200, Vladis Dronov wrote:
> > Select the new implementation of CHACHA20 for S390 when available,
> > it is faster than the generic software implementation.
> > 
> > Reported-by: kernel test robot <lkp at intel.com>
> > Link: https://lore.kernel.org/linux-kernel/202207030630.6SZVkrWf-lkp at intel.com/
> > Signed-off-by: Vladis Dronov <vdronov at redhat.com>
> > ---
> >  drivers/net/Kconfig | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> > index b2a4f998c180..8c1eeb5a8db8 100644
> > --- a/drivers/net/Kconfig
> > +++ b/drivers/net/Kconfig
> > @@ -94,6 +94,7 @@ config WIREGUARD
> >  	select CRYPTO_CURVE25519_NEON if ARM && KERNEL_MODE_NEON
> >  	select CRYPTO_CHACHA_MIPS if CPU_MIPS32_R2
> >  	select CRYPTO_POLY1305_MIPS if MIPS
> > +	select CRYPTO_CHACHA_S390 if S390
> >  	help
> >  	  WireGuard is a secure, fast, and easy to use replacement for IPSec
> >  	  that uses modern cryptography and clever networking tricks. It's
> > -- 
> > 2.36.1
> 
> Thanks for the patch. Queued up as:
> https://git.zx2c4.com/wireguard-linux/commit/?id=1b4ab028730cd00c144eaa51160865504b780961
> 
> I'll include this in my series to net.git soon.

This actually leads to a minor problem:

  WARNING: unmet direct dependencies detected for CRYPTO_CHACHA_S390
    Depends on [n]: CRYPTO [=y] && CRYPTO_HW [=n] && S390 [=y]

This is of course harmless, since this doesn't *actually* depend on
CRYPTO_HW. In fact, the dependency on CRYPTO_HW is entirely a mistake
here that was repeated a few times. I cleaned this up and fixed it in
this patch:

    https://lore.kernel.org/linux-crypto/20220705014653.111335-1-Jason at zx2c4.com/

So hopefully Herbert will take that for 5.19 and then we'll be all set
here.

Jason

From vdronov at redhat.com  Tue Jul  5 12:07:40 2022
From: vdronov at redhat.com (Vlad Dronov)
Date: Tue, 5 Jul 2022 14:07:40 +0200
Subject: [PATCH] wireguard: Kconfig: select CRYPTO_CHACHA_S390
In-Reply-To: <YsOY/eWq7gRjXJK1@zx2c4.com>
References: <20220704191535.76006-1-vdronov@redhat.com>
 <YsOKj/GE2Mb2UsYa@zx2c4.com> <YsOY/eWq7gRjXJK1@zx2c4.com>
Message-ID: <CAMusb+RLB6-oz10yp9Cdigt0TeJ_85M30bH8snZaeM2CyvUiYA@mail.gmail.com>

Hi,

On Tue, Jul 5, 2022 at 3:51 AM Jason A. Donenfeld <Jason at zx2c4.com> wrote:
>
> On Tue, Jul 05, 2022 at 02:49:19AM +0200, Jason A. Donenfeld wrote:
> > Hi Vladis,
> >
> > On Mon, Jul 04, 2022 at 09:15:35PM +0200, Vladis Dronov wrote:
> > > Select the new implementation of CHACHA20 for S390 when available,
> > > it is faster than the generic software implementation.
> > >
> > > Reported-by: kernel test robot <lkp at intel.com>
> > > Link: https://lore.kernel.org/linux-kernel/202207030630.6SZVkrWf-lkp at intel.com/
> > > Signed-off-by: Vladis Dronov <vdronov at redhat.com>
> > > ... skip ...
> >
> > Thanks for the patch. Queued up as:
> > https://git.zx2c4.com/wireguard-linux/commit/?id=1b4ab028730cd00c144eaa51160865504b780961
> >
> > I'll include this in my series to net.git soon.

Thanks a ton, Jason!
Most appreciated.

> This actually leads to a minor problem:
>
>   WARNING: unmet direct dependencies detected for CRYPTO_CHACHA_S390
>     Depends on [n]: CRYPTO [=y] && CRYPTO_HW [=n] && S390 [=y]
>
> This is of course harmless, since this doesn't *actually* depend on
> CRYPTO_HW. In fact, the dependency on CRYPTO_HW is entirely a mistake
> here that was repeated a few times. I cleaned this up and fixed it in
> this patch:
>
>     https://lore.kernel.org/linux-crypto/20220705014653.111335-1-Jason at zx2c4.com/
>
> So hopefully Herbert will take that for 5.19 and then we'll be all set
> here.
>
> Jason

Whoa, that's... funny. Honestly, I was always wondering why CRYPTO_CHACHA_S390
and friends live in drivers/crypto/Kconfig. Now I know why. The patch
looks great, thank you.

Best regards,
Vladis Dronov | Red Hat, Inc. | The Core Kernel | Senior Software Engineer


From Jason at zx2c4.com  Tue Jul  5 13:21:33 2022
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Tue, 5 Jul 2022 15:21:33 +0200
Subject: [PATCH] wireguard: Kconfig: select CRYPTO_CHACHA_S390
In-Reply-To: <CAMusb+RLB6-oz10yp9Cdigt0TeJ_85M30bH8snZaeM2CyvUiYA@mail.gmail.com>
References: <20220704191535.76006-1-vdronov@redhat.com>
 <YsOKj/GE2Mb2UsYa@zx2c4.com> <YsOY/eWq7gRjXJK1@zx2c4.com>
 <CAMusb+RLB6-oz10yp9Cdigt0TeJ_85M30bH8snZaeM2CyvUiYA@mail.gmail.com>
Message-ID: <YsQ63c3mkxKRC4v0@zx2c4.com>

Hi Vlad,

On Tue, Jul 05, 2022 at 02:07:40PM +0200, Vlad Dronov wrote:
> Whoa, that's... funny. Honestly, I was always wondering why CRYPTO_CHACHA_S390
> and friends live in drivers/crypto/Kconfig. Now I know why.

Well... now you know that somebody else thought it was strange too. But
not quite why. At least I don't know why, other than assuming it was
a simple human mistake. But maybe the s390 developers will have an
interesting explanation or something. Herbert CC'd them into that
thread, so I look forward to seeing their response (if any).

Jason

From alexey.ponkin at gmail.com  Tue Jul  5 16:03:32 2022
From: alexey.ponkin at gmail.com (Alexey Ponkin)
Date: Tue, 5 Jul 2022 18:03:32 +0200
Subject: Adding '-fembed-bitcode' to 'wireguard-apple' build
Message-ID: <CA+QYBNnQBGhK=kfM5ppJ3mMPumwv8obcsqgsT68BtxvNcWp+Uw@mail.gmail.com>

Hi guys,
I have the same problem as mentioned here -
https://www.mail-archive.com/wireguard at lists.zx2c4.com/msg07033.html
In short: I added '-fembed-bitcode' to wireguard-apple's Makefile and
it solved the problem.
Let me know if I'm missing anything.

PR - https://github.com/WireGuard/wireguard-apple/pull/13

Cheers.

From darkranger_red at hotmail.com  Tue Jul  5 08:58:46 2022
From: darkranger_red at hotmail.com (Shen Red)
Date: Tue, 5 Jul 2022 08:58:46 +0000
Subject: package from fedorainfracloud for centOS 8 does not build
Message-ID: <SYBP282MB04601262532DDD031AD31F24F2819@SYBP282MB0460.AUSP282.PROD.OUTLOOK.COM>

No, providing multiple versions is not helping. Because the breakage is caused by kernel-4.18.0-394.el8.x86_64, not wireguard-dkms-1.0.20220627-1. If you do have the older kernel-4.18.0-383.el8.x86_64 installed, you can run the following command to rebuild the wireguard module successfully:
sudo dkms install wireguard/1.0.20220627 -k 4.18.0-383.el8.x86_64

The wireguard module built for 4.18.0-383.el8.x86_64 can be used on 4.18.0-394.el8.x86_64.

From urezki at gmail.com  Wed Jul  6 17:48:20 2022
From: urezki at gmail.com (Uladzislau Rezki)
Date: Wed, 6 Jul 2022 19:48:20 +0200
Subject: CONFIG_ANDROID (was: rcu_sched detected expedited stalls in
 amdgpu after suspend)
In-Reply-To: <79c6ad70-47d9-47fe-4bb4-33fcf356dd37@amd.com>
References: <1656357116.rhe0mufk6a.none.ref@localhost>
 <1656357116.rhe0mufk6a.none@localhost>
 <20220627204139.GL1790663@paulmck-ThinkPad-P17-Gen-1>
 <1656379893.q9yb069erk.none@localhost>
 <20220628041252.GV1790663@paulmck-ThinkPad-P17-Gen-1>
 <1656421946.ic03168yc3.none@localhost>
 <20220628185437.GA1790663@paulmck-ThinkPad-P17-Gen-1>
 <1656443915.mdjoauhqe0.none@localhost> <YrtgeSmwLmpzN/zw@pc638>
 <79c6ad70-47d9-47fe-4bb4-33fcf356dd37@amd.com>
Message-ID: <YsXK5A0MiVgHd8Je@pc638.lan>

Hello.

On Mon, Jul 04, 2022 at 01:30:50PM +0200, Christian K?nig wrote:
> Hi guys,
> 
> Am 28.06.22 um 22:11 schrieb Uladzislau Rezki:
> > > Excerpts from Paul E. McKenney's message of June 28, 2022 2:54 pm:
> > > > All you need to do to get the previous behavior is to add something like
> > > > this to your defconfig file:
> > > > 
> > > > CONFIG_RCU_EXP_CPU_STALL_TIMEOUT=21000
> > > > 
> > > > Any reason why this will not work for you?
> 
> sorry for jumping in so later, I was on vacation for a week.
> 
> Well when any RCU period is longer than 20ms and amdgpu in the backtrace my
> educated guess is that we messed up some timeout waiting for the hw.
> 
> We usually do wait a few us, but it can be that somebody is waiting for ms
> instead.
> 
> So there are some todos here as far as I can see and It would be helpful to
> get a cleaner backtrace if possible.
> 
Actually CONFIG_ANDROID looks like is going to be removed, so the CONFIG_RCU_EXP_CPU_STALL_TIMEOUT
will not have any dependencies on the CONFIG_ANDROID anymore:

https://lkml.org/lkml/2022/6/29/756

--
Uladzislau Rezki


From paulmck at kernel.org  Wed Jul  6 17:58:36 2022
From: paulmck at kernel.org (Paul E. McKenney)
Date: Wed, 6 Jul 2022 10:58:36 -0700
Subject: CONFIG_ANDROID (was: rcu_sched detected expedited stalls in
 amdgpu after suspend)
In-Reply-To: <YsXK5A0MiVgHd8Je@pc638.lan>
References: <1656357116.rhe0mufk6a.none@localhost>
 <20220627204139.GL1790663@paulmck-ThinkPad-P17-Gen-1>
 <1656379893.q9yb069erk.none@localhost>
 <20220628041252.GV1790663@paulmck-ThinkPad-P17-Gen-1>
 <1656421946.ic03168yc3.none@localhost>
 <20220628185437.GA1790663@paulmck-ThinkPad-P17-Gen-1>
 <1656443915.mdjoauhqe0.none@localhost> <YrtgeSmwLmpzN/zw@pc638>
 <79c6ad70-47d9-47fe-4bb4-33fcf356dd37@amd.com>
 <YsXK5A0MiVgHd8Je@pc638.lan>
Message-ID: <20220706175836.GI1790663@paulmck-ThinkPad-P17-Gen-1>

On Wed, Jul 06, 2022 at 07:48:20PM +0200, Uladzislau Rezki wrote:
> Hello.
> 
> On Mon, Jul 04, 2022 at 01:30:50PM +0200, Christian K?nig wrote:
> > Hi guys,
> > 
> > Am 28.06.22 um 22:11 schrieb Uladzislau Rezki:
> > > > Excerpts from Paul E. McKenney's message of June 28, 2022 2:54 pm:
> > > > > All you need to do to get the previous behavior is to add something like
> > > > > this to your defconfig file:
> > > > > 
> > > > > CONFIG_RCU_EXP_CPU_STALL_TIMEOUT=21000
> > > > > 
> > > > > Any reason why this will not work for you?
> > 
> > sorry for jumping in so later, I was on vacation for a week.
> > 
> > Well when any RCU period is longer than 20ms and amdgpu in the backtrace my
> > educated guess is that we messed up some timeout waiting for the hw.
> > 
> > We usually do wait a few us, but it can be that somebody is waiting for ms
> > instead.
> > 
> > So there are some todos here as far as I can see and It would be helpful to
> > get a cleaner backtrace if possible.
> > 
> Actually CONFIG_ANDROID looks like is going to be removed, so the CONFIG_RCU_EXP_CPU_STALL_TIMEOUT
> will not have any dependencies on the CONFIG_ANDROID anymore:
> 
> https://lkml.org/lkml/2022/6/29/756

But you can set the RCU_EXP_CPU_STALL_TIMEOUT Kconfig option, if you
wish.  Setting this option to 20 will get you the behavior previously
obtained by setting the now-defunct ANDROID Kconfig option.

							Thanx, Paul

From urezki at gmail.com  Wed Jul  6 18:09:49 2022
From: urezki at gmail.com (Uladzislau Rezki)
Date: Wed, 6 Jul 2022 20:09:49 +0200
Subject: CONFIG_ANDROID (was: rcu_sched detected expedited stalls in
 amdgpu after suspend)
In-Reply-To: <20220706175836.GI1790663@paulmck-ThinkPad-P17-Gen-1>
References: <20220627204139.GL1790663@paulmck-ThinkPad-P17-Gen-1>
 <1656379893.q9yb069erk.none@localhost>
 <20220628041252.GV1790663@paulmck-ThinkPad-P17-Gen-1>
 <1656421946.ic03168yc3.none@localhost>
 <20220628185437.GA1790663@paulmck-ThinkPad-P17-Gen-1>
 <1656443915.mdjoauhqe0.none@localhost> <YrtgeSmwLmpzN/zw@pc638>
 <79c6ad70-47d9-47fe-4bb4-33fcf356dd37@amd.com>
 <YsXK5A0MiVgHd8Je@pc638.lan>
 <20220706175836.GI1790663@paulmck-ThinkPad-P17-Gen-1>
Message-ID: <YsXP7ZwHh/GvWM82@pc638.lan>

On Wed, Jul 06, 2022 at 10:58:36AM -0700, Paul E. McKenney wrote:
> On Wed, Jul 06, 2022 at 07:48:20PM +0200, Uladzislau Rezki wrote:
> > Hello.
> > 
> > On Mon, Jul 04, 2022 at 01:30:50PM +0200, Christian K?nig wrote:
> > > Hi guys,
> > > 
> > > Am 28.06.22 um 22:11 schrieb Uladzislau Rezki:
> > > > > Excerpts from Paul E. McKenney's message of June 28, 2022 2:54 pm:
> > > > > > All you need to do to get the previous behavior is to add something like
> > > > > > this to your defconfig file:
> > > > > > 
> > > > > > CONFIG_RCU_EXP_CPU_STALL_TIMEOUT=21000
> > > > > > 
> > > > > > Any reason why this will not work for you?
> > > 
> > > sorry for jumping in so later, I was on vacation for a week.
> > > 
> > > Well when any RCU period is longer than 20ms and amdgpu in the backtrace my
> > > educated guess is that we messed up some timeout waiting for the hw.
> > > 
> > > We usually do wait a few us, but it can be that somebody is waiting for ms
> > > instead.
> > > 
> > > So there are some todos here as far as I can see and It would be helpful to
> > > get a cleaner backtrace if possible.
> > > 
> > Actually CONFIG_ANDROID looks like is going to be removed, so the CONFIG_RCU_EXP_CPU_STALL_TIMEOUT
> > will not have any dependencies on the CONFIG_ANDROID anymore:
> > 
> > https://lkml.org/lkml/2022/6/29/756
> 
> But you can set the RCU_EXP_CPU_STALL_TIMEOUT Kconfig option, if you
> wish.  Setting this option to 20 will get you the behavior previously
> obtained by setting the now-defunct ANDROID Kconfig option.
> 
Right. Or over boot parameter. So for us it is not a big issue :)

--
Uladzislau Rezki

From paulmck at kernel.org  Wed Jul  6 20:42:02 2022
From: paulmck at kernel.org (Paul E. McKenney)
Date: Wed, 6 Jul 2022 13:42:02 -0700
Subject: CONFIG_ANDROID (was: rcu_sched detected expedited stalls in
 amdgpu after suspend)
In-Reply-To: <YsXP7ZwHh/GvWM82@pc638.lan>
References: <1656379893.q9yb069erk.none@localhost>
 <20220628041252.GV1790663@paulmck-ThinkPad-P17-Gen-1>
 <1656421946.ic03168yc3.none@localhost>
 <20220628185437.GA1790663@paulmck-ThinkPad-P17-Gen-1>
 <1656443915.mdjoauhqe0.none@localhost> <YrtgeSmwLmpzN/zw@pc638>
 <79c6ad70-47d9-47fe-4bb4-33fcf356dd37@amd.com>
 <YsXK5A0MiVgHd8Je@pc638.lan>
 <20220706175836.GI1790663@paulmck-ThinkPad-P17-Gen-1>
 <YsXP7ZwHh/GvWM82@pc638.lan>
Message-ID: <20220706204202.GJ1790663@paulmck-ThinkPad-P17-Gen-1>

On Wed, Jul 06, 2022 at 08:09:49PM +0200, Uladzislau Rezki wrote:
> On Wed, Jul 06, 2022 at 10:58:36AM -0700, Paul E. McKenney wrote:
> > On Wed, Jul 06, 2022 at 07:48:20PM +0200, Uladzislau Rezki wrote:
> > > Hello.
> > > 
> > > On Mon, Jul 04, 2022 at 01:30:50PM +0200, Christian K?nig wrote:
> > > > Hi guys,
> > > > 
> > > > Am 28.06.22 um 22:11 schrieb Uladzislau Rezki:
> > > > > > Excerpts from Paul E. McKenney's message of June 28, 2022 2:54 pm:
> > > > > > > All you need to do to get the previous behavior is to add something like
> > > > > > > this to your defconfig file:
> > > > > > > 
> > > > > > > CONFIG_RCU_EXP_CPU_STALL_TIMEOUT=21000
> > > > > > > 
> > > > > > > Any reason why this will not work for you?
> > > > 
> > > > sorry for jumping in so later, I was on vacation for a week.
> > > > 
> > > > Well when any RCU period is longer than 20ms and amdgpu in the backtrace my
> > > > educated guess is that we messed up some timeout waiting for the hw.
> > > > 
> > > > We usually do wait a few us, but it can be that somebody is waiting for ms
> > > > instead.
> > > > 
> > > > So there are some todos here as far as I can see and It would be helpful to
> > > > get a cleaner backtrace if possible.
> > > > 
> > > Actually CONFIG_ANDROID looks like is going to be removed, so the CONFIG_RCU_EXP_CPU_STALL_TIMEOUT
> > > will not have any dependencies on the CONFIG_ANDROID anymore:
> > > 
> > > https://lkml.org/lkml/2022/6/29/756
> > 
> > But you can set the RCU_EXP_CPU_STALL_TIMEOUT Kconfig option, if you
> > wish.  Setting this option to 20 will get you the behavior previously
> > obtained by setting the now-defunct ANDROID Kconfig option.
> > 
> Right. Or over boot parameter. So for us it is not a big issue :)

Specifically rcupdate.rcu_exp_cpu_stall_timeout, for those just now
tuning in.  ;-)

							Thanx, Paul

From christian.koenig at amd.com  Thu Jul  7 07:30:39 2022
From: christian.koenig at amd.com (=?UTF-8?Q?Christian_K=c3=b6nig?=)
Date: Thu, 7 Jul 2022 09:30:39 +0200
Subject: CONFIG_ANDROID (was: rcu_sched detected expedited stalls in
 amdgpu after suspend)
In-Reply-To: <20220706204202.GJ1790663@paulmck-ThinkPad-P17-Gen-1>
References: <1656379893.q9yb069erk.none@localhost>
 <20220628041252.GV1790663@paulmck-ThinkPad-P17-Gen-1>
 <1656421946.ic03168yc3.none@localhost>
 <20220628185437.GA1790663@paulmck-ThinkPad-P17-Gen-1>
 <1656443915.mdjoauhqe0.none@localhost> <YrtgeSmwLmpzN/zw@pc638>
 <79c6ad70-47d9-47fe-4bb4-33fcf356dd37@amd.com> <YsXK5A0MiVgHd8Je@pc638.lan>
 <20220706175836.GI1790663@paulmck-ThinkPad-P17-Gen-1>
 <YsXP7ZwHh/GvWM82@pc638.lan>
 <20220706204202.GJ1790663@paulmck-ThinkPad-P17-Gen-1>
Message-ID: <fbf83d60-67d3-698d-e2d2-02dc8d7e49c4@amd.com>

Am 06.07.22 um 22:42 schrieb Paul E. McKenney:
> On Wed, Jul 06, 2022 at 08:09:49PM +0200, Uladzislau Rezki wrote:
>> On Wed, Jul 06, 2022 at 10:58:36AM -0700, Paul E. McKenney wrote:
>>> On Wed, Jul 06, 2022 at 07:48:20PM +0200, Uladzislau Rezki wrote:
>>>> Hello.
>>>>
>>>> On Mon, Jul 04, 2022 at 01:30:50PM +0200, Christian K?nig wrote:
>>>>> Hi guys,
>>>>>
>>>>> Am 28.06.22 um 22:11 schrieb Uladzislau Rezki:
>>>>>>> Excerpts from Paul E. McKenney's message of June 28, 2022 2:54 pm:
>>>>>>>> All you need to do to get the previous behavior is to add something like
>>>>>>>> this to your defconfig file:
>>>>>>>>
>>>>>>>> CONFIG_RCU_EXP_CPU_STALL_TIMEOUT=21000
>>>>>>>>
>>>>>>>> Any reason why this will not work for you?
>>>>> sorry for jumping in so later, I was on vacation for a week.
>>>>>
>>>>> Well when any RCU period is longer than 20ms and amdgpu in the backtrace my
>>>>> educated guess is that we messed up some timeout waiting for the hw.
>>>>>
>>>>> We usually do wait a few us, but it can be that somebody is waiting for ms
>>>>> instead.
>>>>>
>>>>> So there are some todos here as far as I can see and It would be helpful to
>>>>> get a cleaner backtrace if possible.
>>>>>
>>>> Actually CONFIG_ANDROID looks like is going to be removed, so the CONFIG_RCU_EXP_CPU_STALL_TIMEOUT
>>>> will not have any dependencies on the CONFIG_ANDROID anymore:
>>>>
>>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flkml.org%2Flkml%2F2022%2F6%2F29%2F756&amp;data=05%7C01%7Cchristian.koenig%40amd.com%7C8b36bcb4fe61475c0eb708da5f8ffce8%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637927369274030797%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=eaK66spsbWVi2uRhcFK7eu4usgkHFZCSvErZxB%2F2npM%3D&amp;reserved=0
>>> But you can set the RCU_EXP_CPU_STALL_TIMEOUT Kconfig option, if you
>>> wish.  Setting this option to 20 will get you the behavior previously
>>> obtained by setting the now-defunct ANDROID Kconfig option.
>>>
>> Right. Or over boot parameter. So for us it is not a big issue :)
> Specifically rcupdate.rcu_exp_cpu_stall_timeout, for those just now
> tuning in.  ;-)

I was just about to write a response asking for that :)

Thanks, I will suggest to our QA to add this parameter while doing some 
tests.

Regards,
Christian.

>
> 							Thanx, Paul


From paulmck at kernel.org  Thu Jul  7 13:29:21 2022
From: paulmck at kernel.org (Paul E. McKenney)
Date: Thu, 7 Jul 2022 06:29:21 -0700
Subject: CONFIG_ANDROID (was: rcu_sched detected expedited stalls in
 amdgpu after suspend)
In-Reply-To: <fbf83d60-67d3-698d-e2d2-02dc8d7e49c4@amd.com>
References: <1656421946.ic03168yc3.none@localhost>
 <20220628185437.GA1790663@paulmck-ThinkPad-P17-Gen-1>
 <1656443915.mdjoauhqe0.none@localhost> <YrtgeSmwLmpzN/zw@pc638>
 <79c6ad70-47d9-47fe-4bb4-33fcf356dd37@amd.com>
 <YsXK5A0MiVgHd8Je@pc638.lan>
 <20220706175836.GI1790663@paulmck-ThinkPad-P17-Gen-1>
 <YsXP7ZwHh/GvWM82@pc638.lan>
 <20220706204202.GJ1790663@paulmck-ThinkPad-P17-Gen-1>
 <fbf83d60-67d3-698d-e2d2-02dc8d7e49c4@amd.com>
Message-ID: <20220707132921.GK1790663@paulmck-ThinkPad-P17-Gen-1>

On Thu, Jul 07, 2022 at 09:30:39AM +0200, Christian K?nig wrote:
> Am 06.07.22 um 22:42 schrieb Paul E. McKenney:
> > On Wed, Jul 06, 2022 at 08:09:49PM +0200, Uladzislau Rezki wrote:
> > > On Wed, Jul 06, 2022 at 10:58:36AM -0700, Paul E. McKenney wrote:
> > > > On Wed, Jul 06, 2022 at 07:48:20PM +0200, Uladzislau Rezki wrote:
> > > > > Hello.
> > > > > 
> > > > > On Mon, Jul 04, 2022 at 01:30:50PM +0200, Christian K?nig wrote:
> > > > > > Hi guys,
> > > > > > 
> > > > > > Am 28.06.22 um 22:11 schrieb Uladzislau Rezki:
> > > > > > > > Excerpts from Paul E. McKenney's message of June 28, 2022 2:54 pm:
> > > > > > > > > All you need to do to get the previous behavior is to add something like
> > > > > > > > > this to your defconfig file:
> > > > > > > > > 
> > > > > > > > > CONFIG_RCU_EXP_CPU_STALL_TIMEOUT=21000
> > > > > > > > > 
> > > > > > > > > Any reason why this will not work for you?
> > > > > > sorry for jumping in so later, I was on vacation for a week.
> > > > > > 
> > > > > > Well when any RCU period is longer than 20ms and amdgpu in the backtrace my
> > > > > > educated guess is that we messed up some timeout waiting for the hw.
> > > > > > 
> > > > > > We usually do wait a few us, but it can be that somebody is waiting for ms
> > > > > > instead.
> > > > > > 
> > > > > > So there are some todos here as far as I can see and It would be helpful to
> > > > > > get a cleaner backtrace if possible.
> > > > > > 
> > > > > Actually CONFIG_ANDROID looks like is going to be removed, so the CONFIG_RCU_EXP_CPU_STALL_TIMEOUT
> > > > > will not have any dependencies on the CONFIG_ANDROID anymore:
> > > > > 
> > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flkml.org%2Flkml%2F2022%2F6%2F29%2F756&amp;data=05%7C01%7Cchristian.koenig%40amd.com%7C8b36bcb4fe61475c0eb708da5f8ffce8%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637927369274030797%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=eaK66spsbWVi2uRhcFK7eu4usgkHFZCSvErZxB%2F2npM%3D&amp;reserved=0
> > > > But you can set the RCU_EXP_CPU_STALL_TIMEOUT Kconfig option, if you
> > > > wish.  Setting this option to 20 will get you the behavior previously
> > > > obtained by setting the now-defunct ANDROID Kconfig option.
> > > > 
> > > Right. Or over boot parameter. So for us it is not a big issue :)
> > Specifically rcupdate.rcu_exp_cpu_stall_timeout, for those just now
> > tuning in.  ;-)
> 
> I was just about to write a response asking for that :)
> 
> Thanks, I will suggest to our QA to add this parameter while doing some
> tests.

Very good!  Please let me know how it goes.

							Thanx, Paul

From faustin at fala.red  Thu Jul  7 17:14:52 2022
From: faustin at fala.red (Faustin Lammler)
Date: Thu, 7 Jul 2022 19:14:52 +0200
Subject: Update wireguard installation instructions for RHEL7/8-Centos8Stream
Message-ID: <YscUjPnRGvyQIO5Y@falared>

Hi!
I am wondering if the installation instruction page [1] should not be
updated to reflect [2] ?

After upgrading a Centos 8 Stream machine, it took me some time to
understand why I was not able to load the wireguard module for the new
kernel (I had to rollback from 4.18.0-394 to 4.18.0-348).

Cheers!

-- 
Faustin

[1]: https://www.wireguard.com/install/#red-hat-enterprise-linux-8-module-kmod-module-dkms-tools
[2]: https://git.zx2c4.com/wireguard-linux-compat/commit/?id=3d3c92b4711b42169137b2ddf42ed4382e2babdf

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.zx2c4.com/pipermail/wireguard/attachments/20220707/2cc89505/attachment.sig>

From darkranger_red at hotmail.com  Tue Jul 12 06:31:47 2022
From: darkranger_red at hotmail.com (Shen Red)
Date: Tue, 12 Jul 2022 06:31:47 +0000
Subject: Update wireguard installation instructions for
 RHEL7/8-Centos8Stream
Message-ID: <SYBP282MB046024065A5CB3522AC577F4F2869@SYBP282MB0460.AUSP282.PROD.OUTLOOK.COM>

I think that the wireguard-linux-compat project doesn't officially drop CentOS 8 Stream support. The recent commit message just indicates that is no longer guaranteed to work, and it doesn't introduce any code changes that actually break the compatibility. The recent breakage is caused by a code change in kernel 4.18.0-394 instead. And that change could also be committed to RHEL8 eventually.

There is no proper instruction for C8S for now. The current workaround is do not update the kernel to 4.18.0-394. Or, if the kernel has been updated, try to build the wireguard module explicitly for the older kernel.

From faustin at fala.red  Wed Jul 13 16:30:00 2022
From: faustin at fala.red (Faustin Lammler)
Date: Wed, 13 Jul 2022 18:30:00 +0200
Subject: Update wireguard installation instructions for
 RHEL7/8-Centos8Stream
In-Reply-To: <SYBP282MB046024065A5CB3522AC577F4F2869@SYBP282MB0460.AUSP282.PROD.OUTLOOK.COM>
References: <SYBP282MB046024065A5CB3522AC577F4F2869@SYBP282MB0460.AUSP282.PROD.OUTLOOK.COM>
Message-ID: <Ys7zCA9oQH1uiQta@falared>

Hi Shen!

Shen Red <darkranger_red at hotmail.com>,
12/07/2022 ? 06:31:47 (+0000):

> I think that the wireguard-linux-compat project doesn't officially
> drop CentOS 8 Stream support. The recent commit message just indicates
> that is no longer guaranteed to work, and it doesn't introduce any
> code changes that actually break the compatibility.

My understanding of the commit message and above all of [1] is that the
CI was disabled for C8S and IMO that should be mentioned in the
installation instruction since there is no more guarantee that wireguard
module will install successfully on recent C8S kernel (and that's the
case with 4.18.0-394).

> The recent breakage is caused by a code change in kernel 4.18.0-394
> instead. And that change could also be committed to RHEL8 eventually.

Yes exact.

> There is no proper instruction for C8S for now. The current workaround
> is do not update the kernel to 4.18.0-394. Or, if the kernel has been
> updated, try to build the wireguard module explicitly for the older
> kernel.

This is the kind of thing that I believe should be visible on the
installation instructions, it will save a lot of time to everyone...

[1]: https://lists.zx2c4.com/pipermail/wireguard/2022-June/007664.html

-- 
Faustin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.zx2c4.com/pipermail/wireguard/attachments/20220713/cffb9b10/attachment.sig>

From sashal at kernel.org  Thu Jul 14 04:22:18 2022
From: sashal at kernel.org (Sasha Levin)
Date: Thu, 14 Jul 2022 00:22:18 -0400
Subject: [PATCH AUTOSEL 5.18 38/41] wireguard: selftests: set fake real time
 in init
In-Reply-To: <20220714042221.281187-1-sashal@kernel.org>
References: <20220714042221.281187-1-sashal@kernel.org>
Message-ID: <20220714042221.281187-38-sashal@kernel.org>

From: "Jason A. Donenfeld" <Jason at zx2c4.com>

[ Upstream commit 829be057dbc1e71383b8d7de8edb31dcf07b4aa0 ]

Not all platforms have an RTC, and rather than trying to force one into
each, it's much easier to just set a fixed time. This is necessary
because WireGuard's latest handshakes parameter is returned in wallclock
time, and if the system time isn't set, and the system is really fast,
then this returns 0, which trips the test.

Turning this on requires setting CONFIG_COMPAT_32BIT_TIME=y, as musl
doesn't support settimeofday without it.

Signed-off-by: Jason A. Donenfeld <Jason at zx2c4.com>
Signed-off-by: Jakub Kicinski <kuba at kernel.org>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 .../testing/selftests/wireguard/qemu/arch/arm.config  |  1 +
 .../selftests/wireguard/qemu/arch/armeb.config        |  1 +
 .../testing/selftests/wireguard/qemu/arch/i686.config |  1 +
 .../testing/selftests/wireguard/qemu/arch/m68k.config |  1 +
 .../testing/selftests/wireguard/qemu/arch/mips.config |  1 +
 .../selftests/wireguard/qemu/arch/mipsel.config       |  1 +
 .../selftests/wireguard/qemu/arch/powerpc.config      |  1 +
 tools/testing/selftests/wireguard/qemu/init.c         | 11 +++++++++++
 8 files changed, 18 insertions(+)

diff --git a/tools/testing/selftests/wireguard/qemu/arch/arm.config b/tools/testing/selftests/wireguard/qemu/arch/arm.config
index fc7959bef9c2..0579c66be83e 100644
--- a/tools/testing/selftests/wireguard/qemu/arch/arm.config
+++ b/tools/testing/selftests/wireguard/qemu/arch/arm.config
@@ -7,6 +7,7 @@ CONFIG_SERIAL_AMBA_PL011_CONSOLE=y
 CONFIG_VIRTIO_MENU=y
 CONFIG_VIRTIO_MMIO=y
 CONFIG_VIRTIO_CONSOLE=y
+CONFIG_COMPAT_32BIT_TIME=y
 CONFIG_CMDLINE_BOOL=y
 CONFIG_CMDLINE="console=ttyAMA0 wg.success=vport0p1 panic_on_warn=1"
 CONFIG_FRAME_WARN=1024
diff --git a/tools/testing/selftests/wireguard/qemu/arch/armeb.config b/tools/testing/selftests/wireguard/qemu/arch/armeb.config
index f3066be81c19..2a3307bbe534 100644
--- a/tools/testing/selftests/wireguard/qemu/arch/armeb.config
+++ b/tools/testing/selftests/wireguard/qemu/arch/armeb.config
@@ -7,6 +7,7 @@ CONFIG_SERIAL_AMBA_PL011_CONSOLE=y
 CONFIG_VIRTIO_MENU=y
 CONFIG_VIRTIO_MMIO=y
 CONFIG_VIRTIO_CONSOLE=y
+CONFIG_COMPAT_32BIT_TIME=y
 CONFIG_CMDLINE_BOOL=y
 CONFIG_CMDLINE="console=ttyAMA0 wg.success=vport0p1 panic_on_warn=1"
 CONFIG_CPU_BIG_ENDIAN=y
diff --git a/tools/testing/selftests/wireguard/qemu/arch/i686.config b/tools/testing/selftests/wireguard/qemu/arch/i686.config
index 6d90892a85a2..cd864b9be6fb 100644
--- a/tools/testing/selftests/wireguard/qemu/arch/i686.config
+++ b/tools/testing/selftests/wireguard/qemu/arch/i686.config
@@ -1,6 +1,7 @@
 CONFIG_ACPI=y
 CONFIG_SERIAL_8250=y
 CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_COMPAT_32BIT_TIME=y
 CONFIG_CMDLINE_BOOL=y
 CONFIG_CMDLINE="console=ttyS0 wg.success=ttyS1 panic_on_warn=1"
 CONFIG_FRAME_WARN=1024
diff --git a/tools/testing/selftests/wireguard/qemu/arch/m68k.config b/tools/testing/selftests/wireguard/qemu/arch/m68k.config
index 82c925e49beb..9639bfe06074 100644
--- a/tools/testing/selftests/wireguard/qemu/arch/m68k.config
+++ b/tools/testing/selftests/wireguard/qemu/arch/m68k.config
@@ -5,5 +5,6 @@ CONFIG_MAC=y
 CONFIG_SERIAL_PMACZILOG=y
 CONFIG_SERIAL_PMACZILOG_TTYS=y
 CONFIG_SERIAL_PMACZILOG_CONSOLE=y
+CONFIG_COMPAT_32BIT_TIME=y
 CONFIG_CMDLINE="console=ttyS0 wg.success=ttyS1 panic_on_warn=1"
 CONFIG_FRAME_WARN=1024
diff --git a/tools/testing/selftests/wireguard/qemu/arch/mips.config b/tools/testing/selftests/wireguard/qemu/arch/mips.config
index d7ec63c17b30..2a84402353ab 100644
--- a/tools/testing/selftests/wireguard/qemu/arch/mips.config
+++ b/tools/testing/selftests/wireguard/qemu/arch/mips.config
@@ -6,6 +6,7 @@ CONFIG_POWER_RESET=y
 CONFIG_POWER_RESET_SYSCON=y
 CONFIG_SERIAL_8250=y
 CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_COMPAT_32BIT_TIME=y
 CONFIG_CMDLINE_BOOL=y
 CONFIG_CMDLINE="console=ttyS0 wg.success=ttyS1 panic_on_warn=1"
 CONFIG_FRAME_WARN=1024
diff --git a/tools/testing/selftests/wireguard/qemu/arch/mipsel.config b/tools/testing/selftests/wireguard/qemu/arch/mipsel.config
index 18a498293737..56146a101e7e 100644
--- a/tools/testing/selftests/wireguard/qemu/arch/mipsel.config
+++ b/tools/testing/selftests/wireguard/qemu/arch/mipsel.config
@@ -7,6 +7,7 @@ CONFIG_POWER_RESET=y
 CONFIG_POWER_RESET_SYSCON=y
 CONFIG_SERIAL_8250=y
 CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_COMPAT_32BIT_TIME=y
 CONFIG_CMDLINE_BOOL=y
 CONFIG_CMDLINE="console=ttyS0 wg.success=ttyS1 panic_on_warn=1"
 CONFIG_FRAME_WARN=1024
diff --git a/tools/testing/selftests/wireguard/qemu/arch/powerpc.config b/tools/testing/selftests/wireguard/qemu/arch/powerpc.config
index 5e04882e8e35..174a9ffe2a36 100644
--- a/tools/testing/selftests/wireguard/qemu/arch/powerpc.config
+++ b/tools/testing/selftests/wireguard/qemu/arch/powerpc.config
@@ -4,6 +4,7 @@ CONFIG_PPC_85xx=y
 CONFIG_PHYS_64BIT=y
 CONFIG_SERIAL_8250=y
 CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_COMPAT_32BIT_TIME=y
 CONFIG_MATH_EMULATION=y
 CONFIG_CMDLINE_BOOL=y
 CONFIG_CMDLINE="console=ttyS0 wg.success=ttyS1 panic_on_warn=1"
diff --git a/tools/testing/selftests/wireguard/qemu/init.c b/tools/testing/selftests/wireguard/qemu/init.c
index 2a0f48fac925..542c34b00eb0 100644
--- a/tools/testing/selftests/wireguard/qemu/init.c
+++ b/tools/testing/selftests/wireguard/qemu/init.c
@@ -11,6 +11,7 @@
 #include <stdlib.h>
 #include <stdbool.h>
 #include <fcntl.h>
+#include <time.h>
 #include <sys/wait.h>
 #include <sys/mount.h>
 #include <sys/stat.h>
@@ -67,6 +68,15 @@ static void seed_rng(void)
 	close(fd);
 }
 
+static void set_time(void)
+{
+	if (time(NULL))
+		return;
+	pretty_message("[+] Setting fake time...");
+	if (stime(&(time_t){1433512680}) < 0)
+		panic("settimeofday()");
+}
+
 static void mount_filesystems(void)
 {
 	pretty_message("[+] Mounting filesystems...");
@@ -256,6 +266,7 @@ int main(int argc, char *argv[])
 	print_banner();
 	mount_filesystems();
 	seed_rng();
+	set_time();
 	kmod_selftests();
 	enable_logging();
 	clear_leaks();
-- 
2.35.1


From sashal at kernel.org  Thu Jul 14 04:22:19 2022
From: sashal at kernel.org (Sasha Levin)
Date: Thu, 14 Jul 2022 00:22:19 -0400
Subject: [PATCH AUTOSEL 5.18 39/41] wireguard: selftests: use virt machine on
 m68k
In-Reply-To: <20220714042221.281187-1-sashal@kernel.org>
References: <20220714042221.281187-1-sashal@kernel.org>
Message-ID: <20220714042221.281187-39-sashal@kernel.org>

From: "Jason A. Donenfeld" <Jason at zx2c4.com>

[ Upstream commit 1f2f341a62639c7066ee4c76b7d9ebe867e0a1d5 ]

This should be a bit more stable hopefully.

Signed-off-by: Jason A. Donenfeld <Jason at zx2c4.com>
Signed-off-by: Jakub Kicinski <kuba at kernel.org>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 tools/testing/selftests/wireguard/qemu/Makefile         | 5 +++--
 tools/testing/selftests/wireguard/qemu/arch/m68k.config | 9 +++------
 2 files changed, 6 insertions(+), 8 deletions(-)

diff --git a/tools/testing/selftests/wireguard/qemu/Makefile b/tools/testing/selftests/wireguard/qemu/Makefile
index bca07b93eeb0..e8a82e495d2e 100644
--- a/tools/testing/selftests/wireguard/qemu/Makefile
+++ b/tools/testing/selftests/wireguard/qemu/Makefile
@@ -210,10 +210,11 @@ QEMU_ARCH := m68k
 KERNEL_ARCH := m68k
 KERNEL_BZIMAGE := $(KERNEL_BUILD_PATH)/vmlinux
 KERNEL_CMDLINE := $(shell sed -n 's/CONFIG_CMDLINE=\(.*\)/\1/p' arch/m68k.config)
+QEMU_VPORT_RESULT := virtio-serial-device
 ifeq ($(HOST_ARCH),$(ARCH))
-QEMU_MACHINE := -cpu host,accel=kvm -machine q800 -append $(KERNEL_CMDLINE)
+QEMU_MACHINE := -cpu host,accel=kvm -machine virt -append $(KERNEL_CMDLINE)
 else
-QEMU_MACHINE := -machine q800 -smp 1 -append $(KERNEL_CMDLINE)
+QEMU_MACHINE := -machine virt -smp 1 -append $(KERNEL_CMDLINE)
 endif
 else ifeq ($(ARCH),riscv64)
 CHOST := riscv64-linux-musl
diff --git a/tools/testing/selftests/wireguard/qemu/arch/m68k.config b/tools/testing/selftests/wireguard/qemu/arch/m68k.config
index 9639bfe06074..39c48cba56b7 100644
--- a/tools/testing/selftests/wireguard/qemu/arch/m68k.config
+++ b/tools/testing/selftests/wireguard/qemu/arch/m68k.config
@@ -1,10 +1,7 @@
 CONFIG_MMU=y
+CONFIG_VIRT=y
 CONFIG_M68KCLASSIC=y
-CONFIG_M68040=y
-CONFIG_MAC=y
-CONFIG_SERIAL_PMACZILOG=y
-CONFIG_SERIAL_PMACZILOG_TTYS=y
-CONFIG_SERIAL_PMACZILOG_CONSOLE=y
+CONFIG_VIRTIO_CONSOLE=y
 CONFIG_COMPAT_32BIT_TIME=y
-CONFIG_CMDLINE="console=ttyS0 wg.success=ttyS1 panic_on_warn=1"
+CONFIG_CMDLINE="console=ttyGF0 wg.success=vport0p1 panic_on_warn=1"
 CONFIG_FRAME_WARN=1024
-- 
2.35.1


From sashal at kernel.org  Thu Jul 14 04:22:20 2022
From: sashal at kernel.org (Sasha Levin)
Date: Thu, 14 Jul 2022 00:22:20 -0400
Subject: [PATCH AUTOSEL 5.18 40/41] wireguard: selftests: always call kernel
 makefile
In-Reply-To: <20220714042221.281187-1-sashal@kernel.org>
References: <20220714042221.281187-1-sashal@kernel.org>
Message-ID: <20220714042221.281187-40-sashal@kernel.org>

From: "Jason A. Donenfeld" <Jason at zx2c4.com>

[ Upstream commit 1a087eec257154e26a81a7a0a15380d7a2431765 ]

These selftests are used for much more extensive changes than just the
wireguard source files. So always call the kernel's build file, which
will do something or nothing after checking the whole tree, per usual.

Signed-off-by: Jason A. Donenfeld <Jason at zx2c4.com>
Signed-off-by: Jakub Kicinski <kuba at kernel.org>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 tools/testing/selftests/wireguard/qemu/Makefile | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/tools/testing/selftests/wireguard/qemu/Makefile b/tools/testing/selftests/wireguard/qemu/Makefile
index e8a82e495d2e..fcc3f668b807 100644
--- a/tools/testing/selftests/wireguard/qemu/Makefile
+++ b/tools/testing/selftests/wireguard/qemu/Makefile
@@ -19,8 +19,6 @@ endif
 MIRROR := https://download.wireguard.com/qemu-test/distfiles/
 
 KERNEL_BUILD_PATH := $(BUILD_PATH)/kernel$(if $(findstring yes,$(DEBUG_KERNEL)),-debug)
-rwildcard=$(foreach d,$(wildcard $1*),$(call rwildcard,$d/,$2) $(filter $(subst *,%,$2),$d))
-WIREGUARD_SOURCES := $(call rwildcard,$(KERNEL_PATH)/drivers/net/wireguard/,*)
 
 default: qemu
 
@@ -325,8 +323,9 @@ $(KERNEL_BUILD_PATH)/.config: $(TOOLCHAIN_PATH)/.installed kernel.config arch/$(
 	cd $(KERNEL_BUILD_PATH) && ARCH=$(KERNEL_ARCH) $(KERNEL_PATH)/scripts/kconfig/merge_config.sh -n $(KERNEL_BUILD_PATH)/.config $(KERNEL_BUILD_PATH)/minimal.config
 	$(if $(findstring yes,$(DEBUG_KERNEL)),cp debug.config $(KERNEL_BUILD_PATH) && cd $(KERNEL_BUILD_PATH) && ARCH=$(KERNEL_ARCH) $(KERNEL_PATH)/scripts/kconfig/merge_config.sh -n $(KERNEL_BUILD_PATH)/.config debug.config,)
 
-$(KERNEL_BZIMAGE): $(TOOLCHAIN_PATH)/.installed $(KERNEL_BUILD_PATH)/.config $(BUILD_PATH)/init-cpio-spec.txt $(IPERF_PATH)/src/iperf3 $(IPUTILS_PATH)/ping $(BASH_PATH)/bash $(IPROUTE2_PATH)/misc/ss $(IPROUTE2_PATH)/ip/ip $(IPTABLES_PATH)/iptables/xtables-legacy-multi $(NMAP_PATH)/ncat/ncat $(WIREGUARD_TOOLS_PATH)/src/wg $(BUILD_PATH)/init ../netns.sh $(WIREGUARD_SOURCES)
+$(KERNEL_BZIMAGE): $(TOOLCHAIN_PATH)/.installed $(KERNEL_BUILD_PATH)/.config $(BUILD_PATH)/init-cpio-spec.txt $(IPERF_PATH)/src/iperf3 $(IPUTILS_PATH)/ping $(BASH_PATH)/bash $(IPROUTE2_PATH)/misc/ss $(IPROUTE2_PATH)/ip/ip $(IPTABLES_PATH)/iptables/xtables-legacy-multi $(NMAP_PATH)/ncat/ncat $(WIREGUARD_TOOLS_PATH)/src/wg $(BUILD_PATH)/init
 	$(MAKE) -C $(KERNEL_PATH) O=$(KERNEL_BUILD_PATH) ARCH=$(KERNEL_ARCH) CROSS_COMPILE=$(CROSS_COMPILE)
+.PHONY: $(KERNEL_BZIMAGE)
 
 $(TOOLCHAIN_PATH)/$(CHOST)/include/linux/.installed: | $(KERNEL_BUILD_PATH)/.config $(TOOLCHAIN_PATH)/.installed
 	rm -rf $(TOOLCHAIN_PATH)/$(CHOST)/include/linux
-- 
2.35.1


From geert at linux-m68k.org  Thu Jul 14 07:08:49 2022
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Thu, 14 Jul 2022 09:08:49 +0200
Subject: [PATCH AUTOSEL 5.18 39/41] wireguard: selftests: use virt machine
 on m68k
In-Reply-To: <20220714042221.281187-39-sashal@kernel.org>
References: <20220714042221.281187-1-sashal@kernel.org>
 <20220714042221.281187-39-sashal@kernel.org>
Message-ID: <CAMuHMdWumKeJmsOsd7_=F-+8znY=0YtH-CbeLN7knSJ1LDOR_w@mail.gmail.com>

Hi Sasha,

On Thu, Jul 14, 2022 at 6:29 AM Sasha Levin <sashal at kernel.org> wrote:
> From: "Jason A. Donenfeld" <Jason at zx2c4.com>
>
> [ Upstream commit 1f2f341a62639c7066ee4c76b7d9ebe867e0a1d5 ]
>
> This should be a bit more stable hopefully.
>
> Signed-off-by: Jason A. Donenfeld <Jason at zx2c4.com>
> Signed-off-by: Jakub Kicinski <kuba at kernel.org>
> Signed-off-by: Sasha Levin <sashal at kernel.org>

Thanks for your patch!

> --- a/tools/testing/selftests/wireguard/qemu/arch/m68k.config
> +++ b/tools/testing/selftests/wireguard/qemu/arch/m68k.config
> @@ -1,10 +1,7 @@
>  CONFIG_MMU=y
> +CONFIG_VIRT=y

The m68k virt machine was introduced in v5.19-rc1, so this patch
must not be backported to v5.18 and earlier.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

From darkranger_red at hotmail.com  Fri Jul 15 07:34:16 2022
From: darkranger_red at hotmail.com (Shen Red)
Date: Fri, 15 Jul 2022 07:34:16 +0000
Subject: =?big5?B?pl7C0DogVXBkYXRlIHdpcmVndWFyZCBpbnN0YWxsYXRpb24gaW5zdHJ1Y3Rpb25z?=
 =?big5?Q?_for_RHEL7/8-Centos8Stream?=
Message-ID: <SYBP282MB04602F7E8D72EAA794403414F28B9@SYBP282MB0460.AUSP282.PROD.OUTLOOK.COM>

I understand your suggestion. Although I am not the administrator of the WireGuard website. But personally I don't even sure how to update the instruction properly for the current circumstances. As my understanding, the instructions from the WireGuard website aims to provide the best practices to install WireGuard. But unfortunately there is no best practice available for C8S for now, each method/workaround seems quite ugly to me.

Or should we just write down lengthy texts on the page to describe the situation? I think it will break the simplicity. Since the Stream is the beta/experimental build of RHEL. The user base is low and the demand of the instruction updating for that user base is also low. Consider that the CentOS Stream 8 does not actually mention in the instruction, only CentOS 8. I think we may leave the instruction in the current shape until we got some decisive solution to provide.

There is a bug #2103865 about the recent WireGuard breakage which I submitted to Red Hat Bugzilla, and I don't see any response yet.

From sashal at kernel.org  Sun Jul 17 23:01:21 2022
From: sashal at kernel.org (Sasha Levin)
Date: Sun, 17 Jul 2022 19:01:21 -0400
Subject: [PATCH AUTOSEL 5.18 39/41] wireguard: selftests: use virt
 machine on m68k
In-Reply-To: <CAMuHMdWumKeJmsOsd7_=F-+8znY=0YtH-CbeLN7knSJ1LDOR_w@mail.gmail.com>
References: <20220714042221.281187-1-sashal@kernel.org>
 <20220714042221.281187-39-sashal@kernel.org>
 <CAMuHMdWumKeJmsOsd7_=F-+8znY=0YtH-CbeLN7knSJ1LDOR_w@mail.gmail.com>
Message-ID: <YtSUwWn1SK+B83v5@sashalap>

On Thu, Jul 14, 2022 at 09:08:49AM +0200, Geert Uytterhoeven wrote:
>Hi Sasha,
>
>On Thu, Jul 14, 2022 at 6:29 AM Sasha Levin <sashal at kernel.org> wrote:
>> From: "Jason A. Donenfeld" <Jason at zx2c4.com>
>>
>> [ Upstream commit 1f2f341a62639c7066ee4c76b7d9ebe867e0a1d5 ]
>>
>> This should be a bit more stable hopefully.
>>
>> Signed-off-by: Jason A. Donenfeld <Jason at zx2c4.com>
>> Signed-off-by: Jakub Kicinski <kuba at kernel.org>
>> Signed-off-by: Sasha Levin <sashal at kernel.org>
>
>Thanks for your patch!
>
>> --- a/tools/testing/selftests/wireguard/qemu/arch/m68k.config
>> +++ b/tools/testing/selftests/wireguard/qemu/arch/m68k.config
>> @@ -1,10 +1,7 @@
>>  CONFIG_MMU=y
>> +CONFIG_VIRT=y
>
>The m68k virt machine was introduced in v5.19-rc1, so this patch
>must not be backported to v5.18 and earlier.

I'll drop it, thanks!

-- 
Thanks,
Sasha

From sashal at kernel.org  Mon Jul 18 01:34:12 2022
From: sashal at kernel.org (Sasha Levin)
Date: Sun, 17 Jul 2022 21:34:12 -0400
Subject: [PATCH AUTOSEL 5.18 39/41] wireguard: selftests: use virt
 machine on m68k
In-Reply-To: <YtSUwWn1SK+B83v5@sashalap>
References: <20220714042221.281187-1-sashal@kernel.org>
 <20220714042221.281187-39-sashal@kernel.org>
 <CAMuHMdWumKeJmsOsd7_=F-+8znY=0YtH-CbeLN7knSJ1LDOR_w@mail.gmail.com>
 <YtSUwWn1SK+B83v5@sashalap>
Message-ID: <YtS4lPL9qb1M5KP/@sashalap>

On Sun, Jul 17, 2022 at 07:01:21PM -0400, Sasha Levin wrote:
>On Thu, Jul 14, 2022 at 09:08:49AM +0200, Geert Uytterhoeven wrote:
>>Hi Sasha,
>>
>>On Thu, Jul 14, 2022 at 6:29 AM Sasha Levin <sashal at kernel.org> wrote:
>>>From: "Jason A. Donenfeld" <Jason at zx2c4.com>
>>>
>>>[ Upstream commit 1f2f341a62639c7066ee4c76b7d9ebe867e0a1d5 ]
>>>
>>>This should be a bit more stable hopefully.
>>>
>>>Signed-off-by: Jason A. Donenfeld <Jason at zx2c4.com>
>>>Signed-off-by: Jakub Kicinski <kuba at kernel.org>
>>>Signed-off-by: Sasha Levin <sashal at kernel.org>
>>
>>Thanks for your patch!
>>
>>>--- a/tools/testing/selftests/wireguard/qemu/arch/m68k.config
>>>+++ b/tools/testing/selftests/wireguard/qemu/arch/m68k.config
>>>@@ -1,10 +1,7 @@
>>> CONFIG_MMU=y
>>>+CONFIG_VIRT=y
>>
>>The m68k virt machine was introduced in v5.19-rc1, so this patch
>>must not be backported to v5.18 and earlier.
>
>I'll drop it, thanks!

I've clicked the wrong button and still queued it by mistake, now really
removed :)

-- 
Thanks,
Sasha

From Jason at zx2c4.com  Tue Jul 26 13:06:09 2022
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Tue, 26 Jul 2022 15:06:09 +0200
Subject: [PATCH] wireguard: selftests: update config fragments
In-Reply-To: <20220726130058.21833-1-lukas.bulwahn@gmail.com>
References: <20220726130058.21833-1-lukas.bulwahn@gmail.com>
Message-ID: <CAHmME9ogBc_uX_TutV7ZC=nmhhZEtKLA3ezyx4VFwotietNytQ@mail.gmail.com>

Hi Lukas,

Thanks for researching this! I'll apply this to my wireguard tree and
send it up to netdev during my next push.

https://git.zx2c4.com/wireguard-linux/commit/?id=6da997932c4d4cb41c4a35d5541d0e4e1154fdb7

Jason

From spike at coder.com  Thu Jul 21 15:38:03 2022
From: spike at coder.com (Spike Curtis)
Date: Thu, 21 Jul 2022 08:38:03 -0700
Subject: wireguard-go - peer goroutines can SIGSEGV on device.Close()
Message-ID: <CAAi99JAdRNepDqE-+P1g7TnBmPa5AU8DBdTXbee8ZbGxZ70deQ@mail.gmail.com>

I have encountered what I think is a bug in wireguard-go which causes
a SIGSEGV like:

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x2 addr=0x20 pc=0x1006ce478]

goroutine 150 [running]:
golang.zx2c4.com/wireguard/tun/netstack.(*netTun).Write(0x140004501e0,
{0x14000192000, 0x58, 0x100000000000000?}, 0x3?)
/Users/spike/go/pkg/mod/github.com/coder/wireguard-go/tun/netstack at v0.0.0-20220614153727-d82b4ba8619f/tun.go:192
+0x108
golang.zx2c4.com/wireguard/device.(*Peer).RoutineSequentialReceiver(0x14000558000)
/Users/spike/go/pkg/mod/golang.zx2c4.com/wireguard at v0.0.0-20220703234212-c31a7b1ab478/device/receive.go:476
+0x4a0
created by golang.zx2c4.com/wireguard/device.(*Peer).Start
/Users/spike/go/pkg/mod/golang.zx2c4.com/wireguard at v0.0.0-20220703234212-c31a7b1ab478/device/peer.go:199
+0x2c8


I believe this happens when I call `Close()` on the Device with this
Peer.  Closing the device triggers gVisor to Attach a nil
NetworkDispatcher to the tun, which the Peer goroutine attempts to
dereference via Write.  This is a race condition that depends on
whether any packets are queued up at the time: if the queues are
empty, we are fine.

I'm able to work around this issue by calling RemoveAllPeers() prior
to Close() on the device, but presumably it wasn't the intention to
make Close() on its own dangerous in this way.

I'm happy to offer a patch if you're interested.

-- 
Spike Curtis
Principal Engineer
coder.com

From sndanailov at gmail.com  Sat Jul 23 21:32:17 2022
From: sndanailov at gmail.com (Sotir Danailov)
Date: Sat, 23 Jul 2022 23:32:17 +0200
Subject: [PATCH] man: wg-quick: kill-switch rules for firewalld
Message-ID: <20220723213217.29475-1-sndanailov@gmail.com>

Signed-off-by: Sotir Danailov <sndanailov at gmail.com>
---
 src/man/wg-quick.8 | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/src/man/wg-quick.8 b/src/man/wg-quick.8
index b84eb64..9f8414e 100644
--- a/src/man/wg-quick.8
+++ b/src/man/wg-quick.8
@@ -156,6 +156,13 @@ two lines `PostUp` and `PreDown` lines to the `[Interface]` section:
     \fBPreDown = iptables -D OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT\fP
 .br
 
+When using `firewalld', the ``kill-switch'' can be done like so:
+
+    \fBPostUp = firewall-cmd --permanent --direct --add-rule ipv4 filter OUTPUT 0 ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT && firewall-cmd --reload\fP
+.br
+    \fBPreDown = firewall-cmd --permanent --direct --remove-rule ipv4 filter OUTPUT 0 ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT && firewall-cmd --reload\fP
+.br
+
 The `PostUp' and `PreDown' fields have been added to specify an
 .BR iptables (8)
 command which, when used with interfaces that have a peer that specifies 0.0.0.0/0 as part of the
-- 
2.37.1


From lukas.bulwahn at gmail.com  Tue Jul 26 13:00:58 2022
From: lukas.bulwahn at gmail.com (Lukas Bulwahn)
Date: Tue, 26 Jul 2022 15:00:58 +0200
Subject: [PATCH] wireguard: selftests: update config fragments
Message-ID: <20220726130058.21833-1-lukas.bulwahn@gmail.com>

The kernel.config and debug.config fragments in wireguard selftests mention
some config symbols that have been reworked:

Commit c5665868183f ("mm: kmemleak: use the memory pool for early
allocations") removes the config DEBUG_KMEMLEAK_EARLY_LOG_SIZE and since
then, the config's feature is available without further configuration.

Commit 4675ff05de2d ("kmemcheck: rip it out") removes kmemcheck and the
corresponding arch config HAVE_ARCH_KMEMCHECK. There is no need for this
config.

Commit 3bf195ae6037 ("netfilter: nat: merge nf_nat_ipv4,6 into nat core")
removes the config NF_NAT_IPV4 and since then, the config's feature is
available without further configuration.

Commit 41a2901e7d22 ("rcu: Remove SPARSE_RCU_POINTER Kconfig option")
removes the config SPARSE_RCU_POINTER and since then, the config's feature
is enabled by default.

Commit dfb4357da6dd ("time: Remove CONFIG_TIMER_STATS") removes the feature
and config CONFIG_TIMER_STATS without any replacement.

Commit 3ca17b1f3628 ("lib/ubsan: remove null-pointer checks") removes the
check and config UBSAN_NULL without any replacement.

Adjust the config fragments to those changes in configs.

Signed-off-by: Lukas Bulwahn <lukas.bulwahn at gmail.com>
---
 tools/testing/selftests/wireguard/qemu/debug.config  | 5 -----
 tools/testing/selftests/wireguard/qemu/kernel.config | 1 -
 2 files changed, 6 deletions(-)

diff --git a/tools/testing/selftests/wireguard/qemu/debug.config b/tools/testing/selftests/wireguard/qemu/debug.config
index 2b321b8a96cf..9d172210e2c6 100644
--- a/tools/testing/selftests/wireguard/qemu/debug.config
+++ b/tools/testing/selftests/wireguard/qemu/debug.config
@@ -18,15 +18,12 @@ CONFIG_DEBUG_VM=y
 CONFIG_DEBUG_MEMORY_INIT=y
 CONFIG_HAVE_DEBUG_STACKOVERFLOW=y
 CONFIG_DEBUG_STACKOVERFLOW=y
-CONFIG_HAVE_ARCH_KMEMCHECK=y
 CONFIG_HAVE_ARCH_KASAN=y
 CONFIG_KASAN=y
 CONFIG_KASAN_INLINE=y
 CONFIG_UBSAN=y
 CONFIG_UBSAN_SANITIZE_ALL=y
-CONFIG_UBSAN_NULL=y
 CONFIG_DEBUG_KMEMLEAK=y
-CONFIG_DEBUG_KMEMLEAK_EARLY_LOG_SIZE=8192
 CONFIG_DEBUG_STACK_USAGE=y
 CONFIG_DEBUG_SHIRQ=y
 CONFIG_WQ_WATCHDOG=y
@@ -35,7 +32,6 @@ CONFIG_SCHED_INFO=y
 CONFIG_SCHEDSTATS=y
 CONFIG_SCHED_STACK_END_CHECK=y
 CONFIG_DEBUG_TIMEKEEPING=y
-CONFIG_TIMER_STATS=y
 CONFIG_DEBUG_PREEMPT=y
 CONFIG_DEBUG_RT_MUTEXES=y
 CONFIG_DEBUG_SPINLOCK=y
@@ -49,7 +45,6 @@ CONFIG_DEBUG_BUGVERBOSE=y
 CONFIG_DEBUG_LIST=y
 CONFIG_DEBUG_PLIST=y
 CONFIG_PROVE_RCU=y
-CONFIG_SPARSE_RCU_POINTER=y
 CONFIG_RCU_CPU_STALL_TIMEOUT=21
 CONFIG_RCU_TRACE=y
 CONFIG_RCU_EQS_DEBUG=y
diff --git a/tools/testing/selftests/wireguard/qemu/kernel.config b/tools/testing/selftests/wireguard/qemu/kernel.config
index e1858ce7003f..ce2a04717300 100644
--- a/tools/testing/selftests/wireguard/qemu/kernel.config
+++ b/tools/testing/selftests/wireguard/qemu/kernel.config
@@ -19,7 +19,6 @@ CONFIG_NETFILTER_XTABLES=y
 CONFIG_NETFILTER_XT_NAT=y
 CONFIG_NETFILTER_XT_MATCH_LENGTH=y
 CONFIG_NETFILTER_XT_MARK=y
-CONFIG_NF_NAT_IPV4=y
 CONFIG_IP_NF_IPTABLES=y
 CONFIG_IP_NF_FILTER=y
 CONFIG_IP_NF_MANGLE=y
-- 
2.17.1


From darkranger_red at hotmail.com  Wed Jul 27 08:38:27 2022
From: darkranger_red at hotmail.com (Shen Red)
Date: Wed, 27 Jul 2022 08:38:27 +0000
Subject: [PATCH] compat: don't backport ktime_get_coarse_boottime_ns to
 kernel-4.18.0-394
Message-ID: <SYBP282MB04604E97C0764B3D6FF3D27FF2979@SYBP282MB0460.AUSP282.PROD.OUTLOOK.COM>

This patch aims to deal with the recent compilation breakage in CentOS 8
Stream, and the future RHEL 8.7 release. Due to a change in the
kernel-4.18.0-394, which has implemented ktime_get_coarse_boottime_ns()
and caused a redefinition error. According to the response from Red Hat
Bugzilla #2103865. It doesn't seem that change will be reverted. So we have 
to deal with it in WireGuard.

In this patch, the addition in compat.h is actually very similar to the
previous abandoned commit 99935b0. But the condition is a little more
precise. There is a new definition named RHEL_KERNEL_RELEASE represents
RHEL-specific kernel versioning. E.g., 372 from 4.18.0-372.16.1. The
RHEL_KERNEL_RELEASE definition is generated by the shell command in the
modified Kbuild.include. It will return 0 if there is no RHEL kernel
version found.

Signed-off-by: Red Shen <darkranger_red at hotmail.com>
---
 src/compat/Kbuild.include | 2 ++
 src/compat/compat.h       | 5 ++++-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/src/compat/Kbuild.include b/src/compat/Kbuild.include
index 0192ecd..f170a42 100644
--- a/src/compat/Kbuild.include
+++ b/src/compat/Kbuild.include
@@ -109,3 +109,5 @@ endif
 ifneq ($(shell grep -s -F "\#define LINUX_PACKAGE_ID \" Debian " "$(CURDIR)/include/generated/package.h"),)
 ccflags-y += -DISDEBIAN
 endif
+
+ccflags-y += -DRHEL_KERNEL_RELEASE=$(shell grep -s -E '^\#define RHEL_RELEASE[[:space:]]+"[[:digit:]]+' "$(CURDIR)/include/generated/uapi/linux/version.h"| sed 's/\./ /g'| sed 's/"/ /g' | awk '{print $$3} END {if (!NR) print "0"}')
diff --git a/src/compat/compat.h b/src/compat/compat.h
index 69dada8..4f8ee69 100644
--- a/src/compat/compat.h
+++ b/src/compat/compat.h
@@ -16,6 +16,9 @@
 #define ISRHEL7
 #elif RHEL_MAJOR == 8
 #define ISRHEL8
+#if RHEL_MINOR >= 7 && RHEL_KERNEL_RELEASE >= 394
+#define IS_NEWER_RHEL8
+#endif
 #endif
 #endif
 #ifdef UTS_UBUNTU_RELEASE_ABI
@@ -387,7 +390,7 @@ static inline int get_random_bytes_wait(void *buf, int nbytes)
 #define system_power_efficient_wq system_unbound_wq
 #endif

-#if LINUX_VERSION_CODE < KERNEL_VERSION(5, 3, 0)
+#if LINUX_VERSION_CODE < KERNEL_VERSION(5, 3, 0) && !defined(IS_NEWER_RHEL8)
 #include <linux/ktime.h>
 #if LINUX_VERSION_CODE < KERNEL_VERSION(3, 17, 0)
 #include <linux/hrtimer.h>
--
1.8.3.1

From torvalds at linux-foundation.org  Thu Jul 28 23:51:58 2022
From: torvalds at linux-foundation.org (Linus Torvalds)
Date: Thu, 28 Jul 2022 16:51:58 -0700
Subject: Random arrays on kernel stack..
Message-ID: <CAHk-=wjJZGA6w_DxA+k7Ejbqsq+uGK==koPai3sqdsfJqemvag@mail.gmail.com>

So I finally have an arm64 laptop that I'm playing with, and as a
result building the kernel the way I usually do - with warnings as
errors.

And I get this:

  drivers/net/wireguard/allowedips.c: In function ?root_remove_peer_lists?:
  drivers/net/wireguard/allowedips.c:77:1: error: the frame size of
1040 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
     77 | }
        | ^
  drivers/net/wireguard/allowedips.c: In function ?root_free_rcu?:
  drivers/net/wireguard/allowedips.c:64:1: error: the frame size of
1040 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
     64 | }
        | ^

and clearly it only happens for me because it turns out Asahi has for
some odd reason picked that low CONFIG_FRAME_WARN of just 1kB.

So the fix for the warning was just to update my .config file, no biggie.

But when I look at the code that generates that warning, it just
worries me. It has that magical constant 128.

Sure, that same constant is also in push_rcu().

And there it is randomly as a warning, and then it will happily
overflow the stack frame.

That's not ok.

I think that

 (a) that constant should be a bit lower, so that we *can* use a 1kB
stack frame warning on 64-bit architectures

 (b) it should be documented some way as a #define

 (c) push_rcu() should damn well not "warn and corrupt the stack". It
should warn-and-not-corrupt the stack, even if that then means that
the thing isn't pushed at all.

Hmm?

                 Linus

From Jason at zx2c4.com  Fri Jul 29 17:12:16 2022
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Fri, 29 Jul 2022 19:12:16 +0200
Subject: Random arrays on kernel stack..
In-Reply-To: <CAHk-=wjJZGA6w_DxA+k7Ejbqsq+uGK==koPai3sqdsfJqemvag@mail.gmail.com>
References: <CAHk-=wjJZGA6w_DxA+k7Ejbqsq+uGK==koPai3sqdsfJqemvag@mail.gmail.com>
Message-ID: <YuQU8H0UCGTt5C0I@zx2c4.com>

Hey Linus,

On Thu, Jul 28, 2022 at 04:51:58PM -0700, Linus Torvalds wrote:
> So I finally have an arm64 laptop that I'm playing with, and as a

Some intrepid diving into Asahi world, eh? I admit that after playing
with the M1 and benching/optimizing some code on it, I wasn't man enough
to daily drive the thing, and I wound up selling the (already
second hand) Mac Mini shortly after acquiring it.

> result building the kernel the way I usually do - with warnings as
> errors.
> 
> And I get this:
> 
>   drivers/net/wireguard/allowedips.c: In function ?root_remove_peer_lists?:
>   drivers/net/wireguard/allowedips.c:77:1: error: the frame size of
> 1040 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
>      77 | }
>         | ^
>   drivers/net/wireguard/allowedips.c: In function ?root_free_rcu?:
>   drivers/net/wireguard/allowedips.c:64:1: error: the frame size of
> 1040 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
>      64 | }
>         | ^
> 
> and clearly it only happens for me because it turns out Asahi has for
> some odd reason picked that low CONFIG_FRAME_WARN of just 1kB.

Arnd (now CC'd) and I had a discussion about this a few years ago, and
IIRC the conclusion was that the kernel targets 1280 bytes on 64-bit
platforms and 1024 bytes on 32-bit platforms. There's been gradual work
done over the years to get gcc to generate code that matched this
expectation.

So root_remove_peer_lists and root_free_rcu are really nestling up
against the boundary. We'd looked into ways of avoid that, but decided
in the end it was fine, and probably the most okay way to implement
those algorithms, all things considered.

> But when I look at the code that generates that warning, it just
> worries me. It has that magical constant 128.
> 
> Sure, that same constant is also in push_rcu().

I could (should?) put it in a constant. But as context, note that it
doesn't look _so_ magical for anyone hacking on the code. It's a trie
for IPv4 and IPv6 addresses. If you're writing networking code, the
128-bitness of IPv6 addresses is nearly always at the top of your brain,
its general inconvenience an elephant not possible to ignore.

I guess `sizeof(struct in6_addr) * 8` would be a more accurate
reference.

>  (b) it should be documented some way as a #define

Alright, will do.

> And there it is randomly as a warning, and then it will happily
> overflow the stack frame.
> 
> That's not ok.
>
>  (c) push_rcu() should damn well not "warn and corrupt the stack". It
> should warn-and-not-corrupt the stack, even if that then means that
> the thing isn't pushed at all.

That's a good point. Though note that the current WARN_ON is also
dependent on DEBUG being set. The purpose is to catch errors when the
selftest in drivers/net/wireguard/selftest/allowedips.c runs. That file
has this snippet:

  /* These will hit the WARN_ON(len >= 128) in free_node if something
   * goes wrong.
   */
  for (i = 0; i < 128; ++i) {
    part = cpu_to_be64(~(1LLU << (i % 64)));
    memset(&ip, 0xff, 16);
    memcpy((u8 *)&ip + (i < 64) * 8, &part, 8);
    wg_allowedips_insert_v6(&t, &ip, 128, a, &mutex);
  }
  wg_allowedips_free(&t, &mutex);

Anyway, I'll conditionalize it so the stack isn't corrupted.

>  (a) that constant should be a bit lower, so that we *can* use a 1kB
> stack frame warning on 64-bit architectures

That's not so much possible. This needs to do a DFS traversal of the
trie, which means it can be 128 nodes deep since IPv6 addresses have
128 bits. I could just malloc, instead, but malloc'ing in order to free
something is kind of annoying. And it *does* fit after all. I could
suppress that option for just that file, but that might hide other bugs.
And there's the 1280 target I mentioned earlier, so maybe this is all
fine? Unless you have a different suggestion?

I think, anyhow, this is roughly where Arnd and I left off a few years
ago.

Jason

From torvalds at linux-foundation.org  Fri Jul 29 17:56:32 2022
From: torvalds at linux-foundation.org (Linus Torvalds)
Date: Fri, 29 Jul 2022 10:56:32 -0700
Subject: Random arrays on kernel stack..
In-Reply-To: <YuQU8H0UCGTt5C0I@zx2c4.com>
References: <CAHk-=wjJZGA6w_DxA+k7Ejbqsq+uGK==koPai3sqdsfJqemvag@mail.gmail.com>
 <YuQU8H0UCGTt5C0I@zx2c4.com>
Message-ID: <CAHk-=wheoU5mkht1xk_4Tyw78oa-8iGvGE9nBdUmGqCykgo1xw@mail.gmail.com>

On Fri, Jul 29, 2022 at 10:12 AM Jason A. Donenfeld <Jason at zx2c4.com> wrote:
>
> That's a good point. Though note that the current WARN_ON is also
> dependent on DEBUG being set.

Sure. And I think that's ok.

> >  (a) that constant should be a bit lower, so that we *can* use a 1kB
> > stack frame warning on 64-bit architectures
>
> That's not so much possible. This needs to do a DFS traversal of the
> trie, which means it can be 128 nodes deep since IPv6 addresses have
> 128 bits.

Ahh. Ok. That at least explains where the constant comes from. That
would be a good thing to have somewhere in that definition of the
value ;)

And I agree that malloc() isn't a great choice.

I don't really worry about the stack frame warning (I just raised it
to the same 2k limit I have on my x86-64 box), so doing that 1k
allocation is fine.

And with that constant 128 explained, I don't think it's wrong to not
even test for overflow. We don't test for things that can't happen.

But *if* you test for it for debug purposes, then at that point I
think you need to just do the "warn and don't corrupt stack".

                     Linus

From dxld at darkboxed.org  Mon Jul  4 21:52:51 2022
From: dxld at darkboxed.org (=?UTF-8?q?Daniel=20Gr=C3=B6ber?=)
Date: Mon, 04 Jul 2022 21:52:51 -0000
Subject: [PATCH] wg: Support restricting resolved Endpoint address family
Message-ID: <20220704215240.196594-1-dxld@darkboxed.org>

On IPv4-only hosts it can happen that the v6 default route pointed at a
wireguard interface blackholes wireguard peer traffic intended for the v4
network when the Endpoint hostname resolves to both v6 and v4 records as
most hosts will prefer the v6 address by default. This makes using
dual-stack dynamic-dns services for peer endpoints cumbersome.

We allow users to control which address family they want with the new
AddressFamily= config option, see wg.8 for details. We also update
reresolve-dns to take the AddressFamily option into account.
---
 contrib/reresolve-dns/reresolve-dns.sh |  4 ++-
 src/config.c                           | 41 ++++++++++++++++++++------
 src/config.h                           |  2 +-
 src/containers.h                       |  5 ++++
 src/man/wg.8                           |  8 ++++-
 src/set.c                              |  9 +++++-
 src/setconf.c                          |  2 +-
 7 files changed, 57 insertions(+), 14 deletions(-)

diff --git a/contrib/reresolve-dns/reresolve-dns.sh b/contrib/reresolve-dns/reresolve-dns.sh
index 711c332..bdb47ac 100755
--- a/contrib/reresolve-dns/reresolve-dns.sh
+++ b/contrib/reresolve-dns/reresolve-dns.sh
@@ -17,7 +17,7 @@ process_peer() {
 	[[ $PEER_SECTION -ne 1 || -z $PUBLIC_KEY || -z $ENDPOINT ]] && return 0
 	[[ $(wg show "$INTERFACE" latest-handshakes) =~ ${PUBLIC_KEY//+/\\+}\	([0-9]+) ]] || return 0
 	(( ($EPOCHSECONDS - ${BASH_REMATCH[1]}) > 135 )) || return 0
-	wg set "$INTERFACE" peer "$PUBLIC_KEY" endpoint "$ENDPOINT"
+	wg set "$INTERFACE" peer "$PUBLIC_KEY" endpoint "$ENDPOINT" address-family "$FAMILY"
 	reset_peer_section
 }
 
@@ -25,6 +25,7 @@ reset_peer_section() {
 	PEER_SECTION=0
 	PUBLIC_KEY=""
 	ENDPOINT=""
+	FAMILY=unspec
 }
 
 reset_peer_section
@@ -38,6 +39,7 @@ while read -r line || [[ -n $line ]]; do
 		case "$key" in
 		PublicKey) PUBLIC_KEY="$value"; continue ;;
 		Endpoint) ENDPOINT="$value"; continue ;;
+		AddressFamily) FAMILY="$value"; continue ;;
 		esac
 	fi
 done < "$CONFIG_FILE"
diff --git a/src/config.c b/src/config.c
index 81ccb47..e8db900 100644
--- a/src/config.c
+++ b/src/config.c
@@ -192,14 +192,14 @@ static inline int parse_dns_retries(void)
 	return (int)ret;
 }
 
-static inline bool parse_endpoint(struct sockaddr *endpoint, const char *value)
+static inline bool parse_endpoint(struct sockaddr *endpoint, const char *value, int family)
 {
 	char *mutable = strdup(value);
 	char *begin, *end;
 	int ret, retries = parse_dns_retries();
 	struct addrinfo *resolved;
 	struct addrinfo hints = {
-		.ai_family = AF_UNSPEC,
+		.ai_family = family,
 		.ai_socktype = SOCK_DGRAM,
 		.ai_protocol = IPPROTO_UDP
 	};
@@ -279,6 +279,20 @@ static inline bool parse_endpoint(struct sockaddr *endpoint, const char *value)
 	return true;
 }
 
+static inline bool parse_address_family(int *family, const char *value)
+{
+	if (strcmp(value, "inet") == 0)
+		*family = AF_INET;
+	else if (strcmp(value, "inet6") == 0)
+		*family = AF_INET6;
+	else if (strcmp(value, "unspec") == 0)
+		*family = AF_UNSPEC;
+	else
+		return false;
+
+	return true;
+}
+
 static inline bool parse_persistent_keepalive(uint16_t *interval, uint32_t *flags, const char *value)
 {
 	unsigned long ret;
@@ -454,8 +468,10 @@ static bool process_line(struct config_ctx *ctx, const char *line)
 			goto error;
 	} else if (ctx->is_peer_section) {
 		if (key_match("Endpoint"))
-			ret = parse_endpoint(&ctx->last_peer->endpoint.addr, value);
-		else if (key_match("PublicKey")) {
+			ctx->last_peer->endpoint_value = strdup(value);
+		else if (key_match("AddressFamily")) {
+			ret = parse_address_family(&ctx->last_peer->addr_fam, value);
+		} else if (key_match("PublicKey")) {
 			ret = parse_key(ctx->last_peer->public_key, value);
 			if (ret)
 				ctx->last_peer->flags |= WGPEER_HAS_PUBLIC_KEY;
@@ -527,19 +543,22 @@ bool config_read_init(struct config_ctx *ctx, bool append)
 	return true;
 }
 
-struct wgdevice *config_read_finish(struct config_ctx *ctx)
+struct wgdevice *config_read_finish(struct wgdevice *device)
 {
 	struct wgpeer *peer;
 
-	for_each_wgpeer(ctx->device, peer) {
+	for_each_wgpeer(device, peer) {
 		if (!(peer->flags & WGPEER_HAS_PUBLIC_KEY)) {
 			fprintf(stderr, "A peer is missing a public key\n");
 			goto err;
 		}
+
+		if (!parse_endpoint(&peer->endpoint.addr, peer->endpoint_value, peer->addr_fam))
+			goto err;
 	}
-	return ctx->device;
+	return device;
 err:
-	free_wgdevice(ctx->device);
+	free_wgdevice(device);
 	return NULL;
 }
 
@@ -611,7 +630,11 @@ struct wgdevice *config_read_cmd(const char *argv[], int argc)
 			argv += 1;
 			argc -= 1;
 		} else if (!strcmp(argv[0], "endpoint") && argc >= 2 && peer) {
-			if (!parse_endpoint(&peer->endpoint.addr, argv[1]))
+			peer->endpoint_value = strdup(argv[1]);
+			argv += 2;
+			argc -= 2;
+		} else if (!strcmp(argv[0], "address-family") && argc >= 2 && peer) {
+			if (!parse_address_family(&peer->addr_fam, argv[1]))
 				goto error;
 			argv += 2;
 			argc -= 2;
diff --git a/src/config.h b/src/config.h
index 443cf21..6f81da2 100644
--- a/src/config.h
+++ b/src/config.h
@@ -22,6 +22,6 @@ struct config_ctx {
 struct wgdevice *config_read_cmd(const char *argv[], int argc);
 bool config_read_init(struct config_ctx *ctx, bool append);
 bool config_read_line(struct config_ctx *ctx, const char *line);
-struct wgdevice *config_read_finish(struct config_ctx *ctx);
+struct wgdevice *config_read_finish(struct wgdevice *device);
 
 #endif
diff --git a/src/containers.h b/src/containers.h
index a82e8dd..c111621 100644
--- a/src/containers.h
+++ b/src/containers.h
@@ -52,12 +52,15 @@ struct wgpeer {
 	uint8_t public_key[WG_KEY_LEN];
 	uint8_t preshared_key[WG_KEY_LEN];
 
+	char *endpoint_value;
 	union {
 		struct sockaddr addr;
 		struct sockaddr_in addr4;
 		struct sockaddr_in6 addr6;
 	} endpoint;
 
+	int addr_fam;
+
 	struct timespec64 last_handshake_time;
 	uint64_t rx_bytes, tx_bytes;
 	uint16_t persistent_keepalive_interval;
@@ -99,6 +102,8 @@ static inline void free_wgdevice(struct wgdevice *dev)
 	for (struct wgpeer *peer = dev->first_peer, *np = peer ? peer->next_peer : NULL; peer; peer = np, np = peer ? peer->next_peer : NULL) {
 		for (struct wgallowedip *allowedip = peer->first_allowedip, *na = allowedip ? allowedip->next_allowedip : NULL; allowedip; allowedip = na, na = allowedip ? allowedip->next_allowedip : NULL)
 			free(allowedip);
+		if (peer->endpoint_value)
+			free(peer->endpoint_value);
 		free(peer);
 	}
 	free(dev);
diff --git a/src/man/wg.8 b/src/man/wg.8
index 7984539..fd9fde7 100644
--- a/src/man/wg.8
+++ b/src/man/wg.8
@@ -55,7 +55,7 @@ transfer-rx, transfer-tx, persistent-keepalive.
 Shows the current configuration of \fI<interface>\fP in the format described
 by \fICONFIGURATION FILE FORMAT\fP below.
 .TP
-\fBset\fP \fI<interface>\fP [\fIlisten-port\fP \fI<port>\fP] [\fIfwmark\fP \fI<fwmark>\fP] [\fIprivate-key\fP \fI<file-path>\fP] [\fIpeer\fP \fI<base64-public-key>\fP [\fIremove\fP] [\fIpreshared-key\fP \fI<file-path>\fP] [\fIendpoint\fP \fI<ip>:<port>\fP] [\fIpersistent-keepalive\fP \fI<interval seconds>\fP] [\fIallowed-ips\fP \fI<ip1>/<cidr1>\fP[,\fI<ip2>/<cidr2>\fP]...] ]...
+\fBset\fP \fI<interface>\fP [\fIlisten-port\fP \fI<port>\fP] [\fIfwmark\fP \fI<fwmark>\fP] [\fIprivate-key\fP \fI<file-path>\fP] [\fIpeer\fP \fI<base64-public-key>\fP [\fIremove\fP] [\fIpreshared-key\fP \fI<file-path>\fP] [\fIendpoint\fP \fI<ip>:<port>\fP] [\fIaddress-family\fP \fI<family>\fP] [\fIpersistent-keepalive\fP \fI<interval seconds>\fP] [\fIallowed-ips\fP \fI<ip1>/<cidr1>\fP[,\fI<ip2>/<cidr2>\fP]...] ]...
 Sets configuration values for the specified \fI<interface>\fP. Multiple
 \fIpeer\fPs may be specified, and if the \fIremove\fP argument is given
 for a peer, that peer is removed, not configured. If \fIlisten-port\fP
@@ -163,6 +163,12 @@ port number. This endpoint will be updated automatically to the most recent
 source IP address and port of correctly authenticated packets from the peer.
 Optional.
 .IP \(bu
+AddressFamily \(em one of \fIinet\fP, \fIinet6\fP or \fIunspec\fP. When a
+hostname is given for \fIEndpoint\fP, setting this to \fIinet\fP or
+\fIinet6\fP will allow only addresses of the given family to be
+used. Defaults to \fIunspec\fP, which causes the first returned address of
+any type to be used.
+.IP \(bu
 PersistentKeepalive \(em a seconds interval, between 1 and 65535 inclusive, of
 how often to send an authenticated empty packet to the peer for the purpose of keeping a
 stateful firewall or NAT mapping valid persistently. For example, if the interface
diff --git a/src/set.c b/src/set.c
index 75560fd..20ee85e 100644
--- a/src/set.c
+++ b/src/set.c
@@ -18,13 +18,20 @@ int set_main(int argc, const char *argv[])
 	int ret = 1;
 
 	if (argc < 3) {
-		fprintf(stderr, "Usage: %s %s <interface> [listen-port <port>] [fwmark <mark>] [private-key <file path>] [peer <base64 public key> [remove] [preshared-key <file path>] [endpoint <ip>:<port>] [persistent-keepalive <interval seconds>] [allowed-ips <ip1>/<cidr1>[,<ip2>/<cidr2>]...] ]...\n", PROG_NAME, argv[0]);
+		fprintf(stderr, "Usage: %s %s <interface> [listen-port <port>] [fwmark <mark>] [private-key <file path>] [peer <base64 public key> [remove] [preshared-key <file path>] [endpoint <ip>:<port>] [address-family <family>] [persistent-keepalive <interval seconds>] [allowed-ips <ip1>/<cidr1>[,<ip2>/<cidr2>]...] ]...\n", PROG_NAME, argv[0]);
 		return 1;
 	}
 
 	device = config_read_cmd(argv + 2, argc - 2);
 	if (!device)
 		goto cleanup;
+
+	device = config_read_finish(device);
+	if (!device) {
+		fprintf(stderr, "Invalid configuration\n");
+		goto cleanup;
+	}
+
 	strncpy(device->name, argv[1], IFNAMSIZ -  1);
 	device->name[IFNAMSIZ - 1] = '\0';
 
diff --git a/src/setconf.c b/src/setconf.c
index 1c5b138..c90fd30 100644
--- a/src/setconf.c
+++ b/src/setconf.c
@@ -127,7 +127,7 @@ int setconf_main(int argc, const char *argv[])
 			goto cleanup;
 		}
 	}
-	device = config_read_finish(&ctx);
+	device = config_read_finish(ctx.device);
 	if (!device) {
 		fprintf(stderr, "Invalid configuration\n");
 		goto cleanup;
-- 
2.30.2


From Quentin.Vallin at anuvu.com  Tue Jul 19 21:37:02 2022
From: Quentin.Vallin at anuvu.com (Quentin Vallin)
Date: Tue, 19 Jul 2022 21:37:02 -0000
Subject: [Question or feature request] Support multiple peer config file using
 something like /etc/wireguard/conf.d
Message-ID: <MN2PR10MB418992D0FB239AC2D3DC8B298E8F9@MN2PR10MB4189.namprd10.prod.outlook.com>

Hi,?

I'm trying to separate?my peer configuration and automate it.?

I know that I can use the post hook PostUp = wg addconf /path/to/my/file

It would be easier to have a special path were wireguard can merge the config file together, like /etc/wireguard/conf.d/<interface_name>/<files>.conf.?

I don't find anything in the doc. Do you have a clue if that feature exists? Or if that feature is on the backlog?

Thank you for your amazing tool !

Quentin.