[ANNOUNCE] WireGuard Snapshot `0.0.20180620` Available

[ANNOUNCE] WireGuard Snapshot `0.0.20180620` Available

[Jason A. Donenfeld]

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

Hello,

A new snapshot, `0.0.20180620`, has been tagged in the git repository.

Please note that this snapshot is, like the rest of the project at this point
in time, experimental, and does not consitute a real release that would be
considered secure and bug-free. WireGuard is generally thought to be fairly
stable, and most likely will not crash your computer (though it may).
However, as this is a pre-release snapshot, it comes with no guarantees, and
its security is not yet to be depended on; it is not applicable for CVEs.

With all that said, if you'd like to test this snapshot out, there are a
few relevent changes.

== Changes ==

  * chacha20poly1305: use slow crypto on -rt kernels on arm too
  
  Leftover from the last commit of the previous snapshot that we forgot to
  handle.
  
  * tools: getentropy requires macOS 10.12
  
  Small build time fixup for old versions of macOS.
  
  * queueing: remove useless spinlocks on sc
  * queueing: re-enable preemption periodically to lower latency
  * simd: encapsulate fpu amortization into nice functions
  * simd: no need to restore fpu state when no preemption
  
  This will improve general system latency on preempt-enabled systems, like
  desktops.
  
  * dns-hatchet: apply resolv.conf's selinux context to new resolv.conf
  
  Fixes wg-quick's dns hatchet on CentOS.
  
  * qemu: bump default kernel
  
  By bumping to 4.17.2, we actually uncovered a bug in the SLUB allocator, which
  upstream is now fixing: https://lkml.org/lkml/2018/6/18/1407
  
  * noise: take locks for ss precomputation
  * netlink: maintain static_identity lock over entire private key update
  
  Minor locking correctness fixes and optimizations.
  
  * noise: wait for crng before taking locks
  
  We now make sure that an outgoing packet which needs a potentially unseeded
  rng won't block a call to wg(8), which takes similar locks for retrieving
  data.
  
  * receive: drop handshake packets if rng is not initialized
  
  If the rng is unseeded, we drop incoming handshake packets, so that it's not
  possible for an attacker to fill the handshake queue thereby provoking
  cookies.
  
  * ratelimiter: mitigate reference underflow
  * ratelimiter: do not allow concurrent init and uninit
  
  Minor correctness and hardening fixes, which don't fix anything particular in
  WireGuard, but might be useful if our ratelimiter is ever used elsewhere.
  
  * compat: use stabler lkml links
  * poly1305: add missing string.h header
  
  Minor fixups.

This snapshot contains commits from: Jason A. Donenfeld.

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

This snapshot is available in tarball form here:
  https://git.zx2c4.com/WireGuard/snapshot/WireGuard-0.0.20180620.tar.xz
  SHA2-256: b4db98ea751c8e667454f98ea1c15d704a784fe1bc093b03bd64575418a7c242
  BLAKE2b-256: f4e5a65f384a04cb1202e2866afc52469f121acb092a06be270d13ed211efdec

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

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-----

iQJEBAEBCAAuFiEEq5lC5tSkz8NBJiCnSfxwEqXeA64FAlsqqI0QHGphc29uQHp4
MmM0LmNvbQAKCRBJ/HASpd4DrmPrEADFN1u60NGocdWyFtXnv16wrvM93ZKbOteX
Wa3wkh/pagPktCHyi4qNAU1C3VGyzAF5V/9vBVd9D+nzhZcDd2Zyj7u+5dDRlPun
N5zaxj5wq84peSxjHKXZht/11P5g6e2/9hDFNsM8PAE7qfrmSrhoxGdymSFT9kHA
iyCp89uXfyWcqtKffw3kfzrjgZLi3cwi793GydWGoURPFdy3xpy8NCvakpsakmG0
JYFRTq8YKceAPSBN8uFEC/BlermAWssd78OiQjCzIpkxZc64MEidoCvZPSynVWqD
wSOxfsH8aHd/GYq74+IQ/uLaFlt3W0ive/IZ7ESF+Q3c5FdkguVMIN4lo9XxBPKa
a3MDREdxToLZMxbh3ublDrjxDHNx6rARHsaIlkmcxynnMPz+j/5J5yi8z8R/p6bY
K8hF6KJqW18h90EuKfVdAkKUnaKfS7k82VKXBz2M6d1bFnz4psE5eD2uLzCXkIFl
Sj/+QlqanU/P4r8ZASOWRNXzrLtpFxR7fAzlgE/hTTY6heA/txxeTQK79iswniya
4fsZ0pVApnH7oLWpAsntByuiSAPnQB+R+4eLKgU5KUngRTtx8ITSazo3Z5/ZWCnI
sMTJT1L2+yRh6kLI5IVjHaQ0w0cn7Ymd/rlmW23Yyi3QEZUeFV1DKClSOy93Rs58
v7U2S/briA==
=Mdq3
-----END PGP SIGNATURE-----

