git: 74ae3f3e33b8 - main - if_wg: import latest fixup work from the wireguard-freebsd project

[Jason A. Donenfeld]

Hi Scott,

I had hoped to talk about this with you in person, but I guess you
wanted it drawn out publicly. So I'll try to respond point by point. I
hope we can still talk about this face to face though, as I'd like to
calm the intensity a bit.

> - I want to be pragmatic about code APIs.  Maybe iflib isn’t ready for
> pseudo interfaces yet, and fixing it is non-trivial and out of scope.
> Going back to ifnet puts it back in line with openbsd and likely does
> fix the vnet problems.  However, it’s a radical change to the driver, and
> not something that I can support as a last-minute action for FreeBSD
> 13.0 or for pfSense.  Therefore, I’m advising against its immediate
> inclusion.  The final choice is not mine to make for FreeBSD, but
> that’s my recommendation.  For pfSense, I’ll be discussing this with
> the rest of the engineering staff on Monday.

I don't have much to say about iflib particulars as I don't really
have enough knowledge about the FreeBSD network stack to form strong
preferences, but I did notice there was lots of boilerplate that made
usage rather weird and confusing, and it made it harder to integrate
with vnets and jails. I trust Kyle's judgement about this, and seeing
that he's basically the main developer now of this code, I trust his
technical judgement there. As far as I can see, getting rid of iflib
made things a lot cleaner and simpler, though.

> - The LKML wouldn’t accept this kind of submission, they’d insist that
> it be broken down into consumable pieces, and that bug fixes be
> considered and provided that don’t rely on massive re-writes.  I’ve
> been dealing with linux for 20+ years and BSD for almost 30 years,
> and I’ve got to say that despite my distaste for how the LKML is run,
> they get results.

I don't think you're right about LKML. The original WireGuard
submission there was quite big:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/?id=e7096c131e5161fa3b8e52a650d7719d2857adfd
But regardless, I generally agree with you that smaller commits are
better -- we actually worked in smaller commits in our staging repo --
but given that this wound up being a rewrite, and the crazy rapid fire
of the work we were doing, it was a lot more clear in the end to just
squash this rather than having all our intermediate work, which
sometimes was a bit incoherent. Moving forward, we'll certainly have
smaller commits. You can already see the incremental followup commits
Kyle has made. The rest of us will be working on more things too in
the coming weeks and you can expect for incremental progress as such.

> The Ugly:
> - An accusation was made, tonight, to me, that the code Netgate
> sponsored was not reviewed and was shoved into the tree at the last
> minute.  This grossly ignores the actual history to the point of
> weakening my tolerance for this entire discussion.  It shows a pretty
> irrational bias against mmacy and Netgate and a gross ignorance of
> the history and provenience of the work.

I don't have much to say about this accusation. I don't know anything
about Netgate's processes. The code certainly appeared rushed and
incomplete, full of problems, but that doesn't really address the
accusation. I don't know who made that but it wasn't me. If anything,
I'm biased in favor of Netgate. You guys are shipping WireGuard and
that's super cool! So whatever parts of my biases are irrational I
think mostly serve to make me enthusiastic about what you guys are up
to.

> - The Netgate copyright was unilaterally removed.  Yes, it was re-
> instated a few minutes ago, and with good reason.  Please don’t
> do that again.

There was tons of churn and cruft in our staging repo as we pushed
commits rapid fire. Of course the copyright line was fixed before we
pushed it to freebsd-src. I mean, gosh, this whole awesome FreeBSD
wireguard project wouldn't have even existed without you guys starting
it. The tone of your email sounds like you've got a very different
impression, so I should really stress that I'm _incredibly grateful_
that Netgate got things rolling.

> - The removal of the ASM crypto bits really confuses me.  An
> accusation was made, again tonight, that Netgate merely paid to
> benchmark the code, that we contributed nothing to it, and that it’s
> bad code that can’t be audited.  What I see is that the meat of the
> implementation is copyrighted by Jason and others.  There’s a
> modest but non-trivial amount of glue code that has (or had) the
> Netgate copyright. I’m not going to touch the audit nonsense.
> I need data here, and I’m not seeing it.

Again, I have no idea at *all* where that accusation is coming from.
All I can comment on is the code as I found it, and it was a total
mess. I'm confident we'll be able to wire up the nice AVX code
properly, though. It looks like FreeBSD already has lots of this sort
of thing working in opencrypto/ using code from OpenSSL (similarly to
the code previously imported from the old crusty compat linux module).
So let's do that properly. I wrote about it here:
https://lists.freebsd.org/pipermail/freebsd-hackers/2021-March/057076.html

> There seems to be a lot of bad blood, poor understanding, and
> misinformation going on.  I need all of this bullshit to stop

Jeeze louise, I really couldn't agree more with you here. I'm really
wayyyy more aligned with your perspectives and goals than the tone of
your email seems to suggest. We both want freebsd's wireguard
implementation to be awesome -- awesome security, awesome performance,
awesome stability, awesome community support, and so on. My goal is to
both write code myself and help others write code to make that happen.
I've really enjoyed working with Kyle and MattD on that in the last
week. And I'm happy to work on that with you and anyone else who wants
to help too. I'm especially excited about potentially collaborating
with the FreeBSD crypto maintainers.

I hope we get a chance to talk later today.

Regards,
Jason