Re: [Openvpn-devel] OpenVPN on ARM64 Windows

[Samuli S. <sa...@op...>]

Hi and welcome!

Il 28/04/2018 02:26, Jon Kunkee via Openvpn-devel ha scritto:
> Hi,
> 
> As a few of you have heard on IRC, I'm a Microsoft engineer working on the ARM64 version of Windows desktop, mostly on the x86 usermode emulation layers. One of the challenges usermode-only emulation poses is that applications relying on drivers don't run unless the driver is ported. There has been quite some interest in OpenVPN on my team and my proof of concept went well, so I am taking a shot at porting tap-windows6 to ARM64 and contributing the port back to the community.
> 
> (I'll have patches to share soon! Please bear with me.)

Patches to tap-windows6 driver are very, very welcome! As the driver
itself changes very rarely, we have not spent much effort in the support
code (e.g. build system) either.

> My proof of concept was pretty simple: Copy the source files into a VS2017 driver project, tweak the project properties to reflect the SOURCES file, lie about the NDIS version, and suddenly I had a working ARM64 tap0901.sys through which I could ping an OpenVPN server's VPN-side IP. Not bad!
> 
> Needless to say, a lot more work is required to ship this. I've already done a lot of it, and I'm planning to do the rest--but I'd love help, even if just advice and historical perspective. 
> 
> 
> The work splits into a few different buckets; I'm interested in your thoughts about my approach:
> 
> The Windows Driver Kit only supports ARM64 drivers from Windows 10 1709 forward, so tap-windows6's build system needed to migrate to the newer SDK, complete with new folder names and build engine semantics. Just switching SDKs required no driver code changes and I expect it should still run downlevel to Win7, if not Vista (but I haven't yet tested anything but Win10!). BuildTap.py needed a moderate number of straightforward changes.

I'm very interested in seeing and testing these changes. I think porting
the buildsystem to a newer SDK would be a good candidate for a PR.

> Appveyor will need to be updated to handle the environment and output changes; I'm happy to explain what's needed, but I have no previous experience with the service.

Ilya may be able to help you with that: he has written all our AppVeyor
integrations so far.

> Along with the SDK changes, the build script needed many changes to add a third architecture (ARM64).
>
These changes would make another PR.

> The installer also needed changes to support ARM64. I've written an NSIS header to replace x64.nsh to make this easy. (Complex NSIS scripting...um...ouch. Just...ouch. :)

We intend to switch away from NSIS to MSI packages. I believe Simon
already did some work in there but he was rather busy for an extended
period of time. But now he is back, so migrating away from NSIS might
make sense at this point. Thoughts Simon?

> The driver does technically need code changes, though: ARM64 Windows only supports NDIS >=6.30, while Windows 7 only supports NDIS <= 6.20. If I find that these changes are small enough, I'll simply base them on the NDIS version supported by the OS. If they're bigger, supporting two (or many) NDIS versions gets messy. I'm just starting on this now, but the NDIS maintainers made it sound somewhat simple for a driver that doesn't interact with hardware.
> 
> I cracked open the devcon.exe sample from the Win7 DDK and the only change I had to make was renaming the binary to tapinstall.exe. For the new build system, I pulled the latest devcon sources from
>     https://github.com/Microsoft/Windows-driver-samples/tree/master/setup/devcon
> and built it with the new WDK, then renamed it to tapinstall.exe in buildtap.py. This might break the current signing pattern. I did make one change to support ARM64 as a build target, and it's under review:>     https://github.com/Microsoft/Windows-driver-samples/pull/238
> As for whether or not the Microsoft code can now be redistributed, I think the 'clone the Microsoft repo' is a fairly easy way forward. On the other hand, the MS-PL isn't nearly as heavy as anything that the DDK came with:
>     https://raw.githubusercontent.com/Microsoft/Windows-driver-samples/master/LICENSE

MS-PL is an Open Source Initiative-approved license:

https://opensource.org/licenses/alphabetical

I think we're safe on the licensing front.

> As for signing, I get similar errors before and after my changes. I'm not quite sure what the goal is for which script section, but it does appear that the new build system invokes Inf2Cat itself using the test certs provided with the SDK. Since that doesn't cover tapinstall.exe or the installer EXE nor does it cover the official attestation case, it's insufficient. (I'll keep my ear to the ground about making this signing stuff more palatable in general.)

The tap-windows6 buildsystem signs, by default, files (tap0901.cat
files, tapinstall.exe, NSIS package) using a certificate with OpenVPN in
the (subject) name in the user's certificate store. It is also possible
to use a certificate file (pfx) and pass the password in the command-line.

Due to lack of proper refactoring the buildsystem is rather clunky and
could use some work. So any patches are most welcome! The clunkiness is,
however, quite well documented. In addition to README.md we have a quite
thorough Wiki page on how to sign the thing:

https://community.openvpn.net/openvpn/wiki/BuildingTapWindows6

I do have access the the Windows developer portal and can submit drivers
for official MS "blessing". But I have not yet even tried going through
the process.

> The x86 usermode daemon and UI work beautifully with the ARM64 driver, so bundling the properly-tri-arch tap-windows6 installer with the x86 usermode should be fine for now for the user experience. As pointed out on IRC, this is a big potential bottleneck since this is where the cryptography and routing are done, but it just works for now and I don't have the resources to add the ARM64 Windows ABI to GCC+mingw nor do I feel a pressing need to resuscitate the old MSVC openvpn-build paths and then hope the community is happy supporting that in the future, seeing as how it's currently unsupported. 

Yes, MSVC buildsystem has not been maintained in years. Occasionally
somebody tries to use it and notices it does not work and notifies us.
But nobody has stepped up to do the maintenance required.

> Going forward I'll be happy to smoke-test new versions of OpenVPN on an ARM64 device, as long as I have one available. 
> 
> 
> Overall, I think ARM64 support only requires changes to tap-windows6 and the build environment, but there are a lot of little changes. I'd love to hear your feedback, and I'm sure I missed explaining something.
> 
> Thanks,
> Jon Kunkee
>  
> (Shout out to kitsune1, cron2, mattock, pekster, and others who have given me feedback on IRC to get me this far!)

One final note on PRs/patches: keep them as small and atomic as possible
and they will be easy to review and marge. Just like you did with your
first PR :).

-- 
Samuli Seppänen
Community Manager
OpenVPN Technologies, Inc

irc freenode net: mattock