Re: [ANNOUNCE] WireGuard Snapshot `0.0.20180620` Available

[Lonnie Abelbeck]

> On Jun 20, 2018, at 2:19 PM, Jason A. Donenfeld <Jason@zx2c4.com> =
wrote:
>=20
> A new snapshot, `0.0.20180620`, has been tagged in the git repository.

I find 0.0.20180620 much slower than previous version 0.0.20180531

All things being equal, only WireGuard version changes.

Both boxes:
# uname -a
Linux pbx 3.16.54-astlinux #1 SMP PREEMPT Mon Jun 11 09:17:57 CDT 2018 =
x86_64 GNU/Linux


Test: 0.0.20180531
--
Qotom Q190G4N-S07 NIC x4
# iperf3 -s

Jetway NF9HG-2930 NIC x4
# iperf3 -c 10.4.0.10 -t30 -P2

[SUM]   0.00-30.00  sec  2.65 GBytes   758 Mbits/sec  571             =
sender
[SUM]   0.00-30.02  sec  2.64 GBytes   756 Mbits/sec                  =
receiver
--

Test: 0.0.20180620
--
Qotom Q190G4N-S07 NIC x4
# iperf3 -s

Jetway NF9HG-2930 NIC x4
# iperf3 -c 10.4.0.10 -t30 -P2

[SUM]   0.00-30.00  sec  1.50 GBytes   430 Mbits/sec   96             =
sender
[SUM]   0.00-30.02  sec  1.50 GBytes   428 Mbits/sec                  =
receiver
--

Interesting note, using -P1 the difference is not as pronounced, but =
still slower.

Any ideas ?

Lonnie

Re: [ANNOUNCE] WireGuard Snapshot `0.0.20180620` Available

[Matthias Urlichs]

On 20.06.2018 22:11, Lonnie Abelbeck wrote:
> Any ideas ?

That's … ugly. Could you please "git bisect" this?

-- 
-- Matthias Urlichs

Re: [ANNOUNCE] WireGuard Snapshot `0.0.20180620` Available

[Jason A. Donenfeld]

Hey Lonnie,

Thanks for letting me know. Can you tell me if this patch --
https://=D7=90.cc/GJpT3gVY -- brings the performance back up? And if that
works, can you then try each of those three fragments separate to see
which one has an actual effect (or perhaps all do).

Jason

Re: [ANNOUNCE] WireGuard Snapshot `0.0.20180620` Available

[Lonnie Abelbeck]

> On Jun 20, 2018, at 4:24 PM, Jason A. Donenfeld <Jason@zx2c4.com> =
wrote:
>=20
> Hey Lonnie,
>=20
> Thanks for letting me know. Can you tell me if this patch --
> https://=D7=90.cc/GJpT3gVY -- brings the performance back up? And if =
that
> works, can you then try each of those three fragments separate to see
> which one has an actual effect (or perhaps all do).
>=20
> Jason

Hunk #1 only does the trick, though performance is ever so slightly =
slower than before overall.

Is this issue because our project uses CONFIG_PREEMPT=3Dy ?

Data below.

Lonnie

-- 0.0.20180531 reference --
[SUM]   0.00-30.00  sec  2.65 GBytes   758 Mbits/sec  571             =
sender
[SUM]   0.00-30.02  sec  2.64 GBytes   756 Mbits/sec                  =
receiver

-- full patch --  hunk #1, #2 and #3
[SUM]   0.00-30.00  sec  2.53 GBytes   724 Mbits/sec  921             =
sender
[SUM]   0.00-30.01  sec  2.52 GBytes   722 Mbits/sec                  =
receiver

-- hunk #1 only --
[SUM]   0.00-30.00  sec  2.57 GBytes   735 Mbits/sec  807             =
sender
[SUM]   0.00-30.01  sec  2.56 GBytes   733 Mbits/sec                  =
receiver

-- hunk #2 only --
[SUM]   0.00-30.00  sec  1.52 GBytes   434 Mbits/sec   91             =
sender
[SUM]   0.00-30.02  sec  1.51 GBytes   433 Mbits/sec                  =
receiver

-- hunk #3 only --
[SUM]   0.00-30.00  sec  1.51 GBytes   432 Mbits/sec  330             =
sender
[SUM]   0.00-30.03  sec  1.50 GBytes   430 Mbits/sec                  =
receiver

Re: [ANNOUNCE] WireGuard Snapshot `0.0.20180620` Available

[Jason A. Donenfeld]

Hey Lonnie,

Thanks for helping to debug this.

On Thu, Jun 21, 2018 at 12:37 AM Lonnie Abelbeck
<lists@lonnie.abelbeck.com> wrote:
> Hunk #1 only does the trick, though performance is ever so slightly slowe=
r than before overall.

It's good to hear that hunks #2 and #3 don't have much an effect,
though it does still seem to have _some_ effect.

