Never do anything in a driver that can be done just as well in an application. It just adds unnecessary complexity and endangers system stability. Why do you want this in UMDF? Where are you going to load the driver?

How did you open the file? Are you opening it as a HID device? You're really making it very hard to help you, because we have to pull each piece of information one bit at a time.

What policies are you changing? It is not the job of the driver writer to change the policies of the client computer. Perhaps you need to use a real installer, so you can get permission.

This is probably expected behaviour. IIRC nslookup created DNS UDP packets in UM and sends them out onto the network directly. This sort of traffic is exactly what WFP is designed to handle

But curl.exe probably uses getaddrinfo, GetNameInfo or other Winsock functions to resolve the hostname into an IP address. This will not produce UDP traffic directly, but instead rely on the DNS resolver. The DNS resolver returns most of its answers from cached data, but for domains that are not yet known, will send out UDP DNS queries. These queries can't be directly attributed to a single UM process like curl.exe as you have discovered. These queries are also vital for proper system function and are likely protected from tampering as much as possible. DNS is vital to find things like domain controllers, network time etc. and DNS poisoning is a well known attack

(moving to NTDEV where this belongs)

Select the disk for testing. There aren't specific tests for upper-filter drivers.

Peter

when the IOCTL is completed by the handler using WdfRequestComplete, do I need to explicitly set the event in order to signal the waiting thread, or will the user mode thread be automatically signalled once IOCTL is complete

The event will automatically be signaled. You do not have to do anything other than completing the I/O Request.

It seems unlikely that the memory really does need to be 'cleaned' after use.

From a security point of view, all of these 'services' that can use this area must run either on the card itself, or in ring 0 on the host side. either location can arbitrarily read or corrupt data that is is not supposed to read or write to.

From a correctness point of view, each one of these services that can use this area must have some way of indicating 'this resource is mine now and don't touch it'. That should prevent reading partially written or corrupted data. It doesn't really matter if your protocol has fixed size structures, delimited ones, null terminated or polka dotted and striped ones - initializing the unused bytes to zero does not help and costs extra memory writes

We found the cause. The problem was in code signing.
Signing with signtool.exe was successful when I used the / nph option without using the / ph option.
See the link below for more details.

https://support.microsoft.com/en-us/help/3194715/bugcheck-0x7e-occurs-in-windows-10-when-device-guard-is-active

In addition, we had a project that used RtlVer.lib and we could not load it, but we did not use RtlVer.lib so we did not have any problems.

Has anyone had any issues recently with the attestation "new hardware submission" portal? The submit button is staying greyed after uploading the .cab file and selecting as, Peter, said "all of the checkboxes." The file is uploaded and the "Package acceptance" stage icon goes yellow, then returns to blue but all of the checkboxes are available for selection and the "submit" button is never enabled. Am I correct in thinking that the cab file must at least look semi-correct for the checkboxes to be enabled? Also, the cab file is signed with the same EV cert that worked perfectly 2 weeks ago, and its not expired.

Sorry if this is not a kernel issue, per se, but it is (unfortunately) driver-related.

Thanks.