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: References: <20220630191230.235306-1-kaleshsingh@google.com> Message-ID: 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 > > Signed-off-by: Kalesh Singh > > 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 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> <87a69slh0x.fsf@meer.lwn.net> Message-ID: 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: References: <20220629161527.GA24978@lst.de> <20220629163007.GA25279@lst.de> Message-ID: <87a69slh0x.fsf@meer.lwn.net> "Jason A. Donenfeld" 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: 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 Link: https://lore.kernel.org/linux-kernel/202207030630.6SZVkrWf-lkp at intel.com/ Signed-off-by: Vladis Dronov --- 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: 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> 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: 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 > Link: https://lore.kernel.org/linux-kernel/202207030630.6SZVkrWf-lkp at intel.com/ > Signed-off-by: Vladis Dronov > --- > 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: References: <20220704191535.76006-1-vdronov@redhat.com> Message-ID: 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 > > Link: https://lore.kernel.org/linux-kernel/202207030630.6SZVkrWf-lkp at intel.com/ > > Signed-off-by: Vladis Dronov > > --- > > 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: References: <20220704191535.76006-1-vdronov@redhat.com> Message-ID: Hi, On Tue, Jul 5, 2022 at 3:51 AM Jason A. Donenfeld 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 > > > Link: https://lore.kernel.org/linux-kernel/202207030630.6SZVkrWf-lkp at intel.com/ > > > Signed-off-by: Vladis Dronov > > > ... 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: References: <20220704191535.76006-1-vdronov@redhat.com> Message-ID: 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: 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: 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> <79c6ad70-47d9-47fe-4bb4-33fcf356dd37@amd.com> Message-ID: 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: 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> <79c6ad70-47d9-47fe-4bb4-33fcf356dd37@amd.com> 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> <79c6ad70-47d9-47fe-4bb4-33fcf356dd37@amd.com> <20220706175836.GI1790663@paulmck-ThinkPad-P17-Gen-1> Message-ID: 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: 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> <79c6ad70-47d9-47fe-4bb4-33fcf356dd37@amd.com> <20220706175836.GI1790663@paulmck-ThinkPad-P17-Gen-1> 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> <79c6ad70-47d9-47fe-4bb4-33fcf356dd37@amd.com> <20220706175836.GI1790663@paulmck-ThinkPad-P17-Gen-1> <20220706204202.GJ1790663@paulmck-ThinkPad-P17-Gen-1> Message-ID: 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&data=05%7C01%7Cchristian.koenig%40amd.com%7C8b36bcb4fe61475c0eb708da5f8ffce8%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637927369274030797%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=eaK66spsbWVi2uRhcFK7eu4usgkHFZCSvErZxB%2F2npM%3D&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: References: <1656421946.ic03168yc3.none@localhost> <20220628185437.GA1790663@paulmck-ThinkPad-P17-Gen-1> <1656443915.mdjoauhqe0.none@localhost> <79c6ad70-47d9-47fe-4bb4-33fcf356dd37@amd.com> <20220706175836.GI1790663@paulmck-ThinkPad-P17-Gen-1> <20220706204202.GJ1790663@paulmck-ThinkPad-P17-Gen-1> 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&data=05%7C01%7Cchristian.koenig%40amd.com%7C8b36bcb4fe61475c0eb708da5f8ffce8%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637927369274030797%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=eaK66spsbWVi2uRhcFK7eu4usgkHFZCSvErZxB%2F2npM%3D&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: 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: 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: 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: References: Message-ID: Hi Shen! Shen Red , 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: 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" [ 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 Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin --- .../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 #include #include +#include #include #include #include @@ -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" [ Upstream commit 1f2f341a62639c7066ee4c76b7d9ebe867e0a1d5 ] This should be a bit more stable hopefully. Signed-off-by: Jason A. Donenfeld Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin --- 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" [ 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 Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin --- 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: Hi Sasha, On Thu, Jul 14, 2022 at 6:29 AM Sasha Levin wrote: > From: "Jason A. Donenfeld" > > [ Upstream commit 1f2f341a62639c7066ee4c76b7d9ebe867e0a1d5 ] > > This should be a bit more stable hopefully. > > Signed-off-by: Jason A. Donenfeld > Signed-off-by: Jakub Kicinski > Signed-off-by: Sasha Levin 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: 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: References: <20220714042221.281187-1-sashal@kernel.org> <20220714042221.281187-39-sashal@kernel.org> Message-ID: 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 wrote: >> From: "Jason A. Donenfeld" >> >> [ Upstream commit 1f2f341a62639c7066ee4c76b7d9ebe867e0a1d5 ] >> >> This should be a bit more stable hopefully. >> >> Signed-off-by: Jason A. Donenfeld >> Signed-off-by: Jakub Kicinski >> Signed-off-by: Sasha Levin > >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: References: <20220714042221.281187-1-sashal@kernel.org> <20220714042221.281187-39-sashal@kernel.org> Message-ID: 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 wrote: >>>From: "Jason A. Donenfeld" >>> >>>[ Upstream commit 1f2f341a62639c7066ee4c76b7d9ebe867e0a1d5 ] >>> >>>This should be a bit more stable hopefully. >>> >>>Signed-off-by: Jason A. Donenfeld >>>Signed-off-by: Jakub Kicinski >>>Signed-off-by: Sasha Levin >> >>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: 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: 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 --- 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 --- 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: 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 --- 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 #if LINUX_VERSION_CODE < KERNEL_VERSION(3, 17, 0) #include -- 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: 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: References: Message-ID: 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: References: Message-ID: On Fri, Jul 29, 2022 at 10:12 AM Jason A. Donenfeld 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\fP in the format described by \fICONFIGURATION FILE FORMAT\fP below. .TP -\fBset\fP \fI\fP [\fIlisten-port\fP \fI\fP] [\fIfwmark\fP \fI\fP] [\fIprivate-key\fP \fI\fP] [\fIpeer\fP \fI\fP [\fIremove\fP] [\fIpreshared-key\fP \fI\fP] [\fIendpoint\fP \fI:\fP] [\fIpersistent-keepalive\fP \fI\fP] [\fIallowed-ips\fP \fI/\fP[,\fI/\fP]...] ]... +\fBset\fP \fI\fP [\fIlisten-port\fP \fI\fP] [\fIfwmark\fP \fI\fP] [\fIprivate-key\fP \fI\fP] [\fIpeer\fP \fI\fP [\fIremove\fP] [\fIpreshared-key\fP \fI\fP] [\fIendpoint\fP \fI:\fP] [\fIaddress-family\fP \fI\fP] [\fIpersistent-keepalive\fP \fI\fP] [\fIallowed-ips\fP \fI/\fP[,\fI/\fP]...] ]... Sets configuration values for the specified \fI\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 [listen-port ] [fwmark ] [private-key ] [peer [remove] [preshared-key ] [endpoint :] [persistent-keepalive ] [allowed-ips /[,/]...] ]...\n", PROG_NAME, argv[0]); + fprintf(stderr, "Usage: %s %s [listen-port ] [fwmark ] [private-key ] [peer [remove] [preshared-key ] [endpoint :] [address-family ] [persistent-keepalive ] [allowed-ips /[,/]...] ]...\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: 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//.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.