Development discussion of WireGuard
 help / color / mirror / Atom feed
* [ANNOUNCE] Wintun 0.9 Released with Major Usability Improvements
@ 2020-11-09 16:25 Jason A. Donenfeld
  2020-11-12 13:19 ` Guy Godfroy
  0 siblings, 1 reply; 2+ messages in thread
From: Jason A. Donenfeld @ 2020-11-09 16:25 UTC (permalink / raw)
  To: wireguard

Hi folks,

Simon and I are very excited to announce the release of Wintun 0.9, the
release in which Wintun finally becomes easy and enjoyable to use by
developers. I consider this the most significant release of Wintun yet.

Webpage: https://www.wintun.net/

For background: Wintun is a driver for the Windows kernel that enables
userspace programs to create network tunnels. It's a "/dev/net/tun" of the
Windows world. We use this for WireGuard. We had investigated OpenVPN's "tap6"
driver but found it to be a crumbling mess with dubious security, and instead
endeavored to write a lightweight minimal replacement that obtains extremely
high speeds using a ring buffer, similar to Linux's io_uring.

Big Change 1: API Library and Easy Distribution
-----------------------------------------------

We used to rely on an obscure Microsoft technology for distributing Wintun,
called MSI Merge Modules (MSM), in which application writers would bundle the
signed MSM we provided as part of their MSI installer. This was great in that
it encapsulated a lot of logic and hid it from developers, but relying on MSM
was a hassle and precluded the use of Wintun in many non-MSI apps.

The MSM also would simply make sure the driver was installed, but wouldn't
provide anything else. It was up to developers to then navigate arcane Windows
driver instantiation APIs, which are some of the oldest and most obscure to
use. Then, once installed, developers had to manage a ring and various IOCTLs
themselves. It all worked -- WireGuard and OpenVPN (after receiving our
assistance) successfully deployed it -- but it was cumbersome enough that
nobody else was going to use this.

With Wintun 0.9, we're changing what we distribute and also providing an easy
to use API. Rather than shipping MSMs to developers, we now ship a single
basic boring wintun.dll. This dll hides all of the driver installation and
adapter instantiation logic, and provides a nice interface for managing
adapters and shuffling data in and out of the ring buffer. So, application
developers can now just grab that dll, plop it into their application like
they would any other dll, and use Wintun without even noticing that it's
inserting a kernel driver when necessary

Big Change 2: Support for WOW64 and ARM
---------------------------------------

Windows does not support setupapi.dll and related driver functions on 32-bit
processes running on 64-bit operating systems. This meant that it was
impossible for WOW64 processes to use Wintun. Wintun also formerly required
64bit addresses, which made the kernel ABI clumsy for WOW64 processes. With
Wintun 0.9, we now bundle a 64-bit version of Wintun inside 32-bit versions of
the wintun.dll, and we marshal calls back and forth to an on-demand proxy
process running on the native architecture.

Not only do we have this for basic WOW64, but we also have this working for
Windows' ARM64 emulation of x86 binaries. So you can now run an x86 program on
ARM64 and wintun.dll will figure out what to do.

This has big effects for us. Since Go still has not been ported to ARM64, we
use an ARM build and rely on this new feature of Wintun. This means we should
have a WireGuard for ARM64 Windows release in the coming week or two.

Big Change 3: Administrator User Permissions
--------------------------------------------

Wintun requires the Local System user. But if you're running as Administrator,
the wintun.dll library will attempt to do its operations as Local System,
automatically. This effectively means that normal apps can bundle Wintun now,
rather than just services.


Please let us know if you have any questions or feedback. We're certainly
interested in developer reports on what integrating this is like.

- The API reference is available online:
  https://git.zx2c4.com/wintun/about/

- And there's some simple example code too:
  https://git.zx2c4.com/wintun/tree/example/example.c

- A signed wintun.dll for amd64, arm64, x86, and arm is on the webpage:
  https://www.wintun.net/

- And of course, it's open source:
  git clone https://git.zx2c4.com/wintun

Regards,
Jason

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [ANNOUNCE] Wintun 0.9 Released with Major Usability Improvements
  2020-11-09 16:25 [ANNOUNCE] Wintun 0.9 Released with Major Usability Improvements Jason A. Donenfeld
@ 2020-11-12 13:19 ` Guy Godfroy
  0 siblings, 0 replies; 2+ messages in thread
