All was well with NetSetupAnticipatedInstanceId, until a bug crept into
recent Windows builds that caused old GUIDs not to be properly removed,
resulting in subsequent adapter creations to fail, because NetSetup
AnticipatedInstanceId considers it fatal when the target GUID
already exists, even if in diminished form.
The initial solution was to detect cruft, and then steal a
TrustedInstaller token and sleuth around the registry cleaning things
up. The horror!
Uncomfortable with this, I reopened IDA and had a look around with fresh
eyes, three years after the original discovery of NetSetupAnticipated
InstanceId. There, I found some interesting behavior in
NetSetupSvcDeviceManager::InstallNetworkInterfaces, which amounts to
something like:
if (IsSet("RetiredNetCfgInstanceId") {
if (IsSet("NetSetupAnticipatedInstanceId")
DeleteAdapter(GetValue("RetiredNetCfgInstanceId"));
else
Set("NetSetupAnticipatedInstanceId", GetValue("RetiredNetCfgInstanceId"));
Delete("RetiredNetCfgInstanceId");
}
CreateAdapter = TRUE;
if (IsSet("NetSetupAnticipatedInstanceId")) {
Guid = GetValue("NetSetupAnticipatedInstanceId");
if (AdapterAlreadyExists(Guid))
CreateAdapter = FALSE;
else
SetGuidOfNewAdapter(Guid);
Delete("NetSetupAnticipatedInstanceId");
} else if (IsSet("SuggestedInstanceId")) {
Guid = GetValue("SuggestedInstanceId");
if (!AdapterAlreadyExists(Guid))
SetGuidOfNewAdapter(Guid);
Delete("SuggestedInstanceId");
}
Thus, one appealing strategy would be to set both NetSetupAnticipated
InstanceId and RetiredInstanceId to the same value, and let the service
handle deleting the old one for us before creating the new one.
However, the cleanup of the old adapter winds up being quasi-
asynchronous, and thus we still wind up in the CreateAdapter = FALSE
case.
So, the remaining strategy is to simply use SuggestedInstanceId instead.
This has the behavior that if there's an adapter already in use, it'll
use a new random GUID. The result is that adapter creation won't fail.
That's not great, but the docs have always made it clear that
"requested" is a best-effort sort of thing. Plus, hopefully the creation
of the new adapter will help nudge the bug a bit and cleanup the old
cruft. In some ways, transitioning from our old strategy of "cudgel the
registry until we get the GUID we want" to "ask politely and accept no
for an answer" is a disappointing regression in functionality. But it
also means we don't need to keep crazy token stealing code around, or
fish around in the registry dangerously. This probably also increases
the likelihood that an adapter will be created during edge cases, which
means fewer errors for users, which could be a good thing. On the
downside, we have the perpetual tensions caused by a system that now
"fails open" instead of "fails closed". But so it goes in Windows land.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Prior to the conversion, LastError is ERROR_SUCCESS, so move the logging
to be after the conversion.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
There's no longer a need to do this for every API call. This only exists
now for the pnp guid reuse workaround hack.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
IoAllocateMdl allocates a different size structure depending on the
bottom in-page bits of the address. By passing null, it assumes that the
address is aligned within the page, which it might not be. Fix this by
passing the eventual virtual address to the allocation function so that
the right amount is always allocated.
Reported-by: Oleksandr Muzychuk <oleksandr.muzychuk@apriorit.com>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Should NDIS version check fail the DriverEntry() bailed out without
releasing the TunDispatchSecurityDescriptor.
Signed-off-by: Simon Rozman <simon@rozman.si>
ROOT/NET/000X could have been claimed by a different driver, so we want
to double check.
Link: https://lists.zx2c4.com/pipermail/wireguard/2021-May/006716.html
Reported-by: Piotr Sobczak <piotrs@glosol.com>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
While it does make sense to make readers unblock by setting the read
event on teardown, this is something that consumers of the library
should do _before_ calling EndSession, not something that makes sense
for the library to do itself. The reason is that, in the hypothetical
case in which this makes sense, immediately after unblocking the reader
via SetEvent, the function goes on to free all of the memory that that
reader might want to use. So, rather, the proper shutdown flow is from
the application side, and looks like:
Closing = true;
SetEvent(WintunGetReadWaitEvent());
WaitForReadersToReturn();
WintunEndSession();
Alternatively, rather than using WaitForSingleObject on the read event,
consumers can WaitForMultipleObjects and include a shutdown event, which
is what the example code does.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Recent versions of Windows fail to tidy up, causing issues when reusing
GUIDs. Check to see if a GUID might be orphaned, and forcibly clear out
the registry state if so.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Otherwise we fail to remove the zombie adapter, and then the problem
repeats itself. Note that this is part of a larger issue of clearing out
bad GUIDs in NetSetup2 on recent Windows builds
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Wondering, why WinDbg is refusing to load symbols for wintun.sys
recently...
By default, building puts .pdb files to the output folder. Next to the
final binaries: wintun.sys, wintun.dll, example.exe... Wait?! But the
wintun.pdb from wintun.dll overwrites the wintun.pdb from wintun.sys
then.
Signed-off-by: Simon Rozman <simon@rozman.si>
The time stamping with Inf2Cat never makes the wintun output really "up-
to-date". This keeps triggering wintun project rebuilds over and over
again. Including all the projects depending on wintun.
Thou, the api project really depends on the driver built by wintun
project, those needless driver rebuilds are utterly annoying.
To be correct, the amd64 api project also depends on the arm64 api
project - a dependency which cannot be described using .sln. So, one way
or another, a developer must build projects inside the .sln in a
specific order.
Another solution would be to split the solution file (pun intended). One
.sln for driver, another for the api and example projects. Then open the
one the developer is focused on.
Signed-off-by: Simon Rozman <simon@rozman.si>
While the Wintun driver is typically released only at <major>.<minor>
milestones, the wintun.dll did see some intermediate releases.
To make MSI logic correctly decide to upgrade local wintun.dll file, the
version inscribed in wintun.dll file resources should increment in those
intermediate releases. MSI ignores file timestamps. One could use
REINSTALLMODE=emus Installer property to force copying wintun.dll when
its version doesn't change. But REINSTALLMODE applies to all files in
the MSI session and would be an additional requirement when authoring
MSI packages with wintun.dll.
Bumping only the final ZIP filename version is not sufficient.
Therefore, a <major>.<minor> or <major>.<minor>.<build> versioning is
introduced. Furthermore, we no longer distinguish between WintunVersion
and WintunVersionStr. All our releases used strictly numeric
<major>.<minor> notation, making WintunVersion and WintunVersionStr
always the same.
When the driver didn't change, just bump the version in wintun.proj and
run `msbuild wintun.proj /t:Zip` to rebuild the wintun.dll and make the
new ZIP file.
Signed-off-by: Simon Rozman <simon@rozman.si>
MinGW supplies all Windows header files using lowercase filenames.
This makes some of the #include lines in wintun.h fail to resolve the
.h files correctly on a case-sensitive filesystem.
Signed-off-by: Simon Rozman <simon@rozman.si>
The WintunEnumAdapters() requires namespace mutex. However,
NamespaceTakePoolMutex() works as SYSTEM user only.
WireGuard is using the WintunEnumAdapters() in its manager service to
cleanup stale adapters. As the WireGuard manager service is running as
SYSTEM, this requirement was not apparent before.
This commit also extends the example project to list its existing
adapters at start.
Signed-off-by: Simon Rozman <simon@rozman.si>
Log runtime information to quickly check whether the values are sane
when analyzing error logs sent in by users.
Signed-off-by: Simon Rozman <simon@rozman.si>
Some users are seeing errors like this after rebooting from Windows
Update:
2021-01-28 18:39:45.220197: [TUN] Creating Wintun interface
2021-01-28 18:39:49.420116: [TUN] [Wintun] CreateAdapter: Creating adapter
2021-01-28 18:39:53.704007: [TUN] [Wintun] OpenDeviceObject: Failed to connect to adapter: The system cannot find the path specified. (Code 0x00000003)
2021-01-28 18:39:53.704007: [TUN] [Wintun] WintunStartSession: Failed to open adapter device object
2021-01-28 18:39:54.097037: [TUN] Unable to create Wintun interface: Error starting session: The system cannot find the path specified.
It appears that creation of the device object file might happen
asynchronously, so this commit polls for it.
Reported-by: Artem Kuroptev <artem@kuroptev.com>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Prior, people making calls to LoadLibrary/FreeLibrary would experience
a failure to create or open adapters, because the private namespace was
already loaded into the process and not cleaned up on DLL detachment.
While this pattern is probably a misuse of the library, we should still
support cleaning that up. This commit makes the right calls to free the
boundary descriptor and close the private namespace. It does not,
however, destroy the private namespace using the flag on the second
parameter, in case of races with other processes.
Reported-by: Brad Spencer <bspencer@blackberry.com>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Windows 7 doesn't like our trick of sticking MDLs into the NBL context
area. So we do things more traditionally, by allocating an MDL with
IoAllocateMdl and freeing it with IoFreeMdl. This means that we have to
keep track of the MDL between allocation and free time, and we don't
have any more miniport reserved pointers left in the NBL. So instead we
walk the MdlChain field of the first NB, and free the one that has an
address living inside of the non-partial MDL.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Providing the DataOffset member of the NBL allocation function or
setting that member in the NB header indicates to NDIS not only that the
data starts at that offset, but that there's that amount of space
*available for it to use as it wants* before that offset. This meant
that NDIS was allowed to scribble data before the packet.
This was bounded by the size of the ring, so there was never any risk of
memory corruption, and since the ring is shared by userspace as well as
the rest of the kernel, we've always taken care of reading from it
closely, checking all values, and erroring out on corruption of the
ring. So, if NDIS wrote before the first packet, this would wind up
corrupting the RingTail and Alertable fields of the ring. The receiver
thread would then notice this, error out, and set the RingHead to
MAXULONG on its way out the door, so that userspace can detect it. And
indeed wintun.dll then started returning EOF from its write function.
Mostly this was not an issue, because we're not expecting for data to be
pushed on the head of a packet on ingress. But WSL2's Hyper-V driver is
actually pushing an ethernet header onto the front of the packet before
passing it off to Linux. Practically speaking, this manifested itself in
the RingTail and Alertable fields having Linux's MAC address! And then
the adapter would be EOF'd. This was reported as happening after WSL2
sends the *first* packet, but not others, which makes sense, because it
has to be at the beginning in order to corrupt those fields.
This fixes the problem by simply using a new MDL for the span we want,
instead of using the misunderstood DataOffset field. In order to not
need to keep track of memory allocations, we allocate the MDL as part of
the NBL's context area. And in order to avoid additional mappings, we
use IoBuildPartialMdl, which returns an MDL_PARTIAL, which does not have
an additional mapping that needs to be freed or unmapped.
After making this change, WSL2 no longer appears to halt the adapter,
and all works well.
Fixes: be8d2cb ("Avoid allocating second MDL")
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Otherwise the build fails at odd hours of the day.
Signed-off-by: Stefan Rinkes <stefan.rinkes@gmail.com>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
RtlGenRandom forwards to cryptbase.dll, which is not in KnownDlls.
Therefore it's not a good idea to link to advapi32.dll at link time. How
many other gotchas of unusual forwarded functions are there? I don't
really want to find out. Therefore, delay load everything else.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
