Wix Toolset introduced an issue beginning with the v3.14.0.3827 release.
When linking merge module, the light.exe displays an internal error:
```
WixLink:
"C:\Program Files (x86)\WiX Toolset v3.14\bin\light.exe" -nologo -b o
utput_dir="..\amd64\Release" -spdb -sw1076 -sw1079 -out "..\dist\wintu
n-amd64-0.8.msm" "..\amd64\Release\installer-intermediate\installer.wi
xobj"
light.exe : error LGHT0204: ICEM10: The property 'ProductCode' is not al
lowed in a Merge Module [C:\Users\Simon\Projekti\wintun\installer\instal
ler.vcxproj]
C:\Users\Simon\AppData\Local\Temp\xdyw3dnt\wintun-amd64-0.8.msm : error
LGHT0204: ICE03: Table: Component Column: _IceM05Mark Missing specificat
ions in _Validation Table (or Old Database) [C:\Users\Simon\Projekti\win
tun\installer\installer.vcxproj]
C:\Users\Simon\AppData\Local\Temp\xdyw3dnt\wintun-amd64-0.8.msm : error
LGHT0204: ICE03: Table: File Column: _ICEM07CAB Missing specifications i
n _Validation Table (or Old Database) [C:\Users\Simon\Projekti\wintun\in
staller\installer.vcxproj]
light.exe : error LGHT0217: Error executing ICE action 'ICE103'. The mos
t common cause of this kind of ICE failure is an incorrectly registered
scripting engine. See http://wixtoolset.org/documentation/error217/ for
details and how to solve this problem. The following string format was n
ot expected by the external UI message logger: "There is a problem with
this Windows Installer package. A DLL required for this install to compl
ete could not be run. Contact your support personnel or package vendor.
". [C:\Users\Simon\Projekti\wintun\installer\installer.vcxproj]
The command ""C:\Program Files (x86)\WiX Toolset v3.14\bin\light.exe"
-nologo -b output_dir="..\amd64\Release" -spdb -sw1076 -sw1079 -out "
..\dist\wintun-amd64-0.8.msm" "..\amd64\Release\installer-intermediate
\installer.wixobj"" exited with code 217.
```
This error is not a direct consequence of anything being wrong in our
source code. Fortunately, the utility still produces identical MSM file
as previous WiX Toolset versions do. Unfortunately, it exits with code
217.
However, we need recent v3.14 for ARM64 support.
I know this is a huge issue for our build system, masking out any other
potential true error, but the light.exe exit code has been temporarily
ignored.
Signed-off-by: Simon Rozman <simon@rozman.si>
ARM64 support was introduced in Windows 10. There is no need to pack the
EV signed ARM64 driver for older Windows releases.
The only use-case we do want to pack an EV signed ARM64 driver (or test
signed) in the installer.dll is when we are doing the rundll32.exe
tests. Therefore, the Debug version still packs it.
If there is no driver available to pack, fail at compile time - rather
than build an installer.dll that would fail at runtime.
Signed-off-by: Simon Rozman <simon@rozman.si>
Make all archs are use the standardized concept of volatile.
This patch will cause the most changes to arm64 codegen.
Signed-off-by: Shawn Hoffman <godisgovernment@gmail.com>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
TunDispatchSecurityDescriptor will leak if RtlAbsoluteToSelfRelativeSD
fails. Add cleanup in error path.
Reported-by: Shawn Hoffman <godisgovernment@gmail.com>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
WireGuard is always doing so-called "minor" upgrade. This makes it
enough to run EvaluateWintun only once - somewhere after CostFinalize.
The component state we bind our driver install/remove logic to will be a
singleton: either be installed, left alone, or uninstalled. One single
action for install product session and RemoveExistingProducts session.
Other applications using Wintun might use the so-called "major" upgrade.
In this scenario the existing product is completely uninstalled first.
Including Wintun. The EvaluateWintun was called only once and it
determined that Wintun driver should be uninstalled. Since the MSI did
not execute EvaluateWintun again when installing the new product later,
the Wintun remained uninstalled.
In the case of major upgrades, the Wintun requires two separate action
logics: what to do with Wintun on uninstall of the old product, and what
to do with it when new product is installed.
Therefore, EvaluateWintun has been moved between InstallInitialize and
InstallFinalize to have MSI execute it in install and uninstall
sessions.
Reported-by: Dmitry Smirnov <dmitry.smirnov@netprotect.com>
Tested-by: Simon Rozman <simon@rozman.si>
Signed-off-by: Simon Rozman <simon@rozman.si>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
When using packet forwarding on Windows computer, adjacent NBLs may
represent packet fragments. Those NBLs must not be completed separately,
but in a single NdisMSendNetBufferListsComplete() call.
This fixes a bugcheck on Windows Server with RRAS role and IP forwarding
packets to Wintun adapter.
Signed-off-by: Simon Rozman <simon@rozman.si>
Before duplicating a handle elsewhere and closing the original process
would result in disaster. Also, it turns out that TunHaltEx can be
called before the handles are all closed, so we need to unregister prior
to freeing the ctx, lest disaster occurs. Finally, now that we have a
few different things happening with registration and deregistration, we
serialize all accesses with an eresource, a bit heavy-weight but
sufficient.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
We mark all atomic variables as volatile and have our atomic accessors
built around that. We probably, therefore, want Linux-style
READ/WRITE_ONCE semantics of implying memory barriers. /volatile:ms does
this automatically.
This was already the default on amd64 and x86 but not on ARM.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Reported-by: Lev Stipakov <lstipakov@gmail.com>
Previously we had to spin for a minimum of 15ms because the tick
interval is 156250 on NT. On linux, usually trips to the high
performance timers are discouraged because if they don't hit the RDTSC
path (due to being unstable or the like), they hit more expensive
hardware. I assume that's probably the same on NT, but all of tcpip.sys
and ndis.sys uses the performance counters too, so what are we going to
do?
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
The Empty event state is now set according to
Ctx->Device.Receive.ActiveNbls.Head != NULL. But, we still have to clear
the Empty event inside the TransitionLock to prevent race with
TunPause().
Signed-off-by: Simon Rozman <simon@rozman.si>
Should NBL allocation persist to fail, the receive ring could eventually
fill up as there will be no TunReturnNetBufferLists() calls to advance
its head.
Signed-off-by: Simon Rozman <simon@rozman.si>
This commit is in many ways wrong, but when we're dealing with whql
imports, there's often a large gap in time, and it's useful to be able
to just restore everything exactly how it was prior and then build only
installer.dll and the msm.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
NdisMGetDeviceProperty() should always return non-NULL
FunctionalDeviceObject according to _Outptr_opt_. An explicit
FunctionalDeviceObject NULL check has been added to keep the SDV happy
and not calling our driver "defective".
Signed-off-by: Simon Rozman <simon@rozman.si>
By attaching to NDIS device instead of creating our own device for I/O,
the adapter is always running before client is able to connect and
register rings. NDIS also won't allow adapter to pause with connected
clients.
Signed-off-by: Simon Rozman <simon@rozman.si>
With no PnP notifications and custom surprise removal code we do not
need the TUN_FLAGS_PRESENT any more. The traffic is stopped when handle
is closed or adapter is somehow paused. Though by reusing the NDIS device
for our I/O, the adapter will not be able to pause with a client
connected.
Signed-off-by: Simon Rozman <simon@rozman.si>
Before the TunProcessReceiveData() thread terminates or adapter is
paused, we wait for all receive NBLs to be returned. Unfortunately,
IoReleaseRemoveLockAndWait() leaves the remove lock in non reusable
state.
To be able to start receiving packets on existing adapter again, we
(re)initialize the remove lock on ring registration or adapter resume.
The former addresses TunProcessReceiveData()'s
IoReleaseRemoveLockAndWait() call, the later addresses the TunPause()'s.
Signed-off-by: Simon Rozman <simon@rozman.si>