From: Guy Godfroy @ 2020-11-12 13:19 UTC (permalink / raw)
  To: wireguard

Just noticed that wintun icon is heavily inspired from french subway
warning message "Don't put yout hands on the door" :-)

Anyway, great job.

Le 09/11/2020 à 17:25, Jason A. Donenfeld a écrit :
> Hi folks,
> 
> Simon and I are very excited to announce the release of Wintun 0.9, the
> release in which Wintun finally becomes easy and enjoyable to use by
> developers. I consider this the most significant release of Wintun yet.
> 
> Webpage: https://www.wintun.net/
> 
> For background: Wintun is a driver for the Windows kernel that enables
> userspace programs to create network tunnels. It's a "/dev/net/tun" of the
> Windows world. We use this for WireGuard. We had investigated OpenVPN's "tap6"
> driver but found it to be a crumbling mess with dubious security, and instead
> endeavored to write a lightweight minimal replacement that obtains extremely
> high speeds using a ring buffer, similar to Linux's io_uring.
> 
> Big Change 1: API Library and Easy Distribution
> -----------------------------------------------
> 
> We used to rely on an obscure Microsoft technology for distributing Wintun,
> called MSI Merge Modules (MSM), in which application writers would bundle the
> signed MSM we provided as part of their MSI installer. This was great in that
> it encapsulated a lot of logic and hid it from developers, but relying on MSM
> was a hassle and precluded the use of Wintun in many non-MSI apps.
> 
> The MSM also would simply make sure the driver was installed, but wouldn't
> provide anything else. It was up to developers to then navigate arcane Windows
> driver instantiation APIs, which are some of the oldest and most obscure to
> use. Then, once installed, developers had to manage a ring and various IOCTLs
> themselves. It all worked -- WireGuard and OpenVPN (after receiving our
> assistance) successfully deployed it -- but it was cumbersome enough that
> nobody else was going to use this.
> 
> With Wintun 0.9, we're changing what we distribute and also providing an easy
> to use API. Rather than shipping MSMs to developers, we now ship a single
> basic boring wintun.dll. This dll hides all of the driver installation and
> adapter instantiation logic, and provides a nice interface for managing
> adapters and shuffling data in and out of the ring buffer. So, application
> developers can now just grab that dll, plop it into their application like
> they would any other dll, and use Wintun without even noticing that it's
> inserting a kernel driver when necessary
> 
> Big Change 2: Support for WOW64 and ARM
> ---------------------------------------
> 
> Windows does not support setupapi.dll and related driver functions on 32-bit
> processes running on 64-bit operating systems. This meant that it was
> impossible for WOW64 processes to use Wintun. Wintun also formerly required
> 64bit addresses, which made the kernel ABI clumsy for WOW64 processes. With
> Wintun 0.9, we now bundle a 64-bit version of Wintun inside 32-bit versions of
> the wintun.dll, and we marshal calls back and forth to an on-demand proxy
> process running on the native architecture.
> 
> Not only do we have this for basic WOW64, but we also have this working for
> Windows' ARM64 emulation of x86 binaries. So you can now run an x86 program on
> ARM64 and wintun.dll will figure out what to do.
> 
> This has big effects for us. Since Go still has not been ported to ARM64, we
> use an ARM build and rely on this new feature of Wintun. This means we should
> have a WireGuard for ARM64 Windows release in the coming week or two.
> 
> Big Change 3: Administrator User Permissions
> --------------------------------------------
> 
> Wintun requires the Local System user. But if you're running as Administrator,
> the wintun.dll library will attempt to do its operations as Local System,
> automatically. This effectively means that normal apps can bundle Wintun now,
> rather than just services.
> 
> 
> Please let us know if you have any questions or feedback. We're certainly
> interested in developer reports on what integrating this is like.
> 
> - The API reference is available online:
>   https://git.zx2c4.com/wintun/about/
> 
> - And there's some simple example code too:
>   https://git.zx2c4.com/wintun/tree/example/example.c
> 
> - A signed wintun.dll for amd64, arm64, x86, and arm is on the webpage:
>   https://www.wintun.net/
> 
> - And of course, it's open source:
>   git clone https://git.zx2c4.com/wintun
> 
> Regards,
> Jason
> 

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2020-11-12 13:20 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-11-09 16:25 [ANNOUNCE] Wintun 0.9 Released with Major Usability Improvements Jason A. Donenfeld
2020-11-12 13:19 ` Guy Godfroy

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).