Looks like hunk 1 is rather worrisome though. Can you try out
https://=D7=90.cc/eaxxpxbB and let me know if it has any effect?

> Is this issue because our project uses CONFIG_PREEMPT=3Dy ?

Yes, generally, preemption is good for latency but bad for throughput.
I was trying to make the queues a bit more preemption friendly, but
this seemed to have killed performance, so I'll be revisiting this,
because I don't want to make things worse than before.

I find it very strange that 20180531 is still faster than the last
patch I sent you. The only other difference along the hot path,
besides the last patch I sent you, between the two snapshots is
https://git.zx2c4.com/WireGuard/patch/?id=3Db7b193f499d4acd8a620163ec358c08=
30e856c9e
and this is _removing_ code, so I'd think this would actually
contribute to a speed increase, not a slight decrease. Are you sure
the benchmark conditions were the same in other respects?

Jason

Re: [ANNOUNCE] WireGuard Snapshot `0.0.20180620` Available

[Lonnie Abelbeck]

> On Jun 20, 2018, at 6:47 PM, Jason A. Donenfeld <Jason@zx2c4.com> =
wrote:
>=20
> Hey Lonnie,
>=20
> Thanks for helping to debug this.
>=20
> On Thu, Jun 21, 2018 at 12:37 AM Lonnie Abelbeck
> <lists@lonnie.abelbeck.com> wrote:
>> Hunk #1 only does the trick, though performance is ever so slightly =
slower than before overall.
>=20
> It's good to hear that hunks #2 and #3 don't have much an effect,
> though it does still seem to have _some_ effect.
>=20
> Looks like hunk 1 is rather worrisome though. Can you try out
> https://=D7=90.cc/eaxxpxbB and let me know if it has any effect?

That patch, as is, is very bad
--
[SUM]   0.00-30.00  sec  1.26 GBytes   360 Mbits/sec   98             =
sender
[SUM]   0.00-30.03  sec  1.25 GBytes   358 Mbits/sec                  =
receiver

I then edited the patch to add back in local_bh_disable() / =
local_bh_enable(), much better
--
[SUM]   0.00-30.00  sec  2.62 GBytes   751 Mbits/sec  1389             =
sender
[SUM]   0.00-30.00  sec  2.61 GBytes   748 Mbits/sec                  =
receiver

essentially back to 0.0.20180531 performance, hunk #1 from previous =
patch and hunk #1 from the latest patch.


> Are you sure
> the benchmark conditions were the same in other respects?

Yes, quite sure, but there is some variation of the iperf3 results on =
each run ... I perform a few runs and then pick a median sample.

Lonnie

Re: [ANNOUNCE] WireGuard Snapshot `0.0.20180620` Available

[Lonnie Abelbeck]

[-- Attachment #1: Type: text/plain, Size: 1660 bytes --]


> On Jun 20, 2018, at 7:22 PM, Lonnie Abelbeck <lists@lonnie.abelbeck.com> wrote:
> 
> 
>> On Jun 20, 2018, at 6:47 PM, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>> 
>> Hey Lonnie,
>> 
>> Thanks for helping to debug this.
>> 
>> On Thu, Jun 21, 2018 at 12:37 AM Lonnie Abelbeck
>> <lists@lonnie.abelbeck.com> wrote:
>>> Hunk #1 only does the trick, though performance is ever so slightly slower than before overall.
>> 
>> It's good to hear that hunks #2 and #3 don't have much an effect,
>> though it does still seem to have _some_ effect.
>> 
>> Looks like hunk 1 is rather worrisome though. Can you try out
>> https://א.cc/eaxxpxbB and let me know if it has any effect?
> 
> That patch, as is, is very bad
> --
> [SUM]   0.00-30.00  sec  1.26 GBytes   360 Mbits/sec   98             sender
> [SUM]   0.00-30.03  sec  1.25 GBytes   358 Mbits/sec                  receiver
> 
> I then edited the patch to add back in local_bh_disable() / local_bh_enable(), much better
> --
> [SUM]   0.00-30.00  sec  2.62 GBytes   751 Mbits/sec  1389             sender
> [SUM]   0.00-30.00  sec  2.61 GBytes   748 Mbits/sec                  receiver
> 
> essentially back to 0.0.20180531 performance, hunk #1 from previous patch and hunk #1 from the latest patch.

Hey Jason,

I'm not sure if this helps, but the 0.0.20180620 performance loss is most noticeable on the box performing "iperf3 -s".

Also, here are a couple .png CPU utilizations of the "iperf3 -s" box via htop during the iperf3 test ...

Test: 0.0.20180620



Test: 0.0.20180620 + hunk #1 from previous patch and hunk #1 from the latest patch



Lonnie



[-- Attachment #2.1: Type: text/html, Size: 3434 bytes --]

[-- Attachment #2.2: unpatched.png --]
[-- Type: image/png, Size: 22254 bytes --]

[-- Attachment #2.3: patched.png --]
[-- Type: image/png, Size: 22442 bytes --]