From simon at rozman.si  Wed Apr  1 08:46:11 2020
From: simon at rozman.si (Simon Rozman)
Date: Wed, 1 Apr 2020 06:46:11 +0000
Subject: [PATCH wireguard-windows] Calculate the actual route metric by
 summing interface and route metric.
In-Reply-To: <e7f67006-09a0-e775-5f7d-4d0c8e7e271a@web.de>
References: <20200327170750.5285-1-suyjuris.gi@nicze.de>
 <CAHmME9r4vDKeWCjp2XF3pKaKUDokDphnVoYBqV5YfLd=gTNbPA@mail.gmail.com>
 <e7f67006-09a0-e775-5f7d-4d0c8e7e271a@web.de>
Message-ID: <EE280F52-484A-4C40-BBF3-F23D0E19CFC9@rozman.si>

Hi Ludwig,

Would a support for ExecPostUp/ExecPreDown satisfy your need?

Regards, Simon

?-----Original Message-----
From: WireGuard <wireguard-bounces at lists.zx2c4.com> on behalf of Ludwig Herzog <ludwig.herzog at web.de>
Date: Tuesday, 31 March 2020 at 05:33
To: "wireguard at lists.zx2c4.com" <wireguard at lists.zx2c4.com>
Subject: Re: [PATCH wireguard-windows] Calculate the actual route metric by summing interface and route metric.

    Hi,
    
    I'm reading this maillist since a longer time and was never brave enough
    to mention my problem since I'm not a developer or programmer and don't
    know if I can describe it properly. Now this windows/metric stuff came
    up, so I take a heart ;-)
    
    In short: I have windows 10 client softwares which only work properly
    with manually set adapter and gateway metrics in the VPN network
    adapter, what works for openVPN (even better for a logmein test setup)
    but not for wireguard, since manual metric settings are not recognized /
    overwritten by the windows wireguard app. Is it possible to set the
    metrics somehow in the config file? Or prevent the windows wireguard app
    from overwriting?
    
    Regards
    
    Ludwig
    
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2965 bytes
Desc: not available
URL: <http://lists.zx2c4.com/pipermail/wireguard/attachments/20200401/e570b6aa/attachment.p7s>

From rm at romanrm.net  Wed Apr  1 14:48:11 2020
From: rm at romanrm.net (Roman Mamedov)
Date: Wed, 1 Apr 2020 17:48:11 +0500
Subject: [ANNOUNCE] wireguard-linux-compat v1.0.20200330 released
In-Reply-To: <38842e471ccb3582@frisell.zx2c4.com>
References: <38842e471ccb3582@frisell.zx2c4.com>
Message-ID: <20200401174811.5cf6895c@natsu>

On Mon, 30 Mar 2020 18:19:17 -0600
"Jason A. Donenfeld" <Jason at zx2c4.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> Hello,
> 
> A new version, v1.0.20200330, of the backported WireGuard kernel module for
> 3.10 <= Linux <= 5.5.y has been tagged in the git repository.

My kernel build for 5.4.29 has failed just now:

In file included from <command-line>:
././net/wireguard/compat/compat.h:1029:20: error: redefinition of ?skb_reset_redirect?
 static inline void skb_reset_redirect(struct sk_buff *skb)
                    ^~~~~~~~~~~~~~~~~~
In file included from ././net/wireguard/compat/compat.h:878,
                 from <command-line>:
./include/linux/skbuff.h:4538:20: note: previous definition of ?skb_reset_redirect? was here
 static inline void skb_reset_redirect(struct sk_buff *skb)
                    ^~~~~~~~~~~~~~~~~~
In file included from <command-line>:
././net/wireguard/compat/compat.h: In function ?skb_reset_redirect?:
././net/wireguard/compat/compat.h:1032:2: error: implicit declaration of function ?skb_reset_tc?; did you mean ?skb_reserve?? [-Werror=implicit-function-declaration]
  skb_reset_tc(skb);
  ^~~~~~~~~~~~
  skb_reserve
cc1: some warnings being treated as errors
scripts/Makefile.build:265: recipe for target 'net/wireguard/main.o' failed
make[3]: *** [net/wireguard/main.o] Error 1
scripts/Makefile.build:500: recipe for target 'net/wireguard' failed
make[2]: *** [net/wireguard] Error 2

> 
> == Changes ==
> 
>   * queueing: backport skb_reset_redirect change from 5.6
>   * version: bump
>   
>   This release has only one slight change, to put it closer to he 5.6 codebase,
>   but its main purpose is to bump us to a 1.0.y version number. Now that
>   WireGuard 1.0.0 has been released for Linux 5.6 [1], we can put the same number on
>   the backport compat codebase.
>   
>   [1] https://lists.zx2c4.com/pipermail/wireguard/2020-March/005206.html
> 
> This release contains commits from: Jason A. Donenfeld.
> 
> As always, the source is available at https://git.zx2c4.com/wireguard-linux-compat/
> and information about the project is available at https://www.wireguard.com/ .
> 
> This version is available in compressed tarball form here:
>   https://git.zx2c4.com/wireguard-linux-compat/snapshot/wireguard-linux-compat-1.0.20200330.tar.xz
>   SHA2-256: 2d57b239605be2ee0e4c2da935ff1a23e9ed8bb3ee692e10ae032ae50f280bef
> 
> A PGP signature of that file decompressed is available here:
>   https://git.zx2c4.com/wireguard-linux-compat/snapshot/wireguard-linux-compat-1.0.20200330.tar.asc
>   Signing key: AB9942E6D4A4CFC3412620A749FC7012A5DE03AE
>   Remember to unxz the tarball before verifying the signature.
> 
> If you're a package maintainer, please bump your package version. If you're a
> user, the WireGuard team welcomes any and all feedback on this latest version.
> 
> Finally, WireGuard development thrives on donations. By popular demand, we
> have a webpage for this: https://www.wireguard.com/donations/
> 
> Thank you,
> Jason Donenfeld
> 
> 
> -----BEGIN PGP SIGNATURE-----
> 
> iQJEBAEBCAAuFiEEq5lC5tSkz8NBJiCnSfxwEqXeA64FAl6CjGwQHGphc29uQHp4
> MmM0LmNvbQAKCRBJ/HASpd4DrqfwD/wJlEbOhYd1ixM3OI8Q2endXmJBRh9UimjL
> F2moHwTzDM49o3xQpfgQuBFbZWK0L/JNTSlKxrmBLcX9fBJ2VERT1Nrnlh414Ovw
> FLpmJt9gOWMF6hjlptXKaE/T0vRjzfLli2YzfzyvqMQg9hR/eRKlYhYWOu/fsm3L
> UtmBm8wGdDeo7e119M0dnfcfboW2b3NKQX87/bWrAn21BL9F+JsNx8Ytx2a5cU8z
> ZLj56sDWWclmoIXiLI1e+bKO9pXRXvfkSd11p5KK6knD8i8BtAn7uVVfda5VWxmO
> xooFhNq75photRM0t/VAKhp7ji96pYwSQD6Kw91HPgBcptB29XoacUcpLs40TUx5
> D7LpvYISKItZpPdfgSwIx3kyajBDmn8bpFZH8T+/cDsIvuJbdpGjP88Qr86JiKQ+
> BiVmTW5nXWn0d4tQIbw2w34BVre5cLheyWZN3Nk6f7bfxjba52Qa85rrjPoCNWv+
> PPsVTffIfAxk5ZavSuPUx+QMtmIqnC/bOb2WUn/+lukv+HVYYXO5GyHrfTqS9EW/
> kw/2dC9pGSye6bz7KYTQwRHSJnaA+SDk2ZNFdlrsYaoFfuZJeaFMkiU3xpIYGllv
> +v6rmQw/l0d4yZtHR6jmMV4qWeZetH0/5De21/syOQt8XuySjlkNVLRUPgIdZtKN
> ak69693rPw==
> =K43H
> -----END PGP SIGNATURE-----


-- 
With respect,
Roman

From list at eworm.de  Wed Apr  1 18:32:32 2020
From: list at eworm.de (Christian Hesse)
Date: Wed,  1 Apr 2020 18:32:32 +0200
Subject: [PATCH 1/1] queueing: skb_reset_redirect change has been backported
 to 5.[45]
Message-ID: <20200401163232.154754-1-list@eworm.de>

From: Christian Hesse <mail at eworm.de>

This is a follow up to 2d4fa2a6e7903ec3340f1b075456cbd84ba6a744.

Upstream commit 2c64605b590edadb3fb46d1ec6badb49e940b479 has been backported
to 5.4.29 and 5.5.14.

Signed-off-by: Christian Hesse <mail at eworm.de>
---
 src/compat/compat.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/compat/compat.h b/src/compat/compat.h
index fe2d07e..7f16332 100644
--- a/src/compat/compat.h
+++ b/src/compat/compat.h
@@ -1024,7 +1024,8 @@ out:
 #define COMPAT_CANNOT_USE_MAX_MTU
 #endif
 
-#if LINUX_VERSION_CODE < KERNEL_VERSION(5, 6, 0)
+#if (LINUX_VERSION_CODE < KERNEL_VERSION(5, 4, 29) || \
+    (LINUX_VERSION_CODE >= KERNEL_VERSION(5, 5, 0) && LINUX_VERSION_CODE < KERNEL_VERSION(5, 5, 14)))
 #include <linux/skbuff.h>
 static inline void skb_reset_redirect(struct sk_buff *skb)
 {

From Jason at zx2c4.com  Wed Apr  1 21:11:15 2020
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Wed, 01 Apr 2020 13:11:15 -0600
Subject: [ANNOUNCE] wireguard-linux-compat v1.0.20200401 released
Message-ID: <38846280368266f8@frisell.zx2c4.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hello,

A new version, v1.0.20200401, of the backported WireGuard kernel module for
3.10 <= Linux <= 5.5.y has been tagged in the git repository.

== Changes ==

  * compat: queueing: skb_reset_redirect change has been backported to 5.[45]
  * qemu: bump default kernel to 5.5.14
  
  An upstream stable backport broke our compat layer, which this release
  rectifies.

This release contains commits from: Jason A. Donenfeld and Christian Hesse.

As always, the source is available at https://git.zx2c4.com/wireguard-linux-compat/
and information about the project is available at https://www.wireguard.com/ .

This version is available in compressed tarball form here:
  https://git.zx2c4.com/wireguard-linux-compat/snapshot/wireguard-linux-compat-1.0.20200401.tar.xz
  SHA2-256: 7dfb4a8315e1d6ae406ff32d01c496175df558dd65968a19e5222d02c7cfb77a

A PGP signature of that file decompressed is available here:
  https://git.zx2c4.com/wireguard-linux-compat/snapshot/wireguard-linux-compat-1.0.20200401.tar.asc
  Signing key: AB9942E6D4A4CFC3412620A749FC7012A5DE03AE
  Remember to unxz the tarball before verifying the signature.

If you're a package maintainer, please bump your package version. If you're a
user, the WireGuard team welcomes any and all feedback on this latest version.

Finally, WireGuard development thrives on donations. By popular demand, we
have a webpage for this: https://www.wireguard.com/donations/

Thank you,
Jason Donenfeld


-----BEGIN PGP SIGNATURE-----

iQJEBAEBCAAuFiEEq5lC5tSkz8NBJiCnSfxwEqXeA64FAl6E50wQHGphc29uQHp4
MmM0LmNvbQAKCRBJ/HASpd4DrkKyD/9I2vPCtJxtW3zdsbFo6hHMvHuJfUPsj361
NyOk2VfsKSWIPAkBWP5pUZIxOMqCpB/oyyybfNMBo4863r6shStvMMqGifZMZBBK
kfYZGiE8A+nv9P9QWyzeiB6RPFHfeSWuzldhSFdoV6XLTwi0eWvMuvFRsCy/9P27
O0xgKyFjk3K7y74USDR/6xJK/6tzwpa2UYLaSxvIrO03D+qxgK4KQiNR53Oz+Gic
byPF14X57ibGx7NxVquAAPK1IA89zfNgM9TW6MTNvxctnmzm7AJ6JFIcfBlqyUGA
lQNRxST5j8HOMQAOFNlrhxTfIQP5R/KphfX35s/xBZdLPXm3//1V5is+SVNXcScD
attsaiJq7BP6R23hA/R3uJYd9nmEqUPBiKZLiSWcgsmN+pUrwuT62mrG79MVwO2z
pgo8Fo76rIOL5XwJnmqjtKpUnFRoS1NR72fz3qp9ep0Zg7eIW14p9iYEsHKXyr7z
DhLJSEuKZixfmJatpZEPwUMZSDwACSHjG8kpdMSDIMu/xkL42U2/8o79S1OQyRMD
nMklhBiPdKxF2jOSX9jtHamOiOijRw2tJeF/LOcXqwsQYBKnaxswKJ1tqyrMrpQG
nB90ccerpwN6Rup7DIrv3FXLniv9exilJquugimpZkiBIaLXCDhjHzsochdHFLi2
4ugVM6Aw+g==
=0Zlp
-----END PGP SIGNATURE-----

From Jason at zx2c4.com  Wed Apr  1 21:11:36 2020
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Wed, 1 Apr 2020 13:11:36 -0600
Subject: [PATCH 1/1] queueing: skb_reset_redirect change has been
 backported to 5.[45]
In-Reply-To: <20200401163232.154754-1-list@eworm.de>
References: <20200401163232.154754-1-list@eworm.de>
Message-ID: <CAHmME9pimpm-MYur0vA6BCTSkWUwdMtOwEcPHPRc-puE=CBVww@mail.gmail.com>

Applied and released, thanks.

From Jason at zx2c4.com  Sat Apr  4 23:12:46 2020
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Sat, 4 Apr 2020 15:12:46 -0600
Subject: More reliable packages available for RHEL, CentOS, and Fedora
Message-ID: <20200404211246.GA10066@zx2c4.com>

Hey folks,

Joe Doss (cc'd) has maintained our DKMS packages for Fedora, RHEL, and CentOS
for the last several years on his copr. Recently there have been some nice
changes due to the 1.0ing of WireGuard.

- Fedora 32 will get Linux 5.6, so it won't need the DKMS package:
  https://bodhi.fedoraproject.org/updates/FEDORA-2020-e8b6474ee5
- Fedora 31 and 30 will also get Linux 5.6 during the next month, so
  they won't need the DKMS package.
- Joe has joined ELRepo (cc'd) as a package maintainer, so RHEL/CentOS
  7/8 will now have binary kmods built over there, signed with ELrepo's
  validating UEFI Secure Boot key, so enterprise users will have more
  reliable updates.
- I've contacted Red Hat about bringing WireGuard directly into the RHEL kernel;
  we'll see what happens there. (I've also reached out to Oracle
  regarding their enterprise situation.)
- The wireguard-tools package moved into Fedora-proper, which means it's
  now available on F32, F31, F30, and RHEL/CentOS 7,8 via EPEL.

The net result of this is that when F31 and F32 move to 5.6, we will no
longer need the copr with DKMS, at all, and also that today, enterprise
users now have a more reliable way to use WireGuard.

The most up to date instructions are on https://www.wireguard.com/install/
but the current situation is:

Fedora 32 now and Fedora 31,30 in a few weeks from now:
$ sudo dnf install wireguard-tools

Fedora 31,30 now, but not in a few weeks from now:
$ sudo dnf copr enable jdoss/wireguard
$ sudo dnf install wireguard-dkms wireguard-tools

RHEL 8:
$ sudo yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm
$ sudo yum install https://www.elrepo.org/elrepo-release-8.el8.elrepo.noarch.rpm
$ sudo yum install kmod-wireguard wireguard-tools

CentOS 8:
$ sudo yum install elrepo-release epel-release
$ sudo yum install kmod-wireguard wireguard-tools

RHEL 7:
$ sudo yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
$ sudo yum install https://www.elrepo.org/elrepo-release-7.el7.elrepo.noarch.rpm
$ sudo yum install kmod-wireguard wireguard-tools

CentOS 7:
$ sudo yum install epel-release
$ sudo yum install https://www.elrepo.org/elrepo-release-7.el7.elrepo.noarch.rpm
$ sudo yum install kmod-wireguard wireguard-tools

Thanks,
Jason

From Jason at zx2c4.com  Sat Apr  4 23:22:18 2020
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Sat, 4 Apr 2020 15:22:18 -0600
Subject: More reliable packages available for RHEL, CentOS, and Fedora
In-Reply-To: <20200404211246.GA10066@zx2c4.com>
References: <20200404211246.GA10066@zx2c4.com>
Message-ID: <CAHmME9qr+PHsn6EJAwhkdu0NwN3g3zdkJfX5X+aBjwovN9grsg@mail.gmail.com>

I was asked to loop in the ELRepo mailing list too. Below is the email
I just sent out to wgml.

On Sat, Apr 4, 2020 at 3:12 PM Jason A. Donenfeld <Jason at zx2c4.com> wrote:
>
> Hey folks,
>
> Joe Doss (cc'd) has maintained our DKMS packages for Fedora, RHEL, and CentOS
> for the last several years on his copr. Recently there have been some nice
> changes due to the 1.0ing of WireGuard.
>
> - Fedora 32 will get Linux 5.6, so it won't need the DKMS package:
>   https://bodhi.fedoraproject.org/updates/FEDORA-2020-e8b6474ee5
> - Fedora 31 and 30 will also get Linux 5.6 during the next month, so
>   they won't need the DKMS package.
> - Joe has joined ELRepo (cc'd) as a package maintainer, so RHEL/CentOS
>   7/8 will now have binary kmods built over there, signed with ELrepo's
>   validating UEFI Secure Boot key, so enterprise users will have more
>   reliable updates.
> - I've contacted Red Hat about bringing WireGuard directly into the RHEL kernel;
>   we'll see what happens there. (I've also reached out to Oracle
>   regarding their enterprise situation.)
> - The wireguard-tools package moved into Fedora-proper, which means it's
>   now available on F32, F31, F30, and RHEL/CentOS 7,8 via EPEL.
>
> The net result of this is that when F31 and F32 move to 5.6, we will no
> longer need the copr with DKMS, at all, and also that today, enterprise
> users now have a more reliable way to use WireGuard.
>
> The most up to date instructions are on https://www.wireguard.com/install/
> but the current situation is:
>
> Fedora 32 now and Fedora 31,30 in a few weeks from now:
> $ sudo dnf install wireguard-tools
>
> Fedora 31,30 now, but not in a few weeks from now:
> $ sudo dnf copr enable jdoss/wireguard
> $ sudo dnf install wireguard-dkms wireguard-tools
>
> RHEL 8:
> $ sudo yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm
> $ sudo yum install https://www.elrepo.org/elrepo-release-8.el8.elrepo.noarch.rpm
> $ sudo yum install kmod-wireguard wireguard-tools
>
> CentOS 8:
> $ sudo yum install elrepo-release epel-release
> $ sudo yum install kmod-wireguard wireguard-tools
>
> RHEL 7:
> $ sudo yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
> $ sudo yum install https://www.elrepo.org/elrepo-release-7.el7.elrepo.noarch.rpm
> $ sudo yum install kmod-wireguard wireguard-tools
>
> CentOS 7:
> $ sudo yum install epel-release
> $ sudo yum install https://www.elrepo.org/elrepo-release-7.el7.elrepo.noarch.rpm
> $ sudo yum install kmod-wireguard wireguard-tools
>
> Thanks,
> Jason

From tmb at mageia.org  Wed Apr  1 16:25:57 2020
From: tmb at mageia.org (Thomas Backlund)
Date: Wed, 1 Apr 2020 17:25:57 +0300
Subject: [ANNOUNCE] wireguard-linux-compat v1.0.20200330 released
In-Reply-To: <20200401174811.5cf6895c@natsu>
References: <38842e471ccb3582@frisell.zx2c4.com>
 <20200401174811.5cf6895c@natsu>
Message-ID: <7535207e-40f4-564b-a2be-05d4fc4e123c@mageia.org>


Den 01-04-2020 kl. 15:48, skrev Roman Mamedov:
> On Mon, 30 Mar 2020 18:19:17 -0600
> "Jason A. Donenfeld" <Jason at zx2c4.com> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>>
>> Hello,
>>
>> A new version, v1.0.20200330, of the backported WireGuard kernel module for
>> 3.10 <= Linux <= 5.5.y has been tagged in the git repository.
> My kernel build for 5.4.29 has failed just now:
>
> In file included from <command-line>:
> ././net/wireguard/compat/compat.h:1029:20: error: redefinition of ?skb_reset_redirect?
>   static inline void skb_reset_redirect(struct sk_buff *skb)
>                      ^~~~~~~~~~~~~~~~~~
> In file included from ././net/wireguard/compat/compat.h:878,
>                   from <command-line>:
> ./include/linux/skbuff.h:4538:20: note: previous definition of ?skb_reset_redirect? was here
>   static inline void skb_reset_redirect(struct sk_buff *skb)
>                      ^~~~~~~~~~~~~~~~~~
> In file included from <command-line>:
> ././net/wireguard/compat/compat.h: In function ?skb_reset_redirect?:
> ././net/wireguard/compat/compat.h:1032:2: error: implicit declaration of function ?skb_reset_tc?; did you mean ?skb_reserve?? [-Werror=implicit-function-declaration]
>    skb_reset_tc(skb);
>    ^~~~~~~~~~~~
>    skb_reserve
> cc1: some warnings being treated as errors
> scripts/Makefile.build:265: recipe for target 'net/wireguard/main.o' failed
> make[3]: *** [net/wireguard/main.o] Error 1
> scripts/Makefile.build:500: recipe for target 'net/wireguard' failed
> make[2]: *** [net/wireguard] Error 2
>

This is because the skb_reset_redirect() change from 5.6 got backported 
in 5.5.14 and 5.4.29, so you need the attached patch


--

Thomas


-------------- next part --------------
A non-text attachment was scrubbed...
Name: net-wireguard-fix-check-for-skb_reset_redirect-backport.patch
Type: text/x-patch
Size: 677 bytes
Desc: not available
URL: <http://lists.zx2c4.com/pipermail/wireguard/attachments/20200401/d322b252/attachment.bin>

From roman.chumakov at dtms.de  Wed Apr  1 18:44:27 2020
From: roman.chumakov at dtms.de (Roman Chumakov)
Date: Wed, 1 Apr 2020 18:44:27 +0200
Subject: SIP/SDP Issue
Message-ID: <16959081-aaec-9187-8893-8b627054ec2a@dtms.de>

Hi,

we have windows 7&10 sip client software which doesnt work properly at
all with wintun wireguard interface. As we found out, wireguard
interface ip address isnt recognised and isnt packet in sdp proto.
Could we do something here ?

regards
Roman



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4233 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.zx2c4.com/pipermail/wireguard/attachments/20200401/5641ffe4/attachment.p7s>

From Jason at zx2c4.com  Sun Apr  5 00:59:15 2020
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Sat, 4 Apr 2020 16:59:15 -0600
Subject: SIP/SDP Issue
In-Reply-To: <16959081-aaec-9187-8893-8b627054ec2a@dtms.de>
References: <16959081-aaec-9187-8893-8b627054ec2a@dtms.de>
Message-ID: <CAHmME9rkTZPVGmvOCcemNJwvn-J3+-gdXDVigSm-TOp8vQNsog@mail.gmail.com>

"It doesn't work with some unspecified software" means that we can't
and won't do anything, since how could we?

- What is the name of the software? Is it open source? Is it free?
Have you reverse engineered any of it?
- What debugging have you done already to conclude it has to do with
the ip address being recognized?
- What debugging have you done already to conclude it has to do with
the sdp proto?

This is a technical mailing list; we need technical details to fix things.

From justin at althea.net  Sun Apr  5 02:47:55 2020
From: justin at althea.net (Justin Kilpatrick)
Date: Sat, 04 Apr 2020 20:47:55 -0400
Subject: Multihoming?
In-Reply-To: <445BCA5B-03B7-4127-82E8-029188083D45@gmail.com>
References: <445BCA5B-03B7-4127-82E8-029188083D45@gmail.com>
Message-ID: <49088d54-1381-45a6-a767-8596e6e07723@www.fastmail.com>

Using multiple connections at once is fraught with problems in the first place (see the complexities of teaming and bonding nics) but you can do a simple failover system using Babeld + Wireguard

Althea uses this for failover. In earlier versions of Wireguard it was quite bad (60 second switch times) but more recently handshake re-negotiation is triggered on the fly.

The whole process for Babel to detect the failure, reroute to some other Babeld node advertising the same IP and then for that Wireguard server and the client to renegotiate and get traffic flowing takes only a few seconds (about 5 in my experience). 

-- 
  Justin Kilpatrick
  justin at althea.net

On Tue, Mar 31, 2020, at 3:22 AM, Alex Besogonov wrote:
> Hi, list!
> 
> I?ve read the source code Wireguard implementations and it appears that 
> true multihoming seems to be impossible with the current protocol. By 
> true multihoming I mean possibility of using multiple connections at 
> the same time, preferably with configurable rates for them on both 
> sides.
> 
> A typical use-case would be a small office using two independent ISPs 
> to connect to a Wireguard server, so that failure of one of them would 
> not cause service interruption. Or a mobile user with an LTE and WiFi 
> connections used simultaneously.
> 
> Any ideas on how this could be implemented?

From Jason at zx2c4.com  Sun Apr  5 08:32:02 2020
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Sun, 5 Apr 2020 00:32:02 -0600
Subject: Automatically updating windows client
In-Reply-To: <CAGGi21Y2pMuHhhCGH10Y44fQKLgTi9pL7-y9Tw3KZm=5R8B9hQ@mail.gmail.com>
References: <CAGGi21Y2pMuHhhCGH10Y44fQKLgTi9pL7-y9Tw3KZm=5R8B9hQ@mail.gmail.com>
Message-ID: <CAHmME9riDvhskz-90g6qc-BuwZLU9JO31XBN=B1yYd6=VSSyBQ@mail.gmail.com>

Hi Elliot,

I implemented this:
https://git.zx2c4.com/wireguard-windows/commit/?id=d4c4398cf3c1552ff2a253753f222f1d7df8bc74

This will be part of the next release, so long as we don't find
problems with the implementation before.

Jason

From Jason at zx2c4.com  Sun Apr  5 09:38:17 2020
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Sun, 5 Apr 2020 01:38:17 -0600
Subject: Multihoming?
In-Reply-To: <445BCA5B-03B7-4127-82E8-029188083D45@gmail.com>
References: <445BCA5B-03B7-4127-82E8-029188083D45@gmail.com>
Message-ID: <CAHmME9rVRofNPx=Od3JZym-y=Jd1nN=_hZ9y9BOtNenofU0C1w@mail.gmail.com>

On Sat, Apr 4, 2020 at 4:45 PM Alex Besogonov <alex.besogonov at gmail.com> wrote:
> By true multihoming I mean possibility of using multiple connections at the same time, preferably with configurable rates for them on both sides.

Both connections at the same time, configurable rates... seems a bit
out of scope for an encrypted tunnel, doesn't it?

Rather, set up two tunnels, and then bond them or run some other
aggregation protocol over it. Several years ago I was aggregating
several different internet connections using MPTCP over various pipes.
Things worked extraordinarily well.

From eric at roch.us  Sun Apr  5 07:14:14 2020
From: eric at roch.us (Eric Roch)
Date: Sun, 5 Apr 2020 01:14:14 -0400
Subject: Usability issue in MacOS
Message-ID: <CAD2HyqGC+A92rU=7d1CfbpqRpb9biLiEbdVpfovgN=uGkKseGA@mail.gmail.com>

Hi Jason,

On a similar note, I?ve noticed that it isn?t possible to temporarily
disable the interface if an On-Demand rule is active.  Would it be
possible to add something like the behavior of the WiFi toggle in iOS?
That is, the wg interface is activated when connected to wifi, but
disabling it via the menu bar will turn off On-Demand until a new wifi
is connected (akin to moving with the iOS behavior) or ?tomorrow?
(probably more like 3am or something).

Thanks
Eric

From danabw at hotmail.com  Sun Apr  5 17:58:26 2020
From: danabw at hotmail.com (Dana White)
Date: Sun, 5 Apr 2020 15:58:26 +0000
Subject: Potential bug in Android app - Create from scratch flow 
Message-ID: <MWHPR17MB1648A7DB1266E86F16DC44F8D0C50@MWHPR17MB1648.namprd17.prod.outlook.com>

I?ve spent two days trying to connect from Android (Galaxy S10) to EdgeRouter 12 w/WireGuard app. 

I was creating the tunnel in the app manually via the Create from scratch flow. Could not get it to connect.

No problems connecting from Win laptop w/the exact same config. 

Finally (thanks to someone on #wireguard irc) I tried imported the exact same config into the app, and it worked immediately.

It looks like there may be a problem w/the manual entry process. At least that was my experience, repeatedly. App is current version, just installed for the first time two days ago.

Thanks.

Dana

From vrein at tuta.io  Sun Apr  5 19:37:18 2020
From: vrein at tuta.io (vrein at tuta.io)
Date: Sun, 5 Apr 2020 19:37:18 +0200 (CEST)
Subject: [PROPOSAL] wg-quick ip rule priority
Message-ID: <M4APSeK--3-2@tuta.io>

Hi everyone!
I have some tiny proposal for wg-quick utility: adding priority for iproute2 routing rules

For linux.bash this should be as easy as this:
https://gitea.tort.icu/vrein/wireguard-tools/commit/0947dc76770a5d81ba39340ebe9189b80a92584c

My personal use case:
? I have two peers: A, B

A: allowed ips: 0.0.0.0/0, ::/0
B: allowed ips: 10.5.0.0/24

And I need have connection to every peer.
If those peers are added to the single interface - wg0,
? then all traffic would be intercepted with A peer "allowed ips" mask.


Quick fix for this, which I implemented on my pc
? is to add `ip rule` with priority lower than 32766 but higher than 0
? and higher than other wg interface for peer B.

So there is two interfaces:
? wg0 - which intercepts all traffic
? wg1 - routes all traffic for 10.5.0.0/24 subnet

Here what I have on my PC:
0:????? from all lookup local
125:??? from all fwmark 0xca58 lookup main
125:??? from all to 10.5.0.0/24 lookup 51800
10000:? not from all fwmark 0xca6c lookup 51820
10000:? from all lookup main suppress_prefixlength 0
32766:? from all lookup main
32767:? from all lookup default

Routing rules for wg1 could be added with `(Post|Pre)Up' directive.


PS:
Somehow, connectivity with both A and B peers were worked in single wg0 interface some time ago,
? but after few updates this feature stopped working.

Thank you for attention!



From Jason at zx2c4.com  Sun Apr  5 23:53:48 2020
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Sun, 5 Apr 2020 15:53:48 -0600
Subject: Potential bug in Android app - Create from scratch flow
In-Reply-To: <MWHPR17MB1648A7DB1266E86F16DC44F8D0C50@MWHPR17MB1648.namprd17.prod.outlook.com>
References: <MWHPR17MB1648A7DB1266E86F16DC44F8D0C50@MWHPR17MB1648.namprd17.prod.outlook.com>
Message-ID: <CAHmME9q0sbmNpYB5-ZWaT2MUQq_SPdsF9jJ9frkbffwN+RvP7w@mail.gmail.com>

> Finally (thanks to someone on #wireguard irc) I tried imported the exact same config into the app, and it worked immediately.

Don't use the same config from two devices. One device :: one private key.

> It looks like there may be a problem w/the manual entry process. At least that was my experience, repeatedly. App is current version, just installed for the first time two days ago.

Create it manually, and then export it to a zip. Look in the zip and
see if there's any difference between that file and the one you
imported from the windows app.

From danabw at hotmail.com  Mon Apr  6 00:55:01 2020
From: danabw at hotmail.com (Dana White)
Date: Sun, 5 Apr 2020 22:55:01 +0000
Subject: Potential bug in Android app - Create from scratch flow
In-Reply-To: <CAHmME9q0sbmNpYB5-ZWaT2MUQq_SPdsF9jJ9frkbffwN+RvP7w@mail.gmail.com>
References: <MWHPR17MB1648A7DB1266E86F16DC44F8D0C50@MWHPR17MB1648.namprd17.prod.outlook.com>
 <CAHmME9q0sbmNpYB5-ZWaT2MUQq_SPdsF9jJ9frkbffwN+RvP7w@mail.gmail.com>
Message-ID: <MWHPR17MB16480A2D637D253F9A5BCBBAD0C50@MWHPR17MB1648.namprd17.prod.outlook.com>

Thanks. Using the config was just to test the import process on Android w/a known good config, deleted thereafter. 
	
From your reply sounds like you haven't seen this issue w/the current version of the app? Are you able to manually create and use a new tunnel on the Android app successfully? 

I had another member of the EdgeRouter community note that he had what he thought was a similar problem recently w/the Android app but didn't take the time to follow upon it. 

I'll do as you request and get back. 

Dana

-----Original Message-----
From: Jason A. Donenfeld <Jason at zx2c4.com> 
Sent: Sunday, April 5, 2020 2:54 PM
To: Dana White <danabw at hotmail.com>
Cc: WireGuard mailing list <wireguard at lists.zx2c4.com>
Subject: Re: Potential bug in Android app - Create from scratch flow

> Finally (thanks to someone on #wireguard irc) I tried imported the exact same config into the app, and it worked immediately.

Don't use the same config from two devices. One device :: one private key.

> It looks like there may be a problem w/the manual entry process. At least that was my experience, repeatedly. App is current version, just installed for the first time two days ago.

Create it manually, and then export it to a zip. Look in the zip and see if there's any difference between that file and the one you imported from the windows app.

From danabw at hotmail.com  Mon Apr  6 01:23:20 2020
From: danabw at hotmail.com (Dana White)
Date: Sun, 5 Apr 2020 23:23:20 +0000
Subject: Potential bug in Android app - Create from scratch flow
In-Reply-To: <CAHmME9q0sbmNpYB5-ZWaT2MUQq_SPdsF9jJ9frkbffwN+RvP7w@mail.gmail.com>
References: <MWHPR17MB1648A7DB1266E86F16DC44F8D0C50@MWHPR17MB1648.namprd17.prod.outlook.com>
 <CAHmME9q0sbmNpYB5-ZWaT2MUQq_SPdsF9jJ9frkbffwN+RvP7w@mail.gmail.com>
Message-ID: <MWHPR17MB164823F1B470B5B30D25BF01D0C50@MWHPR17MB1648.namprd17.prod.outlook.com>

OK, operator error once again is to blame. 

My router public key in the config had a single digit missing. 

The really odd part is that I can't understand how that happened, as I copy/pasted the router public key from an existing config (that still works and has the full correct key) because there was no way I was going to type out something that long/difficult. I do have problems with my mousepad on my computer sometimes jumping the cursor around when my palm hits it and sometimes messing up what I?m doing, but no idea how that could account for removing a letter and not leaving a space. 

But egg on my face is egg on my face, what can I say. 

Bowing and backing away in shame. 

Thanks for the suggestion to export/compare, that was what allowed me to see the issue clearly. 

Dana 

-----Original Message-----
From: Jason A. Donenfeld <Jason at zx2c4.com> 
Sent: Sunday, April 5, 2020 2:54 PM
To: Dana White <danabw at hotmail.com>
Cc: WireGuard mailing list <wireguard at lists.zx2c4.com>
Subject: Re: Potential bug in Android app - Create from scratch flow

> Finally (thanks to someone on #wireguard irc) I tried imported the exact same config into the app, and it worked immediately.

Don't use the same config from two devices. One device :: one private key.

> It looks like there may be a problem w/the manual entry process. At least that was my experience, repeatedly. App is current version, just installed for the first time two days ago.

Create it manually, and then export it to a zip. Look in the zip and see if there's any difference between that file and the one you imported from the windows app.

From reidrankin at gmail.com  Mon Apr  6 01:43:54 2020
From: reidrankin at gmail.com (Reid Rankin)
Date: Sun, 5 Apr 2020 19:43:54 -0400
Subject: Thoughts on wg-dynamic
Message-ID: <CAMaqUZ2i+LFg8wreOr=H1gB5ocw9+N5uacsZukcjEx6xNrbdkQ@mail.gmail.com>

I've been thinking about wg-dynamic -- or something quite like it -- a
lot in recent months, and I've had some ideas I think are worth
sharing even though I haven't figured out an ideal final form for them
yet.

Just to let you know where I'm coming from (and to add to the
community gestalt of potential usecases), I've been working on a
stateless WG-based mesh networking system where each node has only
read-only storage. In my application the network is in fact statically
configured -- but none of the nodes knows this configuration on boot.
Instead, the configuration is distributed dynamically and
signature-checked. For this purpose, I've been working on a
configuration protocol that seems more and more like I'm duplicating
effort with wg-dynamic, so I want to share my thoughts so far and
hopefully end up making the upstream project better. (I do realize
that wg-dynamic doesn't have signature support as a design goal, but
good protocols are extensible and I only need 32 bytes of space in
some sort of "vendor option".)

On to the fun stuff. First, I came up with the idea to run the
configuration protocol using IPv6 link-local addresses. I see that
wg-dynamic is doing the same thing, and independent engineers coming
up with the same design is usually a good sign that it's the right
fit. However, I've taken it one step further, by using
cryptographically-generated addresses; each peer automatically gets
fe80:(truncated hash of pubkey)/128 stuck in its allowed IP list. (I'm
considering harmonizing this address generation algorithm with RFC3972
in the future.) This means that initiating the protocol requires no
configuration other than the public key of the peer you'd like to
contact.

The current use of fe80::/128 as a magic address for the wg-dynamic
server brings up an important distinction between my usecase and the
current goals of wg-dynamic, and I think it might be a
significant-enough distinction to warrant changing its direction
slightly. Specifically, wg-dynamic is currently designed as a
centralized system -- nodes are not peers, because one must be in
charge of assigning IPs. I believe that my application, where each
peer knows the correct (signed) IP assignment for each other peer but
none are responsible for issuing new assignments, demonstrates that
the concerns of assigning configurations and distributing that
configuration information are fundamenally separate.

I beleive that the CGA-based approach would be more appropriate for
wg-dynamic as a whole, because it would fit better with WG's own
decentralized design, enable interesting new use cases, and simplify
configuration. Obviously it's important to specify which peers you to
trust to assign addresses -- I suggest that centralized, non-PKI-based
systems retain the "magic" address for an implicitly trusted central
server, which would use both its link-local CGA and fe80::/128. Still,
this would eliminate the chicken-and-egg problem, where some mechanism
would be needed to assign link-local IPs to each client before they
could communicate with the server to get their "real" IP assignment.
(I also suspect that if the current system were deployed as-is, many
operators would just roll their own hash-based IP allocation system
instead of maintaining some sort of database of assignments, and fewer
knobs is better when there's a sensible default and nothing to be
gained but incompatibility by tweaking it.)

Secondly, wg-dynamic needs a reliable transport to use at layer 4, but
I don't think it should be TCP. Wireguard itself is a tiny,
lightweight protocol -- one implementable on a microcontroller, if you
so desire -- but TCP is only available because it's built into kernels
everywhere, and while those implementations are battle-tested at this
point there's been a rich history of bugs in TCP stacks before the
kinks got worked out. I believe that it's important that whatever the
final form of wg-dynamic it should not preclude a completely
self-contained implementation -- say, in userspace, or on a
microcontroller. There's been plenty of work courtesy of the IDS and
DPI crowd towards reassembling TCP streams in userland, but there
aren't many full userland TCP stacks -- and the ones that are there I
wouldn't trust.

Therefore, I suggest TFTP as a transport. (No, seriously.) TFTP has
many things going for it in this application: it has simple,
well-understood state machine which can be implemented securely in a
mostly-stateless timer-driven fashion (sound familiar?), it can return
short blocks of data in only a single RTT (which TCP can't), and it's
got existing tooling that would be useful for
prototyping/experimentation/whatever. Essentially, it's got everything
you need and nothing you don't, and running it inside a WG tunnel gets
you all the security features the protocol lacks intrinsically.

TFTP is also symmetric -- there's not a huge distinction between a
server and a client, and data can be pulled or pushed as needed. A
traditional DHCP-style configuration request or renewal could be
modelled by a client requesting a magically-named "file"; a server
could send an updated configuration by pushing the same file instead,
reducing the need to rely on short lease times in networks whose
configurations (read: routes) change frequently.

TFTP is also extensible. A number of useful options already exist --
for example, one to set the block size of a transfer to take advantage
of the full MTU available, and another that provides windowed
transmission and acknowledgement and can provide throughput comparable
to TCP in many cases. And while TFTP is inherently a one-way protocol,
it's easy to add support for a request/response paradigm. (I've got a
prototype of this; the client sends a request and includes an option
requesting a response, which the server fills in with a magical file
name the client can request to retrieve said response. All simple
state-machine-based stuff.)

What I haven't solved yet -- and the reason I've delayed until now to
write this up and share it -- is all the stuff above layer 4. In my
prototype system, I use a userland daemon with access to the WG
private key to intercept incoming WG handshake requests, decrypt the
public key of the initiator, and add each new initiator as a peer with
one of these link-local CGAs before delivering the handshake packet.
(This increases my risk of DoS somewhat, but that's acceptable in my
application.) I then can use TFTP to transfer data between hosts, but
I think I've gotten too caught up in the specifics of my own
application (verifying signatures, creation and distribution of signed
config blobs, etc).

I'm hoping that by taking a step back and treating the problem as one
of developing a generic, extensible in-band configuration scheme the
natural form of a solution to that problem will emerge, and I can
build all my other fancy crap on top of it. I think link-local CGAs
and TFTP are elegant solutions, but I really need a higher-level
protocol to build my fancy stuff on top of -- which means I need
wg-dynamic. And I don't just need it to be an idea, I need it to be a
tiny, elegant, documented protocol.

So I want to get involved. Let's talk about architecture, get some
consensus, do some documentation. Let's build an MVP for Linux, but
also for Go and Rust. I'm game for all of it -- somebody hit me up and
let me know how I can help.

--Reid

From buddybalaa at gmail.com  Sun Apr  5 23:53:12 2020
From: buddybalaa at gmail.com (Mo Balaa)
Date: Sun, 5 Apr 2020 16:53:12 -0500
Subject: More advanced user configuration like SSH?
In-Reply-To: <adeb013d-5881-e113-b865-599a3c572fa5@frhoelzlwimmer.de>
References: <adeb013d-5881-e113-b865-599a3c572fa5@frhoelzlwimmer.de>
Message-ID: <CAKmhVkpOVaZcenbTZKSM-2xKJDoF1u8s4OK=nZMVJzjfNu0UcQ@mail.gmail.com>

You could deliver WireGuard configuration to peers via a ssh invocation;

Something like:

ssh user at host register_peer peerName
---
endpoint: 192.168.0.1:18521
ip_assignment: 192.168.1.2

Then just parse the YAML locally to configure the users interface.




On Sun, Apr 5, 2020 at 4:48 PM F. H?lzlwimmer <git.ich at frhoelzlwimmer.de> wrote:
>
> Dear all,
>
>
> I would like to allow all of my colleagues to set up a wireguard VPN to
> our servers.
> We are managing our users (+ their SSH keys) via FreeIPA.
> Is there a possibility to integrate Wireguard and FreeIPA authentication?
>
> --------
> In my dreams, wireguard could be used just like SSH:
> "wg-quick user at wgserver.com"
> with SSH-keys read from e.g. "~/authorized_peers" or some authentication
> service.
>
>
> Best regards,
> Florian H?lzlwimmer
>

From contact at alexy-rousseau.com  Mon Apr  6 07:03:08 2020
From: contact at alexy-rousseau.com (Alexy-Rousseau)
Date: Mon, 6 Apr 2020 07:03:08 +0200
Subject: Some difficulties to initiate a simple tunnel with Android
Message-ID: <A37EAA6A-CB8A-4CA0-844A-C5A54152BF98@alexy-rousseau.com>

Hello everyone,

I want to create a very simple app where the user can connect itself to the VPN without any configuration.
If I understand everything clearly I just have to use the tunnel module who implements the wireguard-go version.

I?m a little bit confused :

- I read the source code of the tunnel path and the ui module and it seems that there is some dependencies between ui and tunnel.

I have some questions :

- Is it possible to use very simply the tunnel module, without ui and initiate very simply a VPN connection?

- Do I have a good idea by using now the tunnel? Will the compatibility of the library be maintained with updates?

- If the main difference between the Android & iOS app is the implementation of the tunnel module, is it a good idea to create a flutter UI with two different ways to communicate with the library for each OS?

Thanks in advance for your help!

?
Kind regards, Alexy ROUSSEAU

From Jason at zx2c4.com  Mon Apr  6 07:11:49 2020
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Sun, 5 Apr 2020 23:11:49 -0600
Subject: Some difficulties to initiate a simple tunnel with Android
In-Reply-To: <A37EAA6A-CB8A-4CA0-844A-C5A54152BF98@alexy-rousseau.com>
References: <A37EAA6A-CB8A-4CA0-844A-C5A54152BF98@alexy-rousseau.com>
Message-ID: <CAHmME9okzeuM-830h8QtwM-szp5GcT2i5mYC1ZSKN+KLA=eqXQ@mail.gmail.com>

On Sun, Apr 5, 2020 at 11:03 PM Alexy-Rousseau
<contact at alexy-rousseau.com> wrote:
>
> Hello everyone,
>
> I want to create a very simple app where the user can connect itself to the VPN without any configuration.
> If I understand everything clearly I just have to use the tunnel module who implements the wireguard-go version.
>
> I?m a little bit confused :
>
> - I read the source code of the tunnel path and the ui module and it seems that there is some dependencies between ui and tunnel.
>
> I have some questions :
>
> - Is it possible to use very simply the tunnel module, without ui and initiate very simply a VPN connection?
>
> - Do I have a good idea by using now the tunnel? Will the compatibility of the library be maintained with updates?
>
> - If the main difference between the Android & iOS app is the implementation of the tunnel module, is it a good idea to create a flutter UI with two different ways to communicate with the library for each OS?
>
> Thanks in advance for your help!
>
> ?
> Kind regards, Alexy ROUSSEAU

Things are now nicely modularized. Include this in your gradle:

dependencies {
    implementation 'com.wireguard.android:tunnel:1.0.20200329'
}

And then you'll be able to embed a tunnel in your Android app.

Documentation is available at:
https://javadoc.io/doc/com.wireguard.android/tunnel/latest/index.html

We're working on improving these docs, but here's a small sample
project that might help:
https://data.zx2c4.com/WireGuardTestApp-88b19fa5-8117-4835-b788-eac338113faa.zip

From simon at rozman.si  Mon Apr  6 08:12:54 2020
From: simon at rozman.si (Simon Rozman)
Date: Mon, 6 Apr 2020 06:12:54 +0000
Subject: Search Domain/DNS Suffix
In-Reply-To: <CAB8Qo2SaN0rkBHKqb-PSH0Sh5WbC5jbkMA8mpdq+-L6art2s+w@mail.gmail.com>
References: <CAB8Qo2SaN0rkBHKqb-PSH0Sh5WbC5jbkMA8mpdq+-L6art2s+w@mail.gmail.com>
Message-ID: <474EFC8E-BD8D-40B2-A0A9-3A9346A2A8AB@rozman.si>

Hi,

I have a similar requirement - to set connection specific DNS suffix. I solved it by extending the wireguard-windows: https://git.zx2c4.com/wireguard-windows/commit/?h=sr/mydist&id=3672fbc0bcb1821c98566fac32ba0638d4d4c611

However, I do not plan to ask zx2c4 to merge it upstream, as he has better idea to provide PostUpExec feature which would allow universal mean for any extra system configuration required. Stay tuned.

Meanwhile, just a suggestion (haven't tested it thou)... Add a task to Task Scheduler to fire every couple of minutes doing:

reg.exe add HKLM\SYSTEM\CurrentControlSet\services\Tcpip\Parameters\Interfaces\<GUID of your WG adapter*> /v Domain /t REG_SZ /d contoso.local

This should setup the connection specific DNS suffix soon after the tunnel is established and keep it set. But its nuts and doesn't scale. The PostUpExec will be the right approach.

Regards, Simon

* On Windows 10 the WG adapter GUID is pseudo-random based on your WG config. As long as your config is static, it won't change. Once WG connected, look it up in HKLM\SYSTEM\CurrentControlSet\services\Tcpip\Parameters\Interfaces.

?-----Original Message-----
From: WireGuard <wireguard-bounces at lists.zx2c4.com> on behalf of Duncan X Simpson <virtualdxs at gmail.com>
Date: Sunday, 5 April 2020 at 23:51
To: "wireguard at lists.zx2c4.com" <wireguard at lists.zx2c4.com>
Subject: Search Domain/DNS Suffix

    Hello all,
    
    I'm trying to deploy a wireguard VPN for a small company and it's
    working great, with one issue: On Windows/Mac I can't find a way to
    set search domains on the connection. Windows, I can probably just set
    a system-wide search domain via the registry (I plan to test that
    tonight), but on Mac I can't figure out anything. Even the normal
    command line method, networksetup -setsearchdomains [interface],
    doesn't take effect - I can retrieve whatever I set with networksetup
    -getsearchdomains [interface], but it's not used by the system.
    
    Does anybody know a solution or workaround?
    
    Duncan X Simpson, K7DXS
    Removal of this tagline is a violation of Federal Law.
    
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2965 bytes
Desc: not available
URL: <http://lists.zx2c4.com/pipermail/wireguard/attachments/20200406/d9f1eb91/attachment.p7s>

From phillip.mcmahon at gmail.com  Mon Apr  6 08:16:11 2020
From: phillip.mcmahon at gmail.com (Phillip McMahon)
Date: Mon, 6 Apr 2020 08:16:11 +0200
Subject: Android app user (not test on iOS)
Message-ID: <CABtXGiDykFrPtVPsn8QOfr2WayPOU_hn+_VpgmJy9Ap3+LOTfw@mail.gmail.com>

I had to edit some existing configs in my android UI. Namely, to
change the DNS entries.

Updated with new IPs hit save and all looked good.

Going back to the config screen the old IP was still present.

Had to kill the app via the android task manager, reload, and then the
new value is visually present and also being used.

From Jason at zx2c4.com  Mon Apr  6 08:24:42 2020
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Mon, 6 Apr 2020 00:24:42 -0600
Subject: Android app user (not test on iOS)
In-Reply-To: <CABtXGiDykFrPtVPsn8QOfr2WayPOU_hn+_VpgmJy9Ap3+LOTfw@mail.gmail.com>
References: <CABtXGiDykFrPtVPsn8QOfr2WayPOU_hn+_VpgmJy9Ap3+LOTfw@mail.gmail.com>
Message-ID: <CAHmME9rWYZ1VHXgUw2Pku0oxKetNZHyuKHAreAVDgAOYXCdgtw@mail.gmail.com>

Update the app. This was fixed, but you're still running an old
version, most likely.

From phillip.mcmahon at gmail.com  Mon Apr  6 08:27:27 2020
From: phillip.mcmahon at gmail.com (Phillip McMahon)
Date: Mon, 6 Apr 2020 08:27:27 +0200
Subject: Android app user (not test on iOS)
In-Reply-To: <CAHmME9rWYZ1VHXgUw2Pku0oxKetNZHyuKHAreAVDgAOYXCdgtw@mail.gmail.com>
References: <CABtXGiDykFrPtVPsn8QOfr2WayPOU_hn+_VpgmJy9Ap3+LOTfw@mail.gmail.com>
 <CAHmME9rWYZ1VHXgUw2Pku0oxKetNZHyuKHAreAVDgAOYXCdgtw@mail.gmail.com>
Message-ID: <CABtXGiB3V4tXZ5CzN764zj+A3Ro_yji2e_+mQauTJjYMRegf2Q@mail.gmail.com>

Thanks.

>From encountering the bug, and me sending the email the app did indeed
get updated automatically on my phone.

Awesome. Thanks for your hard work.

On Mon, 6 Apr 2020 at 08:24, Jason A. Donenfeld <Jason at zx2c4.com> wrote:
>
> Update the app. This was fixed, but you're still running an old
> version, most likely.



-- 
Use this contact page to send me encrypted messages and files

https://flowcrypt.com/me/phillipmcmahon

P.S. Drowning in email? Try SaneBox and take back control:
http://sanebox.com/t/old3m. I love it.

From arti.zirk at gmail.com  Mon Apr  6 10:28:33 2020
From: arti.zirk at gmail.com (Arti Zirk)
Date: Mon, 06 Apr 2020 11:28:33 +0300
Subject: Thoughts on wg-dynamic
In-Reply-To: <CAMaqUZ2i+LFg8wreOr=H1gB5ocw9+N5uacsZukcjEx6xNrbdkQ@mail.gmail.com>
References: <CAMaqUZ2i+LFg8wreOr=H1gB5ocw9+N5uacsZukcjEx6xNrbdkQ@mail.gmail.com>
Message-ID: <c41fb7b6ba61a41804ef50a7c92857367c51a36e.camel@gmail.com>

On P, 2020-04-05 at 19:43 -0400, Reid Rankin wrote:
> However, I've taken it one step further, by using
> cryptographically-generated addresses; each peer automatically gets
> fe80:(truncated hash of pubkey)/128 stuck in its allowed IP list.
> (I'm considering harmonizing this address generation algorithm with
> RFC3972 in the future.) This means that initiating the protocol
> requires no configuration other than the public key of the peer you'd
> like to contact.

While back there was a tool posted to this mailing list[0] that
generated WireGuard IP aadresses from the public key called wg-ip[1].

It would simplify things if that or some other link-local IP genration
algorithm would get integrated into wg-quick toolset.

I have also written a Python version of wg-ip generation algorithm that
might me slightly easier to read[2].

[0] https://lists.zx2c4.com/pipermail/wireguard/2018-April/002593.html
[1] https://github.com/chmduquesne/wg-ip
[2] https://gist.github.com/artizirk/c91e4f8c237dec07e3ad1b286f1855a7


From reidrankin at gmail.com  Mon Apr  6 11:46:02 2020
From: reidrankin at gmail.com (Reid Rankin)
Date: Mon, 6 Apr 2020 05:46:02 -0400
Subject: Thoughts on wg-dynamic
In-Reply-To: <c41fb7b6ba61a41804ef50a7c92857367c51a36e.camel@gmail.com>
References: <CAMaqUZ2i+LFg8wreOr=H1gB5ocw9+N5uacsZukcjEx6xNrbdkQ@mail.gmail.com>
 <c41fb7b6ba61a41804ef50a7c92857367c51a36e.camel@gmail.com>
Message-ID: <CAMaqUZ0mx-3RtcNU4WQReGHWNgZ__b+AqpgHQKJpkHwpaqM_4A@mail.gmail.com>

That's a neat tool, and I'd probably use it in my own projects -- I'm
a big fan of the shell-script-only approach for userland tools -- but
the algorithm it uses has a few rough edges I'd prefer didn't get
standardized:

- The hash is taken over a (newline-terminated!) Base64-encoded key
and not the raw bytes; there's nothing else in the protocol that would
require implementations to have a Base64 encoder. (This might matter
in a microcontroller implementation.) It wouldn't be hard to pipe to
`base64 -d` before hashing, which would fix this.
- I'm a fan of SHA-256 in general, but again, there's nothing else in
the protocol that would require implementers to have a SHA-256 engine.
(This would definitely matter in a microcontroller implementation.)
OTOH, `sha256sum` is a commonly available utility and reasonable to
use in a bash script, while `b2sum` is not so much.

My prototype also uses the `(subnet & mask) | (hash & ~mask)`
construction, though I use the full fe80::/10 space, instead of
fe80::/64. There's a decent argument to be made for just using the
/64, though -- it's the "interface identifier" portion of the address,
which is why that's what RFC 3972 does as well. That said, I'm not
sure there's quite the same need for subnetting in a link-local
address space. (I also feel like the subnet id/interface id dichotomy
is going the way of IPv4 class-based routing, and was probably only
conceived of as a clever ploy to keep ISPs from screwing everyone over
by only handing out out /120s.)

I've taken another look at RFC 3972, and the only way it would work
here would be by using well-known modifier and Sec parameters of zero
-- and it would force reliance on SHA-1. So I'm now thinking we don't
bother.

In any case, that makes at least two independent engineering efforts
that both use `(subnet & mask) | (hash & ~mask)` rather than using
subnet as a prefix for the hash.

--Reid

From reidrankin at gmail.com  Mon Apr  6 11:46:51 2020
From: reidrankin at gmail.com (Reid Rankin)
Date: Mon, 6 Apr 2020 05:46:51 -0400
Subject: Thoughts on wg-dynamic
In-Reply-To: <CAFX-c4sfzqEwCk+1Ec7dRtVD60jougU1w9=V-cAQ-8Qk0S+HZg@mail.gmail.com>
References: <CAMaqUZ2i+LFg8wreOr=H1gB5ocw9+N5uacsZukcjEx6xNrbdkQ@mail.gmail.com>
 <CAFX-c4sfzqEwCk+1Ec7dRtVD60jougU1w9=V-cAQ-8Qk0S+HZg@mail.gmail.com>
Message-ID: <CAMaqUZ0G8Gt=33Fxh=UxgPUXz3z5c0AjbFq6F9QxgcTU-xWKzg@mail.gmail.com>

I looked at something similar, but I really don't want to pay the
extra overhead -- and it just feels wrong to use
IP-in-Ethernet-in-GRE-in-UDP-in-IP(-in-WG-in-UDP-in-IP) if you don't
have to for routing purposes. (Version 2.0 of the product I'm working
on might use something similar for dynamic routing, but for now I'm
content with the assumption that all peers can reach each other.)

--Reid

On Sun, Apr 5, 2020 at 8:02 PM brian mullan <bmullan.mail at gmail.com> wrote:
>
> Reid
>
> I've been using
>
> m13253/VxWireguard-Generator: Utility to generate VXLAN over Wireguard mesh SD-WAN configuration
>
> https://github.com/m13253/VxWireguard-Generator
>
> I added BGP with BGP VRF.  It all works great in my multi cloud, multi node use-case.
>
> Brian

From aranea at aixah.de  Fri Apr 10 09:39:55 2020
From: aranea at aixah.de (Luis Ressel)
Date: Fri, 10 Apr 2020 07:39:55 +0000
Subject: [PROPOSAL] wg-quick ip rule priority
In-Reply-To: <M4APSeK--3-2@tuta.io>
References: <M4APSeK--3-2@tuta.io>
Message-ID: <20200410073955.i3epess3yd4uximo@vega>

On Sun, Apr 05, 2020 at 07:37:18PM +0200, vrein at tuta.io wrote:
> Hi everyone!
> I have some tiny proposal for wg-quick utility: adding priority for iproute2 routing rules
> 
> For linux.bash this should be as easy as this:
> https://gitea.tort.icu/vrein/wireguard-tools/commit/0947dc76770a5d81ba39340ebe9189b80a92584c

While I don't think it'd be a bad idea to support configurable rule
priorities if they're useful to someone, they shouldn't be neccessary
for the use case you described -- you can avoid the separate routing
rules for wg1 altogether.

All you should need to do is to add "FwMark = 51820" (or some other
arbitrary value, as long as it's identical for both wg tunnels) to the
config files of both wg interfaces. Then you end up with these ip rules
(taken from your post rather than an actual test):

0:????? from all lookup local
32764:? from all lookup main suppress_prefixlength 0
32765:? not from all fwmark 0xca6c lookup 51820
32766:? from all lookup main
32767:? from all lookup default

Furthermore, wg-quick would add an "0.0.0.0/0 dev wg0" route to table
51820, and "10.5.0.0/24 dev wg1" to the main table.

This would result in encrypted traffic using the routes in the main
table, traffic to 10.5.0.0/24 the wg1 tunnel, and everything else the
wg0 tunnel, exactly as intended by you.

> PS:
> Somehow, connectivity with both A and B peers were worked in single wg0 interface some time ago,
> ? but after few updates this feature stopped working.

It should indeed be possible to have both of these peers on the same wg
interface. If you're running into issues with that, please elaborate on
them here or pay us a visit on IRC (#wireguard on Freenode).


Luis

From aranea at aixah.de  Fri Apr 10 10:01:12 2020
From: aranea at aixah.de (Luis Ressel)
Date: Fri, 10 Apr 2020 08:01:12 +0000
Subject: wg set fail to update endpoint if traffic is flowing
In-Reply-To: <i2UwKoKpd7CcDmlKuf5GHwFTjVhsyWaKbbI_QaLQ5yjGbpBkH7klwefEhR8B7TICn7B4uguk3sK23sExHYpQFUX9txdU-RDQR7w0bCuNj4E=@nexmanti.net>
References: <i2UwKoKpd7CcDmlKuf5GHwFTjVhsyWaKbbI_QaLQ5yjGbpBkH7klwefEhR8B7TICn7B4uguk3sK23sExHYpQFUX9txdU-RDQR7w0bCuNj4E=@nexmanti.net>
Message-ID: <20200410080112.qyltsntafey7asdy@vega>

On Tue, Mar 31, 2020 at 08:36:52AM +0000, xtus wrote:
> The set endpoint works only if no traffic is flowing.
> 
> Is this expected behavior?

Yes, it is. It's not that wg set fails to update the endpoint; rather,
the endpoint you've set is immediately overwritten again -- to support
seamless roaming, wg updates the endpoint every time it receives an
authenticated packet from a peer.


Luis

From jayakumar82.s at gmail.com  Wed Apr  8 22:40:29 2020
From: jayakumar82.s at gmail.com (Jayakumar S)
Date: Wed, 8 Apr 2020 16:40:29 -0400
Subject: Wireguard Windows Implementation
Message-ID: <CAECTAb_TW53o9Xb=F+gkamVH2aqG1iQKCiQkiO0JjTtVEE=isA@mail.gmail.com>

Hi Guys,

Thank you so much for explaining the internals of Wireguard
implementation in Linux kernel. The sequence explained in the slide
(page 11) helps a lot to understand the flow in the following
document.

https://www.wireguard.com/talks/fosdem2017-slides.pdf

Likewise, do you have any document for Windows implementation. I know
there will be a lot of differences between Windows & Linux
implementation. By any chance if you have CryptoRouting flow in
Windows it could be very useful. Basically, I want to understand the
flow between user space module, NDIS miniport driver.

Thanks,
Jay

From guy.godfroy at gugod.fr  Fri Apr 10 11:42:29 2020
From: guy.godfroy at gugod.fr (Guy Godfroy)
Date: Fri, 10 Apr 2020 11:42:29 +0200
Subject: [PATCH] wg-quick: add 'reload' command (wrapper for 'wg syncconf')
In-Reply-To: <20200330084157.51834-1-tore@fud.no>
References: <20200330084157.51834-1-tore@fud.no>
Message-ID: <c9dab5f9-e34b-bf53-c018-b2985c7bdf9a@gugod.fr>

Hello,

I wish this patch could be merged. This would make stuff easier, cleaner 
and consistent with a lot of other services.

Guy Godfroy

Le 30/03/2020 ? 10:41, Tore Anderson a ?crit?:
> Also add an ExecReload statement that uses this in the systemd template unit.
> 
> Signed-off-by: Tore Anderson <tore at fud.no>
> ---
>   src/man/wg-quick.8            |  9 ++++++---
>   src/systemd/wg-quick at .service |  1 +
>   src/wg-quick/darwin.bash      | 17 ++++++++++++++++-
>   src/wg-quick/freebsd.bash     | 15 ++++++++++++++-
>   src/wg-quick/linux.bash       | 15 ++++++++++++++-
>   src/wg-quick/openbsd.bash     | 15 ++++++++++++++-
>   6 files changed, 65 insertions(+), 7 deletions(-)
> 
> diff --git a/src/man/wg-quick.8 b/src/man/wg-quick.8reload
> index eca3b48..023805e 100644
> --- a/src/man/wg-quick.8
> +++ b/src/man/wg-quick.8
> @@ -10,6 +10,8 @@ wg-quick - set up a WireGuard interface simply
>   |
>   .I down
>   |
> +.I reload
> +|
>   .I save
>   |
>   .I strip
> @@ -28,9 +30,10 @@ Use \fIup\fP to add and set up an interface, and use \fIdown\fP to tear down and
>   an interface. Running \fIup\fP adds a WireGuard interface, brings up the interface with the
>   supplied IP addresses, sets up mtu and routes, and optionally runs pre/post up scripts. Running \fIdown\fP
>   optionally saves the current configuration, removes the WireGuard interface, and optionally
> -runs pre/post down scripts. Running \fIsave\fP saves the configuration of an existing
> -interface without bringing the interface down. Use \fIstrip\fP to output a configuration file
> -with all
> +runs pre/post down scripts. Running \fIreload\fP synchronises any changes to peers/keys in
> +the config file with an already active interfaces. Running \fIsave\fP saves the configuration
> +of an existing interface without bringing the interface down. Use \fIstrip\fP to output a
> +configuration file with all
>   .BR wg-quick (8)-specific
>   options removed, suitable for use with
>   .BR wg (8).
> diff --git a/src/systemd/wg-quick at .service b/src/systemd/wg-quick at .service
> index 7c5f9d1..a3b89d9 100644
> --- a/src/systemd/wg-quick at .service
> +++ b/src/systemd/wg-quick at .service
> @@ -14,6 +14,7 @@ Type=oneshot
>   RemainAfterExit=yes
>   ExecStart=/usr/bin/wg-quick up %i
>   ExecStop=/usr/bin/wg-quick down %i
> +ExecReload=/usr/bin/wg-quick reload %i
>   Environment=WG_ENDPOINT_RESOLUTION_RETRIES=infinity
>   
>   [Install]
> diff --git a/src/wg-quick/darwin.bash b/src/wg-quick/darwin.bash
> index d9d07cf..a732d6a 100755
> --- a/src/wg-quick/darwin.bash
> +++ b/src/wg-quick/darwin.bash
> @@ -350,6 +350,10 @@ set_config() {
>   	cmd wg setconf "$REAL_INTERFACE" <(echo "$WG_CONFIG")
>   }
>   
> +sync_config() {
> +	cmd wg syncconf "$REAL_INTERFACE" <(echo "$WG_CONFIG")
> +}
> +
>   save_config() {
>   	local old_umask new_config current_config address cmd
>   	new_config=$'[Interface]\n'
> @@ -398,7 +402,7 @@ execute_hooks() {
>   
>   cmd_usage() {
>   	cat >&2 <<-_EOF
> -	Usage: $PROGRAM [ up | down | save | strip ] [ CONFIG_FILE | INTERFACE ]
> +	Usage: $PROGRAM [ up | down | reload | save | strip ] [ CONFIG_FILE | INTERFACE ]
>   
>   	  CONFIG_FILE is a configuration file, whose filename is the interface name
>   	  followed by \`.conf'. Otherwise, INTERFACE is an interface name, with
> @@ -458,6 +462,13 @@ cmd_down() {
>   	execute_hooks "${POST_DOWN[@]}"
>   }
>   
> +cmd_reload() {
> +	if ! get_real_interface || [[ " $(wg show interfaces) " != *" $REAL_INTERFACE "* ]]; then
> +		die "\`$INTERFACE' is not a WireGuard interface"
> +	fi
> +	sync_config
> +}
> +
>   cmd_save() {
>   	if ! get_real_interface || [[ " $(wg show interfaces) " != *" $REAL_INTERFACE "* ]]; then
>   		die "\`$INTERFACE' is not a WireGuard interface"
> @@ -482,6 +493,10 @@ elif [[ $# -eq 2 && $1 == down ]]; then
>   	auto_su
>   	parse_options "$2"
>   	cmd_down
> +elif [[ $# -eq 2 && $1 == reload ]]; then
> +	auto_su
> +	parse_options "$2"
> +	cmd_reload
>   elif [[ $# -eq 2 && $1 == save ]]; then
>   	auto_su
>   	parse_options "$2"
> diff --git a/src/wg-quick/freebsd.bash b/src/wg-quick/freebsd.bash
> index c390dcc..6eef1f6 100755
> --- a/src/wg-quick/freebsd.bash
> +++ b/src/wg-quick/freebsd.bash
> @@ -333,6 +333,10 @@ set_config() {
>   	cmd wg setconf "$INTERFACE" <(echo "$WG_CONFIG")
>   }
>   
> +sync_config() {
> +	cmd wg syncconf "$INTERFACE" <(echo "$WG_CONFIG")
> +}
> +
>   save_config() {
>   	local old_umask new_config current_config address cmd
>   	new_config=$'[Interface]\n'
> @@ -382,7 +386,7 @@ execute_hooks() {
>   
>   cmd_usage() {
>   	cat >&2 <<-_EOF
> -	Usage: $PROGRAM [ up | down | save | strip ] [ CONFIG_FILE | INTERFACE ]
> +	Usage: $PROGRAM [ up | down | reload | save | strip ] [ CONFIG_FILE | INTERFACE ]
>   
>   	  CONFIG_FILE is a configuration file, whose filename is the interface name
>   	  followed by \`.conf'. Otherwise, INTERFACE is an interface name, with
> @@ -440,6 +444,11 @@ cmd_down() {
>   	execute_hooks "${POST_DOWN[@]}"
>   }
>   
> +cmd_reload() {
> +	[[ " $(wg show interfaces) " == *" $INTERFACE "* ]] || die "\`$INTERFACE' is not a WireGuard interface"
> +	sync_config
> +}
> +
>   cmd_save() {
>   	[[ " $(wg show interfaces) " == *" $INTERFACE "* ]] || die "\`$INTERFACE' is not a WireGuard interface"
>   	save_config
> @@ -464,6 +473,10 @@ elif [[ $# -eq 2 && $1 == down ]]; then
>   	auto_su
>   	parse_options "$2"
>   	cmd_down
> +elif [[ $# -eq 2 && $1 == reload ]]; then
> +	auto_su
> +	parse_options "$2"
> +	cmd_reload
>   elif [[ $# -eq 2 && $1 == save ]]; then
>   	auto_su
>   	parse_options "$2"
> diff --git a/src/wg-quick/linux.bash b/src/wg-quick/linux.bash
> index 7c2c002..37d6ba8 100755
> --- a/src/wg-quick/linux.bash
> +++ b/src/wg-quick/linux.bash
> @@ -246,6 +246,10 @@ set_config() {
>   	cmd wg setconf "$INTERFACE" <(echo "$WG_CONFIG")
>   }
>   
> +sync_config() {
> +	cmd wg syncconf "$INTERFACE" <(echo "$WG_CONFIG")
> +}
> +
>   save_config() {
>   	local old_umask new_config current_config address cmd
>   	[[ $(ip -all -brief address show dev "$INTERFACE") =~ ^$INTERFACE\ +\ [A-Z]+\ +(.+)$ ]] || true
> @@ -293,7 +297,7 @@ execute_hooks() {
>   
>   cmd_usage() {
>   	cat >&2 <<-_EOF
> -	Usage: $PROGRAM [ up | down | save | strip ] [ CONFIG_FILE | INTERFACE ]
> +	Usage: $PROGRAM [ up | down | reload | save | strip ] [ CONFIG_FILE | INTERFACE ]
>   
>   	  CONFIG_FILE is a configuration file, whose filename is the interface name
>   	  followed by \`.conf'. Otherwise, INTERFACE is an interface name, with
> @@ -347,6 +351,11 @@ cmd_down() {
>   	execute_hooks "${POST_DOWN[@]}"
>   }
>   
> +cmd_reload() {
> +	[[ " $(wg show interfaces) " == *" $INTERFACE "* ]] || die "\`$INTERFACE' is not a WireGuard interface"
> +	sync_config
> +}
> +
>   cmd_save() {
>   	[[ " $(wg show interfaces) " == *" $INTERFACE "* ]] || die "\`$INTERFACE' is not a WireGuard interface"
>   	save_config
> @@ -368,6 +377,10 @@ elif [[ $# -eq 2 && $1 == down ]]; then
>   	auto_su
>   	parse_options "$2"
>   	cmd_down
> +elif [[ $# -eq 2 && $1 == reload ]]; then
> +	auto_su
> +	parse_options "$2"
> +	cmd_reload
>   elif [[ $# -eq 2 && $1 == save ]]; then
>   	auto_su
>   	parse_options "$2"
> diff --git a/src/wg-quick/openbsd.bash b/src/wg-quick/openbsd.bash
> index 8d458d1..c509e70 100755
> --- a/src/wg-quick/openbsd.bash
> +++ b/src/wg-quick/openbsd.bash
> @@ -313,6 +313,10 @@ set_config() {
>   	cmd wg setconf "$REAL_INTERFACE" <(echo "$WG_CONFIG")
>   }
>   
> +sync_config() {
> +	cmd wg syncconf "$INTERFACE" <(echo "$WG_CONFIG")
> +}
> +
>   save_config() {
>   	local old_umask new_config current_config address network cmd
>   	new_config=$'[Interface]\n'
> @@ -361,7 +365,7 @@ execute_hooks() {
>   
>   cmd_usage() {
>   	cat >&2 <<-_EOF
> -	Usage: $PROGRAM [ up | down | save | strip ] [ CONFIG_FILE | INTERFACE ]
> +	Usage: $PROGRAM [ up | down | reload | save | strip ] [ CONFIG_FILE | INTERFACE ]
>   
>   	  CONFIG_FILE is a configuration file, whose filename is the interface name
>   	  followed by \`.conf'. Otherwise, INTERFACE is an interface name, with
> @@ -419,6 +423,11 @@ cmd_down() {
>   	execute_hooks "${POST_DOWN[@]}"
>   }
>   
> +cmd_reload() {
> +	[[ " $(wg show interfaces) " == *" $INTERFACE "* ]] || die "\`$INTERFACE' is not a WireGuard interface"
> +	sync_config
> +}
> +
>   cmd_save() {
>   	if ! get_real_interface || [[ " $(wg show interfaces) " != *" $REAL_INTERFACE "* ]]; then
>   		die "\`$INTERFACE' is not a WireGuard interface"
> @@ -442,6 +451,10 @@ elif [[ $# -eq 2 && $1 == down ]]; then
>   	auto_su
>   	parse_options "$2"
>   	cmd_down
> +elif [[ $# -eq 2 && $1 == reload ]]; then
> +	auto_su
> +	parse_options "$2"
> +	cmd_reload
>   elif [[ $# -eq 2 && $1 == save ]]; then
>   	auto_su
>   	parse_options "$2"
> 

From cwei at gmx.net  Sat Apr 11 20:21:01 2020
From: cwei at gmx.net (Christian Weiss)
Date: Sat, 11 Apr 2020 20:21:01 +0200
Subject: RHEL 7.8, Kernel 3.10: ratelimiter.c:25:1: error: unknown type name
 'hsiphash_key_t'
Message-ID: <0312354a-8bdb-00b1-f342-092c71e4817c@gmx.net>

Hello Dear Mailinglist,

with RHEL 7.8, kernel 3.10 and current Wireguard 1.0.20191226 make
throws the obove error:

# rpm -qa "wireguard*"
wireguard-tools-1.0.20191226-1.el7.x86_64
wireguard-dkms-1.0.20200401-1.el7.noarch

# cat /etc/oracle-release
Oracle Linux Server release 7.8

# uname -a
Linux xxxxxxxx 3.10.0-1127.el7.x86_64 #1 SMP Wed Apr 1 10:20:09 PDT 2020
x86_64 x86_64 x86_64 GNU/Linux

# make
  CC [M]  /var/lib/dkms/wireguard/1.0.20200401/build/main.o
  CC [M]  /var/lib/dkms/wireguard/1.0.20200401/build/noise.o
  CC [M]  /var/lib/dkms/wireguard/1.0.20200401/build/device.o
  CC [M]  /var/lib/dkms/wireguard/1.0.20200401/build/peer.o
  CC [M]  /var/lib/dkms/wireguard/1.0.20200401/build/timers.o
  CC [M]  /var/lib/dkms/wireguard/1.0.20200401/build/queueing.o
  CC [M]  /var/lib/dkms/wireguard/1.0.20200401/build/send.o
  CC [M]  /var/lib/dkms/wireguard/1.0.20200401/build/receive.o
  CC [M]  /var/lib/dkms/wireguard/1.0.20200401/build/socket.o
  CC [M]  /var/lib/dkms/wireguard/1.0.20200401/build/peerlookup.o
  CC [M]  /var/lib/dkms/wireguard/1.0.20200401/build/allowedips.o
  CC [M]  /var/lib/dkms/wireguard/1.0.20200401/build/ratelimiter.o
/var/lib/dkms/wireguard/1.0.20200401/build/ratelimiter.c:25:1: error:
unknown type name ?hsiphash_key_t?
 static hsiphash_key_t key;
 ^
/var/lib/dkms/wireguard/1.0.20200401/build/ratelimiter.c: In function
?wg_ratelimiter_allow?:
/var/lib/dkms/wireguard/1.0.20200401/build/ratelimiter.c:109:3: error:
implicit declaration of function ?hsiphash_2u32?
[-Werror=implicit-function-declaration]
   bucket = &table_v4[hsiphash_2u32(net_word, ip, &key) &
   ^
/var/lib/dkms/wireguard/1.0.20200401/build/ratelimiter.c:116:3: error:
implicit declaration of function ?hsiphash_3u32?
[-Werror=implicit-function-declaration]
   bucket = &table_v6[hsiphash_3u32(net_word, ip >> 32, ip, &key) &
   ^
cc1: some warnings being treated as errors
make[2]: *** [/var/lib/dkms/wireguard/1.0.20200401/build/ratelimiter.o]
Error 1
make[1]: *** [_module_/var/lib/dkms/wireguard/1.0.20200401/build] Error 2
make: *** [module] Error 2


The following change works for me; make succeeds:
--- compat/compat.h.bak 2020-04-11 20:04:15.077425108 +0200
+++ compat/compat.h     2020-04-11 20:06:39.279397118 +0200
@@ -1034,7 +1034,7 @@
 }
 #endif

-#if defined(ISUBUNTU1604)
+#if defined(ISUBUNTU1604) || defined(ISRHEL7)
 #include <linux/siphash.h>
 #ifndef _WG_LINUX_SIPHASH_H
 #define hsiphash_2u32 siphash_2u32

Kind regards,
Christian

From longman at redhat.com  Mon Apr 13 23:15:48 2020
From: longman at redhat.com (Waiman Long)
Date: Mon, 13 Apr 2020 17:15:48 -0400
Subject: [PATCH 0/2] mm, treewide: Rename kzfree() to kfree_sensitive()
Message-ID: <20200413211550.8307-1-longman@redhat.com>

This patchset makes a global rename of the kzfree() to kfree_sensitive()
to highlight the fact buffer clearing is only needed if the data objects
contain sensitive information like encrpytion key. The fact that kzfree()
uses memset() to do the clearing isn't totally safe either as compiler
may compile out the clearing in their optimizer. Instead, the new
kfree_sensitive() uses memzero_explicit() which won't get compiled out.

Waiman Long (2):
  mm, treewide: Rename kzfree() to kfree_sensitive()
  crypto: Remove unnecessary memzero_explicit()

 arch/s390/crypto/prng.c                       |  4 +--
 arch/x86/power/hibernate.c                    |  2 +-
 crypto/adiantum.c                             |  2 +-
 crypto/ahash.c                                |  4 +--
 crypto/api.c                                  |  2 +-
 crypto/asymmetric_keys/verify_pefile.c        |  4 +--
 crypto/deflate.c                              |  2 +-
 crypto/drbg.c                                 | 10 +++---
 crypto/ecc.c                                  |  8 ++---
 crypto/ecdh.c                                 |  2 +-
 crypto/gcm.c                                  |  2 +-
 crypto/gf128mul.c                             |  4 +--
 crypto/jitterentropy-kcapi.c                  |  2 +-
 crypto/rng.c                                  |  2 +-
 crypto/rsa-pkcs1pad.c                         |  6 ++--
 crypto/seqiv.c                                |  2 +-
 crypto/shash.c                                |  2 +-
 crypto/skcipher.c                             |  2 +-
 crypto/testmgr.c                              |  6 ++--
 crypto/zstd.c                                 |  2 +-
 .../allwinner/sun8i-ce/sun8i-ce-cipher.c      | 17 +++-------
 .../allwinner/sun8i-ss/sun8i-ss-cipher.c      | 18 +++-------
 drivers/crypto/amlogic/amlogic-gxl-cipher.c   | 14 +++-----
 drivers/crypto/atmel-ecc.c                    |  2 +-
 drivers/crypto/caam/caampkc.c                 | 28 +++++++--------
 drivers/crypto/cavium/cpt/cptvf_main.c        |  6 ++--
 drivers/crypto/cavium/cpt/cptvf_reqmanager.c  | 12 +++----
 drivers/crypto/cavium/nitrox/nitrox_lib.c     |  4 +--
 drivers/crypto/cavium/zip/zip_crypto.c        |  6 ++--
 drivers/crypto/ccp/ccp-crypto-rsa.c           |  6 ++--
 drivers/crypto/ccree/cc_aead.c                |  4 +--
 drivers/crypto/ccree/cc_buffer_mgr.c          |  4 +--
 drivers/crypto/ccree/cc_cipher.c              |  6 ++--
 drivers/crypto/ccree/cc_hash.c                |  8 ++---
 drivers/crypto/ccree/cc_request_mgr.c         |  2 +-
 drivers/crypto/inside-secure/safexcel_hash.c  |  3 +-
 drivers/crypto/marvell/cesa/hash.c            |  2 +-
 .../crypto/marvell/octeontx/otx_cptvf_main.c  |  6 ++--
 .../marvell/octeontx/otx_cptvf_reqmgr.h       |  2 +-
 drivers/crypto/mediatek/mtk-aes.c             |  2 +-
 drivers/crypto/nx/nx.c                        |  4 +--
 drivers/crypto/virtio/virtio_crypto_algs.c    | 12 +++----
 drivers/crypto/virtio/virtio_crypto_core.c    |  2 +-
 drivers/md/dm-crypt.c                         | 34 +++++++++----------
 drivers/md/dm-integrity.c                     |  6 ++--
 drivers/misc/ibmvmc.c                         |  6 ++--
 .../hisilicon/hns3/hns3pf/hclge_mbx.c         |  2 +-
 .../net/ethernet/intel/ixgbe/ixgbe_ipsec.c    |  6 ++--
 drivers/net/ppp/ppp_mppe.c                    |  6 ++--
 drivers/net/wireguard/noise.c                 |  4 +--
 drivers/net/wireguard/peer.c                  |  2 +-
 drivers/net/wireless/intel/iwlwifi/pcie/rx.c  |  2 +-
 .../net/wireless/intel/iwlwifi/pcie/tx-gen2.c |  6 ++--
 drivers/net/wireless/intel/iwlwifi/pcie/tx.c  |  6 ++--
 drivers/net/wireless/intersil/orinoco/wext.c  |  4 +--
 drivers/s390/crypto/ap_bus.h                  |  4 +--
 drivers/staging/ks7010/ks_hostif.c            |  2 +-
 drivers/staging/rtl8723bs/core/rtw_security.c |  2 +-
 drivers/staging/wlan-ng/p80211netdev.c        |  2 +-
 drivers/target/iscsi/iscsi_target_auth.c      |  2 +-
 fs/btrfs/ioctl.c                              |  2 +-
 fs/cifs/cifsencrypt.c                         |  2 +-
 fs/cifs/connect.c                             | 10 +++---
 fs/cifs/dfs_cache.c                           |  2 +-
 fs/cifs/misc.c                                |  8 ++---
 fs/crypto/keyring.c                           |  6 ++--
 fs/crypto/keysetup_v1.c                       |  4 +--
 fs/ecryptfs/keystore.c                        |  4 +--
 fs/ecryptfs/messaging.c                       |  2 +-
 include/crypto/aead.h                         |  2 +-
 include/crypto/akcipher.h                     |  2 +-
 include/crypto/gf128mul.h                     |  2 +-
 include/crypto/hash.h                         |  2 +-
 include/crypto/internal/acompress.h           |  2 +-
 include/crypto/kpp.h                          |  2 +-
 include/crypto/skcipher.h                     |  2 +-
 include/linux/slab.h                          |  2 +-
 lib/mpi/mpiutil.c                             |  6 ++--
 lib/test_kasan.c                              |  6 ++--
 mm/slab_common.c                              | 10 +++---
 net/atm/mpoa_caches.c                         |  4 +--
 net/bluetooth/ecdh_helper.c                   |  6 ++--
 net/bluetooth/smp.c                           | 24 ++++++-------
 net/core/sock.c                               |  2 +-
 net/ipv4/tcp_fastopen.c                       |  2 +-
 net/mac80211/aead_api.c                       |  4 +--
 net/mac80211/aes_gmac.c                       |  2 +-
 net/mac80211/key.c                            |  2 +-
 net/mac802154/llsec.c                         | 20 +++++------
 net/sctp/auth.c                               |  2 +-
 net/sctp/socket.c                             |  2 +-
 net/sunrpc/auth_gss/gss_krb5_crypto.c         |  4 +--
 net/sunrpc/auth_gss/gss_krb5_keys.c           |  6 ++--
 net/sunrpc/auth_gss/gss_krb5_mech.c           |  2 +-
 net/tipc/crypto.c                             | 10 +++---
 net/wireless/core.c                           |  2 +-
 net/wireless/ibss.c                           |  4 +--
 net/wireless/lib80211_crypt_tkip.c            |  2 +-
 net/wireless/lib80211_crypt_wep.c             |  2 +-
 net/wireless/nl80211.c                        | 24 ++++++-------
 net/wireless/sme.c                            |  6 ++--
 net/wireless/util.c                           |  2 +-
 net/wireless/wext-sme.c                       |  2 +-
 scripts/coccinelle/free/devm_free.cocci       |  4 +--
 scripts/coccinelle/free/ifnullfree.cocci      |  4 +--
 scripts/coccinelle/free/kfree.cocci           |  6 ++--
 scripts/coccinelle/free/kfreeaddr.cocci       |  2 +-
 security/apparmor/domain.c                    |  4 +--
 security/apparmor/include/file.h              |  2 +-
 security/apparmor/policy.c                    | 24 ++++++-------
 security/apparmor/policy_ns.c                 |  6 ++--
 security/apparmor/policy_unpack.c             | 14 ++++----
 security/keys/big_key.c                       |  6 ++--
 security/keys/dh.c                            | 14 ++++----
 security/keys/encrypted-keys/encrypted.c      | 14 ++++----
 security/keys/trusted-keys/trusted_tpm1.c     | 34 +++++++++----------
 security/keys/user_defined.c                  |  6 ++--
 117 files changed, 332 insertions(+), 358 deletions(-)

-- 
2.18.1


From longman at redhat.com  Mon Apr 13 23:15:49 2020
From: longman at redhat.com (Waiman Long)
Date: Mon, 13 Apr 2020 17:15:49 -0400
Subject: [PATCH 1/2] mm, treewide: Rename kzfree() to kfree_sensitive()
In-Reply-To: <20200413211550.8307-1-longman@redhat.com>
References: <20200413211550.8307-1-longman@redhat.com>
Message-ID: <20200413211550.8307-2-longman@redhat.com>

As said by Linus:

  A symmetric naming is only helpful if it implies symmetries in use.
  Otherwise it's actively misleading.

  In "kzalloc()", the z is meaningful and an important part of what the
  caller wants.

  In "kzfree()", the z is actively detrimental, because maybe in the
  future we really _might_ want to use that "memfill(0xdeadbeef)" or
  something. The "zero" part of the interface isn't even _relevant_.

The main reason that kzfree() exists is to clear sensitive information
that should not be leaked to other future users of the same memory
objects.

Rename kzfree() to kfree_sensitive() to follow the example of the
recently added kvfree_sensitive() and make the intention of the API
more explicit. In addition, memzero_explicit() is used to clear the
memory to make sure that it won't get optimized away by the compiler.

The renaming is done by using the command sequence:

  git grep -w --name-only kzfree |\
  xargs sed -i 's/\bkzfree\b/kfree_sensitive/'

followed by some editing of the kfree_sensitive() kerneldoc and the
use of memzero_explicit() instead of memset().

Suggested-by: Joe Perches <joe at perches.com>
Signed-off-by: Waiman Long <longman at redhat.com>
---
 arch/s390/crypto/prng.c                       |  4 +--
 arch/x86/power/hibernate.c                    |  2 +-
 crypto/adiantum.c                             |  2 +-
 crypto/ahash.c                                |  4 +--
 crypto/api.c                                  |  2 +-
 crypto/asymmetric_keys/verify_pefile.c        |  4 +--
 crypto/deflate.c                              |  2 +-
 crypto/drbg.c                                 | 10 +++---
 crypto/ecc.c                                  |  8 ++---
 crypto/ecdh.c                                 |  2 +-
 crypto/gcm.c                                  |  2 +-
 crypto/gf128mul.c                             |  4 +--
 crypto/jitterentropy-kcapi.c                  |  2 +-
 crypto/rng.c                                  |  2 +-
 crypto/rsa-pkcs1pad.c                         |  6 ++--
 crypto/seqiv.c                                |  2 +-
 crypto/shash.c                                |  2 +-
 crypto/skcipher.c                             |  2 +-
 crypto/testmgr.c                              |  6 ++--
 crypto/zstd.c                                 |  2 +-
 .../allwinner/sun8i-ce/sun8i-ce-cipher.c      |  2 +-
 .../allwinner/sun8i-ss/sun8i-ss-cipher.c      |  2 +-
 drivers/crypto/amlogic/amlogic-gxl-cipher.c   |  4 +--
 drivers/crypto/atmel-ecc.c                    |  2 +-
 drivers/crypto/caam/caampkc.c                 | 28 +++++++--------
 drivers/crypto/cavium/cpt/cptvf_main.c        |  6 ++--
 drivers/crypto/cavium/cpt/cptvf_reqmanager.c  | 12 +++----
 drivers/crypto/cavium/nitrox/nitrox_lib.c     |  4 +--
 drivers/crypto/cavium/zip/zip_crypto.c        |  6 ++--
 drivers/crypto/ccp/ccp-crypto-rsa.c           |  6 ++--
 drivers/crypto/ccree/cc_aead.c                |  4 +--
 drivers/crypto/ccree/cc_buffer_mgr.c          |  4 +--
 drivers/crypto/ccree/cc_cipher.c              |  6 ++--
 drivers/crypto/ccree/cc_hash.c                |  8 ++---
 drivers/crypto/ccree/cc_request_mgr.c         |  2 +-
 drivers/crypto/marvell/cesa/hash.c            |  2 +-
 .../crypto/marvell/octeontx/otx_cptvf_main.c  |  6 ++--
 .../marvell/octeontx/otx_cptvf_reqmgr.h       |  2 +-
 drivers/crypto/mediatek/mtk-aes.c             |  2 +-
 drivers/crypto/nx/nx.c                        |  4 +--
 drivers/crypto/virtio/virtio_crypto_algs.c    | 12 +++----
 drivers/crypto/virtio/virtio_crypto_core.c    |  2 +-
 drivers/md/dm-crypt.c                         | 34 +++++++++----------
 drivers/md/dm-integrity.c                     |  6 ++--
 drivers/misc/ibmvmc.c                         |  6 ++--
 .../hisilicon/hns3/hns3pf/hclge_mbx.c         |  2 +-
 .../net/ethernet/intel/ixgbe/ixgbe_ipsec.c    |  6 ++--
 drivers/net/ppp/ppp_mppe.c                    |  6 ++--
 drivers/net/wireguard/noise.c                 |  4 +--
 drivers/net/wireguard/peer.c                  |  2 +-
 drivers/net/wireless/intel/iwlwifi/pcie/rx.c  |  2 +-
 .../net/wireless/intel/iwlwifi/pcie/tx-gen2.c |  6 ++--
 drivers/net/wireless/intel/iwlwifi/pcie/tx.c  |  6 ++--
 drivers/net/wireless/intersil/orinoco/wext.c  |  4 +--
 drivers/s390/crypto/ap_bus.h                  |  4 +--
 drivers/staging/ks7010/ks_hostif.c            |  2 +-
 drivers/staging/rtl8723bs/core/rtw_security.c |  2 +-
 drivers/staging/wlan-ng/p80211netdev.c        |  2 +-
 drivers/target/iscsi/iscsi_target_auth.c      |  2 +-
 fs/btrfs/ioctl.c                              |  2 +-
 fs/cifs/cifsencrypt.c                         |  2 +-
 fs/cifs/connect.c                             | 10 +++---
 fs/cifs/dfs_cache.c                           |  2 +-
 fs/cifs/misc.c                                |  8 ++---
 fs/crypto/keyring.c                           |  6 ++--
 fs/crypto/keysetup_v1.c                       |  4 +--
 fs/ecryptfs/keystore.c                        |  4 +--
 fs/ecryptfs/messaging.c                       |  2 +-
 include/crypto/aead.h                         |  2 +-
 include/crypto/akcipher.h                     |  2 +-
 include/crypto/gf128mul.h                     |  2 +-
 include/crypto/hash.h                         |  2 +-
 include/crypto/internal/acompress.h           |  2 +-
 include/crypto/kpp.h                          |  2 +-
 include/crypto/skcipher.h                     |  2 +-
 include/linux/slab.h                          |  2 +-
 lib/mpi/mpiutil.c                             |  6 ++--
 lib/test_kasan.c                              |  6 ++--
 mm/slab_common.c                              | 10 +++---
 net/atm/mpoa_caches.c                         |  4 +--
 net/bluetooth/ecdh_helper.c                   |  6 ++--
 net/bluetooth/smp.c                           | 24 ++++++-------
 net/core/sock.c                               |  2 +-
 net/ipv4/tcp_fastopen.c                       |  2 +-
 net/mac80211/aead_api.c                       |  4 +--
 net/mac80211/aes_gmac.c                       |  2 +-
 net/mac80211/key.c                            |  2 +-
 net/mac802154/llsec.c                         | 20 +++++------
 net/sctp/auth.c                               |  2 +-
 net/sctp/socket.c                             |  2 +-
 net/sunrpc/auth_gss/gss_krb5_crypto.c         |  4 +--
 net/sunrpc/auth_gss/gss_krb5_keys.c           |  6 ++--
 net/sunrpc/auth_gss/gss_krb5_mech.c           |  2 +-
 net/tipc/crypto.c                             | 10 +++---
 net/wireless/core.c                           |  2 +-
 net/wireless/ibss.c                           |  4 +--
 net/wireless/lib80211_crypt_tkip.c            |  2 +-
 net/wireless/lib80211_crypt_wep.c             |  2 +-
 net/wireless/nl80211.c                        | 24 ++++++-------
 net/wireless/sme.c                            |  6 ++--
 net/wireless/util.c                           |  2 +-
 net/wireless/wext-sme.c                       |  2 +-
 scripts/coccinelle/free/devm_free.cocci       |  4 +--
 scripts/coccinelle/free/ifnullfree.cocci      |  4 +--
 scripts/coccinelle/free/kfree.cocci           |  6 ++--
 scripts/coccinelle/free/kfreeaddr.cocci       |  2 +-
 security/apparmor/domain.c                    |  4 +--
 security/apparmor/include/file.h              |  2 +-
 security/apparmor/policy.c                    | 24 ++++++-------
 security/apparmor/policy_ns.c                 |  6 ++--
 security/apparmor/policy_unpack.c             | 14 ++++----
 security/keys/big_key.c                       |  6 ++--
 security/keys/dh.c                            | 14 ++++----
 security/keys/encrypted-keys/encrypted.c      | 14 ++++----
 security/keys/trusted-keys/trusted_tpm1.c     | 34 +++++++++----------
 security/keys/user_defined.c                  |  6 ++--
 116 files changed, 323 insertions(+), 323 deletions(-)

diff --git a/arch/s390/crypto/prng.c b/arch/s390/crypto/prng.c
index d977643fa627..04caac037b7a 100644
--- a/arch/s390/crypto/prng.c
+++ b/arch/s390/crypto/prng.c
@@ -249,7 +249,7 @@ static void prng_tdes_deinstantiate(void)
 {
 	pr_debug("The prng module stopped "
 		 "after running in triple DES mode\n");
-	kzfree(prng_data);
+	kfree_sensitive(prng_data);
 }
 
 
@@ -442,7 +442,7 @@ static int __init prng_sha512_instantiate(void)
 static void prng_sha512_deinstantiate(void)
 {
 	pr_debug("The prng module stopped after running in SHA-512 mode\n");
-	kzfree(prng_data);
+	kfree_sensitive(prng_data);
 }
 
 
diff --git a/arch/x86/power/hibernate.c b/arch/x86/power/hibernate.c
index fc413717a45f..45e8b775b88e 100644
--- a/arch/x86/power/hibernate.c
+++ b/arch/x86/power/hibernate.c
@@ -98,7 +98,7 @@ static int get_e820_md5(struct e820_table *table, void *buf)
 	if (crypto_shash_digest(desc, (u8 *)table, size, buf))
 		ret = -EINVAL;
 
-	kzfree(desc);
+	kfree_sensitive(desc);
 
 free_tfm:
 	crypto_free_shash(tfm);
diff --git a/crypto/adiantum.c b/crypto/adiantum.c
index cf2b9f4103dd..b7824e214961 100644
--- a/crypto/adiantum.c
+++ b/crypto/adiantum.c
@@ -177,7 +177,7 @@ static int adiantum_setkey(struct crypto_skcipher *tfm, const u8 *key,
 	keyp += NHPOLY1305_KEY_SIZE;
 	WARN_ON(keyp != &data->derived_keys[ARRAY_SIZE(data->derived_keys)]);
 out:
-	kzfree(data);
+	kfree_sensitive(data);
 	return err;
 }
 
diff --git a/crypto/ahash.c b/crypto/ahash.c
index 68a0f0cb75c4..d9d65d1cc669 100644
--- a/crypto/ahash.c
+++ b/crypto/ahash.c
@@ -183,7 +183,7 @@ static int ahash_setkey_unaligned(struct crypto_ahash *tfm, const u8 *key,
 	alignbuffer = (u8 *)ALIGN((unsigned long)buffer, alignmask + 1);
 	memcpy(alignbuffer, key, keylen);
 	ret = tfm->setkey(tfm, alignbuffer, keylen);
-	kzfree(buffer);
+	kfree_sensitive(buffer);
 	return ret;
 }
 
@@ -302,7 +302,7 @@ static void ahash_restore_req(struct ahash_request *req, int err)
 	req->priv = NULL;
 
 	/* Free the req->priv.priv from the ADJUSTED request. */
-	kzfree(priv);
+	kfree_sensitive(priv);
 }
 
 static void ahash_notify_einprogress(struct ahash_request *req)
diff --git a/crypto/api.c b/crypto/api.c
index 7d71a9b10e5f..5fa4fac4bd02 100644
--- a/crypto/api.c
+++ b/crypto/api.c
@@ -564,7 +564,7 @@ void crypto_destroy_tfm(void *mem, struct crypto_tfm *tfm)
 		alg->cra_exit(tfm);
 	crypto_exit_ops(tfm);
 	crypto_mod_put(alg);
-	kzfree(mem);
+	kfree_sensitive(mem);
 }
 EXPORT_SYMBOL_GPL(crypto_destroy_tfm);
 
diff --git a/crypto/asymmetric_keys/verify_pefile.c b/crypto/asymmetric_keys/verify_pefile.c
index cc9dbcecaaca..7553ab18db89 100644
--- a/crypto/asymmetric_keys/verify_pefile.c
+++ b/crypto/asymmetric_keys/verify_pefile.c
@@ -376,7 +376,7 @@ static int pefile_digest_pe(const void *pebuf, unsigned int pelen,
 	}
 
 error:
-	kzfree(desc);
+	kfree_sensitive(desc);
 error_no_desc:
 	crypto_free_shash(tfm);
 	kleave(" = %d", ret);
@@ -447,6 +447,6 @@ int verify_pefile_signature(const void *pebuf, unsigned pelen,
 	ret = pefile_digest_pe(pebuf, pelen, &ctx);
 
 error:
-	kzfree(ctx.digest);
+	kfree_sensitive(ctx.digest);
 	return ret;
 }
diff --git a/crypto/deflate.c b/crypto/deflate.c
index 4c0e6c9d942a..b2a46f6dc961 100644
--- a/crypto/deflate.c
+++ b/crypto/deflate.c
@@ -163,7 +163,7 @@ static void __deflate_exit(void *ctx)
 static void deflate_free_ctx(struct crypto_scomp *tfm, void *ctx)
 {
 	__deflate_exit(ctx);
-	kzfree(ctx);
+	kfree_sensitive(ctx);
 }
 
 static void deflate_exit(struct crypto_tfm *tfm)
diff --git a/crypto/drbg.c b/crypto/drbg.c
index b6929eb5f565..2e4b2189636e 100644
--- a/crypto/drbg.c
+++ b/crypto/drbg.c
@@ -1206,19 +1206,19 @@ static inline void drbg_dealloc_state(struct drbg_state *drbg)
 {
 	if (!drbg)
 		return;
-	kzfree(drbg->Vbuf);
+	kfree_sensitive(drbg->Vbuf);
 	drbg->Vbuf = NULL;
 	drbg->V = NULL;
-	kzfree(drbg->Cbuf);
+	kfree_sensitive(drbg->Cbuf);
 	drbg->Cbuf = NULL;
 	drbg->C = NULL;
-	kzfree(drbg->scratchpadbuf);
+	kfree_sensitive(drbg->scratchpadbuf);
 	drbg->scratchpadbuf = NULL;
 	drbg->reseed_ctr = 0;
 	drbg->d_ops = NULL;
 	drbg->core = NULL;
 	if (IS_ENABLED(CONFIG_CRYPTO_FIPS)) {
-		kzfree(drbg->prev);
+		kfree_sensitive(drbg->prev);
 		drbg->prev = NULL;
 		drbg->fips_primed = false;
 	}
@@ -1685,7 +1685,7 @@ static int drbg_fini_hash_kernel(struct drbg_state *drbg)
 	struct sdesc *sdesc = (struct sdesc *)drbg->priv_data;
 	if (sdesc) {
 		crypto_free_shash(sdesc->shash.tfm);
-		kzfree(sdesc);
+		kfree_sensitive(sdesc);
 	}
 	drbg->priv_data = NULL;
 	return 0;
diff --git a/crypto/ecc.c b/crypto/ecc.c
index 02d35be7702b..37540332c1f3 100644
--- a/crypto/ecc.c
+++ b/crypto/ecc.c
@@ -67,7 +67,7 @@ static u64 *ecc_alloc_digits_space(unsigned int ndigits)
 
 static void ecc_free_digits_space(u64 *space)
 {
-	kzfree(space);
+	kfree_sensitive(space);
 }
 
 static struct ecc_point *ecc_alloc_point(unsigned int ndigits)
@@ -101,9 +101,9 @@ static void ecc_free_point(struct ecc_point *p)
 	if (!p)
 		return;
 
-	kzfree(p->x);
-	kzfree(p->y);
-	kzfree(p);
+	kfree_sensitive(p->x);
+	kfree_sensitive(p->y);
+	kfree_sensitive(p);
 }
 
 static void vli_clear(u64 *vli, unsigned int ndigits)
diff --git a/crypto/ecdh.c b/crypto/ecdh.c
index bd599053a8c4..b0232d6ab4ce 100644
--- a/crypto/ecdh.c
+++ b/crypto/ecdh.c
@@ -124,7 +124,7 @@ static int ecdh_compute_value(struct kpp_request *req)
 
 	/* fall through */
 free_all:
-	kzfree(shared_secret);
+	kfree_sensitive(shared_secret);
 free_pubkey:
 	kfree(public_key);
 	return ret;
diff --git a/crypto/gcm.c b/crypto/gcm.c
index 0103d28c541e..5c2fbb08be56 100644
--- a/crypto/gcm.c
+++ b/crypto/gcm.c
@@ -139,7 +139,7 @@ static int crypto_gcm_setkey(struct crypto_aead *aead, const u8 *key,
 			       CRYPTO_TFM_REQ_MASK);
 	err = crypto_ahash_setkey(ghash, (u8 *)&data->hash, sizeof(be128));
 out:
-	kzfree(data);
+	kfree_sensitive(data);
 	return err;
 }
 
diff --git a/crypto/gf128mul.c b/crypto/gf128mul.c
index a4b1c026aaee..a69ae3e6c16c 100644
--- a/crypto/gf128mul.c
+++ b/crypto/gf128mul.c
@@ -304,8 +304,8 @@ void gf128mul_free_64k(struct gf128mul_64k *t)
 	int i;
 
 	for (i = 0; i < 16; i++)
-		kzfree(t->t[i]);
-	kzfree(t);
+		kfree_sensitive(t->t[i]);
+	kfree_sensitive(t);
 }
 EXPORT_SYMBOL(gf128mul_free_64k);
 
diff --git a/crypto/jitterentropy-kcapi.c b/crypto/jitterentropy-kcapi.c
index a5ce8f96790f..bc5f969360ae 100644
--- a/crypto/jitterentropy-kcapi.c
+++ b/crypto/jitterentropy-kcapi.c
@@ -57,7 +57,7 @@ void *jent_zalloc(unsigned int len)
 
 void jent_zfree(void *ptr)
 {
-	kzfree(ptr);
+	kfree_sensitive(ptr);
 }
 
 int jent_fips_enabled(void)
diff --git a/crypto/rng.c b/crypto/rng.c
index 1490d210f1a1..a888d84b524a 100644
--- a/crypto/rng.c
+++ b/crypto/rng.c
@@ -53,7 +53,7 @@ int crypto_rng_reset(struct crypto_rng *tfm, const u8 *seed, unsigned int slen)
 	err = crypto_rng_alg(tfm)->seed(tfm, seed, slen);
 	crypto_stats_rng_seed(alg, err);
 out:
-	kzfree(buf);
+	kfree_sensitive(buf);
 	return err;
 }
 EXPORT_SYMBOL_GPL(crypto_rng_reset);
diff --git a/crypto/rsa-pkcs1pad.c b/crypto/rsa-pkcs1pad.c
index d31031de51bc..6c992eb5c72f 100644
--- a/crypto/rsa-pkcs1pad.c
+++ b/crypto/rsa-pkcs1pad.c
@@ -199,7 +199,7 @@ static int pkcs1pad_encrypt_sign_complete(struct akcipher_request *req, int err)
 	sg_copy_from_buffer(req->dst,
 			    sg_nents_for_len(req->dst, ctx->key_size),
 			    out_buf, ctx->key_size);
-	kzfree(out_buf);
+	kfree_sensitive(out_buf);
 
 out:
 	req->dst_len = ctx->key_size;
@@ -322,7 +322,7 @@ static int pkcs1pad_decrypt_complete(struct akcipher_request *req, int err)
 				out_buf + pos, req->dst_len);
 
 done:
-	kzfree(req_ctx->out_buf);
+	kfree_sensitive(req_ctx->out_buf);
 
 	return err;
 }
@@ -500,7 +500,7 @@ static int pkcs1pad_verify_complete(struct akcipher_request *req, int err)
 		   req->dst_len) != 0)
 		err = -EKEYREJECTED;
 done:
-	kzfree(req_ctx->out_buf);
+	kfree_sensitive(req_ctx->out_buf);
 
 	return err;
 }
diff --git a/crypto/seqiv.c b/crypto/seqiv.c
index f124b9b54e15..27b2387bc972 100644
--- a/crypto/seqiv.c
+++ b/crypto/seqiv.c
@@ -33,7 +33,7 @@ static void seqiv_aead_encrypt_complete2(struct aead_request *req, int err)
 	memcpy(req->iv, subreq->iv, crypto_aead_ivsize(geniv));
 
 out:
-	kzfree(subreq->iv);
+	kfree_sensitive(subreq->iv);
 }
 
 static void seqiv_aead_encrypt_complete(struct crypto_async_request *base,
diff --git a/crypto/shash.c b/crypto/shash.c
index c075b26c2a1d..fcd8d8c5408b 100644
--- a/crypto/shash.c
+++ b/crypto/shash.c
@@ -44,7 +44,7 @@ static int shash_setkey_unaligned(struct crypto_shash *tfm, const u8 *key,
 	alignbuffer = (u8 *)ALIGN((unsigned long)buffer, alignmask + 1);
 	memcpy(alignbuffer, key, keylen);
 	err = shash->setkey(tfm, alignbuffer, keylen);
-	kzfree(buffer);
+	kfree_sensitive(buffer);
 	return err;
 }
 
diff --git a/crypto/skcipher.c b/crypto/skcipher.c
index 7221def7b9a7..1c4a0d2132c3 100644
--- a/crypto/skcipher.c
+++ b/crypto/skcipher.c
@@ -592,7 +592,7 @@ static int skcipher_setkey_unaligned(struct crypto_skcipher *tfm,
 	alignbuffer = (u8 *)ALIGN((unsigned long)buffer, alignmask + 1);
 	memcpy(alignbuffer, key, keylen);
 	ret = cipher->setkey(tfm, alignbuffer, keylen);
-	kzfree(buffer);
+	kfree_sensitive(buffer);
 	return ret;
 }
 
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index 6863f911fcee..23c27fc96394 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -1744,7 +1744,7 @@ static int test_hash_vs_generic_impl(const char *driver,
 	kfree(vec.plaintext);
 	kfree(vec.digest);
 	crypto_free_shash(generic_tfm);
-	kzfree(generic_desc);
+	kfree_sensitive(generic_desc);
 	return err;
 }
 #else /* !CONFIG_CRYPTO_MANAGER_EXTRA_TESTS */
@@ -3665,7 +3665,7 @@ static int drbg_cavs_test(const struct drbg_testvec *test, int pr,
 	if (IS_ERR(drng)) {
 		printk(KERN_ERR "alg: drbg: could not allocate DRNG handle for "
 		       "%s\n", driver);
-		kzfree(buf);
+		kfree_sensitive(buf);
 		return -ENOMEM;
 	}
 
@@ -3712,7 +3712,7 @@ static int drbg_cavs_test(const struct drbg_testvec *test, int pr,
 
 outbuf:
 	crypto_free_rng(drng);
-	kzfree(buf);
+	kfree_sensitive(buf);
 	return ret;
 }
 
diff --git a/crypto/zstd.c b/crypto/zstd.c
index 5a3ff258d8f7..1a3309f066f7 100644
--- a/crypto/zstd.c
+++ b/crypto/zstd.c
@@ -137,7 +137,7 @@ static void __zstd_exit(void *ctx)
 static void zstd_free_ctx(struct crypto_scomp *tfm, void *ctx)
 {
 	__zstd_exit(ctx);
-	kzfree(ctx);
+	kfree_sensitive(ctx);
 }
 
 static void zstd_exit(struct crypto_tfm *tfm)
diff --git a/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c b/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c
index a5fd8975f3d3..aa4e8fdc2b32 100644
--- a/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c
+++ b/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c
@@ -257,7 +257,7 @@ static int sun8i_ce_cipher(struct skcipher_request *areq)
 		offset = areq->cryptlen - ivsize;
 		if (rctx->op_dir & CE_DECRYPTION) {
 			memcpy(areq->iv, backup_iv, ivsize);
-			kzfree(backup_iv);
+			kfree_sensitive(backup_iv);
 		} else {
 			scatterwalk_map_and_copy(areq->iv, areq->dst, offset,
 						 ivsize, 0);
diff --git a/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-cipher.c b/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-cipher.c
index 84d52fc3a2da..5246ef4f5430 100644
--- a/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-cipher.c
+++ b/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-cipher.c
@@ -250,7 +250,7 @@ static int sun8i_ss_cipher(struct skcipher_request *areq)
 			if (rctx->op_dir & SS_DECRYPTION) {
 				memcpy(areq->iv, backup_iv, ivsize);
 				memzero_explicit(backup_iv, ivsize);
-				kzfree(backup_iv);
+				kfree_sensitive(backup_iv);
 			} else {
 				scatterwalk_map_and_copy(areq->iv, areq->dst, offset,
 							 ivsize, 0);
diff --git a/drivers/crypto/amlogic/amlogic-gxl-cipher.c b/drivers/crypto/amlogic/amlogic-gxl-cipher.c
index 9819dd50fbad..fd1269900d67 100644
--- a/drivers/crypto/amlogic/amlogic-gxl-cipher.c
+++ b/drivers/crypto/amlogic/amlogic-gxl-cipher.c
@@ -254,8 +254,8 @@ static int meson_cipher(struct skcipher_request *areq)
 		}
 	}
 theend:
-	kzfree(bkeyiv);
-	kzfree(backup_iv);
+	kfree_sensitive(bkeyiv);
+	kfree_sensitive(backup_iv);
 
 	return err;
 }
diff --git a/drivers/crypto/atmel-ecc.c b/drivers/crypto/atmel-ecc.c
index ff02cc05affb..9bd8e5167be3 100644
--- a/drivers/crypto/atmel-ecc.c
+++ b/drivers/crypto/atmel-ecc.c
@@ -69,7 +69,7 @@ static void atmel_ecdh_done(struct atmel_i2c_work_data *work_data, void *areq,
 
 	/* fall through */
 free_work_data:
-	kzfree(work_data);
+	kfree_sensitive(work_data);
 	kpp_request_complete(req, status);
 }
 
diff --git a/drivers/crypto/caam/caampkc.c b/drivers/crypto/caam/caampkc.c
index 4fcae37a2e33..203bcd66f8b0 100644
--- a/drivers/crypto/caam/caampkc.c
+++ b/drivers/crypto/caam/caampkc.c
@@ -850,14 +850,14 @@ static int caam_rsa_dec(struct akcipher_request *req)
 
 static void caam_rsa_free_key(struct caam_rsa_key *key)
 {
-	kzfree(key->d);
-	kzfree(key->p);
-	kzfree(key->q);
-	kzfree(key->dp);
-	kzfree(key->dq);
-	kzfree(key->qinv);
-	kzfree(key->tmp1);
-	kzfree(key->tmp2);
+	kfree_sensitive(key->d);
+	kfree_sensitive(key->p);
+	kfree_sensitive(key->q);
+	kfree_sensitive(key->dp);
+	kfree_sensitive(key->dq);
+	kfree_sensitive(key->qinv);
+	kfree_sensitive(key->tmp1);
+	kfree_sensitive(key->tmp2);
 	kfree(key->e);
 	kfree(key->n);
 	memset(key, 0, sizeof(*key));
@@ -1014,17 +1014,17 @@ static void caam_rsa_set_priv_key_form(struct caam_rsa_ctx *ctx,
 	return;
 
 free_dq:
-	kzfree(rsa_key->dq);
+	kfree_sensitive(rsa_key->dq);
 free_dp:
-	kzfree(rsa_key->dp);
+	kfree_sensitive(rsa_key->dp);
 free_tmp2:
-	kzfree(rsa_key->tmp2);
+	kfree_sensitive(rsa_key->tmp2);
 free_tmp1:
-	kzfree(rsa_key->tmp1);
+	kfree_sensitive(rsa_key->tmp1);
 free_q:
-	kzfree(rsa_key->q);
+	kfree_sensitive(rsa_key->q);
 free_p:
-	kzfree(rsa_key->p);
+	kfree_sensitive(rsa_key->p);
 }
 
 static int caam_rsa_set_priv_key(struct crypto_akcipher *tfm, const void *key,
diff --git a/drivers/crypto/cavium/cpt/cptvf_main.c b/drivers/crypto/cavium/cpt/cptvf_main.c
index 0f72e9abdefe..a15245992cf9 100644
--- a/drivers/crypto/cavium/cpt/cptvf_main.c
+++ b/drivers/crypto/cavium/cpt/cptvf_main.c
@@ -74,7 +74,7 @@ static void cleanup_worker_threads(struct cpt_vf *cptvf)
 	for (i = 0; i < cptvf->nr_queues; i++)
 		tasklet_kill(&cwqe_info->vq_wqe[i].twork);
 
-	kzfree(cwqe_info);
+	kfree_sensitive(cwqe_info);
 	cptvf->wqe_info = NULL;
 }
 
@@ -88,7 +88,7 @@ static void free_pending_queues(struct pending_qinfo *pqinfo)
 			continue;
 
 		/* free single queue */
-		kzfree((queue->head));
+		kfree_sensitive((queue->head));
 
 		queue->front = 0;
 		queue->rear = 0;
@@ -189,7 +189,7 @@ static void free_command_queues(struct cpt_vf *cptvf,
 			chunk->head = NULL;
 			chunk->dma_addr = 0;
 			hlist_del(&chunk->nextchunk);
-			kzfree(chunk);
+			kfree_sensitive(chunk);
 		}
 
 		queue->nchunks = 0;
diff --git a/drivers/crypto/cavium/cpt/cptvf_reqmanager.c b/drivers/crypto/cavium/cpt/cptvf_reqmanager.c
index 7a24019356b5..472dbc2d7c5c 100644
--- a/drivers/crypto/cavium/cpt/cptvf_reqmanager.c
+++ b/drivers/crypto/cavium/cpt/cptvf_reqmanager.c
@@ -305,12 +305,12 @@ static void do_request_cleanup(struct cpt_vf *cptvf,
 		}
 	}
 
-	kzfree(info->scatter_components);
-	kzfree(info->gather_components);
-	kzfree(info->out_buffer);
-	kzfree(info->in_buffer);
-	kzfree((void *)info->completion_addr);
-	kzfree(info);
+	kfree_sensitive(info->scatter_components);
+	kfree_sensitive(info->gather_components);
+	kfree_sensitive(info->out_buffer);
+	kfree_sensitive(info->in_buffer);
+	kfree_sensitive((void *)info->completion_addr);
+	kfree_sensitive(info);
 }
 
 static void do_post_process(struct cpt_vf *cptvf, struct cpt_info_buffer *info)
diff --git a/drivers/crypto/cavium/nitrox/nitrox_lib.c b/drivers/crypto/cavium/nitrox/nitrox_lib.c
index 5cbc64b851b9..a5cdc2b48bd6 100644
--- a/drivers/crypto/cavium/nitrox/nitrox_lib.c
+++ b/drivers/crypto/cavium/nitrox/nitrox_lib.c
@@ -90,7 +90,7 @@ static void nitrox_free_aqm_queues(struct nitrox_device *ndev)
 
 	for (i = 0; i < ndev->nr_queues; i++) {
 		nitrox_cmdq_cleanup(ndev->aqmq[i]);
-		kzfree(ndev->aqmq[i]);
+		kfree_sensitive(ndev->aqmq[i]);
 		ndev->aqmq[i] = NULL;
 	}
 }
@@ -122,7 +122,7 @@ static int nitrox_alloc_aqm_queues(struct nitrox_device *ndev)
 
 		err = nitrox_cmdq_init(cmdq, AQM_Q_ALIGN_BYTES);
 		if (err) {
-			kzfree(cmdq);
+			kfree_sensitive(cmdq);
 			goto aqmq_fail;
 		}
 		ndev->aqmq[i] = cmdq;
diff --git a/drivers/crypto/cavium/zip/zip_crypto.c b/drivers/crypto/cavium/zip/zip_crypto.c
index 4985bc812b0e..7df71fcebe8f 100644
--- a/drivers/crypto/cavium/zip/zip_crypto.c
+++ b/drivers/crypto/cavium/zip/zip_crypto.c
@@ -260,7 +260,7 @@ void *zip_alloc_scomp_ctx_deflate(struct crypto_scomp *tfm)
 	ret = zip_ctx_init(zip_ctx, 0);
 
 	if (ret) {
-		kzfree(zip_ctx);
+		kfree_sensitive(zip_ctx);
 		return ERR_PTR(ret);
 	}
 
@@ -279,7 +279,7 @@ void *zip_alloc_scomp_ctx_lzs(struct crypto_scomp *tfm)
 	ret = zip_ctx_init(zip_ctx, 1);
 
 	if (ret) {
-		kzfree(zip_ctx);
+		kfree_sensitive(zip_ctx);
 		return ERR_PTR(ret);
 	}
 
@@ -291,7 +291,7 @@ void zip_free_scomp_ctx(struct crypto_scomp *tfm, void *ctx)
 	struct zip_kernel_ctx *zip_ctx = ctx;
 
 	zip_ctx_exit(zip_ctx);
-	kzfree(zip_ctx);
+	kfree_sensitive(zip_ctx);
 }
 
 int zip_scomp_compress(struct crypto_scomp *tfm,
diff --git a/drivers/crypto/ccp/ccp-crypto-rsa.c b/drivers/crypto/ccp/ccp-crypto-rsa.c
index 649c91d60401..1223ac70aea2 100644
--- a/drivers/crypto/ccp/ccp-crypto-rsa.c
+++ b/drivers/crypto/ccp/ccp-crypto-rsa.c
@@ -112,13 +112,13 @@ static int ccp_check_key_length(unsigned int len)
 static void ccp_rsa_free_key_bufs(struct ccp_ctx *ctx)
 {
 	/* Clean up old key data */
-	kzfree(ctx->u.rsa.e_buf);
+	kfree_sensitive(ctx->u.rsa.e_buf);
 	ctx->u.rsa.e_buf = NULL;
 	ctx->u.rsa.e_len = 0;
-	kzfree(ctx->u.rsa.n_buf);
+	kfree_sensitive(ctx->u.rsa.n_buf);
 	ctx->u.rsa.n_buf = NULL;
 	ctx->u.rsa.n_len = 0;
-	kzfree(ctx->u.rsa.d_buf);
+	kfree_sensitive(ctx->u.rsa.d_buf);
 	ctx->u.rsa.d_buf = NULL;
 	ctx->u.rsa.d_len = 0;
 }
diff --git a/drivers/crypto/ccree/cc_aead.c b/drivers/crypto/ccree/cc_aead.c
index 1cf51edbc4b9..35794c7271fb 100644
--- a/drivers/crypto/ccree/cc_aead.c
+++ b/drivers/crypto/ccree/cc_aead.c
@@ -448,7 +448,7 @@ static int cc_get_plain_hmac_key(struct crypto_aead *tfm, const u8 *authkey,
 		if (dma_mapping_error(dev, key_dma_addr)) {
 			dev_err(dev, "Mapping key va=0x%p len=%u for DMA failed\n",
 				key, keylen);
-			kzfree(key);
+			kfree_sensitive(key);
 			return -ENOMEM;
 		}
 		if (keylen > blocksize) {
@@ -533,7 +533,7 @@ static int cc_get_plain_hmac_key(struct crypto_aead *tfm, const u8 *authkey,
 	if (key_dma_addr)
 		dma_unmap_single(dev, key_dma_addr, keylen, DMA_TO_DEVICE);
 
-	kzfree(key);
+	kfree_sensitive(key);
 
 	return rc;
 }
diff --git a/drivers/crypto/ccree/cc_buffer_mgr.c b/drivers/crypto/ccree/cc_buffer_mgr.c
index b2bd093e7013..a5e041d9d2cf 100644
--- a/drivers/crypto/ccree/cc_buffer_mgr.c
+++ b/drivers/crypto/ccree/cc_buffer_mgr.c
@@ -488,7 +488,7 @@ void cc_unmap_aead_request(struct device *dev, struct aead_request *req)
 	if (areq_ctx->gen_ctx.iv_dma_addr) {
 		dma_unmap_single(dev, areq_ctx->gen_ctx.iv_dma_addr,
 				 hw_iv_size, DMA_BIDIRECTIONAL);
-		kzfree(areq_ctx->gen_ctx.iv);
+		kfree_sensitive(areq_ctx->gen_ctx.iv);
 	}
 
 	/* Release pool */
@@ -559,7 +559,7 @@ static int cc_aead_chain_iv(struct cc_drvdata *drvdata,
 	if (dma_mapping_error(dev, areq_ctx->gen_ctx.iv_dma_addr)) {
 		dev_err(dev, "Mapping iv %u B at va=%pK for DMA failed\n",
 			hw_iv_size, req->iv);
-		kzfree(areq_ctx->gen_ctx.iv);
+		kfree_sensitive(areq_ctx->gen_ctx.iv);
 		areq_ctx->gen_ctx.iv = NULL;
 		rc = -ENOMEM;
 		goto chain_iv_exit;
diff --git a/drivers/crypto/ccree/cc_cipher.c b/drivers/crypto/ccree/cc_cipher.c
index a84335328f37..f380a4b5e32b 100644
--- a/drivers/crypto/ccree/cc_cipher.c
+++ b/drivers/crypto/ccree/cc_cipher.c
@@ -229,7 +229,7 @@ static void cc_cipher_exit(struct crypto_tfm *tfm)
 		&ctx_p->user.key_dma_addr);
 
 	/* Free key buffer in context */
-	kzfree(ctx_p->user.key);
+	kfree_sensitive(ctx_p->user.key);
 	dev_dbg(dev, "Free key buffer in context. key=@%p\n", ctx_p->user.key);
 }
 
@@ -828,7 +828,7 @@ static void cc_cipher_complete(struct device *dev, void *cc_req, int err)
 		/* Not a BACKLOG notification */
 		cc_unmap_cipher_request(dev, req_ctx, ivsize, src, dst);
 		memcpy(req->iv, req_ctx->iv, ivsize);
-		kzfree(req_ctx->iv);
+		kfree_sensitive(req_ctx->iv);
 	}
 
 	skcipher_request_complete(req, err);
@@ -930,7 +930,7 @@ static int cc_cipher_process(struct skcipher_request *req,
 
 exit_process:
 	if (rc != -EINPROGRESS && rc != -EBUSY) {
-		kzfree(req_ctx->iv);
+		kfree_sensitive(req_ctx->iv);
 	}
 
 	return rc;
diff --git a/drivers/crypto/ccree/cc_hash.c b/drivers/crypto/ccree/cc_hash.c
index d5310783af15..683c9a430e11 100644
--- a/drivers/crypto/ccree/cc_hash.c
+++ b/drivers/crypto/ccree/cc_hash.c
@@ -764,7 +764,7 @@ static int cc_hash_setkey(struct crypto_ahash *ahash, const u8 *key,
 		if (dma_mapping_error(dev, ctx->key_params.key_dma_addr)) {
 			dev_err(dev, "Mapping key va=0x%p len=%u for DMA failed\n",
 				ctx->key_params.key, keylen);
-			kzfree(ctx->key_params.key);
+			kfree_sensitive(ctx->key_params.key);
 			return -ENOMEM;
 		}
 		dev_dbg(dev, "mapping key-buffer: key_dma_addr=%pad keylen=%u\n",
@@ -913,7 +913,7 @@ static int cc_hash_setkey(struct crypto_ahash *ahash, const u8 *key,
 			&ctx->key_params.key_dma_addr, ctx->key_params.keylen);
 	}
 
-	kzfree(ctx->key_params.key);
+	kfree_sensitive(ctx->key_params.key);
 
 	return rc;
 }
@@ -950,7 +950,7 @@ static int cc_xcbc_setkey(struct crypto_ahash *ahash,
 	if (dma_mapping_error(dev, ctx->key_params.key_dma_addr)) {
 		dev_err(dev, "Mapping key va=0x%p len=%u for DMA failed\n",
 			key, keylen);
-		kzfree(ctx->key_params.key);
+		kfree_sensitive(ctx->key_params.key);
 		return -ENOMEM;
 	}
 	dev_dbg(dev, "mapping key-buffer: key_dma_addr=%pad keylen=%u\n",
@@ -999,7 +999,7 @@ static int cc_xcbc_setkey(struct crypto_ahash *ahash,
 	dev_dbg(dev, "Unmapped key-buffer: key_dma_addr=%pad keylen=%u\n",
 		&ctx->key_params.key_dma_addr, ctx->key_params.keylen);
 
-	kzfree(ctx->key_params.key);
+	kfree_sensitive(ctx->key_params.key);
 
 	return rc;
 }
diff --git a/drivers/crypto/ccree/cc_request_mgr.c b/drivers/crypto/ccree/cc_request_mgr.c
index 1d7649ecf44e..33fb27745d52 100644
--- a/drivers/crypto/ccree/cc_request_mgr.c
+++ b/drivers/crypto/ccree/cc_request_mgr.c
@@ -107,7 +107,7 @@ void cc_req_mgr_fini(struct cc_drvdata *drvdata)
 	/* Kill tasklet */
 	tasklet_kill(&req_mgr_h->comptask);
 #endif
-	kzfree(req_mgr_h);
+	kfree_sensitive(req_mgr_h);
 	drvdata->request_mgr_handle = NULL;
 }
 
diff --git a/drivers/crypto/marvell/cesa/hash.c b/drivers/crypto/marvell/cesa/hash.c
index b971284332b6..2fdd3d55ed08 100644
--- a/drivers/crypto/marvell/cesa/hash.c
+++ b/drivers/crypto/marvell/cesa/hash.c
@@ -1154,7 +1154,7 @@ static int mv_cesa_ahmac_pad_init(struct ahash_request *req,
 		}
 
 		/* Set the memory region to 0 to avoid any leak. */
-		kzfree(keydup);
+		kfree_sensitive(keydup);
 
 		if (ret)
 			return ret;
diff --git a/drivers/crypto/marvell/octeontx/otx_cptvf_main.c b/drivers/crypto/marvell/octeontx/otx_cptvf_main.c
index a91860b5dc77..ffd33121bb55 100644
--- a/drivers/crypto/marvell/octeontx/otx_cptvf_main.c
+++ b/drivers/crypto/marvell/octeontx/otx_cptvf_main.c
@@ -68,7 +68,7 @@ static void cleanup_worker_threads(struct otx_cptvf *cptvf)
 	for (i = 0; i < cptvf->num_queues; i++)
 		tasklet_kill(&cwqe_info->vq_wqe[i].twork);
 
-	kzfree(cwqe_info);
+	kfree_sensitive(cwqe_info);
 	cptvf->wqe_info = NULL;
 }
 
@@ -82,7 +82,7 @@ static void free_pending_queues(struct otx_cpt_pending_qinfo *pqinfo)
 			continue;
 
 		/* free single queue */
-		kzfree((queue->head));
+		kfree_sensitive((queue->head));
 		queue->front = 0;
 		queue->rear = 0;
 		queue->qlen = 0;
@@ -176,7 +176,7 @@ static void free_command_queues(struct otx_cptvf *cptvf,
 			chunk->head = NULL;
 			chunk->dma_addr = 0;
 			list_del(&chunk->nextchunk);
-			kzfree(chunk);
+			kfree_sensitive(chunk);
 		}
 		queue->num_chunks = 0;
 		queue->idx = 0;
diff --git a/drivers/crypto/marvell/octeontx/otx_cptvf_reqmgr.h b/drivers/crypto/marvell/octeontx/otx_cptvf_reqmgr.h
index a4c9ff730b13..cfaaf8e2f9c2 100644
--- a/drivers/crypto/marvell/octeontx/otx_cptvf_reqmgr.h
+++ b/drivers/crypto/marvell/octeontx/otx_cptvf_reqmgr.h
@@ -215,7 +215,7 @@ static inline void do_request_cleanup(struct pci_dev *pdev,
 						 DMA_BIDIRECTIONAL);
 		}
 	}
-	kzfree(info);
+	kfree_sensitive(info);
 }
 
 struct otx_cptvf_wqe;
diff --git a/drivers/crypto/mediatek/mtk-aes.c b/drivers/crypto/mediatek/mtk-aes.c
index 78d660d963e2..5c71f85da7e2 100644
--- a/drivers/crypto/mediatek/mtk-aes.c
+++ b/drivers/crypto/mediatek/mtk-aes.c
@@ -1057,7 +1057,7 @@ static int mtk_aes_gcm_setkey(struct crypto_aead *aead, const u8 *key,
 	mtk_aes_write_state_be(ctx->key + ctx->keylen, data->hash,
 			       AES_BLOCK_SIZE);
 out:
-	kzfree(data);
+	kfree_sensitive(data);
 	return err;
 }
 
diff --git a/drivers/crypto/nx/nx.c b/drivers/crypto/nx/nx.c
index f03c238f5a31..40882d6d52c1 100644
--- a/drivers/crypto/nx/nx.c
+++ b/drivers/crypto/nx/nx.c
@@ -746,7 +746,7 @@ void nx_crypto_ctx_exit(struct crypto_tfm *tfm)
 {
 	struct nx_crypto_ctx *nx_ctx = crypto_tfm_ctx(tfm);
 
-	kzfree(nx_ctx->kmem);
+	kfree_sensitive(nx_ctx->kmem);
 	nx_ctx->csbcpb = NULL;
 	nx_ctx->csbcpb_aead = NULL;
 	nx_ctx->in_sg = NULL;
@@ -762,7 +762,7 @@ void nx_crypto_ctx_aead_exit(struct crypto_aead *tfm)
 {
 	struct nx_crypto_ctx *nx_ctx = crypto_aead_ctx(tfm);
 
-	kzfree(nx_ctx->kmem);
+	kfree_sensitive(nx_ctx->kmem);
 }
 
 static int nx_probe(struct vio_dev *viodev, const struct vio_device_id *id)
diff --git a/drivers/crypto/virtio/virtio_crypto_algs.c b/drivers/crypto/virtio/virtio_crypto_algs.c
index fd045e64972a..bc575d63dee6 100644
--- a/drivers/crypto/virtio/virtio_crypto_algs.c
+++ b/drivers/crypto/virtio/virtio_crypto_algs.c
@@ -167,7 +167,7 @@ static int virtio_crypto_alg_skcipher_init_session(
 				num_in, vcrypto, GFP_ATOMIC);
 	if (err < 0) {
 		spin_unlock(&vcrypto->ctrl_lock);
-		kzfree(cipher_key);
+		kfree_sensitive(cipher_key);
 		return err;
 	}
 	virtqueue_kick(vcrypto->ctrl_vq);
@@ -184,7 +184,7 @@ static int virtio_crypto_alg_skcipher_init_session(
 		spin_unlock(&vcrypto->ctrl_lock);
 		pr_err("virtio_crypto: Create session failed status: %u\n",
 			le32_to_cpu(vcrypto->input.status));
-		kzfree(cipher_key);
+		kfree_sensitive(cipher_key);
 		return -EINVAL;
 	}
 
@@ -197,7 +197,7 @@ static int virtio_crypto_alg_skcipher_init_session(
 
 	spin_unlock(&vcrypto->ctrl_lock);
 
-	kzfree(cipher_key);
+	kfree_sensitive(cipher_key);
 	return 0;
 }
 
@@ -466,9 +466,9 @@ __virtio_crypto_skcipher_do_req(struct virtio_crypto_sym_request *vc_sym_req,
 	return 0;
 
 free_iv:
-	kzfree(iv);
+	kfree_sensitive(iv);
 free:
-	kzfree(req_data);
+	kfree_sensitive(req_data);
 	kfree(sgs);
 	return err;
 }
@@ -579,7 +579,7 @@ static void virtio_crypto_skcipher_finalize_req(
 					 AES_BLOCK_SIZE, 0);
 	crypto_finalize_skcipher_request(vc_sym_req->base.dataq->engine,
 					   req, err);
-	kzfree(vc_sym_req->iv);
+	kfree_sensitive(vc_sym_req->iv);
 	virtcrypto_clear_request(&vc_sym_req->base);
 }
 
diff --git a/drivers/crypto/virtio/virtio_crypto_core.c b/drivers/crypto/virtio/virtio_crypto_core.c
index c8a962c62663..ba8a19c72391 100644
--- a/drivers/crypto/virtio/virtio_crypto_core.c
+++ b/drivers/crypto/virtio/virtio_crypto_core.c
@@ -17,7 +17,7 @@ void
 virtcrypto_clear_request(struct virtio_crypto_request *vc_req)
 {
 	if (vc_req) {
-		kzfree(vc_req->req_data);
+		kfree_sensitive(vc_req->req_data);
 		kfree(vc_req->sgs);
 	}
 }
diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c
index 3df90daba89e..2423eade2ae6 100644
--- a/drivers/md/dm-crypt.c
+++ b/drivers/md/dm-crypt.c
@@ -405,7 +405,7 @@ static void crypt_iv_lmk_dtr(struct crypt_config *cc)
 		crypto_free_shash(lmk->hash_tfm);
 	lmk->hash_tfm = NULL;
 
-	kzfree(lmk->seed);
+	kfree_sensitive(lmk->seed);
 	lmk->seed = NULL;
 }
 
@@ -556,9 +556,9 @@ static void crypt_iv_tcw_dtr(struct crypt_config *cc)
 {
 	struct iv_tcw_private *tcw = &cc->iv_gen_private.tcw;
 
-	kzfree(tcw->iv_seed);
+	kfree_sensitive(tcw->iv_seed);
 	tcw->iv_seed = NULL;
-	kzfree(tcw->whitening);
+	kfree_sensitive(tcw->whitening);
 	tcw->whitening = NULL;
 
 	if (tcw->crc32_tfm && !IS_ERR(tcw->crc32_tfm))
@@ -992,8 +992,8 @@ static int crypt_iv_elephant(struct crypt_config *cc, struct dm_crypt_request *d
 
 	kunmap_atomic(data);
 out:
-	kzfree(ks);
-	kzfree(es);
+	kfree_sensitive(ks);
+	kfree_sensitive(es);
 	skcipher_request_free(req);
 	return r;
 }
@@ -2247,7 +2247,7 @@ static int crypt_set_keyring_key(struct crypt_config *cc, const char *key_string
 	key = request_key(key_string[0] == 'l' ? &key_type_logon : &key_type_user,
 			  key_desc + 1, NULL);
 	if (IS_ERR(key)) {
-		kzfree(new_key_string);
+		kfree_sensitive(new_key_string);
 		return PTR_ERR(key);
 	}
 
@@ -2257,14 +2257,14 @@ static int crypt_set_keyring_key(struct crypt_config *cc, const char *key_string
 	if (!ukp) {
 		up_read(&key->sem);
 		key_put(key);
-		kzfree(new_key_string);
+		kfree_sensitive(new_key_string);
 		return -EKEYREVOKED;
 	}
 
 	if (cc->key_size != ukp->datalen) {
 		up_read(&key->sem);
 		key_put(key);
-		kzfree(new_key_string);
+		kfree_sensitive(new_key_string);
 		return -EINVAL;
 	}
 
@@ -2280,10 +2280,10 @@ static int crypt_set_keyring_key(struct crypt_config *cc, const char *key_string
 
 	if (!ret) {
 		set_bit(DM_CRYPT_KEY_VALID, &cc->flags);
-		kzfree(cc->key_string);
+		kfree_sensitive(cc->key_string);
 		cc->key_string = new_key_string;
 	} else
-		kzfree(new_key_string);
+		kfree_sensitive(new_key_string);
 
 	return ret;
 }
@@ -2344,7 +2344,7 @@ static int crypt_set_key(struct crypt_config *cc, char *key)
 	clear_bit(DM_CRYPT_KEY_VALID, &cc->flags);
 
 	/* wipe references to any kernel keyring key */
-	kzfree(cc->key_string);
+	kfree_sensitive(cc->key_string);
 	cc->key_string = NULL;
 
 	/* Decode key from its hex representation. */
@@ -2376,7 +2376,7 @@ static int crypt_wipe_key(struct crypt_config *cc)
 			return r;
 	}
 
-	kzfree(cc->key_string);
+	kfree_sensitive(cc->key_string);
 	cc->key_string = NULL;
 	r = crypt_setkey(cc);
 	memset(&cc->key, 0, cc->key_size * sizeof(u8));
@@ -2455,15 +2455,15 @@ static void crypt_dtr(struct dm_target *ti)
 	if (cc->dev)
 		dm_put_device(ti, cc->dev);
 
-	kzfree(cc->cipher_string);
-	kzfree(cc->key_string);
-	kzfree(cc->cipher_auth);
-	kzfree(cc->authenc_key);
+	kfree_sensitive(cc->cipher_string);
+	kfree_sensitive(cc->key_string);
+	kfree_sensitive(cc->cipher_auth);
+	kfree_sensitive(cc->authenc_key);
 
 	mutex_destroy(&cc->bio_alloc_lock);
 
 	/* Must zero key material before freeing */
-	kzfree(cc);
+	kfree_sensitive(cc);
 
 	spin_lock(&dm_crypt_clients_lock);
 	WARN_ON(!dm_crypt_clients_n);
diff --git a/drivers/md/dm-integrity.c b/drivers/md/dm-integrity.c
index 4094c47eca7f..d08ef3c0d148 100644
--- a/drivers/md/dm-integrity.c
+++ b/drivers/md/dm-integrity.c
@@ -3409,8 +3409,8 @@ static struct scatterlist **dm_integrity_alloc_journal_scatterlist(struct dm_int
 
 static void free_alg(struct alg_spec *a)
 {
-	kzfree(a->alg_string);
-	kzfree(a->key);
+	kfree_sensitive(a->alg_string);
+	kfree_sensitive(a->key);
 	memset(a, 0, sizeof *a);
 }
 
@@ -4341,7 +4341,7 @@ static void dm_integrity_dtr(struct dm_target *ti)
 		for (i = 0; i < ic->journal_sections; i++) {
 			struct skcipher_request *req = ic->sk_requests[i];
 			if (req) {
-				kzfree(req->iv);
+				kfree_sensitive(req->iv);
 				skcipher_request_free(req);
 			}
 		}
diff --git a/drivers/misc/ibmvmc.c b/drivers/misc/ibmvmc.c
index 2ed23c99f59f..beda69075a97 100644
--- a/drivers/misc/ibmvmc.c
+++ b/drivers/misc/ibmvmc.c
@@ -286,7 +286,7 @@ static void *alloc_dma_buffer(struct vio_dev *vdev, size_t size,
 
 	if (dma_mapping_error(&vdev->dev, *dma_handle)) {
 		*dma_handle = 0;
-		kzfree(buffer);
+		kfree_sensitive(buffer);
 		return NULL;
 	}
 
@@ -310,7 +310,7 @@ static void free_dma_buffer(struct vio_dev *vdev, size_t size, void *vaddr,
 	dma_unmap_single(&vdev->dev, dma_handle, size, DMA_BIDIRECTIONAL);
 
 	/* deallocate memory */
-	kzfree(vaddr);
+	kfree_sensitive(vaddr);
 }
 
 /**
@@ -883,7 +883,7 @@ static int ibmvmc_close(struct inode *inode, struct file *file)
 		spin_unlock_irqrestore(&hmc->lock, flags);
 	}
 
-	kzfree(session);
+	kfree_sensitive(session);
 
 	return rc;
 }
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c
index 7f24fcb4f96a..965ada2e9d24 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c
@@ -132,7 +132,7 @@ static void hclge_free_vector_ring_chain(struct hnae3_ring_chain_node *head)
 
 	while (chain) {
 		chain_tmp = chain->next;
-		kzfree(chain);
+		kfree_sensitive(chain);
 		chain = chain_tmp;
 	}
 }
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c
index 113f6087c7c9..e567f4ab8a79 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c
@@ -960,9 +960,9 @@ int ixgbe_ipsec_vf_add_sa(struct ixgbe_adapter *adapter, u32 *msgbuf, u32 vf)
 	return 0;
 
 err_aead:
-	kzfree(xs->aead);
+	kfree_sensitive(xs->aead);
 err_xs:
-	kzfree(xs);
+	kfree_sensitive(xs);
 err_out:
 	msgbuf[1] = err;
 	return err;
@@ -1047,7 +1047,7 @@ int ixgbe_ipsec_vf_del_sa(struct ixgbe_adapter *adapter, u32 *msgbuf, u32 vf)
 	ixgbe_ipsec_del_sa(xs);
 
 	/* remove the xs that was made-up in the add request */
-	kzfree(xs);
+	kfree_sensitive(xs);
 
 	return 0;
 }
diff --git a/drivers/net/ppp/ppp_mppe.c b/drivers/net/ppp/ppp_mppe.c
index de3b57d09d0c..208f6e24f37c 100644
--- a/drivers/net/ppp/ppp_mppe.c
+++ b/drivers/net/ppp/ppp_mppe.c
@@ -222,7 +222,7 @@ static void *mppe_alloc(unsigned char *options, int optlen)
 	kfree(state->sha1_digest);
 	if (state->sha1) {
 		crypto_free_shash(state->sha1->tfm);
-		kzfree(state->sha1);
+		kfree_sensitive(state->sha1);
 	}
 	kfree(state);
 out:
@@ -238,8 +238,8 @@ static void mppe_free(void *arg)
 	if (state) {
 		kfree(state->sha1_digest);
 		crypto_free_shash(state->sha1->tfm);
-		kzfree(state->sha1);
-		kzfree(state);
+		kfree_sensitive(state->sha1);
+		kfree_sensitive(state);
 	}
 }
 
diff --git a/drivers/net/wireguard/noise.c b/drivers/net/wireguard/noise.c
index 708dc61c974f..596eb3be2d9e 100644
--- a/drivers/net/wireguard/noise.c
+++ b/drivers/net/wireguard/noise.c
@@ -113,7 +113,7 @@ static struct noise_keypair *keypair_create(struct wg_peer *peer)
 
 static void keypair_free_rcu(struct rcu_head *rcu)
 {
-	kzfree(container_of(rcu, struct noise_keypair, rcu));
+	kfree_sensitive(container_of(rcu, struct noise_keypair, rcu));
 }
 
 static void keypair_free_kref(struct kref *kref)
@@ -825,7 +825,7 @@ bool wg_noise_handshake_begin_session(struct noise_handshake *handshake,
 			handshake->entry.peer->device->index_hashtable,
 			&handshake->entry, &new_keypair->entry);
 	} else {
-		kzfree(new_keypair);
+		kfree_sensitive(new_keypair);
 	}
 	rcu_read_unlock_bh();
 
diff --git a/drivers/net/wireguard/peer.c b/drivers/net/wireguard/peer.c
index 1d634bd3038f..b3b6370e6b95 100644
--- a/drivers/net/wireguard/peer.c
+++ b/drivers/net/wireguard/peer.c
@@ -203,7 +203,7 @@ static void rcu_release(struct rcu_head *rcu)
 	/* The final zeroing takes care of clearing any remaining handshake key
 	 * material and other potentially sensitive information.
 	 */
-	kzfree(peer);
+	kfree_sensitive(peer);
 }
 
 static void kref_release(struct kref *refcount)
diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/rx.c b/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
index 8c29071cb415..82b449c249a4 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
@@ -1369,7 +1369,7 @@ static void iwl_pcie_rx_handle_rb(struct iwl_trans *trans,
 					   &rxcb, rxq->id);
 
 		if (reclaim) {
-			kzfree(txq->entries[cmd_index].free_buf);
+			kfree_sensitive(txq->entries[cmd_index].free_buf);
 			txq->entries[cmd_index].free_buf = NULL;
 		}
 
diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/tx-gen2.c b/drivers/net/wireless/intel/iwlwifi/pcie/tx-gen2.c
index 86fc00167817..022f7a069295 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/tx-gen2.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/tx-gen2.c
@@ -1024,7 +1024,7 @@ static int iwl_pcie_gen2_enqueue_hcmd(struct iwl_trans *trans,
 	BUILD_BUG_ON(IWL_TFH_NUM_TBS > sizeof(out_meta->tbs) * BITS_PER_BYTE);
 	out_meta->flags = cmd->flags;
 	if (WARN_ON_ONCE(txq->entries[idx].free_buf))
-		kzfree(txq->entries[idx].free_buf);
+		kfree_sensitive(txq->entries[idx].free_buf);
 	txq->entries[idx].free_buf = dup_buf;
 
 	trace_iwlwifi_dev_hcmd(trans->dev, cmd, cmd_size, &out_cmd->hdr_wide);
@@ -1254,8 +1254,8 @@ static void iwl_pcie_gen2_txq_free(struct iwl_trans *trans, int txq_id)
 	/* De-alloc array of command/tx buffers */
 	if (txq_id == trans_pcie->cmd_queue)
 		for (i = 0; i < txq->n_window; i++) {
-			kzfree(txq->entries[i].cmd);
-			kzfree(txq->entries[i].free_buf);
+			kfree_sensitive(txq->entries[i].cmd);
+			kfree_sensitive(txq->entries[i].free_buf);
 		}
 	del_timer_sync(&txq->stuck_timer);
 
diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/tx.c b/drivers/net/wireless/intel/iwlwifi/pcie/tx.c
index 4582d418ba4d..aa8277df2f17 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/tx.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/tx.c
@@ -724,8 +724,8 @@ static void iwl_pcie_txq_free(struct iwl_trans *trans, int txq_id)
 	/* De-alloc array of command/tx buffers */
 	if (txq_id == trans_pcie->cmd_queue)
 		for (i = 0; i < txq->n_window; i++) {
-			kzfree(txq->entries[i].cmd);
-			kzfree(txq->entries[i].free_buf);
+			kfree_sensitive(txq->entries[i].cmd);
+			kfree_sensitive(txq->entries[i].free_buf);
 		}
 
 	/* De-alloc circular buffer of TFDs */
@@ -1768,7 +1768,7 @@ static int iwl_pcie_enqueue_hcmd(struct iwl_trans *trans,
 	BUILD_BUG_ON(IWL_TFH_NUM_TBS > sizeof(out_meta->tbs) * BITS_PER_BYTE);
 	out_meta->flags = cmd->flags;
 	if (WARN_ON_ONCE(txq->entries[idx].free_buf))
-		kzfree(txq->entries[idx].free_buf);
+		kfree_sensitive(txq->entries[idx].free_buf);
 	txq->entries[idx].free_buf = dup_buf;
 
 	trace_iwlwifi_dev_hcmd(trans->dev, cmd, cmd_size, &out_cmd->hdr_wide);
diff --git a/drivers/net/wireless/intersil/orinoco/wext.c b/drivers/net/wireless/intersil/orinoco/wext.c
index 1d4dae422106..7b6c4ae8ddb3 100644
--- a/drivers/net/wireless/intersil/orinoco/wext.c
+++ b/drivers/net/wireless/intersil/orinoco/wext.c
@@ -31,8 +31,8 @@ static int orinoco_set_key(struct orinoco_private *priv, int index,
 			   enum orinoco_alg alg, const u8 *key, int key_len,
 			   const u8 *seq, int seq_len)
 {
-	kzfree(priv->keys[index].key);
-	kzfree(priv->keys[index].seq);
+	kfree_sensitive(priv->keys[index].key);
+	kfree_sensitive(priv->keys[index].seq);
 
 	if (key_len) {
 		priv->keys[index].key = kzalloc(key_len, GFP_ATOMIC);
diff --git a/drivers/s390/crypto/ap_bus.h b/drivers/s390/crypto/ap_bus.h
index 8e8e37b6c0ee..99125e29b2c6 100644
--- a/drivers/s390/crypto/ap_bus.h
+++ b/drivers/s390/crypto/ap_bus.h
@@ -219,8 +219,8 @@ static inline void ap_init_message(struct ap_message *ap_msg)
  */
 static inline void ap_release_message(struct ap_message *ap_msg)
 {
-	kzfree(ap_msg->message);
-	kzfree(ap_msg->private);
+	kfree_sensitive(ap_msg->message);
+	kfree_sensitive(ap_msg->private);
 }
 
 #define for_each_ap_card(_ac) \
diff --git a/drivers/staging/ks7010/ks_hostif.c b/drivers/staging/ks7010/ks_hostif.c
index 2666f9e30c15..d70b671b06aa 100644
--- a/drivers/staging/ks7010/ks_hostif.c
+++ b/drivers/staging/ks7010/ks_hostif.c
@@ -246,7 +246,7 @@ michael_mic(u8 *key, u8 *data, unsigned int len, u8 priority, u8 *result)
 	ret = crypto_shash_finup(desc, data + 12, len - 12, result);
 
 err_free_desc:
-	kzfree(desc);
+	kfree_sensitive(desc);
 
 err_free_tfm:
 	crypto_free_shash(tfm);
diff --git a/drivers/staging/rtl8723bs/core/rtw_security.c b/drivers/staging/rtl8723bs/core/rtw_security.c
index 5ebf691bd743..9d7eb027a213 100644
--- a/drivers/staging/rtl8723bs/core/rtw_security.c
+++ b/drivers/staging/rtl8723bs/core/rtw_security.c
@@ -2251,7 +2251,7 @@ static void gf_mulx(u8 *pad)
 
 static void aes_encrypt_deinit(void *ctx)
 {
-	kzfree(ctx);
+	kfree_sensitive(ctx);
 }
 
 
diff --git a/drivers/staging/wlan-ng/p80211netdev.c b/drivers/staging/wlan-ng/p80211netdev.c
index b809c0015c0c..7b091c5a2984 100644
--- a/drivers/staging/wlan-ng/p80211netdev.c
+++ b/drivers/staging/wlan-ng/p80211netdev.c
@@ -429,7 +429,7 @@ static netdev_tx_t p80211knetdev_hard_start_xmit(struct sk_buff *skb,
 failed:
 	/* Free up the WEP buffer if it's not the same as the skb */
 	if ((p80211_wep.data) && (p80211_wep.data != skb->data))
-		kzfree(p80211_wep.data);
+		kfree_sensitive(p80211_wep.data);
 
 	/* we always free the skb here, never in a lower level. */
 	if (!result)
diff --git a/drivers/target/iscsi/iscsi_target_auth.c b/drivers/target/iscsi/iscsi_target_auth.c
index 0e54627d9aa8..62d912b79c61 100644
--- a/drivers/target/iscsi/iscsi_target_auth.c
+++ b/drivers/target/iscsi/iscsi_target_auth.c
@@ -484,7 +484,7 @@ static int chap_server_compute_hash(
 	pr_debug("[server] Sending CHAP_R=0x%s\n", response);
 	auth_ret = 0;
 out:
-	kzfree(desc);
+	kfree_sensitive(desc);
 	if (tfm)
 		crypto_free_shash(tfm);
 	kfree(initiatorchg);
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index 40b729dce91c..eab3f8510426 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -2691,7 +2691,7 @@ static int btrfs_ioctl_get_subvol_info(struct file *file, void __user *argp)
 	btrfs_put_root(root);
 out_free:
 	btrfs_free_path(path);
-	kzfree(subvol_info);
+	kfree_sensitive(subvol_info);
 	return ret;
 }
 
diff --git a/fs/cifs/cifsencrypt.c b/fs/cifs/cifsencrypt.c
index 97b7497c13ef..c6baca36b74c 100644
--- a/fs/cifs/cifsencrypt.c
+++ b/fs/cifs/cifsencrypt.c
@@ -797,7 +797,7 @@ calc_seckey(struct cifs_ses *ses)
 	ses->auth_key.len = CIFS_SESS_KEY_SIZE;
 
 	memzero_explicit(sec_key, CIFS_SESS_KEY_SIZE);
-	kzfree(ctx_arc4);
+	kfree_sensitive(ctx_arc4);
 	return 0;
 }
 
diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c
index 95b3ab0ca8c0..cdeac9d66e26 100644
--- a/fs/cifs/connect.c
+++ b/fs/cifs/connect.c
@@ -2177,7 +2177,7 @@ cifs_parse_mount_options(const char *mountdata, const char *devname,
 			tmp_end++;
 			if (!(tmp_end < end && tmp_end[1] == delim)) {
 				/* No it is not. Set the password to NULL */
-				kzfree(vol->password);
+				kfree_sensitive(vol->password);
 				vol->password = NULL;
 				break;
 			}
@@ -2215,7 +2215,7 @@ cifs_parse_mount_options(const char *mountdata, const char *devname,
 					options = end;
 			}
 
-			kzfree(vol->password);
+			kfree_sensitive(vol->password);
 			/* Now build new password string */
 			temp_len = strlen(value);
 			vol->password = kzalloc(temp_len+1, GFP_KERNEL);
@@ -3200,7 +3200,7 @@ cifs_set_cifscreds(struct smb_vol *vol, struct cifs_ses *ses)
 			rc = -ENOMEM;
 			kfree(vol->username);
 			vol->username = NULL;
-			kzfree(vol->password);
+			kfree_sensitive(vol->password);
 			vol->password = NULL;
 			goto out_key_put;
 		}
@@ -4212,7 +4212,7 @@ void
 cifs_cleanup_volume_info_contents(struct smb_vol *volume_info)
 {
 	kfree(volume_info->username);
-	kzfree(volume_info->password);
+	kfree_sensitive(volume_info->password);
 	kfree(volume_info->UNC);
 	kfree(volume_info->domainname);
 	kfree(volume_info->iocharset);
@@ -5337,7 +5337,7 @@ cifs_construct_tcon(struct cifs_sb_info *cifs_sb, kuid_t fsuid)
 
 out:
 	kfree(vol_info->username);
-	kzfree(vol_info->password);
+	kfree_sensitive(vol_info->password);
 	kfree(vol_info);
 
 	return tcon;
diff --git a/fs/cifs/dfs_cache.c b/fs/cifs/dfs_cache.c
index a67f88bf7ae1..a0223b47dc1b 100644
--- a/fs/cifs/dfs_cache.c
+++ b/fs/cifs/dfs_cache.c
@@ -1131,7 +1131,7 @@ static int dup_vol(struct smb_vol *vol, struct smb_vol *new)
 err_free_unc:
 	kfree(new->UNC);
 err_free_password:
-	kzfree(new->password);
+	kfree_sensitive(new->password);
 err_free_username:
 	kfree(new->username);
 	kfree(new);
diff --git a/fs/cifs/misc.c b/fs/cifs/misc.c
index a456febd4109..503810e9cb76 100644
--- a/fs/cifs/misc.c
+++ b/fs/cifs/misc.c
@@ -100,12 +100,12 @@ sesInfoFree(struct cifs_ses *buf_to_free)
 	kfree(buf_to_free->serverOS);
 	kfree(buf_to_free->serverDomain);
 	kfree(buf_to_free->serverNOS);
-	kzfree(buf_to_free->password);
+	kfree_sensitive(buf_to_free->password);
 	kfree(buf_to_free->user_name);
 	kfree(buf_to_free->domainName);
-	kzfree(buf_to_free->auth_key.response);
+	kfree_sensitive(buf_to_free->auth_key.response);
 	kfree(buf_to_free->iface_list);
-	kzfree(buf_to_free);
+	kfree_sensitive(buf_to_free);
 }
 
 struct cifs_tcon *
@@ -145,7 +145,7 @@ tconInfoFree(struct cifs_tcon *buf_to_free)
 	}
 	atomic_dec(&tconInfoAllocCount);
 	kfree(buf_to_free->nativeFileSystem);
-	kzfree(buf_to_free->password);
+	kfree_sensitive(buf_to_free->password);
 	kfree(buf_to_free->crfid.fid);
 #ifdef CONFIG_CIFS_DFS_UPCALL
 	kfree(buf_to_free->dfs_path);
diff --git a/fs/crypto/keyring.c b/fs/crypto/keyring.c
index ab41b25d4fa1..41460c6331e4 100644
--- a/fs/crypto/keyring.c
+++ b/fs/crypto/keyring.c
@@ -49,7 +49,7 @@ static void free_master_key(struct fscrypt_master_key *mk)
 	}
 
 	key_put(mk->mk_users);
-	kzfree(mk);
+	kfree_sensitive(mk);
 }
 
 static inline bool valid_key_spec(const struct fscrypt_key_specifier *spec)
@@ -491,7 +491,7 @@ static int fscrypt_provisioning_key_preparse(struct key_preparsed_payload *prep)
 static void fscrypt_provisioning_key_free_preparse(
 					struct key_preparsed_payload *prep)
 {
-	kzfree(prep->payload.data[0]);
+	kfree_sensitive(prep->payload.data[0]);
 }
 
 static void fscrypt_provisioning_key_describe(const struct key *key,
@@ -508,7 +508,7 @@ static void fscrypt_provisioning_key_describe(const struct key *key,
 
 static void fscrypt_provisioning_key_destroy(struct key *key)
 {
-	kzfree(key->payload.data[0]);
+	kfree_sensitive(key->payload.data[0]);
 }
 
 static struct key_type key_type_fscrypt_provisioning = {
diff --git a/fs/crypto/keysetup_v1.c b/fs/crypto/keysetup_v1.c
index 801b48c0cd7f..c8a930f8faf2 100644
--- a/fs/crypto/keysetup_v1.c
+++ b/fs/crypto/keysetup_v1.c
@@ -155,7 +155,7 @@ static void free_direct_key(struct fscrypt_direct_key *dk)
 {
 	if (dk) {
 		crypto_free_skcipher(dk->dk_ctfm);
-		kzfree(dk);
+		kfree_sensitive(dk);
 	}
 }
 
@@ -285,7 +285,7 @@ static int setup_v1_file_key_derived(struct fscrypt_info *ci,
 
 	err = fscrypt_set_per_file_enc_key(ci, derived_key);
 out:
-	kzfree(derived_key);
+	kfree_sensitive(derived_key);
 	return err;
 }
 
diff --git a/fs/ecryptfs/keystore.c b/fs/ecryptfs/keystore.c
index af3eb02bbca1..f6a17d259db7 100644
--- a/fs/ecryptfs/keystore.c
+++ b/fs/ecryptfs/keystore.c
@@ -838,7 +838,7 @@ ecryptfs_write_tag_70_packet(char *dest, size_t *remaining_bytes,
 out_release_free_unlock:
 	crypto_free_shash(s->hash_tfm);
 out_free_unlock:
-	kzfree(s->block_aligned_filename);
+	kfree_sensitive(s->block_aligned_filename);
 out_unlock:
 	mutex_unlock(s->tfm_mutex);
 out:
@@ -847,7 +847,7 @@ ecryptfs_write_tag_70_packet(char *dest, size_t *remaining_bytes,
 		key_put(auth_tok_key);
 	}
 	skcipher_request_free(s->skcipher_req);
-	kzfree(s->hash_desc);
+	kfree_sensitive(s->hash_desc);
 	kfree(s);
 	return rc;
 }
diff --git a/fs/ecryptfs/messaging.c b/fs/ecryptfs/messaging.c
index 8646ba76def3..c0dfd9647627 100644
--- a/fs/ecryptfs/messaging.c
+++ b/fs/ecryptfs/messaging.c
@@ -175,7 +175,7 @@ int ecryptfs_exorcise_daemon(struct ecryptfs_daemon *daemon)
 	}
 	hlist_del(&daemon->euid_chain);
 	mutex_unlock(&daemon->mux);
-	kzfree(daemon);
+	kfree_sensitive(daemon);
 out:
 	return rc;
 }
diff --git a/include/crypto/aead.h b/include/crypto/aead.h
index 62c68550aab6..c32a6f5664e9 100644
--- a/include/crypto/aead.h
+++ b/include/crypto/aead.h
@@ -425,7 +425,7 @@ static inline struct aead_request *aead_request_alloc(struct crypto_aead *tfm,
  */
 static inline void aead_request_free(struct aead_request *req)
 {
-	kzfree(req);
+	kfree_sensitive(req);
 }
 
 /**
diff --git a/include/crypto/akcipher.h b/include/crypto/akcipher.h
index 6924b091adec..1d3aa252caba 100644
--- a/include/crypto/akcipher.h
+++ b/include/crypto/akcipher.h
@@ -207,7 +207,7 @@ static inline struct akcipher_request *akcipher_request_alloc(
  */
 static inline void akcipher_request_free(struct akcipher_request *req)
 {
-	kzfree(req);
+	kfree_sensitive(req);
 }
 
 /**
diff --git a/include/crypto/gf128mul.h b/include/crypto/gf128mul.h
index fa0a63d298dc..81330c6446f6 100644
--- a/include/crypto/gf128mul.h
+++ b/include/crypto/gf128mul.h
@@ -230,7 +230,7 @@ void gf128mul_4k_bbe(be128 *a, const struct gf128mul_4k *t);
 void gf128mul_x8_ble(le128 *r, const le128 *x);
 static inline void gf128mul_free_4k(struct gf128mul_4k *t)
 {
-	kzfree(t);
+	kfree_sensitive(t);
 }
 
 
diff --git a/include/crypto/hash.h b/include/crypto/hash.h
index cee446c59497..cef16b7d153e 100644
--- a/include/crypto/hash.h
+++ b/include/crypto/hash.h
@@ -606,7 +606,7 @@ static inline struct ahash_request *ahash_request_alloc(
  */
 static inline void ahash_request_free(struct ahash_request *req)
 {
-	kzfree(req);
+	kfree_sensitive(req);
 }
 
 static inline void ahash_request_zero(struct ahash_request *req)
diff --git a/include/crypto/internal/acompress.h b/include/crypto/internal/acompress.h
index cf478681b53e..cfc47e18820f 100644
--- a/include/crypto/internal/acompress.h
+++ b/include/crypto/internal/acompress.h
@@ -46,7 +46,7 @@ static inline struct acomp_req *__acomp_request_alloc(struct crypto_acomp *tfm)
 
 static inline void __acomp_request_free(struct acomp_req *req)
 {
-	kzfree(req);
+	kfree_sensitive(req);
 }
 
 /**
diff --git a/include/crypto/kpp.h b/include/crypto/kpp.h
index cd9a9b500624..88b591215d5c 100644
--- a/include/crypto/kpp.h
+++ b/include/crypto/kpp.h
@@ -187,7 +187,7 @@ static inline struct kpp_request *kpp_request_alloc(struct crypto_kpp *tfm,
  */
 static inline void kpp_request_free(struct kpp_request *req)
 {
-	kzfree(req);
+	kfree_sensitive(req);
 }
 
 /**
diff --git a/include/crypto/skcipher.h b/include/crypto/skcipher.h
index 141e7690f9c3..1013c9cbae69 100644
--- a/include/crypto/skcipher.h
+++ b/include/crypto/skcipher.h
@@ -508,7 +508,7 @@ static inline struct skcipher_request *skcipher_request_alloc(
  */
 static inline void skcipher_request_free(struct skcipher_request *req)
 {
-	kzfree(req);
+	kfree_sensitive(req);
 }
 
 static inline void skcipher_request_zero(struct skcipher_request *req)
diff --git a/include/linux/slab.h b/include/linux/slab.h
index 6d454886bcaf..7f2018943997 100644
--- a/include/linux/slab.h
+++ b/include/linux/slab.h
@@ -186,7 +186,7 @@ void memcg_deactivate_kmem_caches(struct mem_cgroup *, struct mem_cgroup *);
  */
 void * __must_check krealloc(const void *, size_t, gfp_t);
 void kfree(const void *);
-void kzfree(const void *);
+void kfree_sensitive(const void *);
 size_t __ksize(const void *);
 size_t ksize(const void *);
 
diff --git a/lib/mpi/mpiutil.c b/lib/mpi/mpiutil.c
index 20ed0f766787..4cd2b335cb7f 100644
--- a/lib/mpi/mpiutil.c
+++ b/lib/mpi/mpiutil.c
@@ -69,7 +69,7 @@ void mpi_free_limb_space(mpi_ptr_t a)
 	if (!a)
 		return;
 
-	kzfree(a);
+	kfree_sensitive(a);
 }
 
 void mpi_assign_limb_space(MPI a, mpi_ptr_t ap, unsigned nlimbs)
@@ -95,7 +95,7 @@ int mpi_resize(MPI a, unsigned nlimbs)
 		if (!p)
 			return -ENOMEM;
 		memcpy(p, a->d, a->alloced * sizeof(mpi_limb_t));
-		kzfree(a->d);
+		kfree_sensitive(a->d);
 		a->d = p;
 	} else {
 		a->d = kcalloc(nlimbs, sizeof(mpi_limb_t), GFP_KERNEL);
@@ -112,7 +112,7 @@ void mpi_free(MPI a)
 		return;
 
 	if (a->flags & 4)
-		kzfree(a->d);
+		kfree_sensitive(a->d);
 	else
 		mpi_free_limb_space(a->d);
 
diff --git a/lib/test_kasan.c b/lib/test_kasan.c
index e3087d90e00d..a1c82aa68a33 100644
--- a/lib/test_kasan.c
+++ b/lib/test_kasan.c
@@ -757,15 +757,15 @@ static noinline void __init kmalloc_double_kzfree(void)
 	char *ptr;
 	size_t size = 16;
 
-	pr_info("double-free (kzfree)\n");
+	pr_info("double-free (kfree_sensitive)\n");
 	ptr = kmalloc(size, GFP_KERNEL);
 	if (!ptr) {
 		pr_err("Allocation failed\n");
 		return;
 	}
 
-	kzfree(ptr);
-	kzfree(ptr);
+	kfree_sensitive(ptr);
+	kfree_sensitive(ptr);
 }
 
 #ifdef CONFIG_KASAN_VMALLOC
diff --git a/mm/slab_common.c b/mm/slab_common.c
index 23c7500eea7d..c08bc7eb20bd 100644
--- a/mm/slab_common.c
+++ b/mm/slab_common.c
@@ -1707,17 +1707,17 @@ void *krealloc(const void *p, size_t new_size, gfp_t flags)
 EXPORT_SYMBOL(krealloc);
 
 /**
- * kzfree - like kfree but zero memory
+ * kfree_sensitive - Clear sensitive information in memory before freeing
  * @p: object to free memory of
  *
  * The memory of the object @p points to is zeroed before freed.
- * If @p is %NULL, kzfree() does nothing.
+ * If @p is %NULL, kfree_sensitive() does nothing.
  *
  * Note: this function zeroes the whole allocated buffer which can be a good
  * deal bigger than the requested buffer size passed to kmalloc(). So be
  * careful when using this function in performance sensitive code.
  */
-void kzfree(const void *p)
+void kfree_sensitive(const void *p)
 {
 	size_t ks;
 	void *mem = (void *)p;
@@ -1725,10 +1725,10 @@ void kzfree(const void *p)
 	if (unlikely(ZERO_OR_NULL_PTR(mem)))
 		return;
 	ks = ksize(mem);
-	memset(mem, 0, ks);
+	memzero_explicit(mem, ks);
 	kfree(mem);
 }
-EXPORT_SYMBOL(kzfree);
+EXPORT_SYMBOL(kfree_sensitive);
 
 /**
  * ksize - get the actual amount of memory allocated for a given object
diff --git a/net/atm/mpoa_caches.c b/net/atm/mpoa_caches.c
index 3286f9d527d3..f7a2f0e41105 100644
--- a/net/atm/mpoa_caches.c
+++ b/net/atm/mpoa_caches.c
@@ -180,7 +180,7 @@ static int cache_hit(in_cache_entry *entry, struct mpoa_client *mpc)
 static void in_cache_put(in_cache_entry *entry)
 {
 	if (refcount_dec_and_test(&entry->use)) {
-		kzfree(entry);
+		kfree_sensitive(entry);
 	}
 }
 
@@ -415,7 +415,7 @@ static eg_cache_entry *eg_cache_get_by_src_ip(__be32 ipaddr,
 static void eg_cache_put(eg_cache_entry *entry)
 {
 	if (refcount_dec_and_test(&entry->use)) {
-		kzfree(entry);
+		kfree_sensitive(entry);
 	}
 }
 
diff --git a/net/bluetooth/ecdh_helper.c b/net/bluetooth/ecdh_helper.c
index 2155ce802877..3226fe02e875 100644
--- a/net/bluetooth/ecdh_helper.c
+++ b/net/bluetooth/ecdh_helper.c
@@ -104,7 +104,7 @@ int compute_ecdh_secret(struct crypto_kpp *tfm, const u8 public_key[64],
 free_all:
 	kpp_request_free(req);
 free_tmp:
-	kzfree(tmp);
+	kfree_sensitive(tmp);
 	return err;
 }
 
@@ -151,9 +151,9 @@ int set_ecdh_privkey(struct crypto_kpp *tfm, const u8 private_key[32])
 	err = crypto_kpp_set_secret(tfm, buf, buf_len);
 	/* fall through */
 free_all:
-	kzfree(buf);
+	kfree_sensitive(buf);
 free_tmp:
-	kzfree(tmp);
+	kfree_sensitive(tmp);
 	return err;
 }
 
diff --git a/net/bluetooth/smp.c b/net/bluetooth/smp.c
index 1476a91ce935..445ec3d09b01 100644
--- a/net/bluetooth/smp.c
+++ b/net/bluetooth/smp.c
@@ -753,9 +753,9 @@ static void smp_chan_destroy(struct l2cap_conn *conn)
 	complete = test_bit(SMP_FLAG_COMPLETE, &smp->flags);
 	mgmt_smp_complete(hcon, complete);
 
-	kzfree(smp->csrk);
-	kzfree(smp->slave_csrk);
-	kzfree(smp->link_key);
+	kfree_sensitive(smp->csrk);
+	kfree_sensitive(smp->slave_csrk);
+	kfree_sensitive(smp->link_key);
 
 	crypto_free_shash(smp->tfm_cmac);
 	crypto_free_kpp(smp->tfm_ecdh);
@@ -789,7 +789,7 @@ static void smp_chan_destroy(struct l2cap_conn *conn)
 	}
 
 	chan->data = NULL;
-	kzfree(smp);
+	kfree_sensitive(smp);
 	hci_conn_drop(hcon);
 }
 
@@ -1149,7 +1149,7 @@ static void sc_generate_link_key(struct smp_chan *smp)
 		const u8 salt[16] = { 0x31, 0x70, 0x6d, 0x74 };
 
 		if (smp_h7(smp->tfm_cmac, smp->tk, salt, smp->link_key)) {
-			kzfree(smp->link_key);
+			kfree_sensitive(smp->link_key);
 			smp->link_key = NULL;
 			return;
 		}
@@ -1158,14 +1158,14 @@ static void sc_generate_link_key(struct smp_chan *smp)
 		const u8 tmp1[4] = { 0x31, 0x70, 0x6d, 0x74 };
 
 		if (smp_h6(smp->tfm_cmac, smp->tk, tmp1, smp->link_key)) {
-			kzfree(smp->link_key);
+			kfree_sensitive(smp->link_key);
 			smp->link_key = NULL;
 			return;
 		}
 	}
 
 	if (smp_h6(smp->tfm_cmac, smp->link_key, lebr, smp->link_key)) {
-		kzfree(smp->link_key);
+		kfree_sensitive(smp->link_key);
 		smp->link_key = NULL;
 		return;
 	}
@@ -1400,7 +1400,7 @@ static struct smp_chan *smp_chan_create(struct l2cap_conn *conn)
 free_shash:
 	crypto_free_shash(smp->tfm_cmac);
 zfree_smp:
-	kzfree(smp);
+	kfree_sensitive(smp);
 	return NULL;
 }
 
@@ -3263,7 +3263,7 @@ static struct l2cap_chan *smp_add_cid(struct hci_dev *hdev, u16 cid)
 	tfm_cmac = crypto_alloc_shash("cmac(aes)", 0, 0);
 	if (IS_ERR(tfm_cmac)) {
 		BT_ERR("Unable to create CMAC crypto context");
-		kzfree(smp);
+		kfree_sensitive(smp);
 		return ERR_CAST(tfm_cmac);
 	}
 
@@ -3271,7 +3271,7 @@ static struct l2cap_chan *smp_add_cid(struct hci_dev *hdev, u16 cid)
 	if (IS_ERR(tfm_ecdh)) {
 		BT_ERR("Unable to create ECDH crypto context");
 		crypto_free_shash(tfm_cmac);
-		kzfree(smp);
+		kfree_sensitive(smp);
 		return ERR_CAST(tfm_ecdh);
 	}
 
@@ -3285,7 +3285,7 @@ static struct l2cap_chan *smp_add_cid(struct hci_dev *hdev, u16 cid)
 		if (smp) {
 			crypto_free_shash(smp->tfm_cmac);
 			crypto_free_kpp(smp->tfm_ecdh);
-			kzfree(smp);
+			kfree_sensitive(smp);
 		}
 		return ERR_PTR(-ENOMEM);
 	}
@@ -3332,7 +3332,7 @@ static void smp_del_chan(struct l2cap_chan *chan)
 		chan->data = NULL;
 		crypto_free_shash(smp->tfm_cmac);
 		crypto_free_kpp(smp->tfm_ecdh);
-		kzfree(smp);
+		kfree_sensitive(smp);
 	}
 
 	l2cap_chan_put(chan);
diff --git a/net/core/sock.c b/net/core/sock.c
index ce1d8dce9b7a..e20a672afee5 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -2182,7 +2182,7 @@ static inline void __sock_kfree_s(struct sock *sk, void *mem, int size,
 	if (WARN_ON_ONCE(!mem))
 		return;
 	if (nullify)
-		kzfree(mem);
+		kfree_sensitive(mem);
 	else
 		kfree(mem);
 	atomic_sub(size, &sk->sk_omem_alloc);
diff --git a/net/ipv4/tcp_fastopen.c b/net/ipv4/tcp_fastopen.c
index 19ad9586c720..c1a54f3d58f5 100644
--- a/net/ipv4/tcp_fastopen.c
+++ b/net/ipv4/tcp_fastopen.c
@@ -38,7 +38,7 @@ static void tcp_fastopen_ctx_free(struct rcu_head *head)
 	struct tcp_fastopen_context *ctx =
 	    container_of(head, struct tcp_fastopen_context, rcu);
 
-	kzfree(ctx);
+	kfree_sensitive(ctx);
 }
 
 void tcp_fastopen_destroy_cipher(struct sock *sk)
diff --git a/net/mac80211/aead_api.c b/net/mac80211/aead_api.c
index c5fe95e49c68..d7b3d905d535 100644
--- a/net/mac80211/aead_api.c
+++ b/net/mac80211/aead_api.c
@@ -41,7 +41,7 @@ int aead_encrypt(struct crypto_aead *tfm, u8 *b_0, u8 *aad, size_t aad_len,
 	aead_request_set_ad(aead_req, sg[0].length);
 
 	crypto_aead_encrypt(aead_req);
-	kzfree(aead_req);
+	kfree_sensitive(aead_req);
 
 	return 0;
 }
@@ -76,7 +76,7 @@ int aead_decrypt(struct crypto_aead *tfm, u8 *b_0, u8 *aad, size_t aad_len,
 	aead_request_set_ad(aead_req, sg[0].length);
 
 	err = crypto_aead_decrypt(aead_req);
-	kzfree(aead_req);
+	kfree_sensitive(aead_req);
 
 	return err;
 }
diff --git a/net/mac80211/aes_gmac.c b/net/mac80211/aes_gmac.c
index 16ba09cb5def..6f3b3a0cc10a 100644
--- a/net/mac80211/aes_gmac.c
+++ b/net/mac80211/aes_gmac.c
@@ -60,7 +60,7 @@ int ieee80211_aes_gmac(struct crypto_aead *tfm, const u8 *aad, u8 *nonce,
 	aead_request_set_ad(aead_req, GMAC_AAD_LEN + data_len);
 
 	crypto_aead_encrypt(aead_req);
-	kzfree(aead_req);
+	kfree_sensitive(aead_req);
 
 	return 0;
 }
diff --git a/net/mac80211/key.c b/net/mac80211/key.c
index 8f403c1bb908..6bb765721862 100644
--- a/net/mac80211/key.c
+++ b/net/mac80211/key.c
@@ -732,7 +732,7 @@ static void ieee80211_key_free_common(struct ieee80211_key *key)
 		ieee80211_aes_gcm_key_free(key->u.gcmp.tfm);
 		break;
 	}
-	kzfree(key);
+	kfree_sensitive(key);
 }
 
 static void __ieee80211_key_destroy(struct ieee80211_key *key,
diff --git a/net/mac802154/llsec.c b/net/mac802154/llsec.c
index c079ee69d3d0..585d33144c33 100644
--- a/net/mac802154/llsec.c
+++ b/net/mac802154/llsec.c
@@ -49,7 +49,7 @@ void mac802154_llsec_destroy(struct mac802154_llsec *sec)
 
 		msl = container_of(sl, struct mac802154_llsec_seclevel, level);
 		list_del(&sl->list);
-		kzfree(msl);
+		kfree_sensitive(msl);
 	}
 
 	list_for_each_entry_safe(dev, dn, &sec->table.devices, list) {
@@ -66,7 +66,7 @@ void mac802154_llsec_destroy(struct mac802154_llsec *sec)
 		mkey = container_of(key->key, struct mac802154_llsec_key, key);
 		list_del(&key->list);
 		llsec_key_put(mkey);
-		kzfree(key);
+		kfree_sensitive(key);
 	}
 }
 
@@ -155,7 +155,7 @@ llsec_key_alloc(const struct ieee802154_llsec_key *template)
 		if (key->tfm[i])
 			crypto_free_aead(key->tfm[i]);
 
-	kzfree(key);
+	kfree_sensitive(key);
 	return NULL;
 }
 
@@ -170,7 +170,7 @@ static void llsec_key_release(struct kref *ref)
 		crypto_free_aead(key->tfm[i]);
 
 	crypto_free_sync_skcipher(key->tfm0);
-	kzfree(key);
+	kfree_sensitive(key);
 }
 
 static struct mac802154_llsec_key*
@@ -261,7 +261,7 @@ int mac802154_llsec_key_add(struct mac802154_llsec *sec,
 	return 0;
 
 fail:
-	kzfree(new);
+	kfree_sensitive(new);
 	return -ENOMEM;
 }
 
@@ -341,10 +341,10 @@ static void llsec_dev_free(struct mac802154_llsec_device *dev)
 				      devkey);
 
 		list_del(&pos->list);
-		kzfree(devkey);
+		kfree_sensitive(devkey);
 	}
 
-	kzfree(dev);
+	kfree_sensitive(dev);
 }
 
 int mac802154_llsec_dev_add(struct mac802154_llsec *sec,
@@ -682,7 +682,7 @@ llsec_do_encrypt_auth(struct sk_buff *skb, const struct mac802154_llsec *sec,
 
 	rc = crypto_aead_encrypt(req);
 
-	kzfree(req);
+	kfree_sensitive(req);
 
 	return rc;
 }
@@ -886,7 +886,7 @@ llsec_do_decrypt_auth(struct sk_buff *skb, const struct mac802154_llsec *sec,
 
 	rc = crypto_aead_decrypt(req);
 
-	kzfree(req);
+	kfree_sensitive(req);
 	skb_trim(skb, skb->len - authlen);
 
 	return rc;
@@ -926,7 +926,7 @@ llsec_update_devkey_record(struct mac802154_llsec_device *dev,
 		if (!devkey)
 			list_add_rcu(&next->devkey.list, &dev->dev.keys);
 		else
-			kzfree(next);
+			kfree_sensitive(next);
 
 		spin_unlock_bh(&dev->lock);
 	}
diff --git a/net/sctp/auth.c b/net/sctp/auth.c
index 4278764d82b8..3a22e1747712 100644
--- a/net/sctp/auth.c
+++ b/net/sctp/auth.c
@@ -49,7 +49,7 @@ void sctp_auth_key_put(struct sctp_auth_bytes *key)
 		return;
 
 	if (refcount_dec_and_test(&key->refcnt)) {
-		kzfree(key);
+		kfree_sensitive(key);
 		SCTP_DBG_OBJCNT_DEC(keys);
 	}
 }
diff --git a/net/sctp/socket.c b/net/sctp/socket.c
index 827a9903ee28..3392d18a7e44 100644
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -3748,7 +3748,7 @@ static int sctp_setsockopt_auth_key(struct sock *sk,
 	}
 
 out:
-	kzfree(authkey);
+	kfree_sensitive(authkey);
 	return ret;
 }
 
diff --git a/net/sunrpc/auth_gss/gss_krb5_crypto.c b/net/sunrpc/auth_gss/gss_krb5_crypto.c
index 6f2d30d7b766..19bb244d2444 100644
--- a/net/sunrpc/auth_gss/gss_krb5_crypto.c
+++ b/net/sunrpc/auth_gss/gss_krb5_crypto.c
@@ -1003,7 +1003,7 @@ krb5_rc4_setup_seq_key(struct krb5_ctx *kctx,
 	err = 0;
 
 out_err:
-	kzfree(desc);
+	kfree_sensitive(desc);
 	crypto_free_shash(hmac);
 	dprintk("%s: returning %d\n", __func__, err);
 	return err;
@@ -1079,7 +1079,7 @@ krb5_rc4_setup_enc_key(struct krb5_ctx *kctx,
 	err = 0;
 
 out_err:
-	kzfree(desc);
+	kfree_sensitive(desc);
 	crypto_free_shash(hmac);
 	dprintk("%s: returning %d\n", __func__, err);
 	return err;
diff --git a/net/sunrpc/auth_gss/gss_krb5_keys.c b/net/sunrpc/auth_gss/gss_krb5_keys.c
index 3b7f721c023b..726c076950c0 100644
--- a/net/sunrpc/auth_gss/gss_krb5_keys.c
+++ b/net/sunrpc/auth_gss/gss_krb5_keys.c
@@ -228,11 +228,11 @@ u32 krb5_derive_key(const struct gss_krb5_enctype *gk5e,
 	ret = 0;
 
 err_free_raw:
-	kzfree(rawkey);
+	kfree_sensitive(rawkey);
 err_free_out:
-	kzfree(outblockdata);
+	kfree_sensitive(outblockdata);
 err_free_in:
-	kzfree(inblockdata);
+	kfree_sensitive(inblockdata);
 err_free_cipher:
 	crypto_free_sync_skcipher(cipher);
 err_return:
diff --git a/net/sunrpc/auth_gss/gss_krb5_mech.c b/net/sunrpc/auth_gss/gss_krb5_mech.c
index 75b3c2e9e8f8..a84a5b289484 100644
--- a/net/sunrpc/auth_gss/gss_krb5_mech.c
+++ b/net/sunrpc/auth_gss/gss_krb5_mech.c
@@ -443,7 +443,7 @@ context_derive_keys_rc4(struct krb5_ctx *ctx)
 	desc->tfm = hmac;
 
 	err = crypto_shash_digest(desc, sigkeyconstant, slen, ctx->cksum);
-	kzfree(desc);
+	kfree_sensitive(desc);
 	if (err)
 		goto out_err_free_hmac;
 	/*
diff --git a/net/tipc/crypto.c b/net/tipc/crypto.c
index c8c47fc72653..001bcb0f2480 100644
--- a/net/tipc/crypto.c
+++ b/net/tipc/crypto.c
@@ -441,7 +441,7 @@ static int tipc_aead_init(struct tipc_aead **aead, struct tipc_aead_key *ukey,
 	/* Allocate per-cpu TFM entry pointer */
 	tmp->tfm_entry = alloc_percpu(struct tipc_tfm *);
 	if (!tmp->tfm_entry) {
-		kzfree(tmp);
+		kfree_sensitive(tmp);
 		return -ENOMEM;
 	}
 
@@ -491,7 +491,7 @@ static int tipc_aead_init(struct tipc_aead **aead, struct tipc_aead_key *ukey,
 	/* Not any TFM is allocated? */
 	if (!tfm_cnt) {
 		free_percpu(tmp->tfm_entry);
-		kzfree(tmp);
+		kfree_sensitive(tmp);
 		return err;
 	}
 
@@ -545,7 +545,7 @@ static int tipc_aead_clone(struct tipc_aead **dst, struct tipc_aead *src)
 
 	aead->tfm_entry = alloc_percpu_gfp(struct tipc_tfm *, GFP_ATOMIC);
 	if (unlikely(!aead->tfm_entry)) {
-		kzfree(aead);
+		kfree_sensitive(aead);
 		return -ENOMEM;
 	}
 
@@ -1352,7 +1352,7 @@ int tipc_crypto_start(struct tipc_crypto **crypto, struct net *net,
 	/* Allocate statistic structure */
 	c->stats = alloc_percpu_gfp(struct tipc_crypto_stats, GFP_ATOMIC);
 	if (!c->stats) {
-		kzfree(c);
+		kfree_sensitive(c);
 		return -ENOMEM;
 	}
 
@@ -1408,7 +1408,7 @@ void tipc_crypto_stop(struct tipc_crypto **crypto)
 	free_percpu(c->stats);
 
 	*crypto = NULL;
-	kzfree(c);
+	kfree_sensitive(c);
 }
 
 void tipc_crypto_timeout(struct tipc_crypto *rx)
diff --git a/net/wireless/core.c b/net/wireless/core.c
index 341402b4f178..cd2c982c5317 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -1107,7 +1107,7 @@ static void __cfg80211_unregister_wdev(struct wireless_dev *wdev, bool sync)
 	}
 
 #ifdef CONFIG_CFG80211_WEXT
-	kzfree(wdev->wext.keys);
+	kfree_sensitive(wdev->wext.keys);
 	wdev->wext.keys = NULL;
 #endif
 	/* only initialized if we have a netdev */
diff --git a/net/wireless/ibss.c b/net/wireless/ibss.c
index ae8fe66a9bb8..a0621bb76d8e 100644
--- a/net/wireless/ibss.c
+++ b/net/wireless/ibss.c
@@ -127,7 +127,7 @@ int __cfg80211_join_ibss(struct cfg80211_registered_device *rdev,
 		return -EINVAL;
 
 	if (WARN_ON(wdev->connect_keys))
-		kzfree(wdev->connect_keys);
+		kfree_sensitive(wdev->connect_keys);
 	wdev->connect_keys = connkeys;
 
 	wdev->ibss_fixed = params->channel_fixed;
@@ -161,7 +161,7 @@ static void __cfg80211_clear_ibss(struct net_device *dev, bool nowext)
 
 	ASSERT_WDEV_LOCK(wdev);
 
-	kzfree(wdev->connect_keys);
+	kfree_sensitive(wdev->connect_keys);
 	wdev->connect_keys = NULL;
 
 	rdev_set_qos_map(rdev, dev, NULL);
diff --git a/net/wireless/lib80211_crypt_tkip.c b/net/wireless/lib80211_crypt_tkip.c
index f5e842ba7673..1b4d6c87a5c5 100644
--- a/net/wireless/lib80211_crypt_tkip.c
+++ b/net/wireless/lib80211_crypt_tkip.c
@@ -131,7 +131,7 @@ static void lib80211_tkip_deinit(void *priv)
 		crypto_free_shash(_priv->tx_tfm_michael);
 		crypto_free_shash(_priv->rx_tfm_michael);
 	}
-	kzfree(priv);
+	kfree_sensitive(priv);
 }
 
 static inline u16 RotR1(u16 val)
diff --git a/net/wireless/lib80211_crypt_wep.c b/net/wireless/lib80211_crypt_wep.c
index dafc6f3571db..6ab9957b8f96 100644
--- a/net/wireless/lib80211_crypt_wep.c
+++ b/net/wireless/lib80211_crypt_wep.c
@@ -56,7 +56,7 @@ static void *lib80211_wep_init(int keyidx)
 
 static void lib80211_wep_deinit(void *priv)
 {
-	kzfree(priv);
+	kfree_sensitive(priv);
 }
 
 /* Add WEP IV/key info to a frame that has at least 4 bytes of headroom */
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 5fa402144cda..c1b37c798907 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -9783,7 +9783,7 @@ static int nl80211_join_ibss(struct sk_buff *skb, struct genl_info *info)
 
 		if ((ibss.chandef.width != NL80211_CHAN_WIDTH_20_NOHT) &&
 		    no_ht) {
-			kzfree(connkeys);
+			kfree_sensitive(connkeys);
 			return -EINVAL;
 		}
 	}
@@ -9795,7 +9795,7 @@ static int nl80211_join_ibss(struct sk_buff *skb, struct genl_info *info)
 		int r = validate_pae_over_nl80211(rdev, info);
 
 		if (r < 0) {
-			kzfree(connkeys);
+			kfree_sensitive(connkeys);
 			return r;
 		}
 
@@ -9808,7 +9808,7 @@ static int nl80211_join_ibss(struct sk_buff *skb, struct genl_info *info)
 	wdev_lock(dev->ieee80211_ptr);
 	err = __cfg80211_join_ibss(rdev, dev, &ibss, connkeys);
 	if (err)
-		kzfree(connkeys);
+		kfree_sensitive(connkeys);
 	else if (info->attrs[NL80211_ATTR_SOCKET_OWNER])
 		dev->ieee80211_ptr->conn_owner_nlportid = info->snd_portid;
 	wdev_unlock(dev->ieee80211_ptr);
@@ -10228,7 +10228,7 @@ static int nl80211_connect(struct sk_buff *skb, struct genl_info *info)
 
 	if (info->attrs[NL80211_ATTR_HT_CAPABILITY]) {
 		if (!info->attrs[NL80211_ATTR_HT_CAPABILITY_MASK]) {
-			kzfree(connkeys);
+			kfree_sensitive(connkeys);
 			return -EINVAL;
 		}
 		memcpy(&connect.ht_capa,
@@ -10246,7 +10246,7 @@ static int nl80211_connect(struct sk_buff *skb, struct genl_info *info)
 
 	if (info->attrs[NL80211_ATTR_VHT_CAPABILITY]) {
 		if (!info->attrs[NL80211_ATTR_VHT_CAPABILITY_MASK]) {
-			kzfree(connkeys);
+			kfree_sensitive(connkeys);
 			return -EINVAL;
 		}
 		memcpy(&connect.vht_capa,
@@ -10260,7 +10260,7 @@ static int nl80211_connect(struct sk_buff *skb, struct genl_info *info)
 		       (rdev->wiphy.features & NL80211_FEATURE_QUIET)) &&
 		    !wiphy_ext_feature_isset(&rdev->wiphy,
 					     NL80211_EXT_FEATURE_RRM)) {
-			kzfree(connkeys);
+			kfree_sensitive(connkeys);
 			return -EINVAL;
 		}
 		connect.flags |= ASSOC_REQ_USE_RRM;
@@ -10268,21 +10268,21 @@ static int nl80211_connect(struct sk_buff *skb, struct genl_info *info)
 
 	connect.pbss = nla_get_flag(info->attrs[NL80211_ATTR_PBSS]);
 	if (connect.pbss && !rdev->wiphy.bands[NL80211_BAND_60GHZ]) {
-		kzfree(connkeys);
+		kfree_sensitive(connkeys);
 		return -EOPNOTSUPP;
 	}
 
 	if (info->attrs[NL80211_ATTR_BSS_SELECT]) {
 		/* bss selection makes no sense if bssid is set */
 		if (connect.bssid) {
-			kzfree(connkeys);
+			kfree_sensitive(connkeys);
 			return -EINVAL;
 		}
 
 		err = parse_bss_select(info->attrs[NL80211_ATTR_BSS_SELECT],
 				       wiphy, &connect.bss_select);
 		if (err) {
-			kzfree(connkeys);
+			kfree_sensitive(connkeys);
 			return err;
 		}
 	}
@@ -10312,13 +10312,13 @@ static int nl80211_connect(struct sk_buff *skb, struct genl_info *info)
 		   info->attrs[NL80211_ATTR_FILS_ERP_REALM] ||
 		   info->attrs[NL80211_ATTR_FILS_ERP_NEXT_SEQ_NUM] ||
 		   info->attrs[NL80211_ATTR_FILS_ERP_RRK]) {
-		kzfree(connkeys);
+		kfree_sensitive(connkeys);
 		return -EINVAL;
 	}
 
 	if (nla_get_flag(info->attrs[NL80211_ATTR_EXTERNAL_AUTH_SUPPORT])) {
 		if (!info->attrs[NL80211_ATTR_SOCKET_OWNER]) {
-			kzfree(connkeys);
+			kfree_sensitive(connkeys);
 			GENL_SET_ERR_MSG(info,
 					 "external auth requires connection ownership");
 			return -EINVAL;
@@ -10331,7 +10331,7 @@ static int nl80211_connect(struct sk_buff *skb, struct genl_info *info)
 	err = cfg80211_connect(rdev, dev, &connect, connkeys,
 			       connect.prev_bssid);
 	if (err)
-		kzfree(connkeys);
+		kfree_sensitive(connkeys);
 
 	if (!err && info->attrs[NL80211_ATTR_SOCKET_OWNER]) {
 		dev->ieee80211_ptr->conn_owner_nlportid = info->snd_portid;
diff --git a/net/wireless/sme.c b/net/wireless/sme.c
index ac3e60aa1fc8..8e60d5a6236c 100644
--- a/net/wireless/sme.c
+++ b/net/wireless/sme.c
@@ -741,7 +741,7 @@ void __cfg80211_connect_result(struct net_device *dev,
 	}
 
 	if (cr->status != WLAN_STATUS_SUCCESS) {
-		kzfree(wdev->connect_keys);
+		kfree_sensitive(wdev->connect_keys);
 		wdev->connect_keys = NULL;
 		wdev->ssid_len = 0;
 		wdev->conn_owner_nlportid = 0;
@@ -1096,7 +1096,7 @@ void __cfg80211_disconnected(struct net_device *dev, const u8 *ie,
 	wdev->current_bss = NULL;
 	wdev->ssid_len = 0;
 	wdev->conn_owner_nlportid = 0;
-	kzfree(wdev->connect_keys);
+	kfree_sensitive(wdev->connect_keys);
 	wdev->connect_keys = NULL;
 
 	nl80211_send_disconnected(rdev, dev, reason, ie, ie_len, from_ap);
@@ -1276,7 +1276,7 @@ int cfg80211_disconnect(struct cfg80211_registered_device *rdev,
 
 	ASSERT_WDEV_LOCK(wdev);
 
-	kzfree(wdev->connect_keys);
+	kfree_sensitive(wdev->connect_keys);
 	wdev->connect_keys = NULL;
 
 	wdev->conn_owner_nlportid = 0;
diff --git a/net/wireless/util.c b/net/wireless/util.c
index 6590efbbcbb9..ea172bc244c2 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -853,7 +853,7 @@ void cfg80211_upload_connect_keys(struct wireless_dev *wdev)
 		}
 	}
 
-	kzfree(wdev->connect_keys);
+	kfree_sensitive(wdev->connect_keys);
 	wdev->connect_keys = NULL;
 }
 
diff --git a/net/wireless/wext-sme.c b/net/wireless/wext-sme.c
index 73fd0eae08ca..73df23570d43 100644
--- a/net/wireless/wext-sme.c
+++ b/net/wireless/wext-sme.c
@@ -57,7 +57,7 @@ int cfg80211_mgd_wext_connect(struct cfg80211_registered_device *rdev,
 	err = cfg80211_connect(rdev, wdev->netdev,
 			       &wdev->wext.connect, ck, prev_bssid);
 	if (err)
-		kzfree(ck);
+		kfree_sensitive(ck);
 
 	return err;
 }
diff --git a/scripts/coccinelle/free/devm_free.cocci b/scripts/coccinelle/free/devm_free.cocci
index 3357bf4dbd7c..da80050b91ff 100644
--- a/scripts/coccinelle/free/devm_free.cocci
+++ b/scripts/coccinelle/free/devm_free.cocci
@@ -89,7 +89,7 @@ position p;
 (
  kfree at p(x)
 |
- kzfree at p(x)
+ kfree_sensitive at p(x)
 |
  krealloc at p(x, ...)
 |
@@ -112,7 +112,7 @@ position p != safe.p;
 (
 * kfree at p(x)
 |
-* kzfree at p(x)
+* kfree_sensitive at p(x)
 |
 * krealloc at p(x, ...)
 |
diff --git a/scripts/coccinelle/free/ifnullfree.cocci b/scripts/coccinelle/free/ifnullfree.cocci
index b3290c4ee239..2045391e36a0 100644
--- a/scripts/coccinelle/free/ifnullfree.cocci
+++ b/scripts/coccinelle/free/ifnullfree.cocci
@@ -21,7 +21,7 @@ expression E;
 (
   kfree(E);
 |
-  kzfree(E);
+  kfree_sensitive(E);
 |
   debugfs_remove(E);
 |
@@ -42,7 +42,7 @@ position p;
 @@
 
 * if (E != NULL)
-*	\(kfree at p\|kzfree at p\|debugfs_remove at p\|debugfs_remove_recursive at p\|
+*	\(kfree at p\|kfree_sensitive at p\|debugfs_remove at p\|debugfs_remove_recursive at p\|
 *         usb_free_urb at p\|kmem_cache_destroy at p\|mempool_destroy at p\|
 *         dma_pool_destroy at p\)(E);
 
diff --git a/scripts/coccinelle/free/kfree.cocci b/scripts/coccinelle/free/kfree.cocci
index e9d50e718e46..168568386034 100644
--- a/scripts/coccinelle/free/kfree.cocci
+++ b/scripts/coccinelle/free/kfree.cocci
@@ -24,7 +24,7 @@ position p1;
 (
 * kfree at p1(E)
 |
-* kzfree at p1(E)
+* kfree_sensitive at p1(E)
 )
 
 @print expression@
@@ -68,7 +68,7 @@ while (1) { ...
 (
 * kfree at ok(E)
 |
-* kzfree at ok(E)
+* kfree_sensitive at ok(E)
 )
   ... when != break;
       when != goto l;
@@ -86,7 +86,7 @@ position free.p1!=loop.ok,p2!={print.p,sz.p};
 (
 * kfree at p1(E,...)
 |
-* kzfree at p1(E,...)
+* kfree_sensitive at p1(E,...)
 )
 ...
 (
diff --git a/scripts/coccinelle/free/kfreeaddr.cocci b/scripts/coccinelle/free/kfreeaddr.cocci
index cfaf308328d8..142af6337a04 100644
--- a/scripts/coccinelle/free/kfreeaddr.cocci
+++ b/scripts/coccinelle/free/kfreeaddr.cocci
@@ -20,7 +20,7 @@ position p;
 (
 * kfree at p(&e->f)
 |
-* kzfree at p(&e->f)
+* kfree_sensitive at p(&e->f)
 )
 
 @script:python depends on org@
diff --git a/security/apparmor/domain.c b/security/apparmor/domain.c
index 6ceb74e0f789..9e9d4411b96e 100644
--- a/security/apparmor/domain.c
+++ b/security/apparmor/domain.c
@@ -40,8 +40,8 @@ void aa_free_domain_entries(struct aa_domain *domain)
 			return;
 
 		for (i = 0; i < domain->size; i++)
-			kzfree(domain->table[i]);
-		kzfree(domain->table);
+			kfree_sensitive(domain->table[i]);
+		kfree_sensitive(domain->table);
 		domain->table = NULL;
 	}
 }
diff --git a/security/apparmor/include/file.h b/security/apparmor/include/file.h
index aff26fc71407..d4f8948517d9 100644
--- a/security/apparmor/include/file.h
+++ b/security/apparmor/include/file.h
@@ -72,7 +72,7 @@ static inline void aa_free_file_ctx(struct aa_file_ctx *ctx)
 {
 	if (ctx) {
 		aa_put_label(rcu_access_pointer(ctx->label));
-		kzfree(ctx);
+		kfree_sensitive(ctx);
 	}
 }
 
diff --git a/security/apparmor/policy.c b/security/apparmor/policy.c
index 269f2f53c0b1..4ab00ab060f1 100644
--- a/security/apparmor/policy.c
+++ b/security/apparmor/policy.c
@@ -187,9 +187,9 @@ static void aa_free_data(void *ptr, void *arg)
 {
 	struct aa_data *data = ptr;
 
-	kzfree(data->data);
-	kzfree(data->key);
-	kzfree(data);
+	kfree_sensitive(data->data);
+	kfree_sensitive(data->key);
+	kfree_sensitive(data);
 }
 
 /**
@@ -217,19 +217,19 @@ void aa_free_profile(struct aa_profile *profile)
 	aa_put_profile(rcu_access_pointer(profile->parent));
 
 	aa_put_ns(profile->ns);
-	kzfree(profile->rename);
+	kfree_sensitive(profile->rename);
 
 	aa_free_file_rules(&profile->file);
 	aa_free_cap_rules(&profile->caps);
 	aa_free_rlimit_rules(&profile->rlimits);
 
 	for (i = 0; i < profile->xattr_count; i++)
-		kzfree(profile->xattrs[i]);
-	kzfree(profile->xattrs);
+		kfree_sensitive(profile->xattrs[i]);
+	kfree_sensitive(profile->xattrs);
 	for (i = 0; i < profile->secmark_count; i++)
-		kzfree(profile->secmark[i].label);
-	kzfree(profile->secmark);
-	kzfree(profile->dirname);
+		kfree_sensitive(profile->secmark[i].label);
+	kfree_sensitive(profile->secmark);
+	kfree_sensitive(profile->dirname);
 	aa_put_dfa(profile->xmatch);
 	aa_put_dfa(profile->policy.dfa);
 
@@ -237,13 +237,13 @@ void aa_free_profile(struct aa_profile *profile)
 		rht = profile->data;
 		profile->data = NULL;
 		rhashtable_free_and_destroy(rht, aa_free_data, NULL);
-		kzfree(rht);
+		kfree_sensitive(rht);
 	}
 
-	kzfree(profile->hash);
+	kfree_sensitive(profile->hash);
 	aa_put_loaddata(profile->rawdata);
 
-	kzfree(profile);
+	kfree_sensitive(profile);
 }
 
 /**
diff --git a/security/apparmor/policy_ns.c b/security/apparmor/policy_ns.c
index d7ef540027a5..70921d95fb40 100644
--- a/security/apparmor/policy_ns.c
+++ b/security/apparmor/policy_ns.c
@@ -121,9 +121,9 @@ static struct aa_ns *alloc_ns(const char *prefix, const char *name)
 	return ns;
 
 fail_unconfined:
-	kzfree(ns->base.hname);
+	kfree_sensitive(ns->base.hname);
 fail_ns:
-	kzfree(ns);
+	kfree_sensitive(ns);
 	return NULL;
 }
 
@@ -145,7 +145,7 @@ void aa_free_ns(struct aa_ns *ns)
 
 	ns->unconfined->ns = NULL;
 	aa_free_profile(ns->unconfined);
-	kzfree(ns);
+	kfree_sensitive(ns);
 }
 
 /**
diff --git a/security/apparmor/policy_unpack.c b/security/apparmor/policy_unpack.c
index 2d743c004bc4..5cfbdc6ad106 100644
--- a/security/apparmor/policy_unpack.c
+++ b/security/apparmor/policy_unpack.c
@@ -163,10 +163,10 @@ static void do_loaddata_free(struct work_struct *work)
 		aa_put_ns(ns);
 	}
 
-	kzfree(d->hash);
-	kzfree(d->name);
+	kfree_sensitive(d->hash);
+	kfree_sensitive(d->name);
 	kvfree(d->data);
-	kzfree(d);
+	kfree_sensitive(d);
 }
 
 void aa_loaddata_kref(struct kref *kref)
@@ -890,7 +890,7 @@ static struct aa_profile *unpack_profile(struct aa_ext *e, char **ns_name)
 		while (unpack_strdup(e, &key, NULL)) {
 			data = kzalloc(sizeof(*data), GFP_KERNEL);
 			if (!data) {
-				kzfree(key);
+				kfree_sensitive(key);
 				goto fail;
 			}
 
@@ -898,8 +898,8 @@ static struct aa_profile *unpack_profile(struct aa_ext *e, char **ns_name)
 			data->size = unpack_blob(e, &data->data, NULL);
 			data->data = kvmemdup(data->data, data->size);
 			if (data->size && !data->data) {
-				kzfree(data->key);
-				kzfree(data);
+				kfree_sensitive(data->key);
+				kfree_sensitive(data);
 				goto fail;
 			}
 
@@ -1033,7 +1033,7 @@ void aa_load_ent_free(struct aa_load_ent *ent)
 		aa_put_profile(ent->old);
 		aa_put_profile(ent->new);
 		kfree(ent->ns_name);
-		kzfree(ent);
+		kfree_sensitive(ent);
 	}
 }
 
diff --git a/security/keys/big_key.c b/security/keys/big_key.c
index 82008f900930..a50094ee405a 100644
--- a/security/keys/big_key.c
+++ b/security/keys/big_key.c
@@ -281,7 +281,7 @@ int big_key_preparse(struct key_preparsed_payload *prep)
 err_fput:
 	fput(file);
 err_enckey:
-	kzfree(enckey);
+	kfree_sensitive(enckey);
 error:
 	big_key_free_buffer(buf);
 	return ret;
@@ -297,7 +297,7 @@ void big_key_free_preparse(struct key_preparsed_payload *prep)
 
 		path_put(path);
 	}
-	kzfree(prep->payload.data[big_key_data]);
+	kfree_sensitive(prep->payload.data[big_key_data]);
 }
 
 /*
@@ -329,7 +329,7 @@ void big_key_destroy(struct key *key)
 		path->mnt = NULL;
 		path->dentry = NULL;
 	}
-	kzfree(key->payload.data[big_key_data]);
+	kfree_sensitive(key->payload.data[big_key_data]);
 	key->payload.data[big_key_data] = NULL;
 }
 
diff --git a/security/keys/dh.c b/security/keys/dh.c
index c4c629bb1c03..1abfa70ed6e1 100644
--- a/security/keys/dh.c
+++ b/security/keys/dh.c
@@ -58,9 +58,9 @@ static ssize_t dh_data_from_key(key_serial_t keyid, void **data)
 
 static void dh_free_data(struct dh *dh)
 {
-	kzfree(dh->key);
-	kzfree(dh->p);
-	kzfree(dh->g);
+	kfree_sensitive(dh->key);
+	kfree_sensitive(dh->p);
+	kfree_sensitive(dh->g);
 }
 
 struct dh_completion {
@@ -126,7 +126,7 @@ static void kdf_dealloc(struct kdf_sdesc *sdesc)
 	if (sdesc->shash.tfm)
 		crypto_free_shash(sdesc->shash.tfm);
 
-	kzfree(sdesc);
+	kfree_sensitive(sdesc);
 }
 
 /*
@@ -220,7 +220,7 @@ static int keyctl_dh_compute_kdf(struct kdf_sdesc *sdesc,
 		ret = -EFAULT;
 
 err:
-	kzfree(outbuf);
+	kfree_sensitive(outbuf);
 	return ret;
 }
 
@@ -395,11 +395,11 @@ long __keyctl_dh_compute(struct keyctl_dh_params __user *params,
 out6:
 	kpp_request_free(req);
 out5:
-	kzfree(outbuf);
+	kfree_sensitive(outbuf);
 out4:
 	crypto_free_kpp(tfm);
 out3:
-	kzfree(secret);
+	kfree_sensitive(secret);
 out2:
 	dh_free_data(&dh_inputs);
 out1:
diff --git a/security/keys/encrypted-keys/encrypted.c b/security/keys/encrypted-keys/encrypted.c
index f6797ba44bf7..4b4c1d8c1494 100644
--- a/security/keys/encrypted-keys/encrypted.c
+++ b/security/keys/encrypted-keys/encrypted.c
@@ -382,7 +382,7 @@ static int get_derived_key(u8 *derived_key, enum derived_key_type key_type,
 	memcpy(derived_buf + strlen(derived_buf) + 1, master_key,
 	       master_keylen);
 	ret = calc_hash(hash_tfm, derived_key, derived_buf, derived_buf_len);
-	kzfree(derived_buf);
+	kfree_sensitive(derived_buf);
 	return ret;
 }
 
@@ -824,13 +824,13 @@ static int encrypted_instantiate(struct key *key,
 	ret = encrypted_init(epayload, key->description, format, master_desc,
 			     decrypted_datalen, hex_encoded_iv);
 	if (ret < 0) {
-		kzfree(epayload);
+		kfree_sensitive(epayload);
 		goto out;
 	}
 
 	rcu_assign_keypointer(key, epayload);
 out:
-	kzfree(datablob);
+	kfree_sensitive(datablob);
 	return ret;
 }
 
@@ -839,7 +839,7 @@ static void encrypted_rcu_free(struct rcu_head *rcu)
 	struct encrypted_key_payload *epayload;
 
 	epayload = container_of(rcu, struct encrypted_key_payload, rcu);
-	kzfree(epayload);
+	kfree_sensitive(epayload);
 }
 
 /*
@@ -897,7 +897,7 @@ static int encrypted_update(struct key *key, struct key_preparsed_payload *prep)
 	rcu_assign_keypointer(key, new_epayload);
 	call_rcu(&epayload->rcu, encrypted_rcu_free);
 out:
-	kzfree(buf);
+	kfree_sensitive(buf);
 	return ret;
 }
 
@@ -958,7 +958,7 @@ static long encrypted_read(const struct key *key, char *buffer,
 	memzero_explicit(derived_key, sizeof(derived_key));
 
 	memcpy(buffer, ascii_buf, asciiblob_len);
-	kzfree(ascii_buf);
+	kfree_sensitive(ascii_buf);
 
 	return asciiblob_len;
 out:
@@ -973,7 +973,7 @@ static long encrypted_read(const struct key *key, char *buffer,
  */
 static void encrypted_destroy(struct key *key)
 {
-	kzfree(key->payload.data[0]);
+	kfree_sensitive(key->payload.data[0]);
 }
 
 struct key_type key_type_encrypted = {
diff --git a/security/keys/trusted-keys/trusted_tpm1.c b/security/keys/trusted-keys/trusted_tpm1.c
index 8001ab07e63b..b9fe02e5f84f 100644
--- a/security/keys/trusted-keys/trusted_tpm1.c
+++ b/security/keys/trusted-keys/trusted_tpm1.c
@@ -68,7 +68,7 @@ static int TSS_sha1(const unsigned char *data, unsigned int datalen,
 	}
 
 	ret = crypto_shash_digest(&sdesc->shash, data, datalen, digest);
-	kzfree(sdesc);
+	kfree_sensitive(sdesc);
 	return ret;
 }
 
@@ -112,7 +112,7 @@ static int TSS_rawhmac(unsigned char *digest, const unsigned char *key,
 	if (!ret)
 		ret = crypto_shash_final(&sdesc->shash, digest);
 out:
-	kzfree(sdesc);
+	kfree_sensitive(sdesc);
 	return ret;
 }
 
@@ -166,7 +166,7 @@ int TSS_authhmac(unsigned char *digest, const unsigned char *key,
 				  paramdigest, TPM_NONCE_SIZE, h1,
 				  TPM_NONCE_SIZE, h2, 1, &c, 0, 0);
 out:
-	kzfree(sdesc);
+	kfree_sensitive(sdesc);
 	return ret;
 }
 EXPORT_SYMBOL_GPL(TSS_authhmac);
@@ -251,7 +251,7 @@ int TSS_checkhmac1(unsigned char *buffer,
 	if (memcmp(testhmac, authdata, SHA1_DIGEST_SIZE))
 		ret = -EINVAL;
 out:
-	kzfree(sdesc);
+	kfree_sensitive(sdesc);
 	return ret;
 }
 EXPORT_SYMBOL_GPL(TSS_checkhmac1);
@@ -353,7 +353,7 @@ static int TSS_checkhmac2(unsigned char *buffer,
 	if (memcmp(testhmac2, authdata2, SHA1_DIGEST_SIZE))
 		ret = -EINVAL;
 out:
-	kzfree(sdesc);
+	kfree_sensitive(sdesc);
 	return ret;
 }
 
@@ -563,7 +563,7 @@ static int tpm_seal(struct tpm_buf *tb, uint16_t keytype,
 		*bloblen = storedsize;
 	}
 out:
-	kzfree(td);
+	kfree_sensitive(td);
 	return ret;
 }
 
@@ -1031,12 +1031,12 @@ static int trusted_instantiate(struct key *key,
 	if (!ret && options->pcrlock)
 		ret = pcrlock(options->pcrlock);
 out:
-	kzfree(datablob);
-	kzfree(options);
+	kfree_sensitive(datablob);
+	kfree_sensitive(options);
 	if (!ret)
 		rcu_assign_keypointer(key, payload);
 	else
-		kzfree(payload);
+		kfree_sensitive(payload);
 	return ret;
 }
 
@@ -1045,7 +1045,7 @@ static void trusted_rcu_free(struct rcu_head *rcu)
 	struct trusted_key_payload *p;
 
 	p = container_of(rcu, struct trusted_key_payload, rcu);
-	kzfree(p);
+	kfree_sensitive(p);
 }
 
 /*
@@ -1087,13 +1087,13 @@ static int trusted_update(struct key *key, struct key_preparsed_payload *prep)
 	ret = datablob_parse(datablob, new_p, new_o);
 	if (ret != Opt_update) {
 		ret = -EINVAL;
-		kzfree(new_p);
+		kfree_sensitive(new_p);
 		goto out;
 	}
 
 	if (!new_o->keyhandle) {
 		ret = -EINVAL;
-		kzfree(new_p);
+		kfree_sensitive(new_p);
 		goto out;
 	}
 
@@ -1107,22 +1107,22 @@ static int trusted_update(struct key *key, struct key_preparsed_payload *prep)
 	ret = key_seal(new_p, new_o);
 	if (ret < 0) {
 		pr_info("trusted_key: key_seal failed (%d)\n", ret);
-		kzfree(new_p);
+		kfree_sensitive(new_p);
 		goto out;
 	}
 	if (new_o->pcrlock) {
 		ret = pcrlock(new_o->pcrlock);
 		if (ret < 0) {
 			pr_info("trusted_key: pcrlock failed (%d)\n", ret);
-			kzfree(new_p);
+			kfree_sensitive(new_p);
 			goto out;
 		}
 	}
 	rcu_assign_keypointer(key, new_p);
 	call_rcu(&p->rcu, trusted_rcu_free);
 out:
-	kzfree(datablob);
-	kzfree(new_o);
+	kfree_sensitive(datablob);
+	kfree_sensitive(new_o);
 	return ret;
 }
 
@@ -1154,7 +1154,7 @@ static long trusted_read(const struct key *key, char *buffer,
  */
 static void trusted_destroy(struct key *key)
 {
-	kzfree(key->payload.data[0]);
+	kfree_sensitive(key->payload.data[0]);
 }
 
 struct key_type key_type_trusted = {
diff --git a/security/keys/user_defined.c b/security/keys/user_defined.c
index 07d4287e9084..749e2a4dcb13 100644
--- a/security/keys/user_defined.c
+++ b/security/keys/user_defined.c
@@ -82,7 +82,7 @@ EXPORT_SYMBOL_GPL(user_preparse);
  */
 void user_free_preparse(struct key_preparsed_payload *prep)
 {
-	kzfree(prep->payload.data[0]);
+	kfree_sensitive(prep->payload.data[0]);
 }
 EXPORT_SYMBOL_GPL(user_free_preparse);
 
@@ -91,7 +91,7 @@ static void user_free_payload_rcu(struct rcu_head *head)
 	struct user_key_payload *payload;
 
 	payload = container_of(head, struct user_key_payload, rcu);
-	kzfree(payload);
+	kfree_sensitive(payload);
 }
 
 /*
@@ -147,7 +147,7 @@ void user_destroy(struct key *key)
 {
 	struct user_key_payload *upayload = key->payload.data[0];
 
-	kzfree(upayload);
+	kfree_sensitive(upayload);
 }
 
 EXPORT_SYMBOL_GPL(user_destroy);
-- 
2.18.1


From longman at redhat.com  Mon Apr 13 23:15:50 2020
From: longman at redhat.com (Waiman Long)
Date: Mon, 13 Apr 2020 17:15:50 -0400
Subject: [PATCH 2/2] crypto: Remove unnecessary memzero_explicit()
In-Reply-To: <20200413211550.8307-1-longman@redhat.com>
References: <20200413211550.8307-1-longman@redhat.com>
Message-ID: <20200413211550.8307-3-longman@redhat.com>

Since kfree_sensitive() will do an implicit memzero_explicit(), there
is no need to call memzero_explicit() before it. Eliminate those
memzero_explicit() and simplify the call sites.

Signed-off-by: Waiman Long <longman at redhat.com>
---
 .../crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c  | 15 +++------------
 .../crypto/allwinner/sun8i-ss/sun8i-ss-cipher.c  | 16 +++-------------
 drivers/crypto/amlogic/amlogic-gxl-cipher.c      | 10 ++--------
 drivers/crypto/inside-secure/safexcel_hash.c     |  3 +--
 4 files changed, 9 insertions(+), 35 deletions(-)

diff --git a/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c b/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c
index aa4e8fdc2b32..46c10c7ca6d0 100644
--- a/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c
+++ b/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c
@@ -366,10 +366,7 @@ void sun8i_ce_cipher_exit(struct crypto_tfm *tfm)
 {
 	struct sun8i_cipher_tfm_ctx *op = crypto_tfm_ctx(tfm);
 
-	if (op->key) {
-		memzero_explicit(op->key, op->keylen);
-		kfree(op->key);
-	}
+	kfree_sensitive(op->key);
 	crypto_free_sync_skcipher(op->fallback_tfm);
 	pm_runtime_put_sync_suspend(op->ce->dev);
 }
@@ -391,10 +388,7 @@ int sun8i_ce_aes_setkey(struct crypto_skcipher *tfm, const u8 *key,
 		dev_dbg(ce->dev, "ERROR: Invalid keylen %u\n", keylen);
 		return -EINVAL;
 	}
-	if (op->key) {
-		memzero_explicit(op->key, op->keylen);
-		kfree(op->key);
-	}
+	kfree_sensitive(op->key);
 	op->keylen = keylen;
 	op->key = kmemdup(key, keylen, GFP_KERNEL | GFP_DMA);
 	if (!op->key)
@@ -416,10 +410,7 @@ int sun8i_ce_des3_setkey(struct crypto_skcipher *tfm, const u8 *key,
 	if (err)
 		return err;
 
-	if (op->key) {
-		memzero_explicit(op->key, op->keylen);
-		kfree(op->key);
-	}
+	free_sensitive(op->key, op->keylen);
 	op->keylen = keylen;
 	op->key = kmemdup(key, keylen, GFP_KERNEL | GFP_DMA);
 	if (!op->key)
diff --git a/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-cipher.c b/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-cipher.c
index 5246ef4f5430..7e09a923cbaf 100644
--- a/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-cipher.c
+++ b/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-cipher.c
@@ -249,7 +249,6 @@ static int sun8i_ss_cipher(struct skcipher_request *areq)
 			offset = areq->cryptlen - ivsize;
 			if (rctx->op_dir & SS_DECRYPTION) {
 				memcpy(areq->iv, backup_iv, ivsize);
-				memzero_explicit(backup_iv, ivsize);
 				kfree_sensitive(backup_iv);
 			} else {
 				scatterwalk_map_and_copy(areq->iv, areq->dst, offset,
@@ -367,10 +366,7 @@ void sun8i_ss_cipher_exit(struct crypto_tfm *tfm)
 {
 	struct sun8i_cipher_tfm_ctx *op = crypto_tfm_ctx(tfm);
 
-	if (op->key) {
-		memzero_explicit(op->key, op->keylen);
-		kfree(op->key);
-	}
+	kfree_sensitive(op->key);
 	crypto_free_sync_skcipher(op->fallback_tfm);
 	pm_runtime_put_sync(op->ss->dev);
 }
@@ -392,10 +388,7 @@ int sun8i_ss_aes_setkey(struct crypto_skcipher *tfm, const u8 *key,
 		dev_dbg(ss->dev, "ERROR: Invalid keylen %u\n", keylen);
 		return -EINVAL;
 	}
-	if (op->key) {
-		memzero_explicit(op->key, op->keylen);
-		kfree(op->key);
-	}
+	kfree_sensitive(op->key);
 	op->keylen = keylen;
 	op->key = kmemdup(key, keylen, GFP_KERNEL | GFP_DMA);
 	if (!op->key)
@@ -418,10 +411,7 @@ int sun8i_ss_des3_setkey(struct crypto_skcipher *tfm, const u8 *key,
 		return -EINVAL;
 	}
 
-	if (op->key) {
-		memzero_explicit(op->key, op->keylen);
-		kfree(op->key);
-	}
+	kfree_sensitive(op->key);
 	op->keylen = keylen;
 	op->key = kmemdup(key, keylen, GFP_KERNEL | GFP_DMA);
 	if (!op->key)
diff --git a/drivers/crypto/amlogic/amlogic-gxl-cipher.c b/drivers/crypto/amlogic/amlogic-gxl-cipher.c
index fd1269900d67..f424397fbba4 100644
--- a/drivers/crypto/amlogic/amlogic-gxl-cipher.c
+++ b/drivers/crypto/amlogic/amlogic-gxl-cipher.c
@@ -341,10 +341,7 @@ void meson_cipher_exit(struct crypto_tfm *tfm)
 {
 	struct meson_cipher_tfm_ctx *op = crypto_tfm_ctx(tfm);
 
-	if (op->key) {
-		memzero_explicit(op->key, op->keylen);
-		kfree(op->key);
-	}
+	kfree_sensitive(op->key)
 	crypto_free_sync_skcipher(op->fallback_tfm);
 }
 
@@ -368,10 +365,7 @@ int meson_aes_setkey(struct crypto_skcipher *tfm, const u8 *key,
 		dev_dbg(mc->dev, "ERROR: Invalid keylen %u\n", keylen);
 		return -EINVAL;
 	}
-	if (op->key) {
-		memzero_explicit(op->key, op->keylen);
-		kfree(op->key);
-	}
+	kfree_sensitive(op->key);
 	op->keylen = keylen;
 	op->key = kmemdup(key, keylen, GFP_KERNEL | GFP_DMA);
 	if (!op->key)
diff --git a/drivers/crypto/inside-secure/safexcel_hash.c b/drivers/crypto/inside-secure/safexcel_hash.c
index 43962bc709c6..4a2d162914de 100644
--- a/drivers/crypto/inside-secure/safexcel_hash.c
+++ b/drivers/crypto/inside-secure/safexcel_hash.c
@@ -1081,8 +1081,7 @@ static int safexcel_hmac_init_pad(struct ahash_request *areq,
 		}
 
 		/* Avoid leaking */
-		memzero_explicit(keydup, keylen);
-		kfree(keydup);
+		kfree_sensitive(keydup);
 
 		if (ret)
 			return ret;
-- 
2.18.1


From joe at perches.com  Mon Apr 13 23:31:32 2020
From: joe at perches.com (Joe Perches)
Date: Mon, 13 Apr 2020 14:31:32 -0700
Subject: [PATCH 2/2] crypto: Remove unnecessary memzero_explicit()
In-Reply-To: <20200413211550.8307-3-longman@redhat.com>
References: <20200413211550.8307-1-longman@redhat.com>
 <20200413211550.8307-3-longman@redhat.com>
Message-ID: <efd6ceb1f182aa7364e9706422768a1c1335aee4.camel@perches.com>

On Mon, 2020-04-13 at 17:15 -0400, Waiman Long wrote:
> Since kfree_sensitive() will do an implicit memzero_explicit(), there
> is no need to call memzero_explicit() before it. Eliminate those
> memzero_explicit() and simplify the call sites.

2 bits of trivia:

> diff --git a/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c b/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c
[]
> @@ -391,10 +388,7 @@ int sun8i_ce_aes_setkey(struct crypto_skcipher *tfm, const u8 *key,
>  		dev_dbg(ce->dev, "ERROR: Invalid keylen %u\n", keylen);
>  		return -EINVAL;
>  	}
> -	if (op->key) {
> -		memzero_explicit(op->key, op->keylen);
> -		kfree(op->key);
> -	}
> +	kfree_sensitive(op->key);
>  	op->keylen = keylen;
>  	op->key = kmemdup(key, keylen, GFP_KERNEL | GFP_DMA);
>  	if (!op->key)

It might be a defect to set op->keylen before the kmemdup succeeds.

> @@ -416,10 +410,7 @@ int sun8i_ce_des3_setkey(struct crypto_skcipher *tfm, const u8 *key,
>  	if (err)
>  		return err;
>  
> -	if (op->key) {
> -		memzero_explicit(op->key, op->keylen);
> -		kfree(op->key);
> -	}
> +	free_sensitive(op->key, op->keylen);

Why not kfree_sensitive(op->key) ?



From longman at redhat.com  Mon Apr 13 23:52:24 2020
From: longman at redhat.com (Waiman Long)
Date: Mon, 13 Apr 2020 17:52:24 -0400
Subject: [PATCH 2/2] crypto: Remove unnecessary memzero_explicit()
In-Reply-To: <efd6ceb1f182aa7364e9706422768a1c1335aee4.camel@perches.com>
References: <20200413211550.8307-1-longman@redhat.com>
 <20200413211550.8307-3-longman@redhat.com>
 <efd6ceb1f182aa7364e9706422768a1c1335aee4.camel@perches.com>
Message-ID: <7e13a94b-2e92-850f-33f7-0f42cfcd9009@redhat.com>

On 4/13/20 5:31 PM, Joe Perches wrote:
> On Mon, 2020-04-13 at 17:15 -0400, Waiman Long wrote:
>> Since kfree_sensitive() will do an implicit memzero_explicit(), there
>> is no need to call memzero_explicit() before it. Eliminate those
>> memzero_explicit() and simplify the call sites.
> 2 bits of trivia:
>
>> diff --git a/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c b/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c
> []
>> @@ -391,10 +388,7 @@ int sun8i_ce_aes_setkey(struct crypto_skcipher *tfm, const u8 *key,
>>  		dev_dbg(ce->dev, "ERROR: Invalid keylen %u\n", keylen);
>>  		return -EINVAL;
>>  	}
>> -	if (op->key) {
>> -		memzero_explicit(op->key, op->keylen);
>> -		kfree(op->key);
>> -	}
>> +	kfree_sensitive(op->key);
>>  	op->keylen = keylen;
>>  	op->key = kmemdup(key, keylen, GFP_KERNEL | GFP_DMA);
>>  	if (!op->key)
> It might be a defect to set op->keylen before the kmemdup succeeds.
It could be. I can move it down after the op->key check.
>> @@ -416,10 +410,7 @@ int sun8i_ce_des3_setkey(struct crypto_skcipher *tfm, const u8 *key,
>>  	if (err)
>>  		return err;
>>  
>> -	if (op->key) {
>> -		memzero_explicit(op->key, op->keylen);
>> -		kfree(op->key);
>> -	}
>> +	free_sensitive(op->key, op->keylen);
> Why not kfree_sensitive(op->key) ?

Oh, it is a bug. I will send out v2 to fix that.

Thanks for spotting it.

Cheers,
Longman


>
>


From longman at redhat.com  Tue Apr 14 00:28:46 2020
From: longman at redhat.com (Waiman Long)
Date: Mon, 13 Apr 2020 18:28:46 -0400
Subject: [PATCH v2 2/2] crypto: Remove unnecessary memzero_explicit()
In-Reply-To: <20200413211550.8307-1-longman@redhat.com>
References: <20200413211550.8307-1-longman@redhat.com>
Message-ID: <20200413222846.24240-1-longman@redhat.com>

Since kfree_sensitive() will do an implicit memzero_explicit(), there
is no need to call memzero_explicit() before it. Eliminate those
memzero_explicit() and simplify the call sites. For better correctness,
the setting of keylen is also moved down after the key pointer check.

Signed-off-by: Waiman Long <longman at redhat.com>
---
 .../allwinner/sun8i-ce/sun8i-ce-cipher.c      | 19 +++++-------------
 .../allwinner/sun8i-ss/sun8i-ss-cipher.c      | 20 +++++--------------
 drivers/crypto/amlogic/amlogic-gxl-cipher.c   | 12 +++--------
 drivers/crypto/inside-secure/safexcel_hash.c  |  3 +--
 4 files changed, 14 insertions(+), 40 deletions(-)

diff --git a/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c b/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c
index aa4e8fdc2b32..8358fac98719 100644
--- a/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c
+++ b/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c
@@ -366,10 +366,7 @@ void sun8i_ce_cipher_exit(struct crypto_tfm *tfm)
 {
 	struct sun8i_cipher_tfm_ctx *op = crypto_tfm_ctx(tfm);
 
-	if (op->key) {
-		memzero_explicit(op->key, op->keylen);
-		kfree(op->key);
-	}
+	kfree_sensitive(op->key);
 	crypto_free_sync_skcipher(op->fallback_tfm);
 	pm_runtime_put_sync_suspend(op->ce->dev);
 }
@@ -391,14 +388,11 @@ int sun8i_ce_aes_setkey(struct crypto_skcipher *tfm, const u8 *key,
 		dev_dbg(ce->dev, "ERROR: Invalid keylen %u\n", keylen);
 		return -EINVAL;
 	}
-	if (op->key) {
-		memzero_explicit(op->key, op->keylen);
-		kfree(op->key);
-	}
-	op->keylen = keylen;
+	kfree_sensitive(op->key);
 	op->key = kmemdup(key, keylen, GFP_KERNEL | GFP_DMA);
 	if (!op->key)
 		return -ENOMEM;
+	op->keylen = keylen;
 
 	crypto_sync_skcipher_clear_flags(op->fallback_tfm, CRYPTO_TFM_REQ_MASK);
 	crypto_sync_skcipher_set_flags(op->fallback_tfm, tfm->base.crt_flags & CRYPTO_TFM_REQ_MASK);
@@ -416,14 +410,11 @@ int sun8i_ce_des3_setkey(struct crypto_skcipher *tfm, const u8 *key,
 	if (err)
 		return err;
 
-	if (op->key) {
-		memzero_explicit(op->key, op->keylen);
-		kfree(op->key);
-	}
-	op->keylen = keylen;
+	kfree_sensitive(op->key);
 	op->key = kmemdup(key, keylen, GFP_KERNEL | GFP_DMA);
 	if (!op->key)
 		return -ENOMEM;
+	op->keylen = keylen;
 
 	crypto_sync_skcipher_clear_flags(op->fallback_tfm, CRYPTO_TFM_REQ_MASK);
 	crypto_sync_skcipher_set_flags(op->fallback_tfm, tfm->base.crt_flags & CRYPTO_TFM_REQ_MASK);
diff --git a/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-cipher.c b/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-cipher.c
index 5246ef4f5430..0495fbc27fcc 100644
--- a/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-cipher.c
+++ b/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-cipher.c
@@ -249,7 +249,6 @@ static int sun8i_ss_cipher(struct skcipher_request *areq)
 			offset = areq->cryptlen - ivsize;
 			if (rctx->op_dir & SS_DECRYPTION) {
 				memcpy(areq->iv, backup_iv, ivsize);
-				memzero_explicit(backup_iv, ivsize);
 				kfree_sensitive(backup_iv);
 			} else {
 				scatterwalk_map_and_copy(areq->iv, areq->dst, offset,
@@ -367,10 +366,7 @@ void sun8i_ss_cipher_exit(struct crypto_tfm *tfm)
 {
 	struct sun8i_cipher_tfm_ctx *op = crypto_tfm_ctx(tfm);
 
-	if (op->key) {
-		memzero_explicit(op->key, op->keylen);
-		kfree(op->key);
-	}
+	kfree_sensitive(op->key);
 	crypto_free_sync_skcipher(op->fallback_tfm);
 	pm_runtime_put_sync(op->ss->dev);
 }
@@ -392,14 +388,11 @@ int sun8i_ss_aes_setkey(struct crypto_skcipher *tfm, const u8 *key,
 		dev_dbg(ss->dev, "ERROR: Invalid keylen %u\n", keylen);
 		return -EINVAL;
 	}
-	if (op->key) {
-		memzero_explicit(op->key, op->keylen);
-		kfree(op->key);
-	}
-	op->keylen = keylen;
+	kfree_sensitive(op->key);
 	op->key = kmemdup(key, keylen, GFP_KERNEL | GFP_DMA);
 	if (!op->key)
 		return -ENOMEM;
+	op->keylen = keylen;
 
 	crypto_sync_skcipher_clear_flags(op->fallback_tfm, CRYPTO_TFM_REQ_MASK);
 	crypto_sync_skcipher_set_flags(op->fallback_tfm, tfm->base.crt_flags & CRYPTO_TFM_REQ_MASK);
@@ -418,14 +411,11 @@ int sun8i_ss_des3_setkey(struct crypto_skcipher *tfm, const u8 *key,
 		return -EINVAL;
 	}
 
-	if (op->key) {
-		memzero_explicit(op->key, op->keylen);
-		kfree(op->key);
-	}
-	op->keylen = keylen;
+	kfree_sensitive(op->key);
 	op->key = kmemdup(key, keylen, GFP_KERNEL | GFP_DMA);
 	if (!op->key)
 		return -ENOMEM;
+	op->keylen = keylen;
 
 	crypto_sync_skcipher_clear_flags(op->fallback_tfm, CRYPTO_TFM_REQ_MASK);
 	crypto_sync_skcipher_set_flags(op->fallback_tfm, tfm->base.crt_flags & CRYPTO_TFM_REQ_MASK);
diff --git a/drivers/crypto/amlogic/amlogic-gxl-cipher.c b/drivers/crypto/amlogic/amlogic-gxl-cipher.c
index fd1269900d67..6aa9ce7bbbd4 100644
--- a/drivers/crypto/amlogic/amlogic-gxl-cipher.c
+++ b/drivers/crypto/amlogic/amlogic-gxl-cipher.c
@@ -341,10 +341,7 @@ void meson_cipher_exit(struct crypto_tfm *tfm)
 {
 	struct meson_cipher_tfm_ctx *op = crypto_tfm_ctx(tfm);
 
-	if (op->key) {
-		memzero_explicit(op->key, op->keylen);
-		kfree(op->key);
-	}
+	kfree_sensitive(op->key);
 	crypto_free_sync_skcipher(op->fallback_tfm);
 }
 
@@ -368,14 +365,11 @@ int meson_aes_setkey(struct crypto_skcipher *tfm, const u8 *key,
 		dev_dbg(mc->dev, "ERROR: Invalid keylen %u\n", keylen);
 		return -EINVAL;
 	}
-	if (op->key) {
-		memzero_explicit(op->key, op->keylen);
-		kfree(op->key);
-	}
-	op->keylen = keylen;
+	kfree_sensitive(op->key);
 	op->key = kmemdup(key, keylen, GFP_KERNEL | GFP_DMA);
 	if (!op->key)
 		return -ENOMEM;
+	op->keylen = keylen;
 
 	return crypto_sync_skcipher_setkey(op->fallback_tfm, key, keylen);
 }
diff --git a/drivers/crypto/inside-secure/safexcel_hash.c b/drivers/crypto/inside-secure/safexcel_hash.c
index 43962bc709c6..4a2d162914de 100644
--- a/drivers/crypto/inside-secure/safexcel_hash.c
+++ b/drivers/crypto/inside-secure/safexcel_hash.c
@@ -1081,8 +1081,7 @@ static int safexcel_hmac_init_pad(struct ahash_request *areq,
 		}
 
 		/* Avoid leaking */
-		memzero_explicit(keydup, keylen);
-		kfree(keydup);
+		kfree_sensitive(keydup);
 
 		if (ret)
 			return ret;
-- 
2.18.1


From rientjes at google.com  Tue Apr 14 02:29:58 2020
From: rientjes at google.com (David Rientjes)
Date: Mon, 13 Apr 2020 17:29:58 -0700 (PDT)
Subject: [PATCH 1/2] mm, treewide: Rename kzfree() to kfree_sensitive()
In-Reply-To: <20200413211550.8307-2-longman@redhat.com>
References: <20200413211550.8307-1-longman@redhat.com>
 <20200413211550.8307-2-longman@redhat.com>
Message-ID: <alpine.DEB.2.21.2004131729410.260270@chino.kir.corp.google.com>

On Mon, 13 Apr 2020, Waiman Long wrote:

> As said by Linus:
> 
>   A symmetric naming is only helpful if it implies symmetries in use.
>   Otherwise it's actively misleading.
> 
>   In "kzalloc()", the z is meaningful and an important part of what the
>   caller wants.
> 
>   In "kzfree()", the z is actively detrimental, because maybe in the
>   future we really _might_ want to use that "memfill(0xdeadbeef)" or
>   something. The "zero" part of the interface isn't even _relevant_.
> 
> The main reason that kzfree() exists is to clear sensitive information
> that should not be leaked to other future users of the same memory
> objects.
> 
> Rename kzfree() to kfree_sensitive() to follow the example of the
> recently added kvfree_sensitive() and make the intention of the API
> more explicit. In addition, memzero_explicit() is used to clear the
> memory to make sure that it won't get optimized away by the compiler.
> 
> The renaming is done by using the command sequence:
> 
>   git grep -w --name-only kzfree |\
>   xargs sed -i 's/\bkzfree\b/kfree_sensitive/'
> 
> followed by some editing of the kfree_sensitive() kerneldoc and the
> use of memzero_explicit() instead of memset().
> 
> Suggested-by: Joe Perches <joe at perches.com>
> Signed-off-by: Waiman Long <longman at redhat.com>

Acked-by: David Rientjes <rientjes at google.com>

From christophe.leroy at c-s.fr  Tue Apr 14 08:08:22 2020
From: christophe.leroy at c-s.fr (Christophe Leroy)
Date: Tue, 14 Apr 2020 08:08:22 +0200
Subject: [PATCH v2 2/2] crypto: Remove unnecessary memzero_explicit()
In-Reply-To: <20200413222846.24240-1-longman@redhat.com>
References: <20200413211550.8307-1-longman@redhat.com>
 <20200413222846.24240-1-longman@redhat.com>
Message-ID: <eca85e0b-0af3-c43a-31e4-bd5c3f519798@c-s.fr>



Le 14/04/2020 ? 00:28, Waiman Long a ?crit?:
> Since kfree_sensitive() will do an implicit memzero_explicit(), there
> is no need to call memzero_explicit() before it. Eliminate those
> memzero_explicit() and simplify the call sites. For better correctness,
> the setting of keylen is also moved down after the key pointer check.
> 
> Signed-off-by: Waiman Long <longman at redhat.com>
> ---
>   .../allwinner/sun8i-ce/sun8i-ce-cipher.c      | 19 +++++-------------
>   .../allwinner/sun8i-ss/sun8i-ss-cipher.c      | 20 +++++--------------
>   drivers/crypto/amlogic/amlogic-gxl-cipher.c   | 12 +++--------
>   drivers/crypto/inside-secure/safexcel_hash.c  |  3 +--
>   4 files changed, 14 insertions(+), 40 deletions(-)
> 
> diff --git a/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c b/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c
> index aa4e8fdc2b32..8358fac98719 100644
> --- a/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c
> +++ b/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c
> @@ -366,10 +366,7 @@ void sun8i_ce_cipher_exit(struct crypto_tfm *tfm)
>   {
>   	struct sun8i_cipher_tfm_ctx *op = crypto_tfm_ctx(tfm);
>   
> -	if (op->key) {
> -		memzero_explicit(op->key, op->keylen);
> -		kfree(op->key);
> -	}
> +	kfree_sensitive(op->key);
>   	crypto_free_sync_skcipher(op->fallback_tfm);
>   	pm_runtime_put_sync_suspend(op->ce->dev);
>   }
> @@ -391,14 +388,11 @@ int sun8i_ce_aes_setkey(struct crypto_skcipher *tfm, const u8 *key,
>   		dev_dbg(ce->dev, "ERROR: Invalid keylen %u\n", keylen);
>   		return -EINVAL;
>   	}
> -	if (op->key) {
> -		memzero_explicit(op->key, op->keylen);
> -		kfree(op->key);
> -	}
> -	op->keylen = keylen;
> +	kfree_sensitive(op->key);
>   	op->key = kmemdup(key, keylen, GFP_KERNEL | GFP_DMA);
>   	if (!op->key)
>   		return -ENOMEM;
> +	op->keylen = keylen;

Does it matter at all to ensure op->keylen is not set when of->key is 
NULL ? I'm not sure.

But if it does, then op->keylen should be set to 0 when freeing op->key.

>   
>   	crypto_sync_skcipher_clear_flags(op->fallback_tfm, CRYPTO_TFM_REQ_MASK);
>   	crypto_sync_skcipher_set_flags(op->fallback_tfm, tfm->base.crt_flags & CRYPTO_TFM_REQ_MASK);
> @@ -416,14 +410,11 @@ int sun8i_ce_des3_setkey(struct crypto_skcipher *tfm, const u8 *key,
>   	if (err)
>   		return err;
>   
> -	if (op->key) {
> -		memzero_explicit(op->key, op->keylen);
> -		kfree(op->key);
> -	}
> -	op->keylen = keylen;
> +	kfree_sensitive(op->key);
>   	op->key = kmemdup(key, keylen, GFP_KERNEL | GFP_DMA);
>   	if (!op->key)
>   		return -ENOMEM;
> +	op->keylen = keylen;

Same comment as above.

>   
>   	crypto_sync_skcipher_clear_flags(op->fallback_tfm, CRYPTO_TFM_REQ_MASK);
>   	crypto_sync_skcipher_set_flags(op->fallback_tfm, tfm->base.crt_flags & CRYPTO_TFM_REQ_MASK);
> diff --git a/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-cipher.c b/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-cipher.c
> index 5246ef4f5430..0495fbc27fcc 100644
> --- a/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-cipher.c
> +++ b/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-cipher.c
> @@ -249,7 +249,6 @@ static int sun8i_ss_cipher(struct skcipher_request *areq)
>   			offset = areq->cryptlen - ivsize;
>   			if (rctx->op_dir & SS_DECRYPTION) {
>   				memcpy(areq->iv, backup_iv, ivsize);
> -				memzero_explicit(backup_iv, ivsize);
>   				kfree_sensitive(backup_iv);
>   			} else {
>   				scatterwalk_map_and_copy(areq->iv, areq->dst, offset,
> @@ -367,10 +366,7 @@ void sun8i_ss_cipher_exit(struct crypto_tfm *tfm)
>   {
>   	struct sun8i_cipher_tfm_ctx *op = crypto_tfm_ctx(tfm);
>   
> -	if (op->key) {
> -		memzero_explicit(op->key, op->keylen);
> -		kfree(op->key);
> -	}
> +	kfree_sensitive(op->key);
>   	crypto_free_sync_skcipher(op->fallback_tfm);
>   	pm_runtime_put_sync(op->ss->dev);
>   }
> @@ -392,14 +388,11 @@ int sun8i_ss_aes_setkey(struct crypto_skcipher *tfm, const u8 *key,
>   		dev_dbg(ss->dev, "ERROR: Invalid keylen %u\n", keylen);
>   		return -EINVAL;
>   	}
> -	if (op->key) {
> -		memzero_explicit(op->key, op->keylen);
> -		kfree(op->key);
> -	}
> -	op->keylen = keylen;
> +	kfree_sensitive(op->key);
>   	op->key = kmemdup(key, keylen, GFP_KERNEL | GFP_DMA);
>   	if (!op->key)
>   		return -ENOMEM;
> +	op->keylen = keylen;

Same comment as above.

>   
>   	crypto_sync_skcipher_clear_flags(op->fallback_tfm, CRYPTO_TFM_REQ_MASK);
>   	crypto_sync_skcipher_set_flags(op->fallback_tfm, tfm->base.crt_flags & CRYPTO_TFM_REQ_MASK);
> @@ -418,14 +411,11 @@ int sun8i_ss_des3_setkey(struct crypto_skcipher *tfm, const u8 *key,
>   		return -EINVAL;
>   	}
>   
> -	if (op->key) {
> -		memzero_explicit(op->key, op->keylen);
> -		kfree(op->key);
> -	}
> -	op->keylen = keylen;
> +	kfree_sensitive(op->key);
>   	op->key = kmemdup(key, keylen, GFP_KERNEL | GFP_DMA);
>   	if (!op->key)
>   		return -ENOMEM;
> +	op->keylen = keylen;

Same comment as above.

>   
>   	crypto_sync_skcipher_clear_flags(op->fallback_tfm, CRYPTO_TFM_REQ_MASK);
>   	crypto_sync_skcipher_set_flags(op->fallback_tfm, tfm->base.crt_flags & CRYPTO_TFM_REQ_MASK);
> diff --git a/drivers/crypto/amlogic/amlogic-gxl-cipher.c b/drivers/crypto/amlogic/amlogic-gxl-cipher.c
> index fd1269900d67..6aa9ce7bbbd4 100644
> --- a/drivers/crypto/amlogic/amlogic-gxl-cipher.c
> +++ b/drivers/crypto/amlogic/amlogic-gxl-cipher.c
> @@ -341,10 +341,7 @@ void meson_cipher_exit(struct crypto_tfm *tfm)
>   {
>   	struct meson_cipher_tfm_ctx *op = crypto_tfm_ctx(tfm);
>   
> -	if (op->key) {
> -		memzero_explicit(op->key, op->keylen);
> -		kfree(op->key);
> -	}
> +	kfree_sensitive(op->key);
>   	crypto_free_sync_skcipher(op->fallback_tfm);
>   }
>   
> @@ -368,14 +365,11 @@ int meson_aes_setkey(struct crypto_skcipher *tfm, const u8 *key,
>   		dev_dbg(mc->dev, "ERROR: Invalid keylen %u\n", keylen);
>   		return -EINVAL;
>   	}
> -	if (op->key) {
> -		memzero_explicit(op->key, op->keylen);
> -		kfree(op->key);
> -	}
> -	op->keylen = keylen;
> +	kfree_sensitive(op->key);
>   	op->key = kmemdup(key, keylen, GFP_KERNEL | GFP_DMA);
>   	if (!op->key)
>   		return -ENOMEM;
> +	op->keylen = keylen;

Same comment as above.

>   
>   	return crypto_sync_skcipher_setkey(op->fallback_tfm, key, keylen);
>   }
> diff --git a/drivers/crypto/inside-secure/safexcel_hash.c b/drivers/crypto/inside-secure/safexcel_hash.c
> index 43962bc709c6..4a2d162914de 100644
> --- a/drivers/crypto/inside-secure/safexcel_hash.c
> +++ b/drivers/crypto/inside-secure/safexcel_hash.c
> @@ -1081,8 +1081,7 @@ static int safexcel_hmac_init_pad(struct ahash_request *areq,
>   		}
>   
>   		/* Avoid leaking */
> -		memzero_explicit(keydup, keylen);
> -		kfree(keydup);
> +		kfree_sensitive(keydup);
>   
>   		if (ret)
>   			return ret;
> 


Christophe

From payloadbob at outlook.com  Thu Apr  9 16:30:27 2020
From: payloadbob at outlook.com (payload bob)
Date: Thu, 9 Apr 2020 14:30:27 +0000
Subject: Log debug packets
Message-ID: <DB6PR05MB3461934909D9B35E222450B7DDC10@DB6PR05MB3461.eurprd05.prod.outlook.com>

 Hi.

With debugging enabled you can log all kinds of stuff like malformed or replayed packets. However, debugging only tells you that something went wrong but it does not really show the cause.
It would be really nice if you could log those packets so you know exactly which packet caused an issue. Wireguard already knows about those. With external tools you would need to do lots of extra parsing and basically do everything twice. Also, I don't know to which extend tools like tcpdump/wireshark/iptables for logging traffic could handle all possible wireguard errors.

Regards.

From mike at pmfarmwald.com  Sat Apr 11 21:13:36 2020
From: mike at pmfarmwald.com (mike at pmfarmwald.com)
Date: Sat, 11 Apr 2020 12:13:36 -0700
Subject: Is there a way to use wireguard as a non-encrypted VPN?
Message-ID: <9a3401d61035$4d6b5840$e84208c0$@pmfarmwald.com>

I have some older routers that run OpenWRT just fine, but are a bit slow at
Wireguard (3-5 MBytes/s for SMB transfers) and which are too slow for
playing HD movies.
For these routers/uses I don't care about security, I just want a VPN to
tunnel (thru Comcast, and other ISPs that block lots of ports.)
If there was a way to use Wiireguard?with encryption disabled, I'm pretty
sure my performance would be closer to 20-50 MB/s which would be more than
adequate.
Thanks.
Mike Farmwald




From szaimen at e.mail.de  Tue Apr 14 03:04:58 2020
From: szaimen at e.mail.de (szaimen)
Date: Tue, 14 Apr 2020 01:04:58 +0000
Subject: QR-Code support for Wireguard-Windows
Message-ID: <08eb74400f4d94855ffd4390ac4a9eb3@e.mail.de>

Hi,

I would like to propose a feature request specifically for the Wireguard-Windows client but
probably also for other desktop-clients; I hope this is the appropriate way of doing this since the
issue category seems to be disabled on github for this repo.

I really would like to see getting QR-Code Support for the Wireguard-Windows client since most
laptops where you are most likely using wireguard on have a camera and could propably use it to get
the connection infos directly from the server without having to copy it to the specific device.
(e.g. when not having a second PC, this could work if you connect with your smartphone to your
server over vnc and scan then with the laptop-camea the qr code from your smartphone)

This would be really awesome!

Thank you!

From Jason at zx2c4.com  Tue Apr 14 10:32:03 2020
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Tue, 14 Apr 2020 02:32:03 -0600
Subject: [PATCH 1/2] mm, treewide: Rename kzfree() to kfree_sensitive()
In-Reply-To: <20200413211550.8307-2-longman@redhat.com>
References: <20200413211550.8307-1-longman@redhat.com>
 <20200413211550.8307-2-longman@redhat.com>
Message-ID: <4babf834-c531-50ba-53f6-e88410b15ce3@zx2c4.com>

On 4/13/20 3:15 PM, Waiman Long wrote:
> As said by Linus:
> 
>    A symmetric naming is only helpful if it implies symmetries in use.
>    Otherwise it's actively misleading.
> 
>    In "kzalloc()", the z is meaningful and an important part of what the
>    caller wants.
> 
>    In "kzfree()", the z is actively detrimental, because maybe in the
>    future we really _might_ want to use that "memfill(0xdeadbeef)" or
>    something. The "zero" part of the interface isn't even _relevant_.
> 
> The main reason that kzfree() exists is to clear sensitive information
> that should not be leaked to other future users of the same memory
> objects.
> 
> Rename kzfree() to kfree_sensitive() to follow the example of the
> recently added kvfree_sensitive() and make the intention of the API
> more explicit. 

Seems reasonable to me. One bikeshed, that you can safely discard and 
ignore as a mere bikeshed: kfree_memzero or kfree_scrub or 
kfree_{someverb} seems like a better function name, as it describes what 
the function does, rather than "_sensitive" that suggests something 
about the data maybe but who knows what that entails. If you disagree, 
not a big deal either way.

 > In addition, memzero_explicit() is used to clear the
 > memory to make sure that it won't get optimized away by the compiler.

This had occurred to me momentarily a number of years ago, but I was 
under the impression that the kernel presumes extern function calls to 
always imply a compiler barrier, making it difficult for the compiler to 
reason about what happens in/after kfree, in order to be able to 
optimize out the preceding memset. With LTO, that rule obviously 
changes. I guess new code should be written with cross-object 
optimizations in mind now a days? [Meanwhile, it would be sort of 
interesting to teach gcc about kfree to enable additional scary 
optimizations...]

From stromberg at mullvad.net  Tue Apr 14 10:53:52 2020
From: stromberg at mullvad.net (=?UTF-8?Q?Fredrik_Str=C3=B6mberg?=)
Date: Tue, 14 Apr 2020 10:53:52 +0200
Subject: Is there a way to use wireguard as a non-encrypted VPN?
In-Reply-To: <9a3401d61035$4d6b5840$e84208c0$@pmfarmwald.com>
References: <9a3401d61035$4d6b5840$e84208c0$@pmfarmwald.com>
Message-ID: <CANTUoeduOe9geMx05JxXdvPkT=FnNnYPuyxhC-XHUgOAPHyMgg@mail.gmail.com>

On Tue, Apr 14, 2020 at 10:30 AM <mike at pmfarmwald.com> wrote:
>
> I have some older routers that run OpenWRT just fine, but are a bit slow at
> Wireguard (3-5 MBytes/s for SMB transfers) and which are too slow for
> playing HD movies.
> For these routers/uses I don't care about security, I just want a VPN to
> tunnel (thru Comcast, and other ISPs that block lots of ports.)
> If there was a way to use Wiireguard with encryption disabled, I'm pretty
> sure my performance would be closer to 20-50 MB/s which would be more than
> adequate.
> Thanks.
> Mike Farmwald
>

Hi Mike,

No, WireGuard does not and will never support your use case of
disabling encryption.

If you are able to, buy a router that is powerful enough to do
WireGuard at your preferred throughput. Otherwise you would need to
use other encapsulation methods. OpenVPN with hardware AES
acceleration might work (if your routers support that). However
OpenVPN lives in userspace so it needs to do a memory copy from kernel
to userspace for each packet. I'm not sure how the performance will
work out in practice.

If you look at other methods you might want to consider the state of
its maintenance. PPTP code is likely to be very old and unmaintained
for instance. Your router might very well end up hacked.

Cheers,
Fredrik Stromberg

From mhocko at kernel.org  Tue Apr 14 11:01:29 2020
From: mhocko at kernel.org (Michal Hocko)
Date: Tue, 14 Apr 2020 11:01:29 +0200
Subject: [PATCH 1/2] mm, treewide: Rename kzfree() to kfree_sensitive()
In-Reply-To: <20200413211550.8307-2-longman@redhat.com>
References: <20200413211550.8307-1-longman@redhat.com>
 <20200413211550.8307-2-longman@redhat.com>
Message-ID: <20200414090129.GE4629@dhcp22.suse.cz>

On Mon 13-04-20 17:15:49, Waiman Long wrote:
> As said by Linus:
> 
>   A symmetric naming is only helpful if it implies symmetries in use.
>   Otherwise it's actively misleading.
> 
>   In "kzalloc()", the z is meaningful and an important part of what the
>   caller wants.
> 
>   In "kzfree()", the z is actively detrimental, because maybe in the
>   future we really _might_ want to use that "memfill(0xdeadbeef)" or
>   something. The "zero" part of the interface isn't even _relevant_.
> 
> The main reason that kzfree() exists is to clear sensitive information
> that should not be leaked to other future users of the same memory
> objects.
> 
> Rename kzfree() to kfree_sensitive() to follow the example of the
> recently added kvfree_sensitive() and make the intention of the API
> more explicit. In addition, memzero_explicit() is used to clear the
> memory to make sure that it won't get optimized away by the compiler.
> 
> The renaming is done by using the command sequence:
> 
>   git grep -w --name-only kzfree |\
>   xargs sed -i 's/\bkzfree\b/kfree_sensitive/'
> 
> followed by some editing of the kfree_sensitive() kerneldoc and the
> use of memzero_explicit() instead of memset().
> 
> Suggested-by: Joe Perches <joe at perches.com>
> Signed-off-by: Waiman Long <longman at redhat.com>

Makes sense. I haven't checked all the conversions and will rely on the
script doing the right thing. The core MM part is correct.

Acked-by: Michal Hocko <mhocko at suse.com>
-- 
Michal Hocko
SUSE Labs

From Jason at zx2c4.com  Tue Apr 14 11:06:16 2020
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Tue, 14 Apr 2020 03:06:16 -0600
Subject: RHEL 7.8, Kernel 3.10: ratelimiter.c:25:1: error: unknown type
 name 'hsiphash_key_t'
In-Reply-To: <0312354a-8bdb-00b1-f342-092c71e4817c@gmx.net>
References: <0312354a-8bdb-00b1-f342-092c71e4817c@gmx.net>
Message-ID: <CAHmME9qdGhJsuruytK07c5V68iM=1vE0nD6vzqw3txGSzjOHCg@mail.gmail.com>

Hi Christian,

Thanks. Addressed here:
https://git.zx2c4.com/wireguard-linux-compat/commit/?id=c15894ad17cb0760471c2dd798bfbbea2081b4db
. I'll have a new release out shortly.

By the way, you'll have more reliability using the elrepo kmod these days:
https://lists.zx2c4.com/pipermail/wireguard/2020-April/005239.html

Jason

From Jason at zx2c4.com  Tue Apr 14 11:19:19 2020
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Tue, 14 Apr 2020 03:19:19 -0600
Subject: [ANNOUNCE] wireguard-linux-compat v1.0.20200413 released
Message-ID: <b9c8be5ee78f3f2f@mail.zx2c4.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hello,

A new version, v1.0.20200413, of the backported WireGuard kernel module for
3.10 <= Linux <= 5.5.y has been tagged in the git repository.

== Changes ==

  * compat: support latest suse 15.1 and 15.2
  * compat: support RHEL 7.8's faulty siphash backport
  * compat: error out if bc is missing
  * compat: backport hsiphash_1u32 for tests
  
  We now have improved support for RHEL 7.8, SUSE 15.[12], and Ubuntu 16.04.
  
  * git: add gitattributes so tarball doesn't have gitignore files
  
  Distros won't need to clean this up manually now.

This release contains commits from: Jason A. Donenfeld.

As always, the source is available at https://git.zx2c4.com/wireguard-linux-compat/
and information about the project is available at https://www.wireguard.com/ .

This version is available in compressed tarball form here:
  https://git.zx2c4.com/wireguard-linux-compat/snapshot/wireguard-linux-compat-1.0.20200413.tar.xz
  SHA2-256: 

A PGP signature of that file decompressed is available here:
  https://git.zx2c4.com/wireguard-linux-compat/snapshot/wireguard-linux-compat-1.0.20200413.tar.asc
  Signing key: AB9942E6D4A4CFC3412620A749FC7012A5DE03AE
  Remember to unxz the tarball before verifying the signature.

If you're a package maintainer, please bump your package version. If you're a
user, the WireGuard team welcomes any and all feedback on this latest version.

Finally, WireGuard development thrives on donations. By popular demand, we
have a webpage for this: https://www.wireguard.com/donations/

Thank you,
Jason Donenfeld


-----BEGIN PGP SIGNATURE-----

iQJEBAEBCAAuFiEEq5lC5tSkz8NBJiCnSfxwEqXeA64FAl6VgAEQHGphc29uQHp4
MmM0LmNvbQAKCRBJ/HASpd4DrmRXD/991+PYGqInXaED97SA2uD1yTjnACLipTwf
LSo3UoBW3PMwrKC8hGOZ8r/wuoC4dISiQGzD4fIzUVV+ASJ6VNvoVqkYN/Dx093i
KGwjbdV1f3mPXZZCa6VeltFwjqMsm64N/4172SGIEJ+v9NMi10NutMD5nU2T0oE1
XRoh/TCDW+04bTKZ6AFT8RQjR78XAhqmRJ0L8nMOGQisRuHmOlkgA/Y81IsONvLb
8Zcfhrs4E39Nj8lOLjrDgXI+7P4VbnzsKlr7K7YZQnOtkY7m6+43lYYv+2uXgju9
5UcL2kjZNgBQhB8KO/yJvoQ9LooJxoYazJjHHeViCjYxZwQ4hytkkdvN0uHsBaYa
RVfRRLQ1e524lVBGBtvwx7lmG2oBazuludTYriq+zqUcBoU7lnO60W8OKaCTsEXc
EGJ8PkTguFKfT0phgDko7mQ7a+nMWc3PzQqX7TEpx5e+ircjzixaPkLWydd67uxB
F5FS+DxI1WdLT0pO4LbSTsPay3t6Tp33yo/GwsZG2L3IHS2SHgKtZxbG1puoXM9q
P7krSoXKDUgkW5NasVbfwUvXVHxlultLJ9hkvSuPLq99RoVr4BuG7GCz+FzVHH39
hy/jXAc/gJsw7G5cVFZX2Dqk81g3vzc+2AO+KV0PSWxCx/vKyfMyULV52D+SFfz2
043kPGz6mg==
=AYdA
-----END PGP SIGNATURE-----

From Jason at zx2c4.com  Tue Apr 14 11:28:55 2020
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Tue, 14 Apr 2020 03:28:55 -0600
Subject: [ANNOUNCE] wireguard-linux-compat v1.0.20200413 released
In-Reply-To: <b9c8be5ee78f3f2f@mail.zx2c4.com>
References: <b9c8be5ee78f3f2f@mail.zx2c4.com>
Message-ID: <20200414092855.GA1962743@zx2c4.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


This missing hash from the previous email is:
  https://git.zx2c4.com/wireguard-linux-compat/snapshot/wireguard-linux-compat-1.0.20200413.tar.xz
  SHA2-256: cf166348fbb67419528e73049ce001d29131aea367fa6aef9d3e223f7251e116

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEq5lC5tSkz8NBJiCnSfxwEqXeA64FAl6Vgi8ACgkQSfxwEqXe
A65edQ//fcfg1TWDShOoZsIpabeoot0kbpLpWr5W98McesV19QRnsJTrzLYVU6Ro
yrt6JkAtJHOZlYkMMeoXwY8TvRh9njTTPCOlp6kPdKh8Fqh7RQ3eiKq0MgDK1s89
BZMo7QzHv/5jgbvqMkf5hsmyX7CWw0XG6mbQy3Git9NBbKu0XxzDtYpz/ztry1SV
EWCgDyzWV7hoQbjFmZvT90ODqJ84ybujkpHS1dRNC8j93trG9QdlsPIUlCIkDQr5
XyQbIi58TnZE+3fYdaLbBVwh9N27jdL8GZRGfM9UYdjI5mNZr2ui/aSEeHct0raN
PEGKIH3rD9zMfFqr69AtVlNx8FSrHxt7BboC3M+L4LG1sYHtFpLOPUvUErbLR1Xt
ysg4veVMhOFB2w8hZdSBNtyAOQQ5MT6NCN55BdiZVP8ofJF+85V+TOecXNG9CEvP
B9tK6SUhTIy6UQA1R+O1B5yvvMk22K4B6ewnCAWbO4drBvbgOewofNHdXLuyvNSO
NFlX9g2g2H/p7yn6R2Lz6vBZN7bb4tPyfcCKpFCj6I65RF95q/kQcLsVjYBrybUd
DLaWwbI6fdqKQbtwOR8MMGAmC2JZFIDUEzfewQ/Il2/096qwgUSZW0k7Lt5QF84w
7Eubeqd6BbnInXK2IXYdlw0rN4t7hz2q2NTGVymFo4r2qyiRet0=
=OucQ
-----END PGP SIGNATURE-----

From dhowells at redhat.com  Tue Apr 14 15:06:56 2020
From: dhowells at redhat.com (David Howells)
Date: Tue, 14 Apr 2020 14:06:56 +0100
Subject: [PATCH 1/2] mm, treewide: Rename kzfree() to kfree_sensitive()
In-Reply-To: <20200413211550.8307-2-longman@redhat.com>
References: <20200413211550.8307-2-longman@redhat.com>
 <20200413211550.8307-1-longman@redhat.com>
Message-ID: <3807474.1586869616@warthog.procyon.org.uk>

Waiman Long <longman at redhat.com> wrote:

> As said by Linus:
> 
>   A symmetric naming is only helpful if it implies symmetries in use.
>   Otherwise it's actively misleading.
> 
>   In "kzalloc()", the z is meaningful and an important part of what the
>   caller wants.
> 
>   In "kzfree()", the z is actively detrimental, because maybe in the
>   future we really _might_ want to use that "memfill(0xdeadbeef)" or
>   something. The "zero" part of the interface isn't even _relevant_.
> 
> The main reason that kzfree() exists is to clear sensitive information
> that should not be leaked to other future users of the same memory
> objects.
> 
> Rename kzfree() to kfree_sensitive() to follow the example of the
> recently added kvfree_sensitive() and make the intention of the API
> more explicit. In addition, memzero_explicit() is used to clear the
> memory to make sure that it won't get optimized away by the compiler.
> 
> The renaming is done by using the command sequence:
> 
>   git grep -w --name-only kzfree |\
>   xargs sed -i 's/\bkzfree\b/kfree_sensitive/'
> 
> followed by some editing of the kfree_sensitive() kerneldoc and the
> use of memzero_explicit() instead of memset().
> 
> Suggested-by: Joe Perches <joe at perches.com>
> Signed-off-by: Waiman Long <longman at redhat.com>

Since this changes a lot of crypto stuff, does it make sense for it to go via
the crypto tree?

Acked-by: David Howells <dhowells at redhat.com>


From wireguard at ajs124.de  Tue Apr 14 17:02:41 2020
From: wireguard at ajs124.de (ajs124)
Date: Tue, 14 Apr 2020 17:02:41 +0200
Subject: Is there a way to use wireguard as a non-encrypted VPN?
In-Reply-To: <9a3401d61035$4d6b5840$e84208c0$@pmfarmwald.com>
References: <9a3401d61035$4d6b5840$e84208c0$@pmfarmwald.com>
Message-ID: <20200414170241.2d9d5d6d@desk>

On Sat, 11 Apr 2020 12:13:36 -0700
<mike at pmfarmwald.com> wrote:

> I have some older routers that run OpenWRT just fine, but are a bit slow at
> Wireguard (3-5 MBytes/s for SMB transfers) and which are too slow for
> playing HD movies.
> For these routers/uses I don't care about security, I just want a VPN to
> tunnel (thru Comcast, and other ISPs that block lots of ports.)
> If there was a way to use Wiireguard?with encryption disabled, I'm pretty
> sure my performance would be closer to 20-50 MB/s which would be more than
> adequate.
> Thanks.
> Mike Farmwald
> 

If you're actually just looking for an unencrypted tunnel, there is some standardized stuff like GRE[1] or IP in IP[2] out there.

The Linux Kernel supports both of those natively and it looks to me like OpenWRT should be able to configure at least one of them through its interface.

1: https://en.wikipedia.org/wiki/Generic_Routing_Encapsulation
2: https://en.wikipedia.org/wiki/IP_in_IP

From rm at romanrm.net  Tue Apr 14 17:16:48 2020
From: rm at romanrm.net (Roman Mamedov)
Date: Tue, 14 Apr 2020 20:16:48 +0500
Subject: Is there a way to use wireguard as a non-encrypted VPN?
In-Reply-To: <20200414170241.2d9d5d6d@desk>
References: <9a3401d61035$4d6b5840$e84208c0$@pmfarmwald.com>
 <20200414170241.2d9d5d6d@desk>
Message-ID: <20200414201648.0c6eb3ae@natsu>

On Tue, 14 Apr 2020 17:02:41 +0200
ajs124 <wireguard at ajs124.de> wrote:

> On Sat, 11 Apr 2020 12:13:36 -0700
> <mike at pmfarmwald.com> wrote:
> 
> > I have some older routers that run OpenWRT just fine, but are a bit slow at
> > Wireguard (3-5 MBytes/s for SMB transfers) and which are too slow for
> > playing HD movies.
> > For these routers/uses I don't care about security, I just want a VPN to
> > tunnel (thru Comcast, and other ISPs that block lots of ports.)
> > If there was a way to use Wiireguard?with encryption disabled, I'm pretty
> > sure my performance would be closer to 20-50 MB/s which would be more than
> > adequate.
> > Thanks.
> > Mike Farmwald
> > 
> 
> If you're actually just looking for an unencrypted tunnel, there is some standardized stuff like GRE[1] or IP in IP[2] out there.
> 
> The Linux Kernel supports both of those natively and it looks to me like OpenWRT should be able to configure at least one of them through its interface.
> 
> 1: https://en.wikipedia.org/wiki/Generic_Routing_Encapsulation
> 2: https://en.wikipedia.org/wiki/IP_in_IP

Those both require dedicated IP on both ends of the connection, which is not
always the case on residential ISPs' IPv4 now.

I'd suggest to check out L2TP instead, which doesn't, and can be used without
encryption too, that one can work.

Or PPTP as mentioned, but it's more complex (separate signaling and data
protocols) for no good reason and has more issues traversing NATs/firewalls.

-- 
With respect,
Roman

From longman at redhat.com  Tue Apr 14 18:24:36 2020
From: longman at redhat.com (Waiman Long)
Date: Tue, 14 Apr 2020 12:24:36 -0400
Subject: [PATCH v2 2/2] crypto: Remove unnecessary memzero_explicit()
In-Reply-To: <eca85e0b-0af3-c43a-31e4-bd5c3f519798@c-s.fr>
References: <20200413211550.8307-1-longman@redhat.com>
 <20200413222846.24240-1-longman@redhat.com>
 <eca85e0b-0af3-c43a-31e4-bd5c3f519798@c-s.fr>
Message-ID: <e194a51f-a5e5-a557-c008-b08cac558572@redhat.com>

On 4/14/20 2:08 AM, Christophe Leroy wrote:
>
>
> Le 14/04/2020 ? 00:28, Waiman Long a ?crit?:
>> Since kfree_sensitive() will do an implicit memzero_explicit(), there
>> is no need to call memzero_explicit() before it. Eliminate those
>> memzero_explicit() and simplify the call sites. For better correctness,
>> the setting of keylen is also moved down after the key pointer check.
>>
>> Signed-off-by: Waiman Long <longman at redhat.com>
>> ---
>> ? .../allwinner/sun8i-ce/sun8i-ce-cipher.c????? | 19 +++++-------------
>> ? .../allwinner/sun8i-ss/sun8i-ss-cipher.c????? | 20 +++++--------------
>> ? drivers/crypto/amlogic/amlogic-gxl-cipher.c?? | 12 +++--------
>> ? drivers/crypto/inside-secure/safexcel_hash.c? |? 3 +--
>> ? 4 files changed, 14 insertions(+), 40 deletions(-)
>>
>> diff --git a/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c
>> b/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c
>> index aa4e8fdc2b32..8358fac98719 100644
>> --- a/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c
>> +++ b/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c
>> @@ -366,10 +366,7 @@ void sun8i_ce_cipher_exit(struct crypto_tfm *tfm)
>> ? {
>> ????? struct sun8i_cipher_tfm_ctx *op = crypto_tfm_ctx(tfm);
>> ? -??? if (op->key) {
>> -??????? memzero_explicit(op->key, op->keylen);
>> -??????? kfree(op->key);
>> -??? }
>> +??? kfree_sensitive(op->key);
>> ????? crypto_free_sync_skcipher(op->fallback_tfm);
>> ????? pm_runtime_put_sync_suspend(op->ce->dev);
>> ? }
>> @@ -391,14 +388,11 @@ int sun8i_ce_aes_setkey(struct crypto_skcipher
>> *tfm, const u8 *key,
>> ????????? dev_dbg(ce->dev, "ERROR: Invalid keylen %u\n", keylen);
>> ????????? return -EINVAL;
>> ????? }
>> -??? if (op->key) {
>> -??????? memzero_explicit(op->key, op->keylen);
>> -??????? kfree(op->key);
>> -??? }
>> -??? op->keylen = keylen;
>> +??? kfree_sensitive(op->key);
>> ????? op->key = kmemdup(key, keylen, GFP_KERNEL | GFP_DMA);
>> ????? if (!op->key)
>> ????????? return -ENOMEM;
>> +??? op->keylen = keylen;
>
> Does it matter at all to ensure op->keylen is not set when of->key is
> NULL ? I'm not sure.
>
> But if it does, then op->keylen should be set to 0 when freeing op->key. 

My thinking is that if memory allocation fails, we just don't touch
anything and return an error code. I will not explicitly set keylen to 0
in this case unless it is specified in the API documentation.

Cheers,
Longman


From longman at redhat.com  Tue Apr 14 20:26:48 2020
From: longman at redhat.com (Waiman Long)
Date: Tue, 14 Apr 2020 14:26:48 -0400
Subject: [PATCH 1/2] mm, treewide: Rename kzfree() to kfree_sensitive()
In-Reply-To: <20200414124854.GQ5920@twin.jikos.cz>
References: <20200413211550.8307-1-longman@redhat.com>
 <20200413211550.8307-2-longman@redhat.com>
 <20200414124854.GQ5920@twin.jikos.cz>
Message-ID: <3d8c80cb-68e5-9211-9eda-bc343ed7d894@redhat.com>

On 4/14/20 8:48 AM, David Sterba wrote:
> On Mon, Apr 13, 2020 at 05:15:49PM -0400, Waiman Long wrote:
>>  fs/btrfs/ioctl.c                              |  2 +-
>
>> diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
>> index 40b729dce91c..eab3f8510426 100644
>> --- a/fs/btrfs/ioctl.c
>> +++ b/fs/btrfs/ioctl.c
>> @@ -2691,7 +2691,7 @@ static int btrfs_ioctl_get_subvol_info(struct file *file, void __user *argp)
>>  	btrfs_put_root(root);
>>  out_free:
>>  	btrfs_free_path(path);
>> -	kzfree(subvol_info);
>> +	kfree_sensitive(subvol_info);
> This is not in a sensitive context so please switch it to plain kfree.
> With that you have my acked-by. Thanks.
>
Thanks for letting me know about. I think I will send it out as a
separate patch.

Cheers,
Longman


From longman at redhat.com  Tue Apr 14 21:37:51 2020
From: longman at redhat.com (Waiman Long)
Date: Tue, 14 Apr 2020 15:37:51 -0400
Subject: [PATCH v2 2/2] crypto: Remove unnecessary memzero_explicit()
In-Reply-To: <20200414191601.GZ25468@kitsune.suse.cz>
References: <20200413211550.8307-1-longman@redhat.com>
 <20200413222846.24240-1-longman@redhat.com>
 <eca85e0b-0af3-c43a-31e4-bd5c3f519798@c-s.fr>
 <e194a51f-a5e5-a557-c008-b08cac558572@redhat.com>
 <20200414191601.GZ25468@kitsune.suse.cz>
Message-ID: <578fe9b6-1ccd-2698-60aa-96c3f2dd2c31@redhat.com>

On 4/14/20 3:16 PM, Michal Such?nek wrote:
> On Tue, Apr 14, 2020 at 12:24:36PM -0400, Waiman Long wrote:
>> On 4/14/20 2:08 AM, Christophe Leroy wrote:
>>>
>>> Le 14/04/2020 ? 00:28, Waiman Long a ?crit?:
>>>> Since kfree_sensitive() will do an implicit memzero_explicit(), there
>>>> is no need to call memzero_explicit() before it. Eliminate those
>>>> memzero_explicit() and simplify the call sites. For better correctness,
>>>> the setting of keylen is also moved down after the key pointer check.
>>>>
>>>> Signed-off-by: Waiman Long <longman at redhat.com>
>>>> ---
>>>> ? .../allwinner/sun8i-ce/sun8i-ce-cipher.c????? | 19 +++++-------------
>>>> ? .../allwinner/sun8i-ss/sun8i-ss-cipher.c????? | 20 +++++--------------
>>>> ? drivers/crypto/amlogic/amlogic-gxl-cipher.c?? | 12 +++--------
>>>> ? drivers/crypto/inside-secure/safexcel_hash.c? |? 3 +--
>>>> ? 4 files changed, 14 insertions(+), 40 deletions(-)
>>>>
>>>> diff --git a/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c
>>>> b/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c
>>>> index aa4e8fdc2b32..8358fac98719 100644
>>>> --- a/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c
>>>> +++ b/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c
>>>> @@ -366,10 +366,7 @@ void sun8i_ce_cipher_exit(struct crypto_tfm *tfm)
>>>> ? {
>>>> ????? struct sun8i_cipher_tfm_ctx *op = crypto_tfm_ctx(tfm);
>>>> ? -??? if (op->key) {
>>>> -??????? memzero_explicit(op->key, op->keylen);
>>>> -??????? kfree(op->key);
>>>> -??? }
>>>> +??? kfree_sensitive(op->key);
>>>> ????? crypto_free_sync_skcipher(op->fallback_tfm);
>>>> ????? pm_runtime_put_sync_suspend(op->ce->dev);
>>>> ? }
>>>> @@ -391,14 +388,11 @@ int sun8i_ce_aes_setkey(struct crypto_skcipher
>>>> *tfm, const u8 *key,
>>>> ????????? dev_dbg(ce->dev, "ERROR: Invalid keylen %u\n", keylen);
>>>> ????????? return -EINVAL;
>>>> ????? }
>>>> -??? if (op->key) {
>>>> -??????? memzero_explicit(op->key, op->keylen);
>>>> -??????? kfree(op->key);
>>>> -??? }
>>>> -??? op->keylen = keylen;
>>>> +??? kfree_sensitive(op->key);
>>>> ????? op->key = kmemdup(key, keylen, GFP_KERNEL | GFP_DMA);
>>>> ????? if (!op->key)
>>>> ????????? return -ENOMEM;
>>>> +??? op->keylen = keylen;
>>> Does it matter at all to ensure op->keylen is not set when of->key is
>>> NULL ? I'm not sure.
>>>
>>> But if it does, then op->keylen should be set to 0 when freeing op->key. 
>> My thinking is that if memory allocation fails, we just don't touch
>> anything and return an error code. I will not explicitly set keylen to 0
>> in this case unless it is specified in the API documentation.
> You already freed the key by now so not touching anything is not
> possible. The key is set to NULL on allocation failure so setting keylen
> to 0 should be redundant. However, setting keylen to 0 is consisent with
> not having a key, and it avoids the possibility of leaking the length
> later should that ever cause any problem.

OK, I can change it to clear the key length when the allocation failed
which isn't likely.

Cheers,
Longman



From joe at perches.com  Tue Apr 14 21:44:49 2020
From: joe at perches.com (Joe Perches)
Date: Tue, 14 Apr 2020 12:44:49 -0700
Subject: [PATCH v2 2/2] crypto: Remove unnecessary memzero_explicit()
In-Reply-To: <578fe9b6-1ccd-2698-60aa-96c3f2dd2c31@redhat.com>
References: <20200413211550.8307-1-longman@redhat.com>
 <20200413222846.24240-1-longman@redhat.com>
 <eca85e0b-0af3-c43a-31e4-bd5c3f519798@c-s.fr>
 <e194a51f-a5e5-a557-c008-b08cac558572@redhat.com>
 <20200414191601.GZ25468@kitsune.suse.cz>
 <578fe9b6-1ccd-2698-60aa-96c3f2dd2c31@redhat.com>
Message-ID: <2a58f592879cf67b4c6b8e859ce87e1f9652902a.camel@perches.com>

On Tue, 2020-04-14 at 15:37 -0400, Waiman Long wrote:
> OK, I can change it to clear the key length when the allocation failed
> which isn't likely.


Perhaps:

	kfree_sensitive(op->key);
	op->key = NULL;
	op->keylen = 0;

but I don't know that it impacts any possible state.



From stunnel at attglobal.net  Wed Apr 15 18:22:21 2020
From: stunnel at attglobal.net (Eddie)
Date: Wed, 15 Apr 2020 09:22:21 -0700
Subject: kmod-wireguard 20200413 fails transaction check
Message-ID: <50d9516e-9546-07ce-d0f4-434e5893f2a9@attglobal.net>

Hi,

I'm running a Nethserver box, which is built on top of CentOS 7. Trying 
to update to the latest wireguard throws the following:

Resolving Dependencies
--> Running transaction check
---> Package kmod-wireguard.x86_64 0:1.0.20200401-1.el7_7.elrepo will be 
updated
---> Package kmod-wireguard.x86_64 0:1.0.20200413-1.el7_8.elrepo will be 
an update
--> Processing Dependency: kernel(siphash_4u64) = 0xdb8b9061 for 
package: kmod-wireguard-1.0.20200413-1.el7_8.elrepo.x86_64
--> Processing Dependency: kernel(siphash_3u32) = 0x04e11789 for 
package: kmod-wireguard-1.0.20200413-1.el7_8.elrepo.x86_64
--> Processing Dependency: kernel(siphash_1u64) = 0x0680ac30 for 
package: kmod-wireguard-1.0.20200413-1.el7_8.elrepo.x86_64
--> Finished Dependency Resolution
Error: Package: kmod-wireguard-1.0.20200413-1.el7_8.elrepo.x86_64 (elrepo)
 ?????????? Requires: kernel(siphash_3u32) = 0x04e11789
Error: Package: kmod-wireguard-1.0.20200413-1.el7_8.elrepo.x86_64 (elrepo)
 ?????????? Requires: kernel(siphash_4u64) = 0xdb8b9061
Error: Package: kmod-wireguard-1.0.20200413-1.el7_8.elrepo.x86_64 (elrepo)
 ?????????? Requires: kernel(siphash_1u64) = 0x0680ac30
 ?You could try using --skip-broken to work around the problem
 ?You could try running: rpm -Va --nofiles --nodigest

It's currently running this:

uname -a
Linux Nethserver.BogoLinux.net 3.10.0-1062.12.1.el7.x86_64 #1 SMP Tue 
Feb 4 23:02:59 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

But there is an update to this, which I haven't had time to install yet:

kernel                 x86_64 3.10.0-1062.18.1.el7


Do I need to wait until after the kernel update to update wireguard.

Cheers.

From joe at solidadmin.com  Wed Apr 15 18:27:52 2020
From: joe at solidadmin.com (Joe Doss)
Date: Wed, 15 Apr 2020 11:27:52 -0500
Subject: kmod-wireguard 20200413 fails transaction check
In-Reply-To: <50d9516e-9546-07ce-d0f4-434e5893f2a9@attglobal.net>
References: <50d9516e-9546-07ce-d0f4-434e5893f2a9@attglobal.net>
Message-ID: <3b32d873-3216-facd-4313-028ab31dd5c3@solidadmin.com>

Hey Eddie,

On 4/15/20 11:22 AM, Eddie wrote:
> I'm running a Nethserver box, which is built on top of CentOS 7. Trying
> to update to the latest wireguard throws the following:

We are aware of the problem and we are working on fixing it with Elrepo.

Joe



-- 
Joe Doss
joe at solidadmin.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.zx2c4.com/pipermail/wireguard/attachments/20200415/7e163e20/attachment.asc>

From Jason at zx2c4.com  Wed Apr 15 23:39:47 2020
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Wed, 15 Apr 2020 15:39:47 -0600
Subject: kmod-wireguard 20200413 fails transaction check
In-Reply-To: <50d9516e-9546-07ce-d0f4-434e5893f2a9@attglobal.net>
References: <50d9516e-9546-07ce-d0f4-434e5893f2a9@attglobal.net>
Message-ID: <CAHmME9qRQGQLbuDcfcf8zvsW9twzCkCNqkdMd8kMgEABF=kBYw@mail.gmail.com>

This is because ELRepo is a crumbling mess held together by bubble gum
and scotch tape. Run this:

$ sudo yum install yum-plugins-elrepo

And then try again.

From Jason at zx2c4.com  Wed Apr 15 23:41:32 2020
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Wed, 15 Apr 2020 15:41:32 -0600
Subject: More reliable packages available for RHEL, CentOS, and Fedora
In-Reply-To: <20200404211246.GA10066@zx2c4.com>
References: <20200404211246.GA10066@zx2c4.com>
Message-ID: <CAHmME9oWwW7qC_wzQ3JUE+CZF3eBzJG7v3x5RZww75H8pW+2tQ@mail.gmail.com>

It turns out that ELRepo is a bit of a crumbling mess, unfortunately.
FOR CENTOS USERS ONLY, the instructions in the previous email need to
include:

$ sudo yum install yum-plugins-elrepo

Hopefully Red Hat will simply include WireGuard in RHEL 7 and 8, so
that we won't have to deal with this. But for now, this appears to be
the best we've got.

Jason

From stunnel at attglobal.net  Wed Apr 15 23:47:06 2020
From: stunnel at attglobal.net (Eddie)
Date: Wed, 15 Apr 2020 14:47:06 -0700
Subject: More reliable packages available for RHEL, CentOS, and Fedora
In-Reply-To: <CAHmME9oWwW7qC_wzQ3JUE+CZF3eBzJG7v3x5RZww75H8pW+2tQ@mail.gmail.com>
References: <20200404211246.GA10066@zx2c4.com>
 <CAHmME9oWwW7qC_wzQ3JUE+CZF3eBzJG7v3x5RZww75H8pW+2tQ@mail.gmail.com>
Message-ID: <024be24b-7f0f-1890-f5c5-b9abb1e7e079@attglobal.net>

On 4/15/2020 2:41 PM, Jason A. Donenfeld wrote:
> It turns out that ELRepo is a bit of a crumbling mess, unfortunately.
> FOR CENTOS USERS ONLY, the instructions in the previous email need to
> include:
>
> $ sudo yum install yum-plugins-elrepo
>
> Hopefully Red Hat will simply include WireGuard in RHEL 7 and 8, so
> that we won't have to deal with this. But for now, this appears to be
> the best we've got.
>
> Jason
>
Actually that's:

yum install yum-plugin-elrepo


Cheers.

From stunnel at attglobal.net  Wed Apr 15 23:56:14 2020
From: stunnel at attglobal.net (Eddie)
Date: Wed, 15 Apr 2020 14:56:14 -0700
Subject: kmod-wireguard 20200413 fails transaction check
In-Reply-To: <CAHmME9qRQGQLbuDcfcf8zvsW9twzCkCNqkdMd8kMgEABF=kBYw@mail.gmail.com>
References: <50d9516e-9546-07ce-d0f4-434e5893f2a9@attglobal.net>
 <CAHmME9qRQGQLbuDcfcf8zvsW9twzCkCNqkdMd8kMgEABF=kBYw@mail.gmail.com>
Message-ID: <1a6e785f-9c33-e0e2-d267-4f857040ed20@attglobal.net>

On 4/15/2020 2:39 PM, Jason A. Donenfeld wrote:
> This is because ELRepo is a crumbling mess held together by bubble gum
> and scotch tape. Run this:
>
> $ sudo yum install yum-plugins-elrepo
>
> And then try again.
>
Much better this time, updated successfully.? Thanks.

Cheers.

From Jason at zx2c4.com  Wed Apr 15 23:56:50 2020
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Wed, 15 Apr 2020 15:56:50 -0600
Subject: kmod-wireguard 20200413 fails transaction check
In-Reply-To: <CAHmME9qRQGQLbuDcfcf8zvsW9twzCkCNqkdMd8kMgEABF=kBYw@mail.gmail.com>
References: <50d9516e-9546-07ce-d0f4-434e5893f2a9@attglobal.net>
 <CAHmME9qRQGQLbuDcfcf8zvsW9twzCkCNqkdMd8kMgEABF=kBYw@mail.gmail.com>
Message-ID: <CAHmME9roWgF=8OmYkiexuhAb+dYsiGgRoLGDyiLmNcn8jipj+w@mail.gmail.com>

On Wed, Apr 15, 2020 at 3:39 PM Jason A. Donenfeld <Jason at zx2c4.com> wrote:
>
> This is because ELRepo is a crumbling mess held together by bubble gum
> and scotch tape. Run this:
>
> $ sudo yum install yum-plugins-elrepo

$ sudo yum install yum-plugin-elrepo

From Jason at zx2c4.com  Wed Apr 15 23:57:28 2020
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Wed, 15 Apr 2020 15:57:28 -0600
Subject: kmod-wireguard 20200413 fails transaction check
In-Reply-To: <1a6e785f-9c33-e0e2-d267-4f857040ed20@attglobal.net>
References: <50d9516e-9546-07ce-d0f4-434e5893f2a9@attglobal.net>
 <CAHmME9qRQGQLbuDcfcf8zvsW9twzCkCNqkdMd8kMgEABF=kBYw@mail.gmail.com>
 <1a6e785f-9c33-e0e2-d267-4f857040ed20@attglobal.net>
Message-ID: <CAHmME9pO8D-PAP4JNY3GwXo=khKCROKFrXZhy95nwhB6DBHGzg@mail.gmail.com>

On Wed, Apr 15, 2020 at 3:56 PM Eddie <stunnel at attglobal.net> wrote:
>
> On 4/15/2020 2:39 PM, Jason A. Donenfeld wrote:
> > This is because ELRepo is a crumbling mess held together by bubble gum
> > and scotch tape. Run this:
> >
> > $ sudo yum install yum-plugins-elrepo
> >
> > And then try again.
> >
> Much better this time, updated successfully.  Thanks.

Whew!

The verbosity of that plugin will be decreased in the next release, by
the way. This was just merged:
https://github.com/elrepo/packages/commit/5ecf463d01a9a66a96d220c4116af884bfc917ee

From tanioka404 at gmail.com  Sat Apr 18 17:55:45 2020
From: tanioka404 at gmail.com (Eiji Tanioka)
Date: Sun, 19 Apr 2020 00:55:45 +0900
Subject: Question about Crowdin operation
Message-ID: <CAA2ss9E8hAQqwKwA6aytcXCZPr905NX53LRdfY6-WG24m66AAA@mail.gmail.com>

Hi,

I'm translating WireGuard apps into Japanese.
I have a question about operation in Crowdin.

When translate, we translators need to clarify about original string's
context or meaning. In that situation, which option is preferred?

- send ML about question.
- in Crowdin, use comment.
- in Crowdin, use comment and flag "Issue".
- in Crowdin, use Discussion.

# I had used second option, but never mention to anyone.
# Should I had to mention to ?

Kind regards,
Eiji Tanioka

From me at msfjarvis.dev  Sat Apr 18 18:58:38 2020
From: me at msfjarvis.dev (Harsh Shandilya)
Date: Sat, 18 Apr 2020 16:58:38 +0000
Subject: Question about Crowdin operation
In-Reply-To: <CAA2ss9E8hAQqwKwA6aytcXCZPr905NX53LRdfY6-WG24m66AAA@mail.gmail.com>
References: <CAA2ss9E8hAQqwKwA6aytcXCZPr905NX53LRdfY6-WG24m66AAA@mail.gmail.com>
Message-ID: <8bca79f715ae5c649b5b717feef8e704@msfjarvis.dev>

April 18, 2020 9:25 PM, "Eiji Tanioka" <tanioka404 at gmail.com> wrote:

> Hi,
> 
> I'm translating WireGuard apps into Japanese.
> I have a question about operation in Crowdin.
> 
> When translate, we translators need to clarify about original string's
> context or meaning. In that situation, which option is preferred?
> 
> - send ML about question.
> - in Crowdin, use comment.
> - in Crowdin, use comment and flag "Issue".
> - in Crowdin, use Discussion.
> 
> # I had used second option, but never mention to anyone.
> # Should I had to mention to ?

The second option is perfectly fine, though you'll have better luck if you
mention me or Jason since that will ensure Crowdin does not swallow up the
notifications.

> Kind regards,
> Eiji Tanioka

From Jason at zx2c4.com  Sat Apr 18 22:08:16 2020
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Sat, 18 Apr 2020 14:08:16 -0600
Subject: Question about Crowdin operation
In-Reply-To: <CAA2ss9E8hAQqwKwA6aytcXCZPr905NX53LRdfY6-WG24m66AAA@mail.gmail.com>
References: <CAA2ss9E8hAQqwKwA6aytcXCZPr905NX53LRdfY6-WG24m66AAA@mail.gmail.com>
Message-ID: <CAHmME9rDA8ssOFodvgLp1WQ9usBj=Bc3xVBNdrvwkwyM+2kr5Q@mail.gmail.com>

On Sat, Apr 18, 2020 at 9:56 AM Eiji Tanioka <tanioka404 at gmail.com> wrote:
>
> Hi,
>
> I'm translating WireGuard apps into Japanese.
> I have a question about operation in Crowdin.
>
> When translate, we translators need to clarify about original string's
> context or meaning. In that situation, which option is preferred?
>
> - send ML about question.
> - in Crowdin, use comment.
> - in Crowdin, use comment and flag "Issue".
> - in Crowdin, use Discussion.
>
> # I had used second option, but never mention to anyone.
> # Should I had to mention to ?
>
> Kind regards,
> Eiji Tanioka

Hey Eiji,

CC'ing Harsh, Simon, and Roopesh, as they might have different
opinions on what they prefer.

>From my end, any form of communication is fine, whether its on Crowdin
or on the mailing list, because lowering the barrier for people to
volunteer their hours translating strings for us seems like a good
thing.

I suppose one advantage of Crowdin is that the discussions are placed
beside the translations, which makes it easy for future people to
correlate the two, and most discussions tend to be clarifications on
particular strings, rather than interesting technical conversation
that would benefit from the archiving afforded by mailing lists.

AFAICT, the "issue" flag sends us an email notification, which is a
good thing if you need an answer.

Jason

From me at msfjarvis.dev  Sat Apr 18 22:24:17 2020
From: me at msfjarvis.dev (Harsh Shandilya)
Date: Sat, 18 Apr 2020 20:24:17 +0000
Subject: Question about Crowdin operation
In-Reply-To: <CAHmME9rDA8ssOFodvgLp1WQ9usBj=Bc3xVBNdrvwkwyM+2kr5Q@mail.gmail.com>
References: <CAHmME9rDA8ssOFodvgLp1WQ9usBj=Bc3xVBNdrvwkwyM+2kr5Q@mail.gmail.com>
 <CAA2ss9E8hAQqwKwA6aytcXCZPr905NX53LRdfY6-WG24m66AAA@mail.gmail.com>
Message-ID: <59f5a401d768dfad8b60a0ed3f59a5b6@msfjarvis.dev>

April 19, 2020 1:38 AM, "Jason A. Donenfeld" <Jason at zx2c4.com> wrote:

> On Sat, Apr 18, 2020 at 9:56 AM Eiji Tanioka <tanioka404 at gmail.com> wrote:
> 
>> Hi,
>> 
>> I'm translating WireGuard apps into Japanese.
>> I have a question about operation in Crowdin.
>> 
>> When translate, we translators need to clarify about original string's
>> context or meaning. In that situation, which option is preferred?
>> 
>> - send ML about question.
>> - in Crowdin, use comment.
>> - in Crowdin, use comment and flag "Issue".
>> - in Crowdin, use Discussion.
>> 
>> # I had used second option, but never mention to anyone.
>> # Should I had to mention to ?
>> 
>> Kind regards,
>> Eiji Tanioka
> 
> Hey Eiji,
> 
> CC'ing Harsh, Simon, and Roopesh, as they might have different
> opinions on what they prefer.
> 
> From my end, any form of communication is fine, whether its on Crowdin
> or on the mailing list, because lowering the barrier for people to
> volunteer their hours translating strings for us seems like a good
> thing.

Same goes for me, I'll take whatever's the easiest route for translators
and work with it.

> I suppose one advantage of Crowdin is that the discussions are placed
> beside the translations, which makes it easy for future people to
> correlate the two, and most discussions tend to be clarifications on
> particular strings, rather than interesting technical conversation
> that would benefit from the archiving afforded by mailing lists.
> 
> AFAICT, the "issue" flag sends us an email notification, which is a
> good thing if you need an answer.
> 
> Jason


Harsh Shandilya

From tanioka404 at gmail.com  Sun Apr 19 07:21:00 2020
From: tanioka404 at gmail.com (Eiji Tanioka)
Date: Sun, 19 Apr 2020 14:21:00 +0900
Subject: Question about Crowdin operation
In-Reply-To: <59f5a401d768dfad8b60a0ed3f59a5b6@msfjarvis.dev>
References: <CAA2ss9E8hAQqwKwA6aytcXCZPr905NX53LRdfY6-WG24m66AAA@mail.gmail.com>
 <CAHmME9rDA8ssOFodvgLp1WQ9usBj=Bc3xVBNdrvwkwyM+2kr5Q@mail.gmail.com>
 <59f5a401d768dfad8b60a0ed3f59a5b6@msfjarvis.dev>
Message-ID: <CAA2ss9E0UnqPdj0uHF6rfLD0TdkAB5s=L=OXf6dH+1T20-TBAA@mail.gmail.com>

Harsh, Jason,
Thank you for quick response!

> The second option is perfectly fine, though you'll have better luck if you
> mention me or Jason since that will ensure Crowdin does not swallow up the
> notifications.

> AFAICT, the "issue" flag sends us an email notification, which is a
> good thing if you need an answer.

I understood.
When I use comments is when I need a response, so I will try to use
the mention or issue flag.

2020?4?19?(?) 5:24 Harsh Shandilya <me at msfjarvis.dev>:
>
> April 19, 2020 1:38 AM, "Jason A. Donenfeld" <Jason at zx2c4.com> wrote:
>
> > On Sat, Apr 18, 2020 at 9:56 AM Eiji Tanioka <tanioka404 at gmail.com> wrote:
> >
> >> Hi,
> >>
> >> I'm translating WireGuard apps into Japanese.
> >> I have a question about operation in Crowdin.
> >>
> >> When translate, we translators need to clarify about original string's
> >> context or meaning. In that situation, which option is preferred?
> >>
> >> - send ML about question.
> >> - in Crowdin, use comment.
> >> - in Crowdin, use comment and flag "Issue".
> >> - in Crowdin, use Discussion.
> >>
> >> # I had used second option, but never mention to anyone.
> >> # Should I had to mention to ?
> >>
> >> Kind regards,
> >> Eiji Tanioka
> >
> > Hey Eiji,
> >
> > CC'ing Harsh, Simon, and Roopesh, as they might have different
> > opinions on what they prefer.
> >
> > From my end, any form of communication is fine, whether its on Crowdin
> > or on the mailing list, because lowering the barrier for people to
> > volunteer their hours translating strings for us seems like a good
> > thing.
>
> Same goes for me, I'll take whatever's the easiest route for translators
> and work with it.
>
> > I suppose one advantage of Crowdin is that the discussions are placed
> > beside the translations, which makes it easy for future people to
> > correlate the two, and most discussions tend to be clarifications on
> > particular strings, rather than interesting technical conversation
> > that would benefit from the archiving afforded by mailing lists.
> >
> > AFAICT, the "issue" flag sends us an email notification, which is a
> > good thing if you need an answer.
> >
> > Jason
>
>
> Harsh Shandilya

From Jason at zx2c4.com  Wed Apr 22 08:27:02 2020
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Wed, 22 Apr 2020 00:27:02 -0600
Subject: [PATCH] wireguard: remove errant newline from
 wg_packet_encrypt_worker()
In-Reply-To: <20200422062513.13953-1-sultan@kerneltoast.com>
References: <20200422062513.13953-1-sultan@kerneltoast.com>
Message-ID: <CAHmME9p=_oBBGGCSqshbFsOeS=Hg7RBnoEZ--MPO5jiJS+P4Ew@mail.gmail.com>

Applied to the wireguard tree and will go out with the next wireguard
update patchset I post on netdev.

Thanks,
Jason

From msuchanek at suse.de  Tue Apr 14 21:16:01 2020
From: msuchanek at suse.de (Michal =?iso-8859-1?Q?Such=E1nek?=)
Date: Tue, 14 Apr 2020 21:16:01 +0200
Subject: [PATCH v2 2/2] crypto: Remove unnecessary memzero_explicit()
In-Reply-To: <e194a51f-a5e5-a557-c008-b08cac558572@redhat.com>
References: <20200413211550.8307-1-longman@redhat.com>
 <20200413222846.24240-1-longman@redhat.com>
 <eca85e0b-0af3-c43a-31e4-bd5c3f519798@c-s.fr>
 <e194a51f-a5e5-a557-c008-b08cac558572@redhat.com>
Message-ID: <20200414191601.GZ25468@kitsune.suse.cz>

On Tue, Apr 14, 2020 at 12:24:36PM -0400, Waiman Long wrote:
> On 4/14/20 2:08 AM, Christophe Leroy wrote:
> >
> >
> > Le 14/04/2020 ? 00:28, Waiman Long a ?crit?:
> >> Since kfree_sensitive() will do an implicit memzero_explicit(), there
> >> is no need to call memzero_explicit() before it. Eliminate those
> >> memzero_explicit() and simplify the call sites. For better correctness,
> >> the setting of keylen is also moved down after the key pointer check.
> >>
> >> Signed-off-by: Waiman Long <longman at redhat.com>
> >> ---
> >> ? .../allwinner/sun8i-ce/sun8i-ce-cipher.c????? | 19 +++++-------------
> >> ? .../allwinner/sun8i-ss/sun8i-ss-cipher.c????? | 20 +++++--------------
> >> ? drivers/crypto/amlogic/amlogic-gxl-cipher.c?? | 12 +++--------
> >> ? drivers/crypto/inside-secure/safexcel_hash.c? |? 3 +--
> >> ? 4 files changed, 14 insertions(+), 40 deletions(-)
> >>
> >> diff --git a/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c
> >> b/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c
> >> index aa4e8fdc2b32..8358fac98719 100644
> >> --- a/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c
> >> +++ b/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c
> >> @@ -366,10 +366,7 @@ void sun8i_ce_cipher_exit(struct crypto_tfm *tfm)
> >> ? {
> >> ????? struct sun8i_cipher_tfm_ctx *op = crypto_tfm_ctx(tfm);
> >> ? -??? if (op->key) {
> >> -??????? memzero_explicit(op->key, op->keylen);
> >> -??????? kfree(op->key);
> >> -??? }
> >> +??? kfree_sensitive(op->key);
> >> ????? crypto_free_sync_skcipher(op->fallback_tfm);
> >> ????? pm_runtime_put_sync_suspend(op->ce->dev);
> >> ? }
> >> @@ -391,14 +388,11 @@ int sun8i_ce_aes_setkey(struct crypto_skcipher
> >> *tfm, const u8 *key,
> >> ????????? dev_dbg(ce->dev, "ERROR: Invalid keylen %u\n", keylen);
> >> ????????? return -EINVAL;
> >> ????? }
> >> -??? if (op->key) {
> >> -??????? memzero_explicit(op->key, op->keylen);
> >> -??????? kfree(op->key);
> >> -??? }
> >> -??? op->keylen = keylen;
> >> +??? kfree_sensitive(op->key);
> >> ????? op->key = kmemdup(key, keylen, GFP_KERNEL | GFP_DMA);
> >> ????? if (!op->key)
> >> ????????? return -ENOMEM;
> >> +??? op->keylen = keylen;
> >
> > Does it matter at all to ensure op->keylen is not set when of->key is
> > NULL ? I'm not sure.
> >
> > But if it does, then op->keylen should be set to 0 when freeing op->key. 
> 
> My thinking is that if memory allocation fails, we just don't touch
> anything and return an error code. I will not explicitly set keylen to 0
> in this case unless it is specified in the API documentation.
You already freed the key by now so not touching anything is not
possible. The key is set to NULL on allocation failure so setting keylen
to 0 should be redundant. However, setting keylen to 0 is consisent with
not having a key, and it avoids the possibility of leaking the length
later should that ever cause any problem.

Thanks

Michal

From godisgovernment at gmail.com  Fri Apr 24 20:59:22 2020
From: godisgovernment at gmail.com (Shawn Hoffman)
Date: Fri, 24 Apr 2020 11:59:22 -0700
Subject: [PATCH 0/3] misc code cleanup
Message-ID: <20200424185925.31971-1-godisgovernment@gmail.com>

misc code cleanup. just getting feet wet.

Shawn Hoffman (3):
  don't leak TunDispatchSecurityDescriptor if second
    RtlAbsoluteToSelfRelativeSD fails. practically this can't happen,
    but from wintun code it's unclear.
  use ExEnterCriticalRegionAndAcquireResourceExclusive and
    ExReleaseResourceAndLeaveCriticalRegion
  use RtlSubAuthoritySid instead of directly poking SID

 wintun.c | 29 +++++++++++++++++------------
 1 file changed, 17 insertions(+), 12 deletions(-)

-- 
2.25.0.windows.1


From godisgovernment at gmail.com  Fri Apr 24 20:59:24 2020
From: godisgovernment at gmail.com (Shawn Hoffman)
Date: Fri, 24 Apr 2020 11:59:24 -0700
Subject: [PATCH 2/3] use ExEnterCriticalRegionAndAcquireResourceExclusive and
 ExReleaseResourceAndLeaveCriticalRegion
In-Reply-To: <20200424185925.31971-1-godisgovernment@gmail.com>
References: <20200424185925.31971-1-godisgovernment@gmail.com>
Message-ID: <20200424185925.31971-3-godisgovernment@gmail.com>

---
 wintun.c | 12 ++++--------
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/wintun.c b/wintun.c
index 90e7930..00ac378 100644
--- a/wintun.c
+++ b/wintun.c
@@ -884,15 +884,13 @@ TunDispatchDeviceControl(DEVICE_OBJECT *DeviceObject, IRP *Irp)
     switch (Stack->Parameters.DeviceIoControl.IoControlCode)
     {
     case TUN_IOCTL_REGISTER_RINGS: {
-        KeEnterCriticalRegion();
-        ExAcquireResourceSharedLite(&TunDispatchCtxGuard, TRUE);
+        ExEnterCriticalRegionAndAcquireResourceExclusive(&TunDispatchCtxGuard);
 #pragma warning(suppress : 28175)
         TUN_CTX *Ctx = DeviceObject->Reserved;
         Status = NDIS_STATUS_ADAPTER_NOT_READY;
         if (Ctx)
             Status = TunRegisterBuffers(Ctx, Irp);
-        ExReleaseResourceLite(&TunDispatchCtxGuard);
-        KeLeaveCriticalRegion();
+        ExReleaseResourceAndLeaveCriticalRegion(&TunDispatchCtxGuard);
         break;
     }
     case TUN_IOCTL_FORCE_CLOSE_HANDLES:
@@ -913,14 +911,12 @@ _Use_decl_annotations_
 static NTSTATUS
 TunDispatchClose(DEVICE_OBJECT *DeviceObject, IRP *Irp)
 {
-    KeEnterCriticalRegion();
-    ExAcquireResourceSharedLite(&TunDispatchCtxGuard, TRUE);
+    ExEnterCriticalRegionAndAcquireResourceExclusive(&TunDispatchCtxGuard);
 #pragma warning(suppress : 28175)
     TUN_CTX *Ctx = DeviceObject->Reserved;
     if (Ctx)
         TunUnregisterBuffers(Ctx, IoGetCurrentIrpStackLocation(Irp)->FileObject);
-    ExReleaseResourceLite(&TunDispatchCtxGuard);
-    KeLeaveCriticalRegion();
+    ExReleaseResourceAndLeaveCriticalRegion(&TunDispatchCtxGuard);
     return NdisDispatchClose(DeviceObject, Irp);
 }
 
-- 
2.25.0.windows.1


From godisgovernment at gmail.com  Fri Apr 24 20:59:23 2020
From: godisgovernment at gmail.com (Shawn Hoffman)
Date: Fri, 24 Apr 2020 11:59:23 -0700
Subject: [PATCH 1/3] don't leak TunDispatchSecurityDescriptor if second
 RtlAbsoluteToSelfRelativeSD fails. practically this can't happen,
 but from wintun code it's unclear.
In-Reply-To: <20200424185925.31971-1-godisgovernment@gmail.com>
References: <20200424185925.31971-1-godisgovernment@gmail.com>
Message-ID: <20200424185925.31971-2-godisgovernment@gmail.com>

---
 wintun.c | 15 ++++++++++++---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/wintun.c b/wintun.c
index 624de2f..90e7930 100644
--- a/wintun.c
+++ b/wintun.c
@@ -820,6 +820,14 @@ static NTSTATUS TunInitializeDispatchSecurityDescriptor(VOID)
     return STATUS_SUCCESS;
 }
 
+static VOID TunFreeDispatchSecurityDescriptor(VOID)
+{
+    if (!TunDispatchSecurityDescriptor)
+        return;
+    ExFreePoolWithTag(TunDispatchSecurityDescriptor, TUN_MEMORY_TAG);
+    TunDispatchSecurityDescriptor = NULL;
+}
+
 _IRQL_requires_max_(PASSIVE_LEVEL)
 static VOID
 TunProcessNotification(HANDLE ParentId, HANDLE ProcessId, BOOLEAN Create)
@@ -1387,7 +1395,7 @@ TunUnload(PDRIVER_OBJECT DriverObject)
     NdisMDeregisterMiniportDriver(NdisMiniportDriverHandle);
     ExDeleteResourceLite(&TunDispatchCtxGuard);
     ExDeleteResourceLite(&TunDispatchDeviceListLock);
-    ExFreePoolWithTag(TunDispatchSecurityDescriptor, TUN_MEMORY_TAG);
+    TunFreeDispatchSecurityDescriptor();
 }
 
 DRIVER_INITIALIZE DriverEntry;
@@ -1398,7 +1406,7 @@ DriverEntry(DRIVER_OBJECT *DriverObject, UNICODE_STRING *RegistryPath)
     NTSTATUS Status;
 
     if (!NT_SUCCESS(Status = TunInitializeDispatchSecurityDescriptor()))
-        return Status;
+        goto cleanupSD;
 
     NdisVersion = NdisGetVersion();
     if (NdisVersion < NDIS_MINIPORT_VERSION_MIN)
@@ -1461,6 +1469,7 @@ cleanupNotifier:
 cleanupResources:
     ExDeleteResourceLite(&TunDispatchCtxGuard);
     ExDeleteResourceLite(&TunDispatchDeviceListLock);
-    ExFreePoolWithTag(TunDispatchSecurityDescriptor, TUN_MEMORY_TAG);
+cleanupSD:
+    TunFreeDispatchSecurityDescriptor();
     return Status;
 }
-- 
2.25.0.windows.1


From godisgovernment at gmail.com  Fri Apr 24 20:59:25 2020
From: godisgovernment at gmail.com (Shawn Hoffman)
Date: Fri, 24 Apr 2020 11:59:25 -0700
Subject: [PATCH 3/3] use RtlSubAuthoritySid instead of directly poking SID
In-Reply-To: <20200424185925.31971-1-godisgovernment@gmail.com>
References: <20200424185925.31971-1-godisgovernment@gmail.com>
Message-ID: <20200424185925.31971-4-godisgovernment@gmail.com>

---
 wintun.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/wintun.c b/wintun.c
index 00ac378..a6a0e16 100644
--- a/wintun.c
+++ b/wintun.c
@@ -788,7 +788,7 @@ static NTSTATUS TunInitializeDispatchSecurityDescriptor(VOID)
     SID LocalSystem = { 0 };
     if (!NT_SUCCESS(Status = RtlInitializeSid(&LocalSystem, &NtAuthority, 1)))
         return Status;
-    LocalSystem.SubAuthority[0] = 18;
+    *RtlSubAuthoritySid(&LocalSystem, 0) = SECURITY_LOCAL_SYSTEM_RID;
     struct
     {
         ACL Dacl;
-- 
2.25.0.windows.1


From godisgovernment at gmail.com  Fri Apr 24 21:40:09 2020
From: godisgovernment at gmail.com (Shawn Hoffman)
Date: Fri, 24 Apr 2020 12:40:09 -0700
Subject: [PATCH 0/1] wintun: use standard volatile semantics
Message-ID: <20200424194010.32225-1-godisgovernment@gmail.com>

Make all archs are use the standardized concept of volatile.
This patch will cause the most changes to arm64 codegen, and has
yet to be tested on arm64 so is currently being submitted for
comments. If someone would like to test on arm64 it would be
appreciated. I do have an arm64 device, but it seems there's no
existing arm64/windows wireguard binary package, so I can't
just install such a thing and swap out the driver.

Shawn Hoffman (1):
  replace atomic.h with provided APIs switch to /volatile:iso

 wintun.c               | 76 +++++++++++++++++++++---------------------
 wintun.vcxproj         |  5 ++-
 wintun.vcxproj.filters |  3 --
 3 files changed, 40 insertions(+), 44 deletions(-)

-- 
2.20.1


From godisgovernment at gmail.com  Fri Apr 24 21:40:10 2020
From: godisgovernment at gmail.com (Shawn Hoffman)
Date: Fri, 24 Apr 2020 12:40:10 -0700
Subject: [PATCH 1/1] replace atomic.h with provided APIs switch to
 /volatile:iso
In-Reply-To: <20200424194010.32225-1-godisgovernment@gmail.com>
References: <20200424194010.32225-1-godisgovernment@gmail.com>
Message-ID: <20200424194010.32225-2-godisgovernment@gmail.com>

---
 wintun.c               | 76 +++++++++++++++++++++---------------------
 wintun.vcxproj         |  5 ++-
 wintun.vcxproj.filters |  3 --
 3 files changed, 40 insertions(+), 44 deletions(-)

diff --git a/wintun.c b/wintun.c
index a6a0e16..b042d35 100644
--- a/wintun.c
+++ b/wintun.c
@@ -9,7 +9,6 @@
 #include <ndis.h>
 #include <ntstrsafe.h>
 #include "undocumented.h"
-#include "atomic.h"
 
 #pragma warning(disable : 4100) /* unreferenced formal parameter */
 #pragma warning(disable : 4200) /* nonstandard: zero-sized array in struct/union */
@@ -250,7 +249,7 @@ TunSendNetBufferLists(
 
     KIRQL Irql = ExAcquireSpinLockShared(&Ctx->TransitionLock);
     NDIS_STATUS Status;
-    if ((Status = NDIS_STATUS_PAUSED, !InterlockedGet(&Ctx->Running)) ||
+    if ((Status = NDIS_STATUS_PAUSED, !ReadAcquire(&Ctx->Running)) ||
         (Status = NDIS_STATUS_MEDIA_DISCONNECTED, KeReadStateEvent(&Ctx->Device.Disconnected)))
         goto skipNbl;
 
@@ -258,7 +257,7 @@ TunSendNetBufferLists(
     ULONG RingCapacity = Ctx->Device.Send.Capacity;
 
     /* Allocate space for packets in the ring. */
-    ULONG RingHead = InterlockedGetU(&Ring->Head);
+    ULONG RingHead = ReadULongAcquire(&Ring->Head);
     if (Status = NDIS_STATUS_ADAPTER_NOT_READY, RingHead >= RingCapacity)
         goto skipNbl;
 
@@ -325,7 +324,7 @@ TunSendNetBufferLists(
     {
         NET_BUFFER_LIST *CompletedNbl = Ctx->Device.Send.ActiveNbls.Head;
         Ctx->Device.Send.ActiveNbls.Head = NET_BUFFER_LIST_NEXT_NBL_EX(CompletedNbl);
-        InterlockedSetU(&Ring->Tail, TunNblGetOffset(CompletedNbl));
+        WriteULongRelease(&Ring->Tail, TunNblGetOffset(CompletedNbl));
         KeSetEvent(Ctx->Device.Send.TailMoved, IO_NETWORK_INCREMENT, FALSE);
         NdisMSendNetBufferListsComplete(
             Ctx->MiniportAdapterHandle, CompletedNbl, NDIS_SEND_COMPLETE_FLAGS_DISPATCH_LEVEL);
@@ -343,11 +342,11 @@ skipNbl:
     ExReleaseSpinLockShared(&Ctx->TransitionLock, Irql);
     NdisMSendNetBufferListsComplete(Ctx->MiniportAdapterHandle, NetBufferLists, 0);
 updateStatistics:
-    InterlockedAdd64((LONG64 *)&Ctx->Statistics.ifHCOutOctets, SentPacketsSize);
-    InterlockedAdd64((LONG64 *)&Ctx->Statistics.ifHCOutUcastOctets, SentPacketsSize);
-    InterlockedAdd64((LONG64 *)&Ctx->Statistics.ifHCOutUcastPkts, SentPacketsCount);
-    InterlockedAdd64((LONG64 *)&Ctx->Statistics.ifOutErrors, ErrorPacketsCount);
-    InterlockedAdd64((LONG64 *)&Ctx->Statistics.ifOutDiscards, DiscardedPacketsCount);
+    InterlockedAddNoFence64((LONG64 *)&Ctx->Statistics.ifHCOutOctets, SentPacketsSize);
+    InterlockedAddNoFence64((LONG64 *)&Ctx->Statistics.ifHCOutUcastOctets, SentPacketsSize);
+    InterlockedAddNoFence64((LONG64 *)&Ctx->Statistics.ifHCOutUcastPkts, SentPacketsCount);
+    InterlockedAddNoFence64((LONG64 *)&Ctx->Statistics.ifOutErrors, ErrorPacketsCount);
+    InterlockedAddNoFence64((LONG64 *)&Ctx->Statistics.ifOutDiscards, DiscardedPacketsCount);
 }
 
 static MINIPORT_CANCEL_SEND TunCancelSend;
@@ -393,15 +392,15 @@ TunReturnNetBufferLists(NDIS_HANDLE MiniportAdapterContext, PNET_BUFFER_LIST Net
             if (!Ctx->Device.Receive.ActiveNbls.Head)
                 KeSetEvent(&Ctx->Device.Receive.ActiveNbls.Empty, IO_NO_INCREMENT, FALSE);
             KeReleaseInStackQueuedSpinLock(&LockHandle);
-            InterlockedSetU(&Ring->Head, TunNblGetOffset(CompletedNbl));
+            WriteULongRelease(&Ring->Head, TunNblGetOffset(CompletedNbl));
             NdisFreeNetBufferList(CompletedNbl);
         }
     }
 
-    InterlockedAdd64((LONG64 *)&Ctx->Statistics.ifHCInOctets, ReceivedPacketsSize);
-    InterlockedAdd64((LONG64 *)&Ctx->Statistics.ifHCInUcastOctets, ReceivedPacketsSize);
-    InterlockedAdd64((LONG64 *)&Ctx->Statistics.ifHCInUcastPkts, ReceivedPacketsCount);
-    InterlockedAdd64((LONG64 *)&Ctx->Statistics.ifInErrors, ErrorPacketsCount);
+    InterlockedAddNoFence64((LONG64 *)&Ctx->Statistics.ifHCInOctets, ReceivedPacketsSize);
+    InterlockedAddNoFence64((LONG64 *)&Ctx->Statistics.ifHCInUcastOctets, ReceivedPacketsSize);
+    InterlockedAddNoFence64((LONG64 *)&Ctx->Statistics.ifHCInUcastPkts, ReceivedPacketsCount);
+    InterlockedAddNoFence64((LONG64 *)&Ctx->Statistics.ifInErrors, ErrorPacketsCount);
 }
 
 _IRQL_requires_max_(PASSIVE_LEVEL)
@@ -419,20 +418,20 @@ TunProcessReceiveData(_Inout_ TUN_CTX *Ctx)
     VOID *Events[] = { &Ctx->Device.Disconnected, Ctx->Device.Receive.TailMoved };
     ASSERT(RTL_NUMBER_OF(Events) <= THREAD_WAIT_OBJECTS);
 
-    ULONG RingHead = InterlockedGetU(&Ring->Head);
+    ULONG RingHead = ReadULongAcquire(&Ring->Head);
     if (RingHead >= RingCapacity)
         goto cleanup;
 
     while (!KeReadStateEvent(&Ctx->Device.Disconnected))
     {
         /* Get next packet from the ring. */
-        ULONG RingTail = InterlockedGetU(&Ring->Tail);
+        ULONG RingTail = ReadULongAcquire(&Ring->Tail);
         if (RingHead == RingTail)
         {
             LARGE_INTEGER SpinStart = KeQueryPerformanceCounter(NULL);
             for (;;)
             {
-                RingTail = InterlockedGetU(&Ring->Tail);
+                RingTail = ReadULongAcquire(&Ring->Tail);
                 if (RingTail != RingHead)
                     break;
                 if (KeReadStateEvent(&Ctx->Device.Disconnected))
@@ -444,16 +443,16 @@ TunProcessReceiveData(_Inout_ TUN_CTX *Ctx)
             }
             if (RingHead == RingTail)
             {
-                InterlockedSet(&Ring->Alertable, TRUE);
-                RingTail = InterlockedGetU(&Ring->Tail);
+                WriteRelease(&Ring->Alertable, TRUE);
+                RingTail = ReadULongAcquire(&Ring->Tail);
                 if (RingHead == RingTail)
                 {
                     KeWaitForMultipleObjects(
                         RTL_NUMBER_OF(Events), Events, WaitAny, Executive, KernelMode, FALSE, NULL, NULL);
-                    InterlockedSet(&Ring->Alertable, FALSE);
+                    WriteRelease(&Ring->Alertable, FALSE);
                     continue;
                 }
-                InterlockedSet(&Ring->Alertable, FALSE);
+                WriteRelease(&Ring->Alertable, FALSE);
                 KeClearEvent(Ctx->Device.Receive.TailMoved);
             }
         }
@@ -501,7 +500,7 @@ TunProcessReceiveData(_Inout_ TUN_CTX *Ctx)
         TunNblSetOffsetAndMarkActive(Nbl, RingHead);
 
         KIRQL Irql = ExAcquireSpinLockShared(&Ctx->TransitionLock);
-        if (!InterlockedGet(&Ctx->Running))
+        if (!ReadAcquire(&Ctx->Running))
             goto cleanupNbl;
 
         KLOCK_QUEUE_HANDLE LockHandle;
@@ -530,16 +529,16 @@ TunProcessReceiveData(_Inout_ TUN_CTX *Ctx)
         ExReleaseSpinLockShared(&Ctx->TransitionLock, Irql);
         NdisFreeNetBufferList(Nbl);
     skipNbl:
-        InterlockedIncrement64((LONG64 *)&Ctx->Statistics.ifInDiscards);
+        InterlockedIncrementNoFence64((LONG64 *)&Ctx->Statistics.ifInDiscards);
         KeWaitForSingleObject(&Ctx->Device.Receive.ActiveNbls.Empty, Executive, KernelMode, FALSE, NULL);
-        InterlockedSetU(&Ring->Head, RingHead);
+        WriteULongRelease(&Ring->Head, RingHead);
     }
 
     /* Wait for all NBLs to return: 1. To prevent race between proceeding and invalidating ring head. 2. To have
      * TunDispatchUnregisterBuffers() implicitly wait before releasing ring MDL used by NBL(s). */
     KeWaitForSingleObject(&Ctx->Device.Receive.ActiveNbls.Empty, Executive, KernelMode, FALSE, NULL);
 cleanup:
-    InterlockedSetU(&Ring->Head, MAXULONG);
+    WriteULongRelease(&Ring->Head, MAXULONG);
 }
 
 #define IS_POW2(x) ((x) && !((x) & ((x)-1)))
@@ -595,7 +594,7 @@ TunRegisterBuffers(_Inout_ TUN_CTX *Ctx, _Inout_ IRP *Irp)
     if (Status = STATUS_INSUFFICIENT_RESOURCES, !Ctx->Device.Send.Ring)
         goto cleanupSendUnlockPages;
 
-    Ctx->Device.Send.RingTail = InterlockedGetU(&Ctx->Device.Send.Ring->Tail);
+    Ctx->Device.Send.RingTail = ReadULongAcquire(&Ctx->Device.Send.Ring->Tail);
     if (Status = STATUS_INVALID_PARAMETER, Ctx->Device.Send.RingTail >= Ctx->Device.Send.Capacity)
         goto cleanupSendUnlockPages;
 
@@ -709,7 +708,7 @@ TunUnregisterBuffers(_Inout_ TUN_CTX *Ctx, _In_ FILE_OBJECT *Owner)
     }
     ZwClose(Ctx->Device.Receive.Thread);
 
-    InterlockedSetU(&Ctx->Device.Send.Ring->Tail, MAXULONG);
+    WriteULongRelease(&Ctx->Device.Send.Ring->Tail, MAXULONG);
     KeSetEvent(Ctx->Device.Send.TailMoved, IO_NO_INCREMENT, FALSE);
 
     MmUnlockPages(Ctx->Device.Receive.Mdl);
@@ -926,7 +925,7 @@ static NDIS_STATUS
 TunRestart(NDIS_HANDLE MiniportAdapterContext, PNDIS_MINIPORT_RESTART_PARAMETERS MiniportRestartParameters)
 {
     TUN_CTX *Ctx = (TUN_CTX *)MiniportAdapterContext;
-    InterlockedSet(&Ctx->Running, TRUE);
+    WriteRelease(&Ctx->Running, TRUE);
     return NDIS_STATUS_SUCCESS;
 }
 
@@ -937,7 +936,7 @@ TunPause(NDIS_HANDLE MiniportAdapterContext, PNDIS_MINIPORT_PAUSE_PARAMETERS Min
 {
     TUN_CTX *Ctx = (TUN_CTX *)MiniportAdapterContext;
 
-    InterlockedSet(&Ctx->Running, FALSE);
+    WriteRelease(&Ctx->Running, FALSE);
     ExReleaseSpinLockExclusive(
         &Ctx->TransitionLock,
         ExAcquireSpinLockExclusive(&Ctx->TransitionLock)); /* Ensure above change is visible to all readers. */
@@ -1131,9 +1130,10 @@ TunHaltEx(NDIS_HANDLE MiniportAdapterContext, NDIS_HALT_ACTION HaltAction)
         ExAcquireSpinLockExclusive(&Ctx->TransitionLock)); /* Ensure above change is visible to all readers. */
     NdisFreeNetBufferListPool(Ctx->NblPool);
 
-    InterlockedSetPointer(&Ctx->MiniportAdapterHandle, NULL);
-#pragma warning(suppress : 28175)
-    InterlockedSetPointer(&Ctx->FunctionalDeviceObject->Reserved, NULL);
+#pragma warning(suppress : 6387)
+    WritePointerNoFence(&Ctx->MiniportAdapterHandle, NULL);
+#pragma warning(suppress : 6387 28175)
+    WritePointerNoFence(&Ctx->FunctionalDeviceObject->Reserved, NULL);
     KeEnterCriticalRegion();
     ExAcquireResourceExclusiveLite(&TunDispatchCtxGuard, TRUE); /* Ensure above change is visible to all readers. */
     ExReleaseResourceLite(&TunDispatchCtxGuard);
@@ -1242,16 +1242,16 @@ TunOidQuery(_Inout_ TUN_CTX *Ctx, _Inout_ NDIS_OID_REQUEST *OidRequest)
     case OID_GEN_XMIT_OK:
         return TunOidQueryWrite32or64(
             OidRequest,
-            InterlockedGet64((LONG64 *)&Ctx->Statistics.ifHCOutUcastPkts) +
-                InterlockedGet64((LONG64 *)&Ctx->Statistics.ifHCOutMulticastPkts) +
-                InterlockedGet64((LONG64 *)&Ctx->Statistics.ifHCOutBroadcastPkts));
+            ReadNoFence64((LONG64 *)&Ctx->Statistics.ifHCOutUcastPkts) +
+                ReadNoFence64((LONG64 *)&Ctx->Statistics.ifHCOutMulticastPkts) +
+                ReadNoFence64((LONG64 *)&Ctx->Statistics.ifHCOutBroadcastPkts));
 
     case OID_GEN_RCV_OK:
         return TunOidQueryWrite32or64(
             OidRequest,
-            InterlockedGet64((LONG64 *)&Ctx->Statistics.ifHCInUcastPkts) +
-                InterlockedGet64((LONG64 *)&Ctx->Statistics.ifHCInMulticastPkts) +
-                InterlockedGet64((LONG64 *)&Ctx->Statistics.ifHCInBroadcastPkts));
+            ReadNoFence64((LONG64 *)&Ctx->Statistics.ifHCInUcastPkts) +
+                ReadNoFence64((LONG64 *)&Ctx->Statistics.ifHCInMulticastPkts) +
+                ReadNoFence64((LONG64 *)&Ctx->Statistics.ifHCInBroadcastPkts));
 
     case OID_GEN_STATISTICS:
         return TunOidQueryWriteBuf(OidRequest, &Ctx->Statistics, (ULONG)sizeof(Ctx->Statistics));
diff --git a/wintun.vcxproj b/wintun.vcxproj
index 3bb61d1..abe4a17 100644
--- a/wintun.vcxproj
+++ b/wintun.vcxproj
@@ -125,7 +125,7 @@
   <ItemDefinitionGroup>
     <ClCompile>
       <PreprocessorDefinitions>NDIS_MINIPORT_DRIVER=1;NDIS620_MINIPORT=1;NDIS683_MINIPORT=1;NDIS_WDM=1;%(PreprocessorDefinitions)</PreprocessorDefinitions>
-      <AdditionalOptions>/volatile:ms %(AdditionalOptions)</AdditionalOptions>
+      <AdditionalOptions>/volatile:iso %(AdditionalOptions)</AdditionalOptions>
       <EnablePREfast>true</EnablePREfast>
     </ClCompile>
     <ResourceCompile>
@@ -171,9 +171,8 @@
     <FilesToPackage Include="$(TargetPath)" Condition="'$(ConfigurationType)'=='Driver' or '$(ConfigurationType)'=='DynamicLibrary'" />
   </ItemGroup>
   <ItemGroup>
-    <ClInclude Include="atomic.h" />
     <ClInclude Include="undocumented.h" />
   </ItemGroup>
   <Import Project="$(VCTargetsPath)\Microsoft.Cpp.targets" />
   <ImportGroup Label="ExtensionTargets" />
-</Project>
+</Project>
\ No newline at end of file
diff --git a/wintun.vcxproj.filters b/wintun.vcxproj.filters
index 467cc48..3e19120 100644
--- a/wintun.vcxproj.filters
+++ b/wintun.vcxproj.filters
@@ -33,8 +33,5 @@
     <ClInclude Include="undocumented.h">
       <Filter>Header Files</Filter>
     </ClInclude>
-    <ClInclude Include="atomic.h">
-      <Filter>Header Files</Filter>
-    </ClInclude>
   </ItemGroup>
 </Project>
\ No newline at end of file
-- 
2.20.1


From ale at alerinaldi.it  Sat Apr 18 00:55:49 2020
From: ale at alerinaldi.it (Alessandro Rinaldi)
Date: Sat, 18 Apr 2020 00:55:49 +0200
Subject: engarde - small issue with wireguard-windows
Message-ID: <CAJntV_GNfHPPUQKf=PnFuK3g4J30F+DVy+=9op-=K+u2ihzSHA@mail.gmail.com>

Hello,

I just subscribed to the mailing list so I'll introduce myself: I'm
Alessandro, I'm from Italy and I LOVE WireGuard :)

Last year I was looking for a way to create a reliable network tunnel
over multiple unstable connections. I'm a volunteer in a radio station
and it happens sometimes to broadcast from remote locations where
Internet connections are not good.
What I was looking for was not a failover mechanism, since when
transmitting nearly real-time audio we couldn't afford even the time
for it to detect a problem in the connection and switch to another
one. Audio transmission requires low bandwidth, so we didn't care
about wasting it to have a stable connection.

So I came up with a solution that I called engarde [0]: it basically
takes packets emitted from WireGuard and sends them to the other peer
over all the available network interfaces (like for example, an ADSL
modem over Ethernet, one or two 4G USB dongles, and maybe a WiFi
network). On the other peer, engarde takes all the packets it receives
and sends them to the local UDP port WireGuard is listening on. When
it receives a packet back from WireGuard, it sends them back to all
the destinations it received packets from recently (by default, 30
seconds). Since WireGuard disards duplicated packets by looking at
their timestamps [1], this totally works as a redundant bonding
solution, for both upload and download: as long as at least one
connection is up at any given moment, the tunnel is stable, without
even a minimal interruption.
The behaviour is better described in the project README, along with
some example use cases and configurations.

With the spreading of Covid-19 here in North of Italy, many radio
speakers started transmitting from home, and I know of various radio
stations that used engarde to have a stable audio signal by using, for
example, the speaker's home connection and its smartphone one via USB
tethering.

First of all, I'd love to know what you think about it, or if you have
a better approach than this one: I searched a lot for possible
solutions before coming up with my own one and, even if I'm really
satisfied with it, I'd like to know if there are more "mainstream"
approaches for that.

Also, by testing this, I found a strange issue with the WireGuard
Windows client. For the solution to work, the WireGuard client must
send its packets not directly to the other peer, but to engarde
itself, that will dispatch them through all the interfaces. So, I need
to set "127.0.0.1:54321" as the peer address, where 54321 is the port
engarde is listening on. This works on Linux and Mac, but not on
Windows. When I bring the tunnel up with 127.0.0.1:12345 as peer
address, this is the error I get in logs:
```
2020-04-18 00:45:33.537: [TUN] [Radio] peer(gucn?uwWE) - Failed to
send handshake initiation write udp4 0.0.0.0:59301->127.0.0.1:12345:
wsasendto: Indirizzo richiesto non valido nel proprio contesto.
```
This seems to be returned directly by the OS, since it's translated:
I'm using Italian Windows, in the English version it's "The requested
address is not valid in its context".
The exact same configuration works like a charm in TunSafe.
Is this an issue that could be solved on the WireGuard side?

Thank you so much for any feedback you'll provide me, both for engarde
itself and for the issue I'm having on Windows.

[0] https://github.com/porech/engarde
[1] https://www.wireguard.com/protocol/ , "DoS Mitigation" section

From adhipati at tuta.io  Wed Apr 22 15:05:11 2020
From: adhipati at tuta.io (Adhipati Blambangan)
Date: Wed, 22 Apr 2020 15:05:11 +0200 (CEST)
Subject: Attaching XDP program into wireguard interface
Message-ID: <M5WzVK5--3-2@tuta.io>

Hello everyone,

I have tried to search for the same question in this mailing-list archive, but got no result.

I have wireguard connection in all of my machines running in production, and it works pretty well. Currently, we are thinking of doing some packet-classification using XDP as an early hook in the RX path.

A simple XDP program has been successfully attached to our "standard" interface. But, when I tried to attach the same XDP program to my wg0 interface, the logic in the XDP program did not kicked in. Is this something expected? if yes, is there any plan to support this use-case? I would like to help. But if not, could you guys shed me some light on what went wrong?

Thanks!

Adhipati B.

From alessandromagri at outlook.com  Thu Apr 23 14:21:21 2020
From: alessandromagri at outlook.com (Alessandro Magri)
Date: Thu, 23 Apr 2020 12:21:21 +0000
Subject: Debian package dependencies
Message-ID: <HE1P191MB0234A66C8CBFBB289F58E747B2D30@HE1P191MB0234.EURP191.PROD.OUTLOOK.COM>

Hi,
I'm new to this mail-list, so i hope to use it in the right way.
I'm using wireguard on some Debian machines, and yesterday after some update wireguard promt some strange errors about the wireguard-dkms module config.
In the end I've to install bc to make all work again.

I suggest to add this package to the dependencies list.
Thank's

Alessandro

From david at davidslab.com  Thu Apr 16 17:26:07 2020
From: david at davidslab.com (David Leung)
Date: Thu, 16 Apr 2020 23:26:07 +0800
Subject: Netlink API returns wrong attribute ID for peers on Ubuntu 19.10
Message-ID: <CACfAimOGRV7atBGjwGzDc=tgaNZYpzPjscGygLFBR=TYojJ3DQ@mail.gmail.com>

Hello,

I've been using the Netlink Generic API to get a WireGuard device's
peer endpoints successfully on NixOS.

When I run the same program on Ubuntu 19.10 (running wireguard version
v1.0.20200206), the peers attribute returned is 32776 instead of 8.
This doesn't match what's defined in
https://git.zx2c4.com/wireguard-tools/tree/contrib/embeddable-wg-library/wireguard.c.

I wonder if it's caused by a decoding mistake on my end, or if there's
something strange happening with the Ubuntu package.


Best,
David

From dsterba at suse.cz  Tue Apr 14 14:48:54 2020
From: dsterba at suse.cz (David Sterba)
Date: Tue, 14 Apr 2020 14:48:54 +0200
Subject: [PATCH 1/2] mm, treewide: Rename kzfree() to kfree_sensitive()
In-Reply-To: <20200413211550.8307-2-longman@redhat.com>
References: <20200413211550.8307-1-longman@redhat.com>
 <20200413211550.8307-2-longman@redhat.com>
Message-ID: <20200414124854.GQ5920@twin.jikos.cz>

On Mon, Apr 13, 2020 at 05:15:49PM -0400, Waiman Long wrote:
>  fs/btrfs/ioctl.c                              |  2 +-


> diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
> index 40b729dce91c..eab3f8510426 100644
> --- a/fs/btrfs/ioctl.c
> +++ b/fs/btrfs/ioctl.c
> @@ -2691,7 +2691,7 @@ static int btrfs_ioctl_get_subvol_info(struct file *file, void __user *argp)
>  	btrfs_put_root(root);
>  out_free:
>  	btrfs_free_path(path);
> -	kzfree(subvol_info);
> +	kfree_sensitive(subvol_info);

This is not in a sensitive context so please switch it to plain kfree.
With that you have my acked-by. Thanks.

From kalle-python at gmx.de  Wed Apr 15 14:14:50 2020
From: kalle-python at gmx.de (Kalle)
Date: Wed, 15 Apr 2020 14:14:50 +0200
Subject: Update kmod-wireguard on CentOS 7.7 failed
Message-ID: <r76trq$3frd$1@ciao.gmane.io>

Hello,

this happens on
# cat /etc/redhat-release
CentOS Linux release 7.7.1908 (Core)

# yum update
Resolving Dependencies
--> Running transaction check
---> Package kmod-wireguard.x86_64 0:1.0.20200401-1.el7_7.elrepo will be 
updated
---> Package kmod-wireguard.x86_64 0:1.0.20200413-1.el7_8.elrepo will be 
an update
--> Processing Dependency: kernel(siphash_4u64) = 0xdb8b9061 for 
package: kmod-wireguard-1.0.20200413-1.el7_8.elrepo.x86_64
--> Processing Dependency: kernel(siphash_3u32) = 0x04e11789 for 
package: kmod-wireguard-1.0.20200413-1.el7_8.elrepo.x86_64
--> Processing Dependency: kernel(siphash_1u64) = 0x0680ac30 for 
package: kmod-wireguard-1.0.20200413-1.el7_8.elrepo.x86_64
--> Finished Dependency Resolution
Error: Package: kmod-wireguard-1.0.20200413-1.el7_8.elrepo.x86_64 (elrepo)
            Requires: kernel(siphash_3u32) = 0x04e11789
Error: Package: kmod-wireguard-1.0.20200413-1.el7_8.elrepo.x86_64 (elrepo)
            Requires: kernel(siphash_4u64) = 0xdb8b9061
Error: Package: kmod-wireguard-1.0.20200413-1.el7_8.elrepo.x86_64 (elrepo)
            Requires: kernel(siphash_1u64) = 0x0680ac30
  You could try using --skip-broken to work around the problem
  You could try running: rpm -Va --nofiles --nodigest


Witch kmod-wireguard.x86_64 0:1.0.20200401-1.el7_7.elrepo everything was 
OK. Did i miss something?

Best regards,

Kalle.



From Jason at zx2c4.com  Fri Apr 24 22:55:17 2020
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Fri, 24 Apr 2020 14:55:17 -0600
Subject: Attaching XDP program into wireguard interface
In-Reply-To: <M5WzVK5--3-2@tuta.io>
References: <M5WzVK5--3-2@tuta.io>
Message-ID: <CAHmME9oGY8MVpMe1HbWm6AQCPxb4RcRpiAYrdDTBHAMotMyiGQ@mail.gmail.com>

Could you send some sample code for us to debug this with?

From Jason at zx2c4.com  Fri Apr 24 23:01:18 2020
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Fri, 24 Apr 2020 15:01:18 -0600
Subject: Attaching XDP program into wireguard interface
In-Reply-To: <CAHmME9oGY8MVpMe1HbWm6AQCPxb4RcRpiAYrdDTBHAMotMyiGQ@mail.gmail.com>
References: <M5WzVK5--3-2@tuta.io>
 <CAHmME9oGY8MVpMe1HbWm6AQCPxb4RcRpiAYrdDTBHAMotMyiGQ@mail.gmail.com>
Message-ID: <CAHmME9oDRO6FwJdjOCm0EZNRwtweSZAfxWyyMfptMDSf_h__Bg@mail.gmail.com>

Oh. Set XDP_FLAGS_SKB_MODE.

From Jason at zx2c4.com  Fri Apr 24 23:06:51 2020
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Fri, 24 Apr 2020 15:06:51 -0600
Subject: Attaching XDP program into wireguard interface
In-Reply-To: <CAHmME9oDRO6FwJdjOCm0EZNRwtweSZAfxWyyMfptMDSf_h__Bg@mail.gmail.com>
References: <M5WzVK5--3-2@tuta.io>
 <CAHmME9oGY8MVpMe1HbWm6AQCPxb4RcRpiAYrdDTBHAMotMyiGQ@mail.gmail.com>
 <CAHmME9oDRO6FwJdjOCm0EZNRwtweSZAfxWyyMfptMDSf_h__Bg@mail.gmail.com>
Message-ID: <CAHmME9r0Yd=vhF9mb0Yx5Yuyd=-hSC04zuuC-djumd6htgRj4g@mail.gmail.com>

Actually, try clearing XDP_FLAGS_DRV_MODE and XDP_FLAGS_HW_MODE.

From toke at toke.dk  Fri Apr 24 23:59:22 2020
From: toke at toke.dk (Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?=)
Date: Fri, 24 Apr 2020 23:59:22 +0200
Subject: Attaching XDP program into wireguard interface
In-Reply-To: <CAHmME9oDRO6FwJdjOCm0EZNRwtweSZAfxWyyMfptMDSf_h__Bg@mail.gmail.com>
References: <M5WzVK5--3-2@tuta.io>
 <CAHmME9oGY8MVpMe1HbWm6AQCPxb4RcRpiAYrdDTBHAMotMyiGQ@mail.gmail.com>
 <CAHmME9oDRO6FwJdjOCm0EZNRwtweSZAfxWyyMfptMDSf_h__Bg@mail.gmail.com>
Message-ID: <87a73035qd.fsf@toke.dk>

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

> Oh. Set XDP_FLAGS_SKB_MODE.

Yeah, you'd definitely need to run this in skb/generic XDP mode.

-Toke

From Jason at zx2c4.com  Sat Apr 25 00:02:40 2020
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Fri, 24 Apr 2020 16:02:40 -0600
Subject: Attaching XDP program into wireguard interface
In-Reply-To: <87a73035qd.fsf@toke.dk>
References: <M5WzVK5--3-2@tuta.io>
 <CAHmME9oGY8MVpMe1HbWm6AQCPxb4RcRpiAYrdDTBHAMotMyiGQ@mail.gmail.com>
 <CAHmME9oDRO6FwJdjOCm0EZNRwtweSZAfxWyyMfptMDSf_h__Bg@mail.gmail.com>
 <87a73035qd.fsf@toke.dk>
Message-ID: <CAHmME9rssE6_0hT3nS5703YTS0EG_Pug6vGonx9_tU6yLC2UUg@mail.gmail.com>

On Fri, Apr 24, 2020 at 3:59 PM Toke H?iland-J?rgensen <toke at toke.dk> wrote:
>
> "Jason A. Donenfeld" <Jason at zx2c4.com> writes:
>
> > Oh. Set XDP_FLAGS_SKB_MODE.
>
> Yeah, you'd definitely need to run this in skb/generic XDP mode.
>
> -Toke

It looks like the code in question is likely:

        bpf_op = bpf_chk = ops->ndo_bpf;
       if (!bpf_op && (flags & (XDP_FLAGS_DRV_MODE | XDP_FLAGS_HW_MODE))) {
               NL_SET_ERR_MSG(extack, "underlying driver does not
support XDP in native mode");
               return -EOPNOTSUPP;
       }
       if (!bpf_op || (flags & XDP_FLAGS_SKB_MODE))
               bpf_op = generic_xdp_install;
       if (bpf_op == bpf_chk)
               bpf_chk = generic_xdp_install;

It looks like bpf_op == generic_xdp_install is the case when neither
XDP_FLAGS_DRV_MODE or XDP_FLAGS_HW_MODE is set. Setting
XDP_FLAGS_SKB_MODE explicitly will force it on all drivers, but not
specifying it will fallback to it if the driver doesn't have hardware
support, which is WireGuard's case, unless either XDP_FLAGS_DRV_MODE
or XDP_FLAGS_HW_MODE are set.

From toke at toke.dk  Sat Apr 25 00:25:12 2020
From: toke at toke.dk (Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?=)
Date: Sat, 25 Apr 2020 00:25:12 +0200
Subject: Attaching XDP program into wireguard interface
In-Reply-To: <CAHmME9rssE6_0hT3nS5703YTS0EG_Pug6vGonx9_tU6yLC2UUg@mail.gmail.com>
References: <M5WzVK5--3-2@tuta.io>
 <CAHmME9oGY8MVpMe1HbWm6AQCPxb4RcRpiAYrdDTBHAMotMyiGQ@mail.gmail.com>
 <CAHmME9oDRO6FwJdjOCm0EZNRwtweSZAfxWyyMfptMDSf_h__Bg@mail.gmail.com>
 <87a73035qd.fsf@toke.dk>
 <CAHmME9rssE6_0hT3nS5703YTS0EG_Pug6vGonx9_tU6yLC2UUg@mail.gmail.com>
Message-ID: <877dy434jb.fsf@toke.dk>

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

> On Fri, Apr 24, 2020 at 3:59 PM Toke H?iland-J?rgensen <toke at toke.dk> wrote:
>>
>> "Jason A. Donenfeld" <Jason at zx2c4.com> writes:
>>
>> > Oh. Set XDP_FLAGS_SKB_MODE.
>>
>> Yeah, you'd definitely need to run this in skb/generic XDP mode.
>>
>> -Toke
>
> It looks like the code in question is likely:
>
>         bpf_op = bpf_chk = ops->ndo_bpf;
>        if (!bpf_op && (flags & (XDP_FLAGS_DRV_MODE | XDP_FLAGS_HW_MODE))) {
>                NL_SET_ERR_MSG(extack, "underlying driver does not
> support XDP in native mode");
>                return -EOPNOTSUPP;
>        }
>        if (!bpf_op || (flags & XDP_FLAGS_SKB_MODE))
>                bpf_op = generic_xdp_install;
>        if (bpf_op == bpf_chk)
>                bpf_chk = generic_xdp_install;
>
> It looks like bpf_op == generic_xdp_install is the case when neither
> XDP_FLAGS_DRV_MODE or XDP_FLAGS_HW_MODE is set. Setting
> XDP_FLAGS_SKB_MODE explicitly will force it on all drivers, but not
> specifying it will fallback to it if the driver doesn't have hardware
> support, which is WireGuard's case, unless either XDP_FLAGS_DRV_MODE
> or XDP_FLAGS_HW_MODE are set.

Yup, that sounds right :)

-Toke

From godisgovernment at gmail.com  Sat Apr 25 01:43:25 2020
From: godisgovernment at gmail.com (Shawn Hoffman)
Date: Fri, 24 Apr 2020 16:43:25 -0700
Subject: [PATCH 1/3] fix possible TunDispatchSecurityDescriptor leak.
Message-ID: <20200424234327.1814-1-godisgovernment@gmail.com>

TunDispatchSecurityDescriptor will leak if second
RtlAbsoluteToSelfRelativeSD fails. Practically this can't happen, but
from wintun code it's unclear.

Signed-off-by: Shawn Hoffman <godisgovernment at gmail.com>
---
 wintun.c | 15 ++++++++++++---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/wintun.c b/wintun.c
index 624de2f..90e7930 100644
--- a/wintun.c
+++ b/wintun.c
@@ -820,6 +820,14 @@ static NTSTATUS TunInitializeDispatchSecurityDescriptor(VOID)
     return STATUS_SUCCESS;
 }
 
+static VOID TunFreeDispatchSecurityDescriptor(VOID)
+{
+    if (!TunDispatchSecurityDescriptor)
+        return;
+    ExFreePoolWithTag(TunDispatchSecurityDescriptor, TUN_MEMORY_TAG);
+    TunDispatchSecurityDescriptor = NULL;
+}
+
 _IRQL_requires_max_(PASSIVE_LEVEL)
 static VOID
 TunProcessNotification(HANDLE ParentId, HANDLE ProcessId, BOOLEAN Create)
@@ -1387,7 +1395,7 @@ TunUnload(PDRIVER_OBJECT DriverObject)
     NdisMDeregisterMiniportDriver(NdisMiniportDriverHandle);
     ExDeleteResourceLite(&TunDispatchCtxGuard);
     ExDeleteResourceLite(&TunDispatchDeviceListLock);
-    ExFreePoolWithTag(TunDispatchSecurityDescriptor, TUN_MEMORY_TAG);
+    TunFreeDispatchSecurityDescriptor();
 }
 
 DRIVER_INITIALIZE DriverEntry;
@@ -1398,7 +1406,7 @@ DriverEntry(DRIVER_OBJECT *DriverObject, UNICODE_STRING *RegistryPath)
     NTSTATUS Status;
 
     if (!NT_SUCCESS(Status = TunInitializeDispatchSecurityDescriptor()))
-        return Status;
+        goto cleanupSD;
 
     NdisVersion = NdisGetVersion();
     if (NdisVersion < NDIS_MINIPORT_VERSION_MIN)
@@ -1461,6 +1469,7 @@ cleanupNotifier:
 cleanupResources:
     ExDeleteResourceLite(&TunDispatchCtxGuard);
     ExDeleteResourceLite(&TunDispatchDeviceListLock);
-    ExFreePoolWithTag(TunDispatchSecurityDescriptor, TUN_MEMORY_TAG);
+cleanupSD:
+    TunFreeDispatchSecurityDescriptor();
     return Status;
 }
-- 
2.26.2.windows.1


From godisgovernment at gmail.com  Sat Apr 25 01:43:26 2020
From: godisgovernment at gmail.com (Shawn Hoffman)
Date: Fri, 24 Apr 2020 16:43:26 -0700
Subject: [PATCH 2/3] use ExEnterCriticalRegionAndAcquireResourceExclusive and
 ExReleaseResourceAndLeaveCriticalRegion
In-Reply-To: <20200424234327.1814-1-godisgovernment@gmail.com>
References: <20200424234327.1814-1-godisgovernment@gmail.com>
Message-ID: <20200424234327.1814-2-godisgovernment@gmail.com>

Signed-off-by: Shawn Hoffman <godisgovernment at gmail.com>
---
 wintun.c | 12 ++++--------
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/wintun.c b/wintun.c
index 90e7930..00ac378 100644
--- a/wintun.c
+++ b/wintun.c
@@ -884,15 +884,13 @@ TunDispatchDeviceControl(DEVICE_OBJECT *DeviceObject, IRP *Irp)
     switch (Stack->Parameters.DeviceIoControl.IoControlCode)
     {
     case TUN_IOCTL_REGISTER_RINGS: {
-        KeEnterCriticalRegion();
-        ExAcquireResourceSharedLite(&TunDispatchCtxGuard, TRUE);
+        ExEnterCriticalRegionAndAcquireResourceExclusive(&TunDispatchCtxGuard);
 #pragma warning(suppress : 28175)
         TUN_CTX *Ctx = DeviceObject->Reserved;
         Status = NDIS_STATUS_ADAPTER_NOT_READY;
         if (Ctx)
             Status = TunRegisterBuffers(Ctx, Irp);
-        ExReleaseResourceLite(&TunDispatchCtxGuard);
-        KeLeaveCriticalRegion();
+        ExReleaseResourceAndLeaveCriticalRegion(&TunDispatchCtxGuard);
         break;
     }
     case TUN_IOCTL_FORCE_CLOSE_HANDLES:
@@ -913,14 +911,12 @@ _Use_decl_annotations_
 static NTSTATUS
 TunDispatchClose(DEVICE_OBJECT *DeviceObject, IRP *Irp)
 {
-    KeEnterCriticalRegion();
-    ExAcquireResourceSharedLite(&TunDispatchCtxGuard, TRUE);
+    ExEnterCriticalRegionAndAcquireResourceExclusive(&TunDispatchCtxGuard);
 #pragma warning(suppress : 28175)
     TUN_CTX *Ctx = DeviceObject->Reserved;
     if (Ctx)
         TunUnregisterBuffers(Ctx, IoGetCurrentIrpStackLocation(Irp)->FileObject);
-    ExReleaseResourceLite(&TunDispatchCtxGuard);
-    KeLeaveCriticalRegion();
+    ExReleaseResourceAndLeaveCriticalRegion(&TunDispatchCtxGuard);
     return NdisDispatchClose(DeviceObject, Irp);
 }
 
-- 
2.26.2.windows.1


From godisgovernment at gmail.com  Sat Apr 25 01:43:27 2020
From: godisgovernment at gmail.com (Shawn Hoffman)
Date: Fri, 24 Apr 2020 16:43:27 -0700
Subject: [PATCH 3/3] use RtlSubAuthoritySid instead of directly poking SID
In-Reply-To: <20200424234327.1814-1-godisgovernment@gmail.com>
References: <20200424234327.1814-1-godisgovernment@gmail.com>
Message-ID: <20200424234327.1814-3-godisgovernment@gmail.com>

Signed-off-by: Shawn Hoffman <godisgovernment at gmail.com>
---
 wintun.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/wintun.c b/wintun.c
index 00ac378..a6a0e16 100644
--- a/wintun.c
+++ b/wintun.c
@@ -788,7 +788,7 @@ static NTSTATUS TunInitializeDispatchSecurityDescriptor(VOID)
     SID LocalSystem = { 0 };
     if (!NT_SUCCESS(Status = RtlInitializeSid(&LocalSystem, &NtAuthority, 1)))
         return Status;
-    LocalSystem.SubAuthority[0] = 18;
+    *RtlSubAuthoritySid(&LocalSystem, 0) = SECURITY_LOCAL_SYSTEM_RID;
     struct
     {
         ACL Dacl;
-- 
2.26.2.windows.1


From godisgovernment at gmail.com  Sat Apr 25 01:47:45 2020
From: godisgovernment at gmail.com (Shawn Hoffman)
Date: Fri, 24 Apr 2020 16:47:45 -0700
Subject: [PATCH] use standard volatile semantics
Message-ID: <20200424234745.1031-1-godisgovernment@gmail.com>

Make all archs are use the standardized concept of volatile.
This patch will cause the most changes to arm64 codegen, and has
yet to be tested on arm64 so is currently being submitted for
comments. If someone would like to test on arm64 it would be
appreciated. I do have an arm64 device, but it seems there's no
existing arm64/windows wireguard binary package, so I can't
just install such a thing and swap out the driver.

Signed-off-by: Shawn Hoffman <godisgovernment at gmail.com>
---
 atomic.h               | 54 ------------------------------
 wintun.c               | 76 +++++++++++++++++++++---------------------
 wintun.vcxproj         |  5 ++-
 wintun.vcxproj.filters |  3 --
 4 files changed, 40 insertions(+), 98 deletions(-)
 delete mode 100644 atomic.h

diff --git a/atomic.h b/atomic.h
deleted file mode 100644
index 01dd35e..0000000
--- a/atomic.h
+++ /dev/null
@@ -1,54 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0
- *
- * Copyright (C) 2018-2019 WireGuard LLC. All Rights Reserved.
- */
-
-#pragma once
-
-#include <wdm.h>
-
-static __forceinline VOID
-InterlockedSet(_Inout_ _Interlocked_operand_ LONG volatile *Target, _In_ LONG Value)
-{
-    *Target = Value;
-}
-
-static __forceinline VOID
-InterlockedSetU(_Inout_ _Interlocked_operand_ ULONG volatile *Target, _In_ ULONG Value)
-{
-    *Target = Value;
-}
-
-static __forceinline VOID
-InterlockedSetPointer(_Inout_ _Interlocked_operand_ VOID *volatile *Target, _In_opt_ VOID *Value)
-{
-    *Target = Value;
-}
-
-static __forceinline LONG
-InterlockedGet(_In_ _Interlocked_operand_ LONG volatile *Value)
-{
-    return *Value;
-}
-
-static __forceinline ULONG
-InterlockedGetU(_In_ _Interlocked_operand_ ULONG volatile *Value)
-{
-    return *Value;
-}
-
-static __forceinline PVOID
-InterlockedGetPointer(_In_ _Interlocked_operand_ PVOID volatile *Value)
-{
-    return *Value;
-}
-
-static __forceinline LONG64
-InterlockedGet64(_In_ _Interlocked_operand_ LONG64 volatile *Value)
-{
-#ifdef _WIN64
-    return *Value;
-#else
-    return InterlockedCompareExchange64(Value, 0, 0);
-#endif
-}
\ No newline at end of file
diff --git a/wintun.c b/wintun.c
index a6a0e16..b042d35 100644
--- a/wintun.c
+++ b/wintun.c
@@ -9,7 +9,6 @@
 #include <ndis.h>
 #include <ntstrsafe.h>
 #include "undocumented.h"
-#include "atomic.h"
 
 #pragma warning(disable : 4100) /* unreferenced formal parameter */
 #pragma warning(disable : 4200) /* nonstandard: zero-sized array in struct/union */
@@ -250,7 +249,7 @@ TunSendNetBufferLists(
 
     KIRQL Irql = ExAcquireSpinLockShared(&Ctx->TransitionLock);
     NDIS_STATUS Status;
-    if ((Status = NDIS_STATUS_PAUSED, !InterlockedGet(&Ctx->Running)) ||
+    if ((Status = NDIS_STATUS_PAUSED, !ReadAcquire(&Ctx->Running)) ||
         (Status = NDIS_STATUS_MEDIA_DISCONNECTED, KeReadStateEvent(&Ctx->Device.Disconnected)))
         goto skipNbl;
 
@@ -258,7 +257,7 @@ TunSendNetBufferLists(
     ULONG RingCapacity = Ctx->Device.Send.Capacity;
 
     /* Allocate space for packets in the ring. */
-    ULONG RingHead = InterlockedGetU(&Ring->Head);
+    ULONG RingHead = ReadULongAcquire(&Ring->Head);
     if (Status = NDIS_STATUS_ADAPTER_NOT_READY, RingHead >= RingCapacity)
         goto skipNbl;
 
@@ -325,7 +324,7 @@ TunSendNetBufferLists(
     {
         NET_BUFFER_LIST *CompletedNbl = Ctx->Device.Send.ActiveNbls.Head;
         Ctx->Device.Send.ActiveNbls.Head = NET_BUFFER_LIST_NEXT_NBL_EX(CompletedNbl);
-        InterlockedSetU(&Ring->Tail, TunNblGetOffset(CompletedNbl));
+        WriteULongRelease(&Ring->Tail, TunNblGetOffset(CompletedNbl));
         KeSetEvent(Ctx->Device.Send.TailMoved, IO_NETWORK_INCREMENT, FALSE);
         NdisMSendNetBufferListsComplete(
             Ctx->MiniportAdapterHandle, CompletedNbl, NDIS_SEND_COMPLETE_FLAGS_DISPATCH_LEVEL);
@@ -343,11 +342,11 @@ skipNbl:
     ExReleaseSpinLockShared(&Ctx->TransitionLock, Irql);
     NdisMSendNetBufferListsComplete(Ctx->MiniportAdapterHandle, NetBufferLists, 0);
 updateStatistics:
-    InterlockedAdd64((LONG64 *)&Ctx->Statistics.ifHCOutOctets, SentPacketsSize);
-    InterlockedAdd64((LONG64 *)&Ctx->Statistics.ifHCOutUcastOctets, SentPacketsSize);
-    InterlockedAdd64((LONG64 *)&Ctx->Statistics.ifHCOutUcastPkts, SentPacketsCount);
-    InterlockedAdd64((LONG64 *)&Ctx->Statistics.ifOutErrors, ErrorPacketsCount);
-    InterlockedAdd64((LONG64 *)&Ctx->Statistics.ifOutDiscards, DiscardedPacketsCount);
+    InterlockedAddNoFence64((LONG64 *)&Ctx->Statistics.ifHCOutOctets, SentPacketsSize);
+    InterlockedAddNoFence64((LONG64 *)&Ctx->Statistics.ifHCOutUcastOctets, SentPacketsSize);
+    InterlockedAddNoFence64((LONG64 *)&Ctx->Statistics.ifHCOutUcastPkts, SentPacketsCount);
+    InterlockedAddNoFence64((LONG64 *)&Ctx->Statistics.ifOutErrors, ErrorPacketsCount);
+    InterlockedAddNoFence64((LONG64 *)&Ctx->Statistics.ifOutDiscards, DiscardedPacketsCount);
 }
 
 static MINIPORT_CANCEL_SEND TunCancelSend;
@@ -393,15 +392,15 @@ TunReturnNetBufferLists(NDIS_HANDLE MiniportAdapterContext, PNET_BUFFER_LIST Net
             if (!Ctx->Device.Receive.ActiveNbls.Head)
                 KeSetEvent(&Ctx->Device.Receive.ActiveNbls.Empty, IO_NO_INCREMENT, FALSE);
             KeReleaseInStackQueuedSpinLock(&LockHandle);
-            InterlockedSetU(&Ring->Head, TunNblGetOffset(CompletedNbl));
+            WriteULongRelease(&Ring->Head, TunNblGetOffset(CompletedNbl));
             NdisFreeNetBufferList(CompletedNbl);
         }
     }
 
-    InterlockedAdd64((LONG64 *)&Ctx->Statistics.ifHCInOctets, ReceivedPacketsSize);
-    InterlockedAdd64((LONG64 *)&Ctx->Statistics.ifHCInUcastOctets, ReceivedPacketsSize);
-    InterlockedAdd64((LONG64 *)&Ctx->Statistics.ifHCInUcastPkts, ReceivedPacketsCount);
-    InterlockedAdd64((LONG64 *)&Ctx->Statistics.ifInErrors, ErrorPacketsCount);
+    InterlockedAddNoFence64((LONG64 *)&Ctx->Statistics.ifHCInOctets, ReceivedPacketsSize);
+    InterlockedAddNoFence64((LONG64 *)&Ctx->Statistics.ifHCInUcastOctets, ReceivedPacketsSize);
+    InterlockedAddNoFence64((LONG64 *)&Ctx->Statistics.ifHCInUcastPkts, ReceivedPacketsCount);
+    InterlockedAddNoFence64((LONG64 *)&Ctx->Statistics.ifInErrors, ErrorPacketsCount);
 }
 
 _IRQL_requires_max_(PASSIVE_LEVEL)
@@ -419,20 +418,20 @@ TunProcessReceiveData(_Inout_ TUN_CTX *Ctx)
     VOID *Events[] = { &Ctx->Device.Disconnected, Ctx->Device.Receive.TailMoved };
     ASSERT(RTL_NUMBER_OF(Events) <= THREAD_WAIT_OBJECTS);
 
-    ULONG RingHead = InterlockedGetU(&Ring->Head);
+    ULONG RingHead = ReadULongAcquire(&Ring->Head);
     if (RingHead >= RingCapacity)
         goto cleanup;
 
     while (!KeReadStateEvent(&Ctx->Device.Disconnected))
     {
         /* Get next packet from the ring. */
-        ULONG RingTail = InterlockedGetU(&Ring->Tail);
+        ULONG RingTail = ReadULongAcquire(&Ring->Tail);
         if (RingHead == RingTail)
         {
             LARGE_INTEGER SpinStart = KeQueryPerformanceCounter(NULL);
             for (;;)
             {
-                RingTail = InterlockedGetU(&Ring->Tail);
+                RingTail = ReadULongAcquire(&Ring->Tail);
                 if (RingTail != RingHead)
                     break;
                 if (KeReadStateEvent(&Ctx->Device.Disconnected))
@@ -444,16 +443,16 @@ TunProcessReceiveData(_Inout_ TUN_CTX *Ctx)
             }
             if (RingHead == RingTail)
             {
-                InterlockedSet(&Ring->Alertable, TRUE);
-                RingTail = InterlockedGetU(&Ring->Tail);
+                WriteRelease(&Ring->Alertable, TRUE);
+                RingTail = ReadULongAcquire(&Ring->Tail);
                 if (RingHead == RingTail)
                 {
                     KeWaitForMultipleObjects(
                         RTL_NUMBER_OF(Events), Events, WaitAny, Executive, KernelMode, FALSE, NULL, NULL);
-                    InterlockedSet(&Ring->Alertable, FALSE);
+                    WriteRelease(&Ring->Alertable, FALSE);
                     continue;
                 }
-                InterlockedSet(&Ring->Alertable, FALSE);
+                WriteRelease(&Ring->Alertable, FALSE);
                 KeClearEvent(Ctx->Device.Receive.TailMoved);
             }
         }
@@ -501,7 +500,7 @@ TunProcessReceiveData(_Inout_ TUN_CTX *Ctx)
         TunNblSetOffsetAndMarkActive(Nbl, RingHead);
 
         KIRQL Irql = ExAcquireSpinLockShared(&Ctx->TransitionLock);
-        if (!InterlockedGet(&Ctx->Running))
+        if (!ReadAcquire(&Ctx->Running))
             goto cleanupNbl;
 
         KLOCK_QUEUE_HANDLE LockHandle;
@@ -530,16 +529,16 @@ TunProcessReceiveData(_Inout_ TUN_CTX *Ctx)
         ExReleaseSpinLockShared(&Ctx->TransitionLock, Irql);
         NdisFreeNetBufferList(Nbl);
     skipNbl:
-        InterlockedIncrement64((LONG64 *)&Ctx->Statistics.ifInDiscards);
+        InterlockedIncrementNoFence64((LONG64 *)&Ctx->Statistics.ifInDiscards);
         KeWaitForSingleObject(&Ctx->Device.Receive.ActiveNbls.Empty, Executive, KernelMode, FALSE, NULL);
-        InterlockedSetU(&Ring->Head, RingHead);
+        WriteULongRelease(&Ring->Head, RingHead);
     }
 
     /* Wait for all NBLs to return: 1. To prevent race between proceeding and invalidating ring head. 2. To have
      * TunDispatchUnregisterBuffers() implicitly wait before releasing ring MDL used by NBL(s). */
     KeWaitForSingleObject(&Ctx->Device.Receive.ActiveNbls.Empty, Executive, KernelMode, FALSE, NULL);
 cleanup:
-    InterlockedSetU(&Ring->Head, MAXULONG);
+    WriteULongRelease(&Ring->Head, MAXULONG);
 }
 
 #define IS_POW2(x) ((x) && !((x) & ((x)-1)))
@@ -595,7 +594,7 @@ TunRegisterBuffers(_Inout_ TUN_CTX *Ctx, _Inout_ IRP *Irp)
     if (Status = STATUS_INSUFFICIENT_RESOURCES, !Ctx->Device.Send.Ring)
         goto cleanupSendUnlockPages;
 
-    Ctx->Device.Send.RingTail = InterlockedGetU(&Ctx->Device.Send.Ring->Tail);
+    Ctx->Device.Send.RingTail = ReadULongAcquire(&Ctx->Device.Send.Ring->Tail);
     if (Status = STATUS_INVALID_PARAMETER, Ctx->Device.Send.RingTail >= Ctx->Device.Send.Capacity)
         goto cleanupSendUnlockPages;
 
@@ -709,7 +708,7 @@ TunUnregisterBuffers(_Inout_ TUN_CTX *Ctx, _In_ FILE_OBJECT *Owner)
     }
     ZwClose(Ctx->Device.Receive.Thread);
 
-    InterlockedSetU(&Ctx->Device.Send.Ring->Tail, MAXULONG);
+    WriteULongRelease(&Ctx->Device.Send.Ring->Tail, MAXULONG);
     KeSetEvent(Ctx->Device.Send.TailMoved, IO_NO_INCREMENT, FALSE);
 
     MmUnlockPages(Ctx->Device.Receive.Mdl);
@@ -926,7 +925,7 @@ static NDIS_STATUS
 TunRestart(NDIS_HANDLE MiniportAdapterContext, PNDIS_MINIPORT_RESTART_PARAMETERS MiniportRestartParameters)
 {
     TUN_CTX *Ctx = (TUN_CTX *)MiniportAdapterContext;
-    InterlockedSet(&Ctx->Running, TRUE);
+    WriteRelease(&Ctx->Running, TRUE);
     return NDIS_STATUS_SUCCESS;
 }
 
@@ -937,7 +936,7 @@ TunPause(NDIS_HANDLE MiniportAdapterContext, PNDIS_MINIPORT_PAUSE_PARAMETERS Min
 {
     TUN_CTX *Ctx = (TUN_CTX *)MiniportAdapterContext;
 
-    InterlockedSet(&Ctx->Running, FALSE);
+    WriteRelease(&Ctx->Running, FALSE);
     ExReleaseSpinLockExclusive(
         &Ctx->TransitionLock,
         ExAcquireSpinLockExclusive(&Ctx->TransitionLock)); /* Ensure above change is visible to all readers. */
@@ -1131,9 +1130,10 @@ TunHaltEx(NDIS_HANDLE MiniportAdapterContext, NDIS_HALT_ACTION HaltAction)
         ExAcquireSpinLockExclusive(&Ctx->TransitionLock)); /* Ensure above change is visible to all readers. */
     NdisFreeNetBufferListPool(Ctx->NblPool);
 
-    InterlockedSetPointer(&Ctx->MiniportAdapterHandle, NULL);
-#pragma warning(suppress : 28175)
-    InterlockedSetPointer(&Ctx->FunctionalDeviceObject->Reserved, NULL);
+#pragma warning(suppress : 6387)
+    WritePointerNoFence(&Ctx->MiniportAdapterHandle, NULL);
+#pragma warning(suppress : 6387 28175)
+    WritePointerNoFence(&Ctx->FunctionalDeviceObject->Reserved, NULL);
     KeEnterCriticalRegion();
     ExAcquireResourceExclusiveLite(&TunDispatchCtxGuard, TRUE); /* Ensure above change is visible to all readers. */
     ExReleaseResourceLite(&TunDispatchCtxGuard);
@@ -1242,16 +1242,16 @@ TunOidQuery(_Inout_ TUN_CTX *Ctx, _Inout_ NDIS_OID_REQUEST *OidRequest)
     case OID_GEN_XMIT_OK:
         return TunOidQueryWrite32or64(
             OidRequest,
-            InterlockedGet64((LONG64 *)&Ctx->Statistics.ifHCOutUcastPkts) +
-                InterlockedGet64((LONG64 *)&Ctx->Statistics.ifHCOutMulticastPkts) +
-                InterlockedGet64((LONG64 *)&Ctx->Statistics.ifHCOutBroadcastPkts));
+            ReadNoFence64((LONG64 *)&Ctx->Statistics.ifHCOutUcastPkts) +
+                ReadNoFence64((LONG64 *)&Ctx->Statistics.ifHCOutMulticastPkts) +
+                ReadNoFence64((LONG64 *)&Ctx->Statistics.ifHCOutBroadcastPkts));
 
     case OID_GEN_RCV_OK:
         return TunOidQueryWrite32or64(
             OidRequest,
-            InterlockedGet64((LONG64 *)&Ctx->Statistics.ifHCInUcastPkts) +
-                InterlockedGet64((LONG64 *)&Ctx->Statistics.ifHCInMulticastPkts) +
-                InterlockedGet64((LONG64 *)&Ctx->Statistics.ifHCInBroadcastPkts));
+            ReadNoFence64((LONG64 *)&Ctx->Statistics.ifHCInUcastPkts) +
+                ReadNoFence64((LONG64 *)&Ctx->Statistics.ifHCInMulticastPkts) +
+                ReadNoFence64((LONG64 *)&Ctx->Statistics.ifHCInBroadcastPkts));
 
     case OID_GEN_STATISTICS:
         return TunOidQueryWriteBuf(OidRequest, &Ctx->Statistics, (ULONG)sizeof(Ctx->Statistics));
diff --git a/wintun.vcxproj b/wintun.vcxproj
index 3bb61d1..abe4a17 100644
--- a/wintun.vcxproj
+++ b/wintun.vcxproj
@@ -125,7 +125,7 @@
   <ItemDefinitionGroup>
     <ClCompile>
       <PreprocessorDefinitions>NDIS_MINIPORT_DRIVER=1;NDIS620_MINIPORT=1;NDIS683_MINIPORT=1;NDIS_WDM=1;%(PreprocessorDefinitions)</PreprocessorDefinitions>
-      <AdditionalOptions>/volatile:ms %(AdditionalOptions)</AdditionalOptions>
+      <AdditionalOptions>/volatile:iso %(AdditionalOptions)</AdditionalOptions>
       <EnablePREfast>true</EnablePREfast>
     </ClCompile>
     <ResourceCompile>
@@ -171,9 +171,8 @@
     <FilesToPackage Include="$(TargetPath)" Condition="'$(ConfigurationType)'=='Driver' or '$(ConfigurationType)'=='DynamicLibrary'" />
   </ItemGroup>
   <ItemGroup>
-    <ClInclude Include="atomic.h" />
     <ClInclude Include="undocumented.h" />
   </ItemGroup>
   <Import Project="$(VCTargetsPath)\Microsoft.Cpp.targets" />
   <ImportGroup Label="ExtensionTargets" />
-</Project>
+</Project>
\ No newline at end of file
diff --git a/wintun.vcxproj.filters b/wintun.vcxproj.filters
index 467cc48..3e19120 100644
--- a/wintun.vcxproj.filters
+++ b/wintun.vcxproj.filters
@@ -33,8 +33,5 @@
     <ClInclude Include="undocumented.h">
       <Filter>Header Files</Filter>
     </ClInclude>
-    <ClInclude Include="atomic.h">
-      <Filter>Header Files</Filter>
-    </ClInclude>
   </ItemGroup>
 </Project>
\ No newline at end of file
-- 
2.26.2.windows.1


From simon at rozman.si  Sat Apr 25 08:23:23 2020
From: simon at rozman.si (Simon Rozman)
Date: Sat, 25 Apr 2020 06:23:23 +0000
Subject: [PATCH 0/1] wintun: use standard volatile semantics
In-Reply-To: <20200424194010.32225-1-godisgovernment@gmail.com>
References: <20200424194010.32225-1-godisgovernment@gmail.com>
Message-ID: <B6B013EB-18CF-4017-A096-3512B19C9963@rozman.si>

Hi Shawn!

Thank you. This generally looks good. I can't find any official documentation on the set of functions and macros from wdm.h, but that's nothing new with Microsoft. 

I have some nitpicks thou.

1. As the atomic.h is no longer used; it could be deleted from the repo.
2. By removing #include "atomic.h", you should add #include <wdm.h>. wintun.c is now directly using functions and macros declared in wdm.h.
3. Please add "Signed-of-by: Shawn Hoffman <godisgovernment at gmail.com>" line to your commit message.
4. You are right, there is no WireGuard for Windows 10 ARM64 yet, because there is no MinGW and Go support for Windows 10 ARM64 yet. If we can get arm-w64-mingw32-native, we could use set GOARCH=arm to compile 32-bit ARM wireguard.exe. 32-bit ARM runs at native speed on Windows 10 ARM64. The challenge I see is making SetupAPI work. I do know the SetupAPI does not work in x86 processes on AMD64 Windows. The System32 folder deflection makes it fail when attempting to create a device. I am expecting the same in ARM process on ARM64 Windows.

I have the ARM/ARM64 support high on my TODO list. I do hope to find some time next week to play with your patch and WireGuard ARM.

Regards, Simon

?-----Original Message-----
From: WireGuard <wireguard-bounces at lists.zx2c4.com> on behalf of Shawn Hoffman <godisgovernment at gmail.com>
Date: Friday, 24. April 2020 at 22:52
To: "wireguard at lists.zx2c4.com" <wireguard at lists.zx2c4.com>
Cc: Shawn Hoffman <godisgovernment at gmail.com>
Subject: [PATCH 0/1] wintun: use standard volatile semantics

    Make all archs are use the standardized concept of volatile.
    This patch will cause the most changes to arm64 codegen, and has
    yet to be tested on arm64 so is currently being submitted for
    comments. If someone would like to test on arm64 it would be
    appreciated. I do have an arm64 device, but it seems there's no
    existing arm64/windows wireguard binary package, so I can't
    just install such a thing and swap out the driver.

    Shawn Hoffman (1):
      replace atomic.h with provided APIs switch to /volatile:iso

     wintun.c               | 76 +++++++++++++++++++++---------------------
     wintun.vcxproj         |  5 ++-
     wintun.vcxproj.filters |  3 --
     3 files changed, 40 insertions(+), 44 deletions(-)

    -- 
    2.20.1

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2965 bytes
Desc: not available
URL: <http://lists.zx2c4.com/pipermail/wireguard/attachments/20200425/2f102d23/attachment.p7s>

From Jason at zx2c4.com  Sat Apr 25 10:51:43 2020
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Sat, 25 Apr 2020 02:51:43 -0600
Subject: [PATCH 0/1] wintun: use standard volatile semantics
In-Reply-To: <B6B013EB-18CF-4017-A096-3512B19C9963@rozman.si>
References: <20200424194010.32225-1-godisgovernment@gmail.com>
 <B6B013EB-18CF-4017-A096-3512B19C9963@rozman.si>
Message-ID: <CAHmME9rSMmdCgLdO1ST2ECWFbFvmUxmWWO+QXe+7+pitAhe8uw@mail.gmail.com>

On Sat, Apr 25, 2020 at 12:23 AM Simon Rozman <simon at rozman.si> wrote:
>
> Hi Shawn!
>
> Thank you. This generally looks good. I can't find any official documentation on the set of functions and macros from wdm.h, but that's nothing new with Microsoft.
>
> I have some nitpicks thou.
>
> 1. As the atomic.h is no longer used; it could be deleted from the repo.
> 2. By removing #include "atomic.h", you should add #include <wdm.h>. wintun.c is now directly using functions and macros declared in wdm.h.
> 3. Please add "Signed-of-by: Shawn Hoffman <godisgovernment at gmail.com>" line to your commit message.

He resubmitted with his S-o-b line. See that patch series for the latest.

From godisgovernment at gmail.com  Sun Apr 26 05:52:53 2020
From: godisgovernment at gmail.com (Shawn Hoffman)
Date: Sat, 25 Apr 2020 20:52:53 -0700
Subject: [PATCH 2/3] use ExEnterCriticalRegionAndAcquireResourceExclusive
 and ExReleaseResourceAndLeaveCriticalRegion
In-Reply-To: <20200424234327.1814-2-godisgovernment@gmail.com>
References: <20200424234327.1814-1-godisgovernment@gmail.com>
 <20200424234327.1814-2-godisgovernment@gmail.com>
Message-ID: <CAPqQDTDPUH17QUQG4xehfiM9zFGw7PVQu=u00v5x15ts=L7SVQ@mail.gmail.com>

Looking back over this, the enter+acquire of the existing code is
shared here, so replacing with exclusive will change behavior.
For now, please ignore this patch.


On Fri, Apr 24, 2020 at 4:44 PM Shawn Hoffman <godisgovernment at gmail.com> wrote:
>
> Signed-off-by: Shawn Hoffman <godisgovernment at gmail.com>
> ---
>  wintun.c | 12 ++++--------
>  1 file changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/wintun.c b/wintun.c
> index 90e7930..00ac378 100644
> --- a/wintun.c
> +++ b/wintun.c
> @@ -884,15 +884,13 @@ TunDispatchDeviceControl(DEVICE_OBJECT *DeviceObject, IRP *Irp)
>      switch (Stack->Parameters.DeviceIoControl.IoControlCode)
>      {
>      case TUN_IOCTL_REGISTER_RINGS: {
> -        KeEnterCriticalRegion();
> -        ExAcquireResourceSharedLite(&TunDispatchCtxGuard, TRUE);
> +        ExEnterCriticalRegionAndAcquireResourceExclusive(&TunDispatchCtxGuard);
>  #pragma warning(suppress : 28175)
>          TUN_CTX *Ctx = DeviceObject->Reserved;
>          Status = NDIS_STATUS_ADAPTER_NOT_READY;
>          if (Ctx)
>              Status = TunRegisterBuffers(Ctx, Irp);
> -        ExReleaseResourceLite(&TunDispatchCtxGuard);
> -        KeLeaveCriticalRegion();
> +        ExReleaseResourceAndLeaveCriticalRegion(&TunDispatchCtxGuard);
>          break;
>      }
>      case TUN_IOCTL_FORCE_CLOSE_HANDLES:
> @@ -913,14 +911,12 @@ _Use_decl_annotations_
>  static NTSTATUS
>  TunDispatchClose(DEVICE_OBJECT *DeviceObject, IRP *Irp)
>  {
> -    KeEnterCriticalRegion();
> -    ExAcquireResourceSharedLite(&TunDispatchCtxGuard, TRUE);
> +    ExEnterCriticalRegionAndAcquireResourceExclusive(&TunDispatchCtxGuard);
>  #pragma warning(suppress : 28175)
>      TUN_CTX *Ctx = DeviceObject->Reserved;
>      if (Ctx)
>          TunUnregisterBuffers(Ctx, IoGetCurrentIrpStackLocation(Irp)->FileObject);
> -    ExReleaseResourceLite(&TunDispatchCtxGuard);
> -    KeLeaveCriticalRegion();
> +    ExReleaseResourceAndLeaveCriticalRegion(&TunDispatchCtxGuard);
>      return NdisDispatchClose(DeviceObject, Irp);
>  }
>
> --
> 2.26.2.windows.1
>

From Jason at zx2c4.com  Mon Apr 27 03:24:29 2020
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Sun, 26 Apr 2020 19:24:29 -0600
Subject: [ANNOUNCE] wireguard-linux-compat v1.0.20200426 released
Message-ID: <b9ca30b38895d715@mail.zx2c4.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hello,

A new version, v1.0.20200426, of the backported WireGuard kernel module for
3.10 <= Linux <= 5.5.y has been tagged in the git repository.

== Changes ==

  * crypto: do not export symbols
  
  These don't do anything and only increased file size.
  
  * compat: include sch_generic.h header for skb_reset_tc
  
  A fix for a compiler error on kernels with weird configs.
  
  * compat: import latest fixes for ptr_ring
  * compat: don't assume READ_ONCE barriers on old kernels
  * compat: kvmalloc_array is not required anyway
  
  ptr_ring.h from upstream was imported, with compat modifications, to our
  compat layer, to receive the latest fixes.
  
  * queueing: cleanup ptr_ring in error path of packet_queue_init
  
  Sultan Alsawaf reported a memory leak on an error path.
  
  * main: mark as in-tree
  
  Now that we're upstream, there's no need to set the taint flag.
  
  * compat: prefix icmp[v6]_ndo_send with __compat
  
  Some distros that backported icmp[v6]_ndo_send still try to build the compat
  module in some corner case circumstances, resulting in errors.  Work around
  this with the usual __compat games.

This release contains commits from: Jason A. Donenfeld.

As always, the source is available at https://git.zx2c4.com/wireguard-linux-compat/
and information about the project is available at https://www.wireguard.com/ .

This version is available in compressed tarball form here:
  https://git.zx2c4.com/wireguard-linux-compat/snapshot/wireguard-linux-compat-1.0.20200426.tar.xz
  SHA2-256: 

A PGP signature of that file decompressed is available here:
  https://git.zx2c4.com/wireguard-linux-compat/snapshot/wireguard-linux-compat-1.0.20200426.tar.asc
  Signing key: AB9942E6D4A4CFC3412620A749FC7012A5DE03AE
  Remember to unxz the tarball before verifying the signature.

If you're a package maintainer, please bump your package version. If you're a
user, the WireGuard team welcomes any and all feedback on this latest version.

Finally, WireGuard development thrives on donations. By popular demand, we
have a webpage for this: https://www.wireguard.com/donations/

Thank you,
Jason Donenfeld


-----BEGIN PGP SIGNATURE-----

iQJEBAEBCAAuFiEEq5lC5tSkz8NBJiCnSfxwEqXeA64FAl6mNEcQHGphc29uQHp4
MmM0LmNvbQAKCRBJ/HASpd4DrpqAD/4xD9CHxEIRdCKy/j/0qSBegU9wokp8uOpt
anYHDU8lnma+Om9F6r43zo2wByBb3re68r7S7XH8VNEG3qlTPaRGQ3DKaquUzrI5
rPVFDHz/6v8s5PghqHke2rdEANTlaxzE2oNxWSMz8LnC2dvbl7SKWTp+onfz9YIk
cU0MSUqebwYu4hYGSiYGYCs0qcWEQIO8Ux/6YT1SXwVzCF2yVhQ/OpYAiKIiai6s
R1iz3GMVroOL5ssu2jB23Ge21RQHI6sSs2RKUJ06wgTMl6zLZd0zkmohMSkbQihh
el5MalXFKkZ98bUDaujCM+UAQrt7asaIt9Ezm2pxwXr9GxDnjnIrecQLGAM8Jcub
im/A/3xoplOF5fCyQzsBuNSt4lfemZ4e1auVKl+0xvgtf5uYUhA3I+kTts1EE0fm
74yxFuV3dXTQtZukf4jV7gT1RXebrWSrcCHcLXLi228ltUbhk7swECFzEOG++hCP
J+llzIT3iLblN/dgayX+FkZPKiw5++jl1X77TDc6KC1z7LdbDZPjgekfGPVZGYqy
W37xweT5TAWCm816EnzuES8Oz+9WvUfghTGnpxEiGiYuPaEKGMUeUU37Qc1YTwcM
K1iFkrxoi11ygM8iOy384bDAD7z7nLZBYYJzYlSnRCWis08Lr853afl+s4xVYbOh
42ZO//eS4Q==
=7G1T
-----END PGP SIGNATURE-----

From toke at redhat.com  Mon Apr 27 16:46:25 2020
From: toke at redhat.com (=?UTF-8?q?Toke=20H=C3=B8iland-J=C3=B8rgensen?=)
Date: Mon, 27 Apr 2020 16:46:25 +0200
Subject: [PATCH net] wireguard: Use tunnel helpers for decapsulating ECN
 markings
Message-ID: <20200427144625.581110-1-toke@redhat.com>

WireGuard currently only propagates ECN markings on tunnel decap according
to the old RFC3168 specification. However, the spec has since been updated
in RFC6040 to recommend slightly different decapsulation semantics. This
was implemented in the kernel as a set of common helpers for ECN
decapsulation, so let's just switch over WireGuard to using those, so it
can benefit from this enhancement and any future tweaks.

RFC6040 also recommends dropping packets on certain combinations of
erroneous code points on the inner and outer packet headers which shouldn't
appear in normal operation. The helper signals this by a return value > 1,
so also add a handler for this case.

Fixes: e7096c131e51 ("net: WireGuard secure network tunnel")
Reported-by: Olivier Tilmans <olivier.tilmans at nokia-bell-labs.com>
Cc: Dave Taht <dave.taht at gmail.com>
Cc: Rodney W. Grimes <ietf at gndrsh.dnsmgr.net>
Signed-off-by: Toke H?iland-J?rgensen <toke at redhat.com>
---
 drivers/net/wireguard/receive.c | 16 ++++++++++++----
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireguard/receive.c b/drivers/net/wireguard/receive.c
index da3b782ab7d3..f33e476ad574 100644
--- a/drivers/net/wireguard/receive.c
+++ b/drivers/net/wireguard/receive.c
@@ -393,13 +393,15 @@ static void wg_packet_consume_data_done(struct wg_peer *peer,
 		len = ntohs(ip_hdr(skb)->tot_len);
 		if (unlikely(len < sizeof(struct iphdr)))
 			goto dishonest_packet_size;
-		if (INET_ECN_is_ce(PACKET_CB(skb)->ds))
-			IP_ECN_set_ce(ip_hdr(skb));
+		if (INET_ECN_decapsulate(skb, PACKET_CB(skb)->ds,
+					 ip_hdr(skb)->tos) > 1)
+			goto ecn_decap_error;
 	} else if (skb->protocol == htons(ETH_P_IPV6)) {
 		len = ntohs(ipv6_hdr(skb)->payload_len) +
 		      sizeof(struct ipv6hdr);
-		if (INET_ECN_is_ce(PACKET_CB(skb)->ds))
-			IP6_ECN_set_ce(skb, ipv6_hdr(skb));
+		if (INET_ECN_decapsulate(skb, PACKET_CB(skb)->ds,
+					 ipv6_get_dsfield(ipv6_hdr(skb))) > 1)
+			goto ecn_decap_error;
 	} else {
 		goto dishonest_packet_type;
 	}
@@ -446,6 +448,12 @@ static void wg_packet_consume_data_done(struct wg_peer *peer,
 	++dev->stats.rx_errors;
 	++dev->stats.rx_length_errors;
 	goto packet_processed;
+ecn_decap_error:
+	net_dbg_ratelimited("%s: Non-ECT packet from peer %llu (%pISpfsc)\n",
+			    dev->name, peer->internal_id, &peer->endpoint.addr);
+	++dev->stats.rx_errors;
+	++dev->stats.rx_length_errors;
+	goto packet_processed;
 packet_processed:
 	dev_kfree_skb(skb);
 }
-- 
2.26.2


From Jason at zx2c4.com  Mon Apr 27 21:53:04 2020
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Mon, 27 Apr 2020 13:53:04 -0600
Subject: [PATCH net] wireguard: Use tunnel helpers for decapsulating ECN
 markings
In-Reply-To: <20200427144625.581110-1-toke@redhat.com>
References: <20200427144625.581110-1-toke@redhat.com>
Message-ID: <CAHmME9oMjw6-vG1eSrvPoC51qFSZRf75DUin8to5vGr5RJjDuw@mail.gmail.com>

Hey Toke,

Thanks for fixing this. I wasn't aware there was a newer ECN RFC. A
few comments below:

On Mon, Apr 27, 2020 at 8:47 AM Toke H?iland-J?rgensen <toke at redhat.com> wrote:
> RFC6040 also recommends dropping packets on certain combinations of
> erroneous code points on the inner and outer packet headers which shouldn't
> appear in normal operation. The helper signals this by a return value > 1,
> so also add a handler for this case.

This worries me. In the old implementation, we propagate some outer
header data to the inner header, which is technically an authenticity
violation, but minor enough that we let it slide. This patch here
seems to make that violation a bit worse: namely, we're now changing
the behavior based on a combination of outer header + inner header. An
attacker can manipulate the outer header (set it to CE) in order to
learn whether the inner header was CE or not, based on whether or not
the packet gets dropped, which is often observable. That's some form
of an oracle, which I'm not too keen on having in wireguard. On the
other hand, we pretty much already _explicitly leak this bit_ on tx
side -- in send.c:

PACKET_CB(skb)->ds = ip_tunnel_ecn_encap(0, ip_hdr(skb), skb); // inner packet
...
wg_socket_send_skb_to_peer(peer, skb, PACKET_CB(skb)->ds); // outer packet

We considered that leak a-okay. But a decryption oracle seems slightly
worse than an explicit and intentional leak. But maybe not that much
worse.

I wanted to check with you: is the analysis above correct? And can you
somehow imagine the ==2 case leading to different behavior, in which
the packet isn't dropped? Or would that ruin the "[de]congestion" part
of ECN? I just want to make sure I understand the full picture before
moving in one direction or another.

> +               if (INET_ECN_decapsulate(skb, PACKET_CB(skb)->ds,
> +                                        ip_hdr(skb)->tos) > 1)
> +               if (INET_ECN_decapsulate(skb, PACKET_CB(skb)->ds,
> +                                        ipv6_get_dsfield(ipv6_hdr(skb))) > 1)

The documentation for the function says:

*  returns 0 on success
*          1 if something is broken and should be logged (!!! above)
*          2 if packet should be dropped

Would it be more clear to explicitly check for ==2 then?

> +ecn_decap_error:
> +       net_dbg_ratelimited("%s: Non-ECT packet from peer %llu (%pISpfsc)\n",
> +                           dev->name, peer->internal_id, &peer->endpoint.addr);

All the other error messages in this block are in the form of: "Packet
.* from peer %llu (%pISpfsc)\n", so better text here might be "Packet
is non-ECT from peer %llu (%pISpfsc)\n". However, do you think we
really need to log to the console for this? Does it add much in the
way of wireguard internals debugging? Can't network congestion induce
it in complicated scenarios? Maybe it'd be best just to increment
those error counters instead.

> +       ++dev->stats.rx_errors;
> +       ++dev->stats.rx_length_errors;

This should use stats.rx_frame_errors instead of length_errors, which
is also what net/ipv6/sit.c and drivers/net/geneve.c do on ECN-related
drops.

Thanks,
Jason

From asmadeus at codewreck.org  Mon Apr 27 19:26:53 2020
From: asmadeus at codewreck.org (Dominique Martinet)
Date: Mon, 27 Apr 2020 19:26:53 +0200
Subject: [RFC PATCH] wg-quick: linux: raise priority for mangle nft chain
Message-ID: <1588008413-5667-1-git-send-email-asmadeus@codewreck.org>

Setting mark must be done as early as possible in case there are
ipv6 rpfilter rules in the mangle table (a nft filter could be done
later but with ip6tables this is the latest it can be checked).
Mark must be set before the return path check for it to work correctly.

priority -160 gets rendered as "mangle - 10" in nft list table,
and will correctly set the mark before other mangle prerouting rules
if there are any and same as before if there aren't.
---

I've been discussing with firewalld folks about the ipv6_rpfilter rules
they add which block wireguard setup with wg-quick on ipv6 endpoints by
default ; see https://github.com/firewalld/firewalld/issues/603 for
recap issue.
Long story short: they'll move the rpfilter rule to take effect later
(after mark is set) and add mark matching so that it works always with
nft backend, and sometimes with iptables backend.

Sometimes, because the ip6tables rpfilter module can only be used up to
mangle's prerouting table, and that one's priority with nft `hook
prerouting priority mangle` is "random" (depends on module load order?)

Changing the priority to load a bit earlier is harmless in the default
case and should just work for most people once they get a fixed
firewalld; I believe that is easier to change than try to document
the issue (e.g. telling people to use nft backend or disable
ipv6_rpfilter if they have issues as that is hard to debug)

Thanks!


 src/wg-quick/linux.bash | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/wg-quick/linux.bash b/src/wg-quick/linux.bash
index 7c2c002..9001c6a 100755
--- a/src/wg-quick/linux.bash
+++ b/src/wg-quick/linux.bash
@@ -222,7 +222,7 @@ add_default() {
 	local marker="-m comment --comment \"wg-quick(8) rule for $INTERFACE\"" restore=$'*raw\n' nftable="wg-quick-$INTERFACE" nftcmd 
 	printf -v nftcmd '%sadd table %s %s\n' "$nftcmd" "$pf" "$nftable"
 	printf -v nftcmd '%sadd chain %s %s preraw { type filter hook prerouting priority -300; }\n' "$nftcmd" "$pf" "$nftable"
-	printf -v nftcmd '%sadd chain %s %s premangle { type filter hook prerouting priority -150; }\n' "$nftcmd" "$pf" "$nftable"
+	printf -v nftcmd '%sadd chain %s %s premangle { type filter hook prerouting priority -160; }\n' "$nftcmd" "$pf" "$nftable"
 	printf -v nftcmd '%sadd chain %s %s postmangle { type filter hook postrouting priority -150; }\n' "$nftcmd" "$pf" "$nftable"
 	while read -r line; do
 		[[ $line =~ .*inet6?\ ([0-9a-f:.]+)/[0-9]+.* ]] || continue
-- 
2.26.2


From toke at redhat.com  Mon Apr 27 22:42:42 2020
From: toke at redhat.com (Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?=)
Date: Mon, 27 Apr 2020 22:42:42 +0200
Subject: [PATCH net] wireguard: Use tunnel helpers for decapsulating ECN
 markings
In-Reply-To: <CAHmME9oMjw6-vG1eSrvPoC51qFSZRf75DUin8to5vGr5RJjDuw@mail.gmail.com>
References: <20200427144625.581110-1-toke@redhat.com>
 <CAHmME9oMjw6-vG1eSrvPoC51qFSZRf75DUin8to5vGr5RJjDuw@mail.gmail.com>
Message-ID: <87d07sy81p.fsf@toke.dk>

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

> Hey Toke,
>
> Thanks for fixing this. I wasn't aware there was a newer ECN RFC. A
> few comments below:
>
> On Mon, Apr 27, 2020 at 8:47 AM Toke H?iland-J?rgensen <toke at redhat.com> wrote:
>> RFC6040 also recommends dropping packets on certain combinations of
>> erroneous code points on the inner and outer packet headers which shouldn't
>> appear in normal operation. The helper signals this by a return value > 1,
>> so also add a handler for this case.
>
> This worries me. In the old implementation, we propagate some outer
> header data to the inner header, which is technically an authenticity
> violation, but minor enough that we let it slide. This patch here
> seems to make that violation a bit worse: namely, we're now changing
> the behavior based on a combination of outer header + inner header. An
> attacker can manipulate the outer header (set it to CE) in order to
> learn whether the inner header was CE or not, based on whether or not
> the packet gets dropped, which is often observable. That's some form
> of an oracle, which I'm not too keen on having in wireguard. On the
> other hand, we pretty much already _explicitly leak this bit_ on tx
> side -- in send.c:
>
> PACKET_CB(skb)->ds = ip_tunnel_ecn_encap(0, ip_hdr(skb), skb); // inner packet
> ...
> wg_socket_send_skb_to_peer(peer, skb, PACKET_CB(skb)->ds); // outer packet
>
> We considered that leak a-okay. But a decryption oracle seems slightly
> worse than an explicit and intentional leak. But maybe not that much
> worse.

Well, seeing as those two bits on the outer header are already copied
from the inner header, there's no additional leak added by this change,
is there? An in-path observer could set CE and observe that the packet
gets dropped, but all they would learn is that the bits were zero
(non-ECT). Which they already knew because they could just read the bits
directly from the header.

Also note, BTW, that another difference between RFC 3168 and 6040 is the
propagation of ECT(1) from outer to inner header. That's not actually
done correctly in Linux ATM, but I sent a separate patch to fix this[0],
which Wireguard will also benefit from with this patch.

> I wanted to check with you: is the analysis above correct? And can you
> somehow imagine the ==2 case leading to different behavior, in which
> the packet isn't dropped? Or would that ruin the "[de]congestion" part
> of ECN? I just want to make sure I understand the full picture before
> moving in one direction or another.

So I think the logic here is supposed to be that if there are CE marks
on the outer header, then an AQM somewhere along the path has marked the
packet, which is supposed to be a congestion signal, which we want to
propagate all the way to the receiver (who will then echo it back to the
receiver). However, if the inner packet is non-ECT then we can't
actually propagate the ECN signal; and a drop is thus the only
alternative congestion signal available to us. This case shouldn't
actually happen that often, a middlebox has to be misconfigured to
CE-mark a non-ECT packet in the first place. But, well, misconfigured
middleboxes do exist as you're no doubt aware :)

>> +               if (INET_ECN_decapsulate(skb, PACKET_CB(skb)->ds,
>> +                                        ip_hdr(skb)->tos) > 1)
>> +               if (INET_ECN_decapsulate(skb, PACKET_CB(skb)->ds,
>> +                                        ipv6_get_dsfield(ipv6_hdr(skb))) > 1)
>
> The documentation for the function says:
>
> *  returns 0 on success
> *          1 if something is broken and should be logged (!!! above)
> *          2 if packet should be dropped
>
> Would it be more clear to explicitly check for ==2 then?

Hmm, maybe? Other callers seem to use >1, so I figured it was better to
be consistent with those. I won't insist on that, though, so if you'd
rather I use a ==2 check I can certainly change it?

>> +ecn_decap_error:
>> +       net_dbg_ratelimited("%s: Non-ECT packet from peer %llu (%pISpfsc)\n",
>> +                           dev->name, peer->internal_id, &peer->endpoint.addr);
>
> All the other error messages in this block are in the form of: "Packet
> .* from peer %llu (%pISpfsc)\n", so better text here might be "Packet
> is non-ECT from peer %llu (%pISpfsc)\n". However, do you think we
> really need to log to the console for this? Does it add much in the
> way of wireguard internals debugging? Can't network congestion induce
> it in complicated scenarios? Maybe it'd be best just to increment
> those error counters instead.

The other callers do seem to hide the logging behind a module parameter
specifically for this purpose. I put in this log message because the use
of net_dbg() indicated that these were already meant for non-production
error debugging. But if you'd rather avoid the logging that's fine by me.

>> +       ++dev->stats.rx_errors;
>> +       ++dev->stats.rx_length_errors;
>
> This should use stats.rx_frame_errors instead of length_errors, which
> is also what net/ipv6/sit.c and drivers/net/geneve.c do on ECN-related
> drops.

Oops, that's my bad; copied the wrong error handling block it seems
(didn't even notice they were incrementing different counters). Will
fix.

-Toke

[0] https://lore.kernel.org/netdev/20200427141105.555251-1-toke at redhat.com/T/#u


From toke at redhat.com  Mon Apr 27 23:16:19 2020
From: toke at redhat.com (=?UTF-8?q?Toke=20H=C3=B8iland-J=C3=B8rgensen?=)
Date: Mon, 27 Apr 2020 23:16:19 +0200
Subject: [PATCH net v2] wireguard: use tunnel helpers for decapsulating ECN
 markings
In-Reply-To: <87d07sy81p.fsf@toke.dk>
References: <87d07sy81p.fsf@toke.dk>
Message-ID: <20200427211619.603544-1-toke@redhat.com>

WireGuard currently only propagates ECN markings on tunnel decap according
to the old RFC3168 specification. However, the spec has since been updated
in RFC6040 to recommend slightly different decapsulation semantics. This
was implemented in the kernel as a set of common helpers for ECN
decapsulation, so let's just switch over WireGuard to using those, so it
can benefit from this enhancement and any future tweaks.

RFC6040 also recommends dropping packets on certain combinations of
erroneous code points on the inner and outer packet headers which shouldn't
appear in normal operation. The helper signals this by a return value > 1,
so also add a handler for this case.

Fixes: e7096c131e51 ("net: WireGuard secure network tunnel")
Reported-by: Olivier Tilmans <olivier.tilmans at nokia-bell-labs.com>
Cc: Dave Taht <dave.taht at gmail.com>
Cc: Rodney W. Grimes <ietf at gndrsh.dnsmgr.net>
Signed-off-by: Toke H?iland-J?rgensen <toke at redhat.com>
---
v2:
  - Don't log decap errors, and make sure they are recorded as frame errors,
    not length errors.

 drivers/net/wireguard/receive.c | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireguard/receive.c b/drivers/net/wireguard/receive.c
index da3b782ab7d3..ad36f358c807 100644
--- a/drivers/net/wireguard/receive.c
+++ b/drivers/net/wireguard/receive.c
@@ -393,13 +393,15 @@ static void wg_packet_consume_data_done(struct wg_peer *peer,
 		len = ntohs(ip_hdr(skb)->tot_len);
 		if (unlikely(len < sizeof(struct iphdr)))
 			goto dishonest_packet_size;
-		if (INET_ECN_is_ce(PACKET_CB(skb)->ds))
-			IP_ECN_set_ce(ip_hdr(skb));
+		if (INET_ECN_decapsulate(skb, PACKET_CB(skb)->ds,
+					 ip_hdr(skb)->tos) > 1)
+			goto ecn_decap_error;
 	} else if (skb->protocol == htons(ETH_P_IPV6)) {
 		len = ntohs(ipv6_hdr(skb)->payload_len) +
 		      sizeof(struct ipv6hdr);
-		if (INET_ECN_is_ce(PACKET_CB(skb)->ds))
-			IP6_ECN_set_ce(skb, ipv6_hdr(skb));
+		if (INET_ECN_decapsulate(skb, PACKET_CB(skb)->ds,
+					 ipv6_get_dsfield(ipv6_hdr(skb))) > 1)
+			goto ecn_decap_error;
 	} else {
 		goto dishonest_packet_type;
 	}
@@ -437,6 +439,7 @@ static void wg_packet_consume_data_done(struct wg_peer *peer,
 dishonest_packet_type:
 	net_dbg_ratelimited("%s: Packet is neither ipv4 nor ipv6 from peer %llu (%pISpfsc)\n",
 			    dev->name, peer->internal_id, &peer->endpoint.addr);
+ecn_decap_error:
 	++dev->stats.rx_errors;
 	++dev->stats.rx_frame_errors;
 	goto packet_processed;
-- 
2.26.2


From Jason at zx2c4.com  Tue Apr 28 01:09:29 2020
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Mon, 27 Apr 2020 17:09:29 -0600
Subject: [PATCH net v2] wireguard: use tunnel helpers for decapsulating
 ECN markings
In-Reply-To: <20200427211619.603544-1-toke@redhat.com>
References: <87d07sy81p.fsf@toke.dk> <20200427211619.603544-1-toke@redhat.com>
Message-ID: <CAHmME9rUCYuBCFbw=yhNPqDDJWD3ZUQ_R9xjQ-yp6DXA9_iScA@mail.gmail.com>

On Mon, Apr 27, 2020 at 3:16 PM Toke H?iland-J?rgensen <toke at redhat.com> wrote:
>
> WireGuard currently only propagates ECN markings on tunnel decap according
> to the old RFC3168 specification. However, the spec has since been updated
> in RFC6040 to recommend slightly different decapsulation semantics. This
> was implemented in the kernel as a set of common helpers for ECN
> decapsulation, so let's just switch over WireGuard to using those, so it
> can benefit from this enhancement and any future tweaks.
>
> RFC6040 also recommends dropping packets on certain combinations of
> erroneous code points on the inner and outer packet headers which shouldn't
> appear in normal operation. The helper signals this by a return value > 1,
> so also add a handler for this case.

Thanks for the details in your other email and for this v2. I've
applied this to the wireguard tree and will send things up to net
later this week with a few other things brewing there.

By the way, the original code came out of a discussion I had with Dave
Taht while I was coding this on an airplane many years ago. I read
some old RFCs, made some changes, he tested them with cake, and told
me that the behavior looked correct. And that's about as far as I've
forayed into ECN land with WireGuard. It seems like it might be
helpful (at some point) to add something to the netns.sh test to make
sure that all this machinery is actually working and continues to work
properly as things change in the future.

From Jason at zx2c4.com  Tue Apr 28 02:04:07 2020
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Mon, 27 Apr 2020 18:04:07 -0600
Subject: [RFC PATCH] wg-quick: linux: raise priority for mangle nft chain
In-Reply-To: <1588008413-5667-1-git-send-email-asmadeus@codewreck.org>
References: <1588008413-5667-1-git-send-email-asmadeus@codewreck.org>
Message-ID: <CAHmME9rT_sZrp6rZJV=Jqw-7kwCgkZ2yiBYJqiunb2gibBGhOA@mail.gmail.com>

This patch is missing a Signed-off-by line.

On Mon, Apr 27, 2020 at 2:02 PM Dominique Martinet
<asmadeus at codewreck.org> wrote:
> -       printf -v nftcmd '%sadd chain %s %s premangle { type filter hook prerouting priority -150; }\n' "$nftcmd" "$pf" "$nftable"
> +       printf -v nftcmd '%sadd chain %s %s premangle { type filter hook prerouting priority -160; }\n' "$nftcmd" "$pf" "$nftable"
>         printf -v nftcmd '%sadd chain %s %s postmangle { type filter hook postrouting priority -150; }\n' "$nftcmd" "$pf" "$nftable"

Should this one be -160 too?

From ietf at gndrsh.dnsmgr.net  Tue Apr 28 03:09:28 2020
From: ietf at gndrsh.dnsmgr.net (Rodney W. Grimes)
Date: Mon, 27 Apr 2020 18:09:28 -0700 (PDT)
Subject: [PATCH net] wireguard: Use tunnel helpers for decapsulating ECN
 markings
In-Reply-To: <87d07sy81p.fsf@toke.dk>
Message-ID: <202004280109.03S19SCY001751@gndrsh.dnsmgr.net>

Replying to a single issue I am reading, and really hope I
am miss understanding.  I am neither a wireguard or linux
user so I may be miss understanding what is said.

Inline at {RWG}

> "Jason A. Donenfeld" <Jason at zx2c4.com> writes:
> 
> > Hey Toke,
> >
> > Thanks for fixing this. I wasn't aware there was a newer ECN RFC. A
> > few comments below:
> >
> > On Mon, Apr 27, 2020 at 8:47 AM Toke H?iland-J?rgensen <toke at redhat.com> wrote:
> >> RFC6040 also recommends dropping packets on certain combinations of
> >> erroneous code points on the inner and outer packet headers which shouldn't
> >> appear in normal operation. The helper signals this by a return value > 1,
> >> so also add a handler for this case.
> >
> > This worries me. In the old implementation, we propagate some outer
> > header data to the inner header, which is technically an authenticity
> > violation, but minor enough that we let it slide. This patch here
> > seems to make that violation a bit worse: namely, we're now changing
> > the behavior based on a combination of outer header + inner header. An
> > attacker can manipulate the outer header (set it to CE) in order to
> > learn whether the inner header was CE or not, based on whether or not
> > the packet gets dropped, which is often observable. That's some form

Why is anyone dropping on decap over the CE bit?  It should be passed
on, not lead to a packet drop.  If the outer header is CE on an inner
header of CE it should just continue to be a CE, dropping it is actually
breaking the purpose of the CE codepoint, to signal congestion before
having to cause a packet loss.

> > of an oracle, which I'm not too keen on having in wireguard. On the
> > other hand, we pretty much already _explicitly leak this bit_ on tx
> > side -- in send.c:
> >
> > PACKET_CB(skb)->ds = ip_tunnel_ecn_encap(0, ip_hdr(skb), skb); // inner packet
> > ...
> > wg_socket_send_skb_to_peer(peer, skb, PACKET_CB(skb)->ds); // outer packet
> >
> > We considered that leak a-okay. But a decryption oracle seems slightly
> > worse than an explicit and intentional leak. But maybe not that much
> > worse.
> 
> Well, seeing as those two bits on the outer header are already copied
> from the inner header, there's no additional leak added by this change,
> is there? An in-path observer could set CE and observe that the packet
> gets dropped, but all they would learn is that the bits were zero

Again why is CE leading to anyone dropping?

> (non-ECT). Which they already knew because they could just read the bits
> directly from the header.
> 
> Also note, BTW, that another difference between RFC 3168 and 6040 is the
> propagation of ECT(1) from outer to inner header. That's not actually
> done correctly in Linux ATM, but I sent a separate patch to fix this[0],
> which Wireguard will also benefit from with this patch.

Thanks for this.

> 
> > I wanted to check with you: is the analysis above correct? And can you
> > somehow imagine the ==2 case leading to different behavior, in which
> > the packet isn't dropped? Or would that ruin the "[de]congestion" part
> > of ECN? I just want to make sure I understand the full picture before
> > moving in one direction or another.
> 
> So I think the logic here is supposed to be that if there are CE marks
> on the outer header, then an AQM somewhere along the path has marked the
> packet, which is supposed to be a congestion signal, which we want to
> propagate all the way to the receiver (who will then echo it back to the
> receiver). However, if the inner packet is non-ECT then we can't
> actually propagate the ECN signal; and a drop is thus the only
> alternative congestion signal available to us.

You cannot get a CE mark on the outer packet if the inner packet is
not ECT, as the outer packet would also be not ECT and thus not
eligible for CE mark.  If you get the above sited condition something
has gone *wrong*.


> This case shouldn't
> actually happen that often, a middlebox has to be misconfigured to
> CE-mark a non-ECT packet in the first place. But, well, misconfigured
> middleboxes do exist as you're no doubt aware :)

That is true, though I believe the be liberal in what you accept
concept would say ok, someone messed up, just propogate it and
let the end nodes deal with it, otherwise your creating a blackhole
that could be very hard to find.

> 
> >> +               if (INET_ECN_decapsulate(skb, PACKET_CB(skb)->ds,
> >> +                                        ip_hdr(skb)->tos) > 1)
> >> +               if (INET_ECN_decapsulate(skb, PACKET_CB(skb)->ds,
> >> +                                        ipv6_get_dsfield(ipv6_hdr(skb))) > 1)
> >
> > The documentation for the function says:
> >
> > *  returns 0 on success
> > *          1 if something is broken and should be logged (!!! above)
> > *          2 if packet should be dropped
> >
> > Would it be more clear to explicitly check for ==2 then?
> 
> Hmm, maybe? Other callers seem to use >1, so I figured it was better to
> be consistent with those. I won't insist on that, though, so if you'd
> rather I use a ==2 check I can certainly change it?
> 
> >> +ecn_decap_error:
> >> +       net_dbg_ratelimited("%s: Non-ECT packet from peer %llu (%pISpfsc)\n",
> >> +                           dev->name, peer->internal_id, &peer->endpoint.addr);
> >
> > All the other error messages in this block are in the form of: "Packet
> > .* from peer %llu (%pISpfsc)\n", so better text here might be "Packet
> > is non-ECT from peer %llu (%pISpfsc)\n". However, do you think we
> > really need to log to the console for this? Does it add much in the
> > way of wireguard internals debugging? Can't network congestion induce
> > it in complicated scenarios? Maybe it'd be best just to increment
> > those error counters instead.
> 
> The other callers do seem to hide the logging behind a module parameter
> specifically for this purpose. I put in this log message because the use
> of net_dbg() indicated that these were already meant for non-production
> error debugging. But if you'd rather avoid the logging that's fine by me.
> 
> >> +       ++dev->stats.rx_errors;
> >> +       ++dev->stats.rx_length_errors;
> >
> > This should use stats.rx_frame_errors instead of length_errors, which
> > is also what net/ipv6/sit.c and drivers/net/geneve.c do on ECN-related
> > drops.
> 
> Oops, that's my bad; copied the wrong error handling block it seems
> (didn't even notice they were incrementing different counters). Will
> fix.
> 
> -Toke
> 
> [0] https://lore.kernel.org/netdev/20200427141105.555251-1-toke at redhat.com/T/#u
> 
> 
> 

-- 
Rod Grimes                                                 rgrimes at freebsd.org

From asmadeus at codewreck.org  Tue Apr 28 08:56:17 2020
From: asmadeus at codewreck.org (Dominique Martinet)
Date: Tue, 28 Apr 2020 08:56:17 +0200
Subject: [RFC PATCH] wg-quick: linux: raise priority for mangle nft chain
In-Reply-To: <CAHmME9rT_sZrp6rZJV=Jqw-7kwCgkZ2yiBYJqiunb2gibBGhOA@mail.gmail.com>
References: <1588008413-5667-1-git-send-email-asmadeus@codewreck.org>
 <CAHmME9rT_sZrp6rZJV=Jqw-7kwCgkZ2yiBYJqiunb2gibBGhOA@mail.gmail.com>
Message-ID: <20200428065617.GA19621@nautica>

Jason A. Donenfeld wrote on Mon, Apr 27, 2020:
> This patch is missing a Signed-off-by line.

Sorry, will add and resend without RFC after some feedback.

> On Mon, Apr 27, 2020 at 2:02 PM Dominique Martinet
> <asmadeus at codewreck.org> wrote:
> > -       printf -v nftcmd '%sadd chain %s %s premangle { type filter hook prerouting priority -150; }\n' "$nftcmd" "$pf" "$nftable"
> > +       printf -v nftcmd '%sadd chain %s %s premangle { type filter hook prerouting priority -160; }\n' "$nftcmd" "$pf" "$nftable"
> >         printf -v nftcmd '%sadd chain %s %s postmangle { type filter hook postrouting priority -150; }\n' "$nftcmd" "$pf" "$nftable"
> 
> Should this one be -160 too?

Good question, the only two chains I'm aware of conflicting are
wg-quick's premangle and ip6tables's mangle/PREROUTING rpfilter
(e.g. a rule like:
ip6tables -t mangle -A PREROUTING -m rpfilter --validmark --invert -j DROP
)

As I understand rpfilter only makes sense on prerouting or broadly
speaking input (firewalld's nft backend will move the rpfilter rule all
the way down to filter input table, but that's not possible with
ip6tables) - it checks the incoming packet came through the same
interface we would send back to.
For postrouting the kernel already picked an interface for us so there
would be little point in checking the kernel would pick the same
interface again? So no rpfilter and marks aren't used in these rules.

If someone ever comes in with an ip6tables rule that relies on mark
checking in mangle POSTROUTING then it would help to move postmangle to
-160 as well, I'm just not aware of any.
Letting you decide on this one, I'd tend not to bother until a usecase
shows up, but I guess there's no harm in moving it anyway....

-- 
Dominique | Asmadeus

From toke at redhat.com  Tue Apr 28 11:00:25 2020
From: toke at redhat.com (Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?=)
Date: Tue, 28 Apr 2020 11:00:25 +0200
Subject: [PATCH net v2] wireguard: use tunnel helpers for decapsulating
 ECN markings
In-Reply-To: <CAHmME9rUCYuBCFbw=yhNPqDDJWD3ZUQ_R9xjQ-yp6DXA9_iScA@mail.gmail.com>
References: <87d07sy81p.fsf@toke.dk> <20200427211619.603544-1-toke@redhat.com>
 <CAHmME9rUCYuBCFbw=yhNPqDDJWD3ZUQ_R9xjQ-yp6DXA9_iScA@mail.gmail.com>
Message-ID: <874kt4x9w6.fsf@toke.dk>

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

> On Mon, Apr 27, 2020 at 3:16 PM Toke H?iland-J?rgensen <toke at redhat.com> wrote:
>>
>> WireGuard currently only propagates ECN markings on tunnel decap according
>> to the old RFC3168 specification. However, the spec has since been updated
>> in RFC6040 to recommend slightly different decapsulation semantics. This
>> was implemented in the kernel as a set of common helpers for ECN
>> decapsulation, so let's just switch over WireGuard to using those, so it
>> can benefit from this enhancement and any future tweaks.
>>
>> RFC6040 also recommends dropping packets on certain combinations of
>> erroneous code points on the inner and outer packet headers which shouldn't
>> appear in normal operation. The helper signals this by a return value > 1,
>> so also add a handler for this case.
>
> Thanks for the details in your other email and for this v2. I've
> applied this to the wireguard tree and will send things up to net
> later this week with a few other things brewing there.

Thanks!

> By the way, the original code came out of a discussion I had with Dave
> Taht while I was coding this on an airplane many years ago. I read
> some old RFCs, made some changes, he tested them with cake, and told
> me that the behavior looked correct. And that's about as far as I've
> forayed into ECN land with WireGuard. It seems like it might be
> helpful (at some point) to add something to the netns.sh test to make
> sure that all this machinery is actually working and continues to work
> properly as things change in the future.

Yeah, good point. I guess I can look into that too at some point :)

-Toke


From toke at redhat.com  Tue Apr 28 11:10:43 2020
From: toke at redhat.com (Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?=)
Date: Tue, 28 Apr 2020 11:10:43 +0200
Subject: [PATCH net] wireguard: Use tunnel helpers for decapsulating ECN
 markings
In-Reply-To: <202004280109.03S19SCY001751@gndrsh.dnsmgr.net>
References: <202004280109.03S19SCY001751@gndrsh.dnsmgr.net>
Message-ID: <87zhawvuuk.fsf@toke.dk>

"Rodney W. Grimes" <ietf at gndrsh.dnsmgr.net> writes:

> Replying to a single issue I am reading, and really hope I
> am miss understanding.  I am neither a wireguard or linux
> user so I may be miss understanding what is said.
>
> Inline at {RWG}
>
>> "Jason A. Donenfeld" <Jason at zx2c4.com> writes:
>> 
>> > Hey Toke,
>> >
>> > Thanks for fixing this. I wasn't aware there was a newer ECN RFC. A
>> > few comments below:
>> >
>> > On Mon, Apr 27, 2020 at 8:47 AM Toke H?iland-J?rgensen <toke at redhat.com> wrote:
>> >> RFC6040 also recommends dropping packets on certain combinations of
>> >> erroneous code points on the inner and outer packet headers which shouldn't
>> >> appear in normal operation. The helper signals this by a return value > 1,
>> >> so also add a handler for this case.
>> >
>> > This worries me. In the old implementation, we propagate some outer
>> > header data to the inner header, which is technically an authenticity
>> > violation, but minor enough that we let it slide. This patch here
>> > seems to make that violation a bit worse: namely, we're now changing
>> > the behavior based on a combination of outer header + inner header. An
>> > attacker can manipulate the outer header (set it to CE) in order to
>> > learn whether the inner header was CE or not, based on whether or not
>> > the packet gets dropped, which is often observable. That's some form
>
> Why is anyone dropping on decap over the CE bit?  It should be passed
> on, not lead to a packet drop.  If the outer header is CE on an inner
> header of CE it should just continue to be a CE, dropping it is actually
> breaking the purpose of the CE codepoint, to signal congestion before
> having to cause a packet loss.
>
>> > of an oracle, which I'm not too keen on having in wireguard. On the
>> > other hand, we pretty much already _explicitly leak this bit_ on tx
>> > side -- in send.c:
>> >
>> > PACKET_CB(skb)->ds = ip_tunnel_ecn_encap(0, ip_hdr(skb), skb); // inner packet
>> > ...
>> > wg_socket_send_skb_to_peer(peer, skb, PACKET_CB(skb)->ds); // outer packet
>> >
>> > We considered that leak a-okay. But a decryption oracle seems slightly
>> > worse than an explicit and intentional leak. But maybe not that much
>> > worse.
>> 
>> Well, seeing as those two bits on the outer header are already copied
>> from the inner header, there's no additional leak added by this change,
>> is there? An in-path observer could set CE and observe that the packet
>> gets dropped, but all they would learn is that the bits were zero
>
> Again why is CE leading to anyone dropping?
>
>> (non-ECT). Which they already knew because they could just read the bits
>> directly from the header.
>> 
>> Also note, BTW, that another difference between RFC 3168 and 6040 is the
>> propagation of ECT(1) from outer to inner header. That's not actually
>> done correctly in Linux ATM, but I sent a separate patch to fix this[0],
>> which Wireguard will also benefit from with this patch.
>
> Thanks for this.
>
>> 
>> > I wanted to check with you: is the analysis above correct? And can you
>> > somehow imagine the ==2 case leading to different behavior, in which
>> > the packet isn't dropped? Or would that ruin the "[de]congestion" part
>> > of ECN? I just want to make sure I understand the full picture before
>> > moving in one direction or another.
>> 
>> So I think the logic here is supposed to be that if there are CE marks
>> on the outer header, then an AQM somewhere along the path has marked the
>> packet, which is supposed to be a congestion signal, which we want to
>> propagate all the way to the receiver (who will then echo it back to the
>> receiver). However, if the inner packet is non-ECT then we can't
>> actually propagate the ECN signal; and a drop is thus the only
>> alternative congestion signal available to us.
>
> You cannot get a CE mark on the outer packet if the inner packet is
> not ECT, as the outer packet would also be not ECT and thus not
> eligible for CE mark.  If you get the above sited condition something
> has gone *wrong*.

Yup, you're quite right. If everything is working correctly, this should
never happen. This being the internet, though, there are bound to be
cases where it will go wrong :)

>> This case shouldn't
>> actually happen that often, a middlebox has to be misconfigured to
>> CE-mark a non-ECT packet in the first place. But, well, misconfigured
>> middleboxes do exist as you're no doubt aware :)
>
> That is true, though I believe the be liberal in what you accept
> concept would say ok, someone messed up, just propogate it and
> let the end nodes deal with it, otherwise your creating a blackhole
> that could be very hard to find.

But that would lead you to ignore a congestion signal. And someone has
to go through an awful lot of trouble to set this signal; if they're
just randomly mangling bits the packet checksum will likely be wrong and
the packet would be dropped anyway. So on balance I'd tend to agree with
the RFC that the right thing to do is to propagate the congestion
signal; which in the case of a non-ECT packet means dropping it,
otherwise we'd just be contributing to the RFC-violating behaviour...

I do believe the advice in the RFC to log these cases is exactly because
of the risk of blackholes you're referring to. I discussed this a bit
with Jason and we ended up agreeing that just marking it as a framing
error should be enough for Wireguard, though...

-Toke


From dave.taht at gmail.com  Tue Apr 28 20:52:13 2020
From: dave.taht at gmail.com (Dave Taht)
Date: Tue, 28 Apr 2020 11:52:13 -0700
Subject: [PATCH net] wireguard: Use tunnel helpers for decapsulating ECN
 markings
In-Reply-To: <87zhawvuuk.fsf@toke.dk>
References: <202004280109.03S19SCY001751@gndrsh.dnsmgr.net>
 <87zhawvuuk.fsf@toke.dk>
Message-ID: <CAA93jw7-yiy=ic71DWG4XHLU5eCGb1p-6bKVX7NQFmTOu+jpLQ@mail.gmail.com>

On Tue, Apr 28, 2020 at 2:10 AM Toke H?iland-J?rgensen <toke at redhat.com> wrote:
>
> "Rodney W. Grimes" <ietf at gndrsh.dnsmgr.net> writes:
>
> > Replying to a single issue I am reading, and really hope I
> > am miss understanding.  I am neither a wireguard or linux
> > user so I may be miss understanding what is said.
> >
> > Inline at {RWG}
> >
> >> "Jason A. Donenfeld" <Jason at zx2c4.com> writes:
> >>
> >> > Hey Toke,
> >> >
> >> > Thanks for fixing this. I wasn't aware there was a newer ECN RFC. A
> >> > few comments below:
> >> >
> >> > On Mon, Apr 27, 2020 at 8:47 AM Toke H?iland-J?rgensen <toke at redhat.com> wrote:
> >> >> RFC6040 also recommends dropping packets on certain combinations of
> >> >> erroneous code points on the inner and outer packet headers which shouldn't
> >> >> appear in normal operation. The helper signals this by a return value > 1,
> >> >> so also add a handler for this case.
> >> >
> >> > This worries me. In the old implementation, we propagate some outer
> >> > header data to the inner header, which is technically an authenticity
> >> > violation, but minor enough that we let it slide. This patch here
> >> > seems to make that violation a bit worse: namely, we're now changing
> >> > the behavior based on a combination of outer header + inner header. An
> >> > attacker can manipulate the outer header (set it to CE) in order to
> >> > learn whether the inner header was CE or not, based on whether or not
> >> > the packet gets dropped, which is often observable. That's some form
> >
> > Why is anyone dropping on decap over the CE bit?  It should be passed
> > on, not lead to a packet drop.  If the outer header is CE on an inner
> > header of CE it should just continue to be a CE, dropping it is actually
> > breaking the purpose of the CE codepoint, to signal congestion before
> > having to cause a packet loss.
> >
> >> > of an oracle, which I'm not too keen on having in wireguard. On the
> >> > other hand, we pretty much already _explicitly leak this bit_ on tx
> >> > side -- in send.c:
> >> >
> >> > PACKET_CB(skb)->ds = ip_tunnel_ecn_encap(0, ip_hdr(skb), skb); // inner packet
> >> > ...
> >> > wg_socket_send_skb_to_peer(peer, skb, PACKET_CB(skb)->ds); // outer packet
> >> >
> >> > We considered that leak a-okay. But a decryption oracle seems slightly
> >> > worse than an explicit and intentional leak. But maybe not that much
> >> > worse.
> >>
> >> Well, seeing as those two bits on the outer header are already copied
> >> from the inner header, there's no additional leak added by this change,
> >> is there? An in-path observer could set CE and observe that the packet
> >> gets dropped, but all they would learn is that the bits were zero
> >
> > Again why is CE leading to anyone dropping?
> >
> >> (non-ECT). Which they already knew because they could just read the bits
> >> directly from the header.
> >>
> >> Also note, BTW, that another difference between RFC 3168 and 6040 is the
> >> propagation of ECT(1) from outer to inner header. That's not actually
> >> done correctly in Linux ATM, but I sent a separate patch to fix this[0],
> >> which Wireguard will also benefit from with this patch.

I note that there is a large ISP in argentina that has been
mis-marking most udp & tcp traffic
as CE for years now and despite many attempts to get 'em to fix it,
when last I checked (2? 3?)
months back, they still were doing it.

My impression of overall competence and veracity of multiple transit
and isp providers has been sorely
tried recently. While I support treating ect 1 and 2 properly, I am
inclined to start thinking that
ce on a non-ect encapsulated packet is something that should not be dropped.

but, whatever is decided on that front is in the hooks in the other
patch above, not in wireguard,
and I'll make the same comment there.



> >
> > Thanks for this.
> >
> >>
> >> > I wanted to check with you: is the analysis above correct? And can you
> >> > somehow imagine the ==2 case leading to different behavior, in which
> >> > the packet isn't dropped? Or would that ruin the "[de]congestion" part
> >> > of ECN? I just want to make sure I understand the full picture before
> >> > moving in one direction or another.
> >>
> >> So I think the logic here is supposed to be that if there are CE marks
> >> on the outer header, then an AQM somewhere along the path has marked the
> >> packet, which is supposed to be a congestion signal, which we want to
> >> propagate all the way to the receiver (who will then echo it back to the
> >> receiver). However, if the inner packet is non-ECT then we can't
> >> actually propagate the ECN signal; and a drop is thus the only
> >> alternative congestion signal available to us.
> >
> > You cannot get a CE mark on the outer packet if the inner packet is
> > not ECT, as the outer packet would also be not ECT and thus not
> > eligible for CE mark.  If you get the above sited condition something
> > has gone *wrong*.
>
> Yup, you're quite right. If everything is working correctly, this should
> never happen. This being the internet, though, there are bound to be
> cases where it will go wrong :)
>
> >> This case shouldn't
> >> actually happen that often, a middlebox has to be misconfigured to
> >> CE-mark a non-ECT packet in the first place. But, well, misconfigured
> >> middleboxes do exist as you're no doubt aware :)
> >
> > That is true, though I believe the be liberal in what you accept
> > concept would say ok, someone messed up, just propogate it and
> > let the end nodes deal with it, otherwise your creating a blackhole
> > that could be very hard to find.
>
> But that would lead you to ignore a congestion signal. And someone has
> to go through an awful lot of trouble to set this signal; if they're
> just randomly mangling bits the packet checksum will likely be wrong and
> the packet would be dropped anyway. So on balance I'd tend to agree with
> the RFC that the right thing to do is to propagate the congestion
> signal; which in the case of a non-ECT packet means dropping it,
> otherwise we'd just be contributing to the RFC-violating behaviour...
>
> I do believe the advice in the RFC to log these cases is exactly because
> of the risk of blackholes you're referring to. I discussed this a bit
> with Jason and we ended up agreeing that just marking it as a framing
> error should be enough for Wireguard, though...
>
> -Toke
>


-- 
Make Music, Not War

Dave T?ht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-435-0729

From Jason at zx2c4.com  Tue Apr 28 21:31:18 2020
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Tue, 28 Apr 2020 13:31:18 -0600
Subject: [PATCH net] wireguard: Use tunnel helpers for decapsulating ECN
 markings
In-Reply-To: <CAA93jw7-yiy=ic71DWG4XHLU5eCGb1p-6bKVX7NQFmTOu+jpLQ@mail.gmail.com>
References: <202004280109.03S19SCY001751@gndrsh.dnsmgr.net>
 <87zhawvuuk.fsf@toke.dk>
 <CAA93jw7-yiy=ic71DWG4XHLU5eCGb1p-6bKVX7NQFmTOu+jpLQ@mail.gmail.com>
Message-ID: <CAHmME9o1binUdw40Uxw7+RU6pDse7k0bw5seNy2CHZ3hw+Pw3Q@mail.gmail.com>

On Tue, Apr 28, 2020 at 12:52 PM Dave Taht <dave.taht at gmail.com> wrote:
>
> On Tue, Apr 28, 2020 at 2:10 AM Toke H?iland-J?rgensen <toke at redhat.com> wrote:
> >
> > "Rodney W. Grimes" <ietf at gndrsh.dnsmgr.net> writes:
> >
> > > Replying to a single issue I am reading, and really hope I
> > > am miss understanding.  I am neither a wireguard or linux
> > > user so I may be miss understanding what is said.
> > >
> > > Inline at {RWG}
> > >
> > >> "Jason A. Donenfeld" <Jason at zx2c4.com> writes:
> > >>
> > >> > Hey Toke,
> > >> >
> > >> > Thanks for fixing this. I wasn't aware there was a newer ECN RFC. A
> > >> > few comments below:
> > >> >
> > >> > On Mon, Apr 27, 2020 at 8:47 AM Toke H?iland-J?rgensen <toke at redhat.com> wrote:
> > >> >> RFC6040 also recommends dropping packets on certain combinations of
> > >> >> erroneous code points on the inner and outer packet headers which shouldn't
> > >> >> appear in normal operation. The helper signals this by a return value > 1,
> > >> >> so also add a handler for this case.
> > >> >
> > >> > This worries me. In the old implementation, we propagate some outer
> > >> > header data to the inner header, which is technically an authenticity
> > >> > violation, but minor enough that we let it slide. This patch here
> > >> > seems to make that violation a bit worse: namely, we're now changing
> > >> > the behavior based on a combination of outer header + inner header. An
> > >> > attacker can manipulate the outer header (set it to CE) in order to
> > >> > learn whether the inner header was CE or not, based on whether or not
> > >> > the packet gets dropped, which is often observable. That's some form
> > >
> > > Why is anyone dropping on decap over the CE bit?  It should be passed
> > > on, not lead to a packet drop.  If the outer header is CE on an inner
> > > header of CE it should just continue to be a CE, dropping it is actually
> > > breaking the purpose of the CE codepoint, to signal congestion before
> > > having to cause a packet loss.
> > >
> > >> > of an oracle, which I'm not too keen on having in wireguard. On the
> > >> > other hand, we pretty much already _explicitly leak this bit_ on tx
> > >> > side -- in send.c:
> > >> >
> > >> > PACKET_CB(skb)->ds = ip_tunnel_ecn_encap(0, ip_hdr(skb), skb); // inner packet
> > >> > ...
> > >> > wg_socket_send_skb_to_peer(peer, skb, PACKET_CB(skb)->ds); // outer packet
> > >> >
> > >> > We considered that leak a-okay. But a decryption oracle seems slightly
> > >> > worse than an explicit and intentional leak. But maybe not that much
> > >> > worse.
> > >>
> > >> Well, seeing as those two bits on the outer header are already copied
> > >> from the inner header, there's no additional leak added by this change,
> > >> is there? An in-path observer could set CE and observe that the packet
> > >> gets dropped, but all they would learn is that the bits were zero
> > >
> > > Again why is CE leading to anyone dropping?
> > >
> > >> (non-ECT). Which they already knew because they could just read the bits
> > >> directly from the header.
> > >>
> > >> Also note, BTW, that another difference between RFC 3168 and 6040 is the
> > >> propagation of ECT(1) from outer to inner header. That's not actually
> > >> done correctly in Linux ATM, but I sent a separate patch to fix this[0],
> > >> which Wireguard will also benefit from with this patch.
>
> I note that there is a large ISP in argentina that has been
> mis-marking most udp & tcp traffic
> as CE for years now and despite many attempts to get 'em to fix it,
> when last I checked (2? 3?)
> months back, they still were doing it.
>
> My impression of overall competence and veracity of multiple transit
> and isp providers has been sorely
> tried recently. While I support treating ect 1 and 2 properly, I am
> inclined to start thinking that
> ce on a non-ect encapsulated packet is something that should not be dropped.
>
> but, whatever is decided on that front is in the hooks in the other
> patch above, not in wireguard,
> and I'll make the same comment there.

Thanks for pointing this out. We're going to drop the dropping
behavior in wireguard, especially in light of the fact that folks like
to use wireguard for working around issues with their broken ISP or in
other weird circumstances.

From ietf at gndrsh.dnsmgr.net  Wed Apr 29 10:22:11 2020
From: ietf at gndrsh.dnsmgr.net (Rodney W. Grimes)
Date: Wed, 29 Apr 2020 01:22:11 -0700 (PDT)
Subject: [PATCH net] wireguard: Use tunnel helpers for decapsulating ECN
 markings
In-Reply-To: <CAHmME9o1binUdw40Uxw7+RU6pDse7k0bw5seNy2CHZ3hw+Pw3Q@mail.gmail.com>
Message-ID: <202004290822.03T8MBOL008079@gndrsh.dnsmgr.net>

> On Tue, Apr 28, 2020 at 12:52 PM Dave Taht <dave.taht at gmail.com> wrote:
> >
> > On Tue, Apr 28, 2020 at 2:10 AM Toke H?iland-J?rgensen <toke at redhat.com> wrote:
> > >
> > > "Rodney W. Grimes" <ietf at gndrsh.dnsmgr.net> writes:
> > >
> > > > Replying to a single issue I am reading, and really hope I
> > > > am miss understanding.  I am neither a wireguard or linux
> > > > user so I may be miss understanding what is said.
> > > >
> > > > Inline at {RWG}
> > > >
> > > >> "Jason A. Donenfeld" <Jason at zx2c4.com> writes:
> > > >>
> > > >> > Hey Toke,
> > > >> >
> > > >> > Thanks for fixing this. I wasn't aware there was a newer ECN RFC. A
> > > >> > few comments below:
> > > >> >
> > > >> > On Mon, Apr 27, 2020 at 8:47 AM Toke H?iland-J?rgensen <toke at redhat.com> wrote:
> > > >> >> RFC6040 also recommends dropping packets on certain combinations of
> > > >> >> erroneous code points on the inner and outer packet headers which shouldn't
> > > >> >> appear in normal operation. The helper signals this by a return value > 1,
> > > >> >> so also add a handler for this case.
> > > >> >
> > > >> > This worries me. In the old implementation, we propagate some outer
> > > >> > header data to the inner header, which is technically an authenticity
> > > >> > violation, but minor enough that we let it slide. This patch here
> > > >> > seems to make that violation a bit worse: namely, we're now changing
> > > >> > the behavior based on a combination of outer header + inner header. An
> > > >> > attacker can manipulate the outer header (set it to CE) in order to
> > > >> > learn whether the inner header was CE or not, based on whether or not
> > > >> > the packet gets dropped, which is often observable. That's some form
> > > >
> > > > Why is anyone dropping on decap over the CE bit?  It should be passed
> > > > on, not lead to a packet drop.  If the outer header is CE on an inner
> > > > header of CE it should just continue to be a CE, dropping it is actually
> > > > breaking the purpose of the CE codepoint, to signal congestion before
> > > > having to cause a packet loss.
> > > >
> > > >> > of an oracle, which I'm not too keen on having in wireguard. On the
> > > >> > other hand, we pretty much already _explicitly leak this bit_ on tx
> > > >> > side -- in send.c:
> > > >> >
> > > >> > PACKET_CB(skb)->ds = ip_tunnel_ecn_encap(0, ip_hdr(skb), skb); // inner packet
> > > >> > ...
> > > >> > wg_socket_send_skb_to_peer(peer, skb, PACKET_CB(skb)->ds); // outer packet
> > > >> >
> > > >> > We considered that leak a-okay. But a decryption oracle seems slightly
> > > >> > worse than an explicit and intentional leak. But maybe not that much
> > > >> > worse.
> > > >>
> > > >> Well, seeing as those two bits on the outer header are already copied
> > > >> from the inner header, there's no additional leak added by this change,
> > > >> is there? An in-path observer could set CE and observe that the packet
> > > >> gets dropped, but all they would learn is that the bits were zero
> > > >
> > > > Again why is CE leading to anyone dropping?
> > > >
> > > >> (non-ECT). Which they already knew because they could just read the bits
> > > >> directly from the header.
> > > >>
> > > >> Also note, BTW, that another difference between RFC 3168 and 6040 is the
> > > >> propagation of ECT(1) from outer to inner header. That's not actually
> > > >> done correctly in Linux ATM, but I sent a separate patch to fix this[0],
> > > >> which Wireguard will also benefit from with this patch.
> >
> > I note that there is a large ISP in argentina that has been
> > mis-marking most udp & tcp traffic
> > as CE for years now and despite many attempts to get 'em to fix it,
> > when last I checked (2? 3?)
> > months back, they still were doing it.
> >
> > My impression of overall competence and veracity of multiple transit
> > and isp providers has been sorely
> > tried recently. While I support treating ect 1 and 2 properly, I am
> > inclined to start thinking that
> > ce on a non-ect encapsulated packet is something that should not be dropped.
> >
> > but, whatever is decided on that front is in the hooks in the other
> > patch above, not in wireguard,
> > and I'll make the same comment there.
> 
> Thanks for pointing this out. We're going to drop the dropping
> behavior in wireguard, especially in light of the fact that folks like
> to use wireguard for working around issues with their broken ISP or in
> other weird circumstances.

Thank you!  

-- 
Rod Grimes                                                 rgrimes at freebsd.org

From Jason at zx2c4.com  Thu Apr 30 06:41:13 2020
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Wed, 29 Apr 2020 22:41:13 -0600
Subject: [ANNOUNCE] wireguard-linux-compat v1.0.20200429 released
Message-ID: <b9ca878e1f0ade3b@mail.zx2c4.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hello,

A new version, v1.0.20200429, of the backported WireGuard kernel module for
3.10 <= Linux <= 5.5.y has been tagged in the git repository.

== Changes ==

  * receive: use tunnel helpers for decapsulating ECN markings
  
  ECN markings are now decapsulated using RFC6040 instead of the old RFC3168.
  
  * compat: ip6_dst_lookup_flow was backported to 3.16.83
  * compat: ip6_dst_lookup_flow was backported to 4.19.119
  
  Greg and Ben backported the ip6_dst_lookup_flow patches to stable kernels,
  causing breaking in our compat module, which these changes fix.

This release contains commits from: Jason A. Donenfeld and Toke 
H?iland-J?rgensen.

As always, the source is available at https://git.zx2c4.com/wireguard-linux-compat/
and information about the project is available at https://www.wireguard.com/ .

This version is available in compressed tarball form here:
  https://git.zx2c4.com/wireguard-linux-compat/snapshot/wireguard-linux-compat-1.0.20200429.tar.xz
  SHA2-256: c0050a94c33c195d4129a75ab4dca05ba021c5265e40fce8b2dfda7d7055cda2

A PGP signature of that file decompressed is available here:
  https://git.zx2c4.com/wireguard-linux-compat/snapshot/wireguard-linux-compat-1.0.20200429.tar.asc
  Signing key: AB9942E6D4A4CFC3412620A749FC7012A5DE03AE
  Remember to unxz the tarball before verifying the signature.

If you're a package maintainer, please bump your package version. If you're a
user, the WireGuard team welcomes any and all feedback on this latest version.

Finally, WireGuard development thrives on donations. By popular demand, we
have a webpage for this: https://www.wireguard.com/donations/

Thank you,
Jason Donenfeld


-----BEGIN PGP SIGNATURE-----

iQJEBAEBCAAuFiEEq5lC5tSkz8NBJiCnSfxwEqXeA64FAl6qVt4QHGphc29uQHp4
MmM0LmNvbQAKCRBJ/HASpd4Drg0fD/4qdNPOkG/Yve98FyM8fXAaX3BcgvuwY2md
DL/roczbyOHKMa1CLEJ+u/xNto9Vq7vFVY7hW5bFyOlaD30mmdERGH8Xi2sF3bQb
bYrNNaq66aTEUtWrBCFn5D9WZAQ3WFxVpTPKZlvjKZrwAfwJYkjvP0ubQpsgI3K2
3uY0xY94mEexqbRO9H4FMtZH0Hk4oL3s4tzHZFMtYqjuzr9CLtleJQuksdyHb0Ip
aqrBwkYpn5B0rU1vIwwlRyzwxzdMlKM2vpdodYeJoGnMZNzp78Y3L8TCfSWYgut0
jPfqOHgJaqZbgTzkGTGXwEuFHwDuivRA+tn6B/zf7IpSN8YdTgffKS/o+7Tfuxqo
bTeDIBAbe2voskyDwCTEv7aVK14X9/OPq8oAuQogpqVTSEl7UW2dXhr6aPtAo5C1
aFRun4yh91yU0KVBvrgrKnr7g/606VvTjHbFoKqYwZmrPtdhzw38nMGzeVaSeNXG
oovWNq5tZLhhjzhp6Z5pn0hxhOrx8GZBXhH+R5yh7qJJBCgPrRqKQu5glRqN/OB6
iREAzK0jxc3FrNgLz0//ONGr/Eg5JaULyY+GToP0bWuJcgTN7adMXY/FcEquoJsA
+0IV03hkXqCZRNfCiiRAuoCn/hy6yHEWDLh6Lwoh5cbnvjnbGxON+LEXgTVl+vQQ
eMO7VIQj9Q==
=QwjT
-----END PGP SIGNATURE-----

From mardnh at gmx.de  Thu Apr 30 15:55:51 2020
From: mardnh at gmx.de (Martin Hauke)
Date: Thu, 30 Apr 2020 15:55:51 +0200
Subject: [PATCH] systemd: add file wireguard.target
Message-ID: <20200430135551.9911-1-mardnh@gmx.de>

Add file wireguard.target, which allows you to stop or restart all
instances.
---
 src/systemd/wg-quick at .service | 1 +
 src/systemd/wireguard.target  | 2 ++
 2 files changed, 3 insertions(+)
 create mode 100644 src/systemd/wireguard.target

diff --git a/src/systemd/wg-quick at .service b/src/systemd/wg-quick at .service
index 7c5f9d1..c22f7b3 100644
--- a/src/systemd/wg-quick at .service
+++ b/src/systemd/wg-quick at .service
@@ -2,6 +2,7 @@
 Description=WireGuard via wg-quick(8) for %I
 After=network-online.target nss-lookup.target
 Wants=network-online.target nss-lookup.target
+PartOf=wireguard.target
 Documentation=man:wg-quick(8)
 Documentation=man:wg(8)
 Documentation=https://www.wireguard.com/
diff --git a/src/systemd/wireguard.target b/src/systemd/wireguard.target
new file mode 100644
index 0000000..8e59224
--- /dev/null
+++ b/src/systemd/wireguard.target
@@ -0,0 +1,2 @@
+[Unit]
+Description=Target to restart all parts of WireGuard
--
2.26.2


From hans at hanswkraus.com  Thu Apr 16 18:12:58 2020
From: hans at hanswkraus.com (Hans Kraus)
Date: Thu, 16 Apr 2020 16:12:58 -0000
Subject: Newbie - WireGuard per systemd on Debian Buster
Message-ID: <cf665c35-adf9-6f74-b360-1c3cfd723963@hanswkraus.com>

I'm a newbie to wireguard and trying to install a working environment,
starting with one server and one client. First I used the example in
<https://github.com/pirate/wireguard-docs/tree/master/example-simple-client-to-server>
and got it working.

To get a more persistent installation I followed the example in
<https://wiki.debian.org/Wireguard>, with one server and one client,
"Step 2 - Alternative C - systemd". My server has a fixed ip4 address,
my client(s) get their addresses via DHCP (home network and road
warrior). My two "/etc/systemd/network" files on my server are:

/etc/systemd/network/wg0.netdev
---------------------------------------------
[NetDev]
Name=wg0
Kind=wireguard
Description=Wireguard kraush

[WireGuard]
PrivateKey=<private key server>
ListenPort=#####

[WireGuardPeer]
PublicKey=<public key client>
AllowedIPs=<free range>.0/24
---------------------------------------------

/etc/systemd/network/wg0.network
---------------------------------------------
[Match]
Name=wg0

[Network]
Address=<free range>.1/24
---------------------------------------------
I omitted the "Endpoint=<remote IP or hostname>:<remote port>" part
because I don't know (at least at server startup) the IP address of my
client(s).

That doesn't work. wg0 is up, ip addr show shows an address bound to the
interface. But it seems that the server doesn't recognize the peer
because "wg show wg0 peers" gives an empty list back.

Any help appreciated,
Hans

-- 
Diese E-Mail wurde von Avast Antivirus-Software auf Viren gepr?ft.
https://www.avast.com/antivirus


From wgmailinglist.all at jzdm.de  Tue Apr 28 16:13:45 2020
From: wgmailinglist.all at jzdm.de (Johannes Z. D. Mieth)
Date: Tue, 28 Apr 2020 16:13:45 +0200
Subject: EdgeRouter binaries
Message-ID: <d70eb47c-717a-4d11-28ab-e133e38444e7@jzdm.de>

Dear all,

unfortunately the GitHub repository [1] for WireGuard EdgeRouter
binaries seems to be discontinued [2].
Does anybody have a recommendation for another repository to get
WireGuard binaries from?
What I need are binaries for the EdgeRouter X with firmware ?
v2.0.8-hotfix, kernel 4.14.54.

Kind regards,
??? Johannes

[1] https://github.com/Lochnair/vyatta-wireguard
[2]
https://github.com/Lochnair/vyatta-wireguard/issues/140#issuecomment-587031573

From riccardo at rcrdbrt.com  Thu Apr 30 16:01:29 2020
From: riccardo at rcrdbrt.com (Riccardo Berto)
Date: Thu, 30 Apr 2020 16:01:29 +0200
Subject: [PATCH] systemd: add file wireguard.target
In-Reply-To: <20200430135551.9911-1-mardnh@gmx.de>
References: <20200430135551.9911-1-mardnh@gmx.de>
Message-ID: <4c6e0e4e-9542-489e-7bb6-84b17ce44e15@rcrdbrt.com>

Vouching for this, sounds quite useful.

On 4/30/20 3:55 PM, Martin Hauke wrote:
> Add file wireguard.target, which allows you to stop or restart all
> instances.
> ---
>  src/systemd/wg-quick at .service | 1 +
>  src/systemd/wireguard.target  | 2 ++
>  2 files changed, 3 insertions(+)
>  create mode 100644 src/systemd/wireguard.target
>
> diff --git a/src/systemd/wg-quick at .service b/src/systemd/wg-quick at .service
> index 7c5f9d1..c22f7b3 100644
> --- a/src/systemd/wg-quick at .service
> +++ b/src/systemd/wg-quick at .service
> @@ -2,6 +2,7 @@
>  Description=WireGuard via wg-quick(8) for %I
>  After=network-online.target nss-lookup.target
>  Wants=network-online.target nss-lookup.target
> +PartOf=wireguard.target
>  Documentation=man:wg-quick(8)
>  Documentation=man:wg(8)
>  Documentation=https://www.wireguard.com/
> diff --git a/src/systemd/wireguard.target b/src/systemd/wireguard.target
> new file mode 100644
> index 0000000..8e59224
> --- /dev/null
> +++ b/src/systemd/wireguard.target
> @@ -0,0 +1,2 @@
> +[Unit]
> +Description=Target to restart all parts of WireGuard
> --
> 2.26.2
>

From mike at pineview.net  Tue Apr 14 11:06:32 2020
From: mike at pineview.net (Mike O'Connor)
Date: Tue, 14 Apr 2020 09:06:32 -0000
Subject: Is there a way to use wireguard as a non-encrypted VPN?
In-Reply-To: <9a3401d61035$4d6b5840$e84208c0$@pmfarmwald.com>
References: <9a3401d61035$4d6b5840$e84208c0$@pmfarmwald.com>
Message-ID: <42e91c0b-ca22-d279-4be5-5ece42687400@pineview.net>

On 12/4/20 4:43 am, mike at pmfarmwald.com wrote:
> I have some older routers that run OpenWRT just fine, but are a bit slow at
> Wireguard (3-5 MBytes/s for SMB transfers) and which are too slow for
> playing HD movies.
> For these routers/uses I don't care about security, I just want a VPN to
> tunnel (thru Comcast, and other ISPs that block lots of ports.)
> If there was a way to use Wiireguard?with encryption disabled, I'm pretty
> sure my performance would be closer to 20-50 MB/s which would be more than
> adequate.
> Thanks.
> Mike Farmwald
>
>
>
I suggest that your use a GRE tunnel connection.

Mike


From shadowofdarkness at gmail.com  Sun Apr 19 17:21:20 2020
From: shadowofdarkness at gmail.com (Dark Shadow)
Date: Sun, 19 Apr 2020 15:21:20 -0000
Subject: Android client fails to auto start connection if using a DDNS address
 as endpoint
Message-ID: <CAMXzSMozuS_dSpODmp3LzAmoetr9jKXUZpbQthx5P9YXk-xGAw@mail.gmail.com>

I set up Wireguard and had it working fine when manually starting the
connection.
After that I wanted to have it be always on so that it would auto
connect when turning the phone on but I found that it would say it was
connected but no data would transfer.
Manually turning it off and on again would fix the connection

If I change the server address to a IP address everything works
correctly and the connection just works after turning on the phone.

I assume this is a bug that can hopefully be fixed as I would prefer
to use the dyndns address in the settings.

From skyler.mantysaari at samipsolutions.fi  Wed Apr 29 11:19:14 2020
From: skyler.mantysaari at samipsolutions.fi (=?UTF-8?Q?Skyler_M=c3=a4ntysaari?=)
Date: Wed, 29 Apr 2020 12:19:14 +0300
Subject: Split tunneling with VyOS and Mac client
Message-ID: <c74e7d0a-f902-c872-4aed-7ab71f2aa1de@samip.fi>

Dear list subscribers,

I have tried to find actual documentation on split tunneling with 
Wireguard, but couldn't find really any actual examples on it. IPv6 
works, but my IPv4 connection does not work after connecting the VPN and 
I only want IPv6 to be tunneled. IPv4 should use the non-vpn gateway.

Pinging for example Cloudflare's DNS does not work, I get timeouts.
This is to give myself IPv6 connectivity when the actual network lacks it.

Server config:
 ?address 2a01:xxx:xx:f80b::1/64
 ?address 192.168.99.1/24
 ?peer sky-mbp {
 ???? allowed-ips 2a01:xxx:xx:f80b:bad:c0de::1/128
 ???? allowed-ips 192.168.99.3/32
 ???? persistent-keepalive 15
 ???? pubkey <censored>
 ?}
 ?port 51820

Client config:
[Interface]
PrivateKey = <censored>
Address = 192.168.99.3/32, 2a01:xxx:xx:f80b:bad:c0de:0:1/128
DNS = 2a01:xxx:xx:f80b::1

[Peer]
PublicKey = <censored>
AllowedIPs = 192.168.99.1/32, ::0/0
Endpoint = server_ipv4_address_censored:51820
PersistentKeepalive = 15


Best regards,
Skyler M


From leeloored at gmx.com  Sun Apr 26 23:01:49 2020
From: leeloored at gmx.com (Kent Friis)
Date: Sun, 26 Apr 2020 23:01:49 +0200
Subject: Multiple unreachable
Message-ID: <20200426230149.bf9e998b37a983892c635e78@gmx.com>

I have a pretty simple Wireguard setup between two machines. The power
supply in my brothers server died, so the tunnel is of course down. My
machine is running Linux 5.6.7 (from kernel.org, no patches or out of
tree drivers) with in-kernel Wireguard.

To see if he has gotten his server back up, I tried to ping it (via the
tunnel). That gave more unreachable responses than expected (note the
sequence number):

PING 172.16.1.1 (172.16.1.1) 56(84) bytes of data.
>From 172.24.0.1 icmp_seq=1 Destination Host Unreachable
>From 172.24.0.1 icmp_seq=1 Destination Host Unreachable
>From 172.24.0.1 icmp_seq=1 Destination Host Unreachable
>From 172.24.0.1 icmp_seq=1 Destination Host Unreachable
>From 172.24.0.1 icmp_seq=1 Destination Host Unreachable
>From 172.24.0.1 icmp_seq=1 Destination Host Unreachable
...
>From 172.24.0.1 icmp_seq=1 Destination Host Unreachable
>From 172.24.0.1 icmp_seq=1 Destination Host Unreachable
>From 172.24.0.1 icmp_seq=1 Destination Host Unreachable
>From 172.24.0.1 icmp_seq=1 Destination Host Unreachable
>From 172.24.0.1 icmp_seq=1 Destination Host Unreachable
>From 172.24.0.1 icmp_seq=1 Destination Host Unreachable
>From 172.24.0.1 icmp_seq=1 Destination Host Unreachable
>From 172.24.0.1 icmp_seq=1 Destination Host Unreachable
>From 172.24.0.1 icmp_seq=1 Destination Host Unreachable
>From 172.24.0.1 icmp_seq=1 Destination Host Unreachable
>From 172.24.0.1 icmp_seq=1 Destination Host Unreachable
>From 172.24.0.1 icmp_seq=1 Destination Host Unreachable
>From 172.24.0.1 icmp_seq=1 Destination Host Unreachable
>From 172.24.0.1 icmp_seq=1 Destination Host Unreachable
ping: sendmsg: Destination address required
^C
--- 172.16.1.1 ping statistics ---
1 packets transmitted, 0 received, +50 errors, 100% packet loss, time 0ms

172.24.0.1 is my end.
172.16.1.1 is my brother (not online)

rc.wireguard:
ip link add dev wg0 type wireguard
wg setconf wg0 /etc/wireguard/wg0.conf
ip address add dev wg0 172.24.0.1
ip link set up dev wg0
ip route add 172.16.1.0/24 dev wg0

wg0.conf:
[Interface]
PrivateKey = removed
ListenPort = 51820

[Peer]
PublicKey = also removed
AllowedIPs = 172.16.1.0/24

My PC has been rebooted since the tunnel was last up, so Wireguard has no
ip address for the other end.

This is not causing any problems that I've noticed, but I assume there is
a bug somewhere to give this many errors. Pinging an unreachable host on the
LAN only gives one "Host Unreachable" message per sequence number.

-Kent

From rfraile at rfraile.eu  Tue Apr 21 10:59:09 2020
From: rfraile at rfraile.eu (Ricardo Fraile)
Date: Tue, 21 Apr 2020 08:59:09 -0000
Subject: Search Domain/DNS Suffix
Message-ID: <f27176e3fc6ede8d04682a9b504df177@rfraile.eu>

Hi,

I tried to solve a similar issue on Linux a few months ago but sadly it 
wasn't merged to wg-quick:

https://www.mail-archive.com/wireguard at lists.zx2c4.com/msg04530.html

In my particular opinion, I think that this option is mandatory at the 
same level as DNS servers.

Regards,