[PATCH] wireguard: release correct lock on exceptional case

2020-10-31 Thread Jason A. Donenfeld
Backtrace from Jesper: ddb{0}> show panic noise_keypair: lock not held ddb{0}> trace db_enter() at db_enter+0x10 panic(81db9b58) at panic+0x12a rw_exit_write(8801ed10) at rw_exit_write+0xb5 noise_remote_begin_session(8801ec10) at noise_remote_begin_session+0x3c 1

[PATCH] tcpdump: special case dumping of layer 3 packets

2020-10-27 Thread Jason A. Donenfeld
Different link types get different printers. But until now, different link types would get the same pcap dumper. This is mostly fine, except for on LOOP-type interfaces, which have raw layer 3 packets. On these, the first four bytes of the packet represent the AF family, which the pcap data format

[PATCH] ifconfig: keep track of allowed ips pointer correctly

2020-10-27 Thread Jason A. Donenfeld
Somebody on IRC mentioned that using ifconfig to set wgallowedips wasn't working on macppc. I don't have a macppc to test this on, but it seems like the code is assuming that the two values printed out by this test program must always be the same: struct s { int i; }; struct p {

Re: fix build without pf

2020-07-12 Thread Jason A. Donenfeld
ok zx2c4

Re: get public key as non-root

2020-07-03 Thread Jason A. Donenfeld
On Fri, Jul 3, 2020 at 11:47 AM Klemens Nanni wrote: > Is there any particular reason why an interface's *public* key is only > shown to the root user in ifconfig? Yes, there is a reason for this. The WireGuard protocol has a property called "identity hiding". See section 3.4 and 4.3.4 lemma 7

Re: wg(4): encapsulated transport checksums

2020-06-27 Thread Jason A. Donenfeld
Hi Richard, Thanks for the patch. I had problems parsing some terminology in your description, so I thought I'd lay out my understanding of the matter, and you can let me know whether or not this corresponds with what you had in mind: - On egress, we must compute the packet checksum, because it

Re: [PATCH] net: prevent if_clone_destroy from racing with rest of stack

2020-06-25 Thread Jason A. Donenfeld
On Thu, Jun 25, 2020 at 3:54 AM Vitaliy Makkoveev wrote: > ifp = ifunit(name); > if (ifp == NULL) > return (ENXIO); > + ifp->if_dying = 1; Reference counting, plus an explicit tear-down window, and wait period, like you've proposed sounds like a good idea.

Re: [PATCH] net: prevent if_clone_destroy from racing with rest of stack

2020-06-25 Thread Jason A. Donenfeld
On Thu, Jun 25, 2020 at 2:49 AM Martin Pieuchot wrote: > > On 24/06/20(Wed) 19:54, Jason A. Donenfeld wrote: > > On Wed, Jun 24, 2020 at 4:02 AM Martin Pieuchot wrote: > > > Yes, that might be a better way. If I understood your original mail the > > > issue

Re: [PATCH] net: prevent if_clone_destroy from racing with rest of stack

2020-06-24 Thread Jason A. Donenfeld
Hi Martin, On Wed, Jun 24, 2020 at 4:02 AM Martin Pieuchot wrote: > Yes, that might be a better way. If I understood your original mail the > issue is related to ifunit(), right? ifunit() is not used in packet- > processing contexts, that's why we did not protect it by the NET_LOCK(). > > I'm

Re: [PATCH] net: prevent if_clone_destroy from racing with rest of stack

2020-06-23 Thread Jason A. Donenfeld
On Tue, Jun 23, 2020 at 8:21 AM Martin Pieuchot wrote: > I'd argue this is a related problem but a different one. The diff I > sent serializes cloning/destroying pseudo-interfaces. It has value on > its own because *all* if_clone_*() operations are now serialized. > > Now you correctly points

Re: [PATCH] net: prevent if_clone_destroy from racing with rest of stack

2020-06-23 Thread Jason A. Donenfeld
On 6/23/20, Martin Pieuchot wrote: > On 23/06/20(Tue) 01:00, Jason A. Donenfeld wrote: >> You can crash a system by running something like: >> >> for i in 1 2 3; do while true; do ifconfig bridge0 create& ifconfig >> bridge0 destroy& done& done >&g

[PATCH] net: prevent if_clone_destroy from racing with rest of stack

2020-06-23 Thread Jason A. Donenfeld
You can crash a system by running something like: for i in 1 2 3; do while true; do ifconfig bridge0 create& ifconfig bridge0 destroy& done& done This works with every type of interface I've tried. It appears that if_clone_destroy and if_clone_create race with other ioctls, which causes a

[PATCH 2/3] wireguard: increase if_txmit to 64

2020-06-22 Thread Jason A. Donenfeld
This increases throughput by keeping the worker threads active for longer. --- sys/net/if_wg.c | 1 + 1 file changed, 1 insertion(+) diff --git sys/net/if_wg.c sys/net/if_wg.c index e27a575cc1b..5b7550840f8 100644 --- sys/net/if_wg.c +++ sys/net/if_wg.c @@ -2651,6 +2651,7 @@

[PATCH 1/3] conf: build wg(4) with ordinary kernel config

2020-06-22 Thread Jason A. Donenfeld
This will help us get a bit of testing in the snapshot builds. --- sys/conf/GENERIC | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git sys/conf/GENERIC sys/conf/GENERIC index 34d608cff44..f0eff16d2b8 100644 --- sys/conf/GENERIC +++ sys/conf/GENERIC @@ -109,7 +109,7 @@ pseudo-device

[PATCH 3/3] wireguard: mark interface as MPSAFE

2020-06-22 Thread Jason A. Donenfeld
This enables us to process queueing of different packet queues without KERNEL_LOCK. Combined with the increase in txlen, this keeps our encryption workers more active. This results in a ~30% performance boost. --- sys/net/if_wg.c | 22 +++--- 1 file changed, 11 insertions(+), 11

Re: use libc base64 code instead of libcrypt for ifconfig wg key handling

2020-06-21 Thread Jason A. Donenfeld
On Sun, Jun 21, 2020 at 7:01 PM David Gwynne wrote: > > libc has undocumented base64 encoding and decoding funtionality. this > cuts ifconfig over to using it instead of the code in libcrypto. > > whether the libc functionality should be "blessed" and documented is a > separate issue. > > ok? OK

Re: sparc64 boot issue on qemu

2020-06-01 Thread Jason A. Donenfeld
On Mon, Jun 1, 2020 at 2:37 PM Mark Cave-Ayland wrote: > Oh wow it looks great! Totally. I was super impressed as well. > I also have commit access to OpenBIOS so I can tidy that up > and get it posted over on the OpenBIOS mailing list. Probably the main thing > is to > figure out what to do

Re: sparc64 boot issue on qemu

2020-06-01 Thread Jason A. Donenfeld
On Mon, Jun 1, 2020 at 2:08 PM Jason A. Donenfeld wrote: > > Hi Mark, > > On Mon, Jun 1, 2020 at 1:54 PM Mark Cave-Ayland > wrote: > > > > On 01/06/2020 08:23, Jason A. Donenfeld wrote: > > > > > On Sun, May 31, 2020 at 3:18 AM Mark Cave-Ayland > >

Re: sparc64 boot issue on qemu

2020-06-01 Thread Jason A. Donenfeld
Hi Mark, On Mon, Jun 1, 2020 at 1:54 PM Mark Cave-Ayland wrote: > > On 01/06/2020 08:23, Jason A. Donenfeld wrote: > > > On Sun, May 31, 2020 at 3:18 AM Mark Cave-Ayland > > wrote: > >> > >> AFAICT the problem here is the Forth being used at > >>

Re: sparc64 boot issue on qemu

2020-06-01 Thread Jason A. Donenfeld
On Sun, May 31, 2020 at 7:22 AM Otto Moerbeek wrote: > Thanks, the following works indeed. > > -Otto > > Index: bootblk.fth > === > RCS file: /cvs/src/sys/arch/sparc64/stand/bootblk/bootblk.fth,v > retrieving revision 1.9 >

Re: sparc64 boot issue on qemu

2020-06-01 Thread Jason A. Donenfeld
On Sun, May 31, 2020 at 3:18 AM Mark Cave-Ayland wrote: > > AFAICT the problem here is the Forth being used at > https://github.com/openbsd/src/blob/master/sys/arch/sparc64/dev/fb.c#L511: > since the > addr word isn't part of the IEEE-1275 specification, it is currently > unimplemented in >

Re: sparc64 boot issue on qemu

2020-05-29 Thread Jason A. Donenfeld
On Fri, May 29, 2020 at 4:56 PM Jason A. Donenfeld wrote: > > Oh that's a nice observation about `boot disk -V`. Doing so actually > got me booting up entirely: > > $ qemu-img convert -O qcow2 miniroot66.fs disk.qcow2 > $ qemu-img resize disk.qcow2 20G > $ qemu-system-sparc6

Re: sparc64 boot issue on qemu

2020-05-29 Thread Jason A. Donenfeld
Note that you need to run this with `-nographic`, because the kernel crashes when trying to use vgafb on sparc64/qemu. I've witnessed two varieties crashes: - https://data.zx2c4.com/openbsd-6.7-sparc64-vga-panic-miniroot67.png This happens when booting up miniroot67.fs -

Re: sparc64 boot issue on qemu

2020-05-29 Thread Jason A. Donenfeld
On Fri, May 29, 2020 at 4:56 PM Jason A. Donenfeld wrote: > > Oh that's a nice observation about `boot disk -V`. Doing so actually > got me booting up entirely: > > $ qemu-img convert -O qcow2 miniroot66.fs disk.qcow2 Er, copy and paste error. The below is actually from miniroot67.fs.

Re: sparc64 boot issue on qemu

2020-05-29 Thread Jason A. Donenfeld
Oh that's a nice observation about `boot disk -V`. Doing so actually got me booting up entirely: $ qemu-img convert -O qcow2 miniroot66.fs disk.qcow2 $ qemu-img resize disk.qcow2 20G $ qemu-system-sparc64 -m 1024 -drive file=disk.qcow2,if=ide -net nic,model=ne2k_pci -net user -boot a -nographic

Re: WireGuard patchset for OpenBSD, rev. 2

2020-05-28 Thread Jason A. Donenfeld
On Thu, May 28, 2020 at 1:19 AM Otto Moerbeek wrote: > Of course.., I was running it from a !wxallowed mount. BTW, qemu is in > packages, no need to build it yourself. Sure, but now I've been somewhat nerd sniped and am playing with this fcode forth implementation in qemu :-P. I wonder if

Re: WireGuard patchset for OpenBSD, rev. 2

2020-05-28 Thread Jason A. Donenfeld
On Thu, May 28, 2020 at 12:15 AM Otto Moerbeek wrote: > > On Wed, May 27, 2020 at 11:28:09PM -0600, Jason A. Donenfeld wrote: > > > Hi Otto, > > > > On Wed, May 27, 2020 at 4:07 AM Otto Moerbeek wrote: > > > Although I'm not terribly interested in bugs tha

Re: WireGuard patchset for OpenBSD, rev. 2

2020-05-27 Thread Jason A. Donenfeld
Hi Otto, On Wed, May 27, 2020 at 4:07 AM Otto Moerbeek wrote: > Although I'm not terribly interested in bugs that are only seen (s0 > far) using emulation, please send me the details on how you set up > qemu. Right, it could very well be a TCG bug. But maybe not. Here's how to get things

Re: WireGuard patchset for OpenBSD, rev. 2

2020-05-27 Thread Jason A. Donenfeld
On Wed, May 27, 2020 at 2:12 AM Jason A. Donenfeld wrote: > > Hi again Klemens, > > On Tue, May 26, 2020 at 5:42 PM Jason A. Donenfeld wrote: > > > > On Tue, May 26, 2020 at 4:52 PM Jason A. Donenfeld wrote: > > > With regards to your crash, though, that's a

Re: WireGuard patchset for OpenBSD, rev. 2

2020-05-27 Thread Jason A. Donenfeld
Hey David, On Wed, May 27, 2020 at 2:26 AM David Gwynne wrote: > > On Tue, May 26, 2020 at 05:42:13PM -0600, Jason A. Donenfeld wrote: > > On Tue, May 26, 2020 at 4:52 PM Jason A. Donenfeld wrote: > > > With regards to your crash, though, that's a bit more puzzling, and &g

Re: WireGuard patchset for OpenBSD, rev. 2

2020-05-27 Thread Jason A. Donenfeld
Hi again Klemens, On Tue, May 26, 2020 at 5:42 PM Jason A. Donenfeld wrote: > > On Tue, May 26, 2020 at 4:52 PM Jason A. Donenfeld wrote: > > With regards to your crash, though, that's a bit more puzzling, and > > I'd be interested to learn more details. Because these struc

Re: WireGuard patchset for OpenBSD, rev. 2

2020-05-27 Thread Jason A. Donenfeld
Hi Martin, To answer a few but not all of your questions: On Wed, May 27, 2020 at 1:34 AM Martin Pieuchot wrote: > First question is, is it possible to use the wg(4) interface without a > port? No, that is not how WireGuard works. For details on the actual protocol particulars, please see

Re: WireGuard patchset for OpenBSD, rev. 2

2020-05-26 Thread Jason A. Donenfeld
On Tue, May 26, 2020 at 4:52 PM Jason A. Donenfeld wrote: > With regards to your crash, though, that's a bit more puzzling, and > I'd be interested to learn more details. Because these structs are > already naturally aligned, the __packed attribute, even with the odd > nesting Ma

Re: WireGuard patchset for OpenBSD, rev. 2

2020-05-26 Thread Jason A. Donenfeld
Hey Klemens, Theo, On Tue, May 26, 2020 at 2:38 PM Klemens Nanni wrote: > > On Tue, May 26, 2020 at 02:23:06PM -0600, Jason A. Donenfeld wrote: > > That's good news that it's working for you now, but I didn't change > > anything within the last 24 hours (you mentioned "yes

Re: WireGuard patchset for OpenBSD, rev. 2

2020-05-26 Thread Jason A. Donenfeld
On Tue, May 26, 2020 at 2:33 PM Theo de Raadt wrote: > > Jason A. Donenfeld wrote: > > > Hey Klemens, > > > > On Tue, May 26, 2020 at 9:13 AM Klemens Nanni wrote: > > > I worked with the patches from the wireguard-openbsd repository after > > > versi

Re: WireGuard patchset for OpenBSD, rev. 2

2020-05-26 Thread Jason A. Donenfeld
Hey Klemens, On Tue, May 26, 2020 at 9:13 AM Klemens Nanni wrote: > I worked with the patches from the wireguard-openbsd repository after > version one of this diff on tech@ became a bit old. > > That was until yesterday; the kernel would panic due to memory > alignment issues in various spots,

Re: WireGuard patchset for OpenBSD, rev. 2

2020-05-26 Thread Jason A. Donenfeld
Hey Tobias, On Tue, May 26, 2020 at 5:28 AM Tobias Heider wrote: > > + if (((SIZE_MAX - size) / sizeof(struct wg_aip_io)) < sc->sc_aip_num) > > + goto error; > > I still think those two should return an error. 'goto error' is misleading as > it doesn't actually set ret != 0.

Re: WireGuard patchset for OpenBSD, rev. 2

2020-05-26 Thread Jason A. Donenfeld
Hey tech@, A few things I thought I should add to our v2 revision: First, the improvements we've made in the last few weeks have been pretty substantial, and we've now got a much more faithful protocol implementation. I've been running this on a few high traffic servers, and I'll probably move

Re: WireGuard patchset for OpenBSD

2020-05-25 Thread Jason A. Donenfeld
On Mon, May 25, 2020 at 2:16 PM Theo de Raadt wrote: > > I'll make a comment that I am quite unhappy about this ioctl > methodology. I don't like void *'s and varying sizes. > > I would be much happier if this was a fixed structure, filled with > known objects. > > It looks fragile. Indeed the

Re: WireGuard patchset for OpenBSD

2020-05-12 Thread Jason A. Donenfeld
On Tue, May 12, 2020 at 3:48 AM Kevin Chadwick wrote: > > On 2020-05-12 06:05, Matt Dunwoodie wrote: > > I don't want to put misleading numbers out there and every use case > >is different, therefore you should perform your own tests. In my > >environment (tcbbench between two Lenovo

Re: WireGuard patchset for OpenBSD

2020-05-12 Thread Jason A. Donenfeld
On Tue, May 12, 2020 at 12:37 AM Theo de Raadt wrote: > > Jason A. Donenfeld wrote: > > > On Mon, May 11, 2020 at 11:03:45PM -0600, Jason A. Donenfeld wrote: > > > I plan to publish some easy one-click > > > scripts for users to mess around with the kernel

Re: WireGuard patchset for OpenBSD

2020-05-12 Thread Jason A. Donenfeld
On Mon, May 11, 2020 at 11:03:45PM -0600, Jason A. Donenfeld wrote: > I plan to publish some easy one-click > scripts for users to mess around with the kernel support while we're > working through it here on the list. While tailing my opensmtpd log waiting for the mailing list server t

Re: WireGuard patchset for OpenBSD

2020-05-12 Thread Jason A. Donenfeld
Hey folks, [resending, as my original reply was to Matt's message that got killed by the graylist, so he resent with a new msgid.] Just wanted to chime in here to mention how thrilled I am about this. Matt has been at this for a long time, came to visit Paris last summer to work with me on

Re: WireGuard patchset for OpenBSD

2020-05-12 Thread Jason A. Donenfeld
Hey folks, Just wanted to chime in here to mention how thrilled I am about this. Matt has been at this for a long time, came to visit Paris last summer to work with me on this, and I think the end result is a very high quality implementation. I expect all sorts of useful feedback on network

Re: OpenBSD kernel implementation

2018-12-11 Thread Jason A. Donenfeld
Hi Brad, Exciting to see you working on this. However, I'm afraid the implementation you describe sounds deeply flawed and kind of misses the point of WireGuard. On Tue, Dec 11, 2018 at 2:24 PM wrote: > Currently, I want to take all the code that doesn't need to be in the > kernel and move it