[ANNOUNCE] WireGuardNT, a high-performance WireGuard implementation for the Windows kernel

[Jason A. Donenfeld]

Hello Jeff,

On Sun, Sep 12, 2021 at 3:55 PM Jeffrey Walton <noloader at gmail.com> wrote:
> One month to move into the next phase may be a bit tight for some
> folks. 30 days is probably fine for a developer or standalone
> installation, but some organizations cannot move that fast.
>
> I've worked in US Financial and US Federal, and some changes take
> longer to approve. Some organizations have processes in place that
> require approvals from management. It may take months to get a Change
> Control Request approved.
>
> When I worked at Treasury a trivial change could take two or three
> months and it required management signoffs and complete testing before
> being released to the production network. Nearly everyone dreaded a
> Change Control Request.

I'm not sure I really follow this line of reasoning here. You've
divided the into two categories:
A) "a developer or standalone installation" that is presumably
frequently upgrading in order to have the latest in greatest.
B) "US Financial and US Federal" and similar organizations for whom
changes require extensive paperwork and reliability testing.

For group (A), the gradual three phase rollout outlined in the initial
email works very well, as it means each component gets an appropriate
amount of testing depending on the phase, with related rollback
controls. It's group (B) that you've raised a concern about. But, if
each change for (B) requires paperwork and reliability testing,
wouldn't _that_ procedure also catch issues? Obviously a downside of
not updating like (A) does is that you miss timely security updates,
but I assume that (B) argues that their slow processes of sign-offs
and testing and paperwork increases reliability and accountability,
which may well be more important for (B). And it would seem that those
processes basically accomplish the same thing as the three phase plan
that's available to group (A) does. So it doesn't seem like anybody is
left out. Unless, of course, all those sign-offs and testing aren't
_actually_ testing anything meaningful, and they're just a Brazilesque
paperwork nightmare, in which case, with regard for neither security
nor reliability, what does it matter either way?

Anyway, there's no exact timeline of precisely 30 days. It will be a
good time after nobody has reported a bug. While products have "go to
market" deadlines, projects have the luxury of being on the "when it's
ready" schedule, which means we don't need to rush. At the same time,
I very much look forward to the reduced maintenance burden of no
longer maintaining duplicate code paths in the wireguard-windows repo.
The jd/remove-wintun branch has a commit that removes about a thousand
lines, which isn't _that_ much, but those are lines that are a bit
stressful in the sense that abstraction layers and duplicated code
paths are common sources of bugs, so they require extra vigilance from
me (and auditors).

> It may be noteworthy... on Windows OSes, the trend is to move stuff
> out of the kernel and into userspace to reduce risk. For example,
> Microsoft moved parts of the GDI out of the kernel and into userspace.
> So some folks may actually want the userland architecture to reduce
> risk.

I don't think it actually makes a practical difference in this case:
the userspace tunnel service retained SeLoadDriverPrivilege so that it
could *unload* Wintun when quitting. Besides, WireGuard was made to be
implemented in operating system kernels; figuring out how to do that
in a minimally scary way was an original thrust of the project. Linux,
OpenBSD, FreeBSD, and now NT.

Jason