How to write a driver to prepare for device guard(memory integrity)?

We have a project that supports os over xp using vs 2005 and wdk 7600.
It worked normally on Windows 10 version (1709).
However, if memory integrity is turned on in Windows 10 device guard protection, some drivers fail to load.
Only drivers that add / INTEGRITYCHECK to the link option to use the PsSetCreateProcessNotifyRoutineEx API will fail to load.

When running the StartSevice API for loading, an error occurs with Error Code 87 (The parameter is incorrect).

  1. What should I do to successfully load this driver?
  2. Is it ok to load other drivers properly when memory integrity is turned on?
    (See the FAQs at https://blogs.msdn.microsoft.com/windows_hardware_certification/2015/05/22/driver-compatibility-with-device-guard-in-windows-10/.) If using standard settings with the old versions of the WDK and Visual Studio, and the INIT section is marked as RWX.

So to solve the problem, I want to rebuild with vs2017 and wdk 10 according to driver compatibility with Device Guard in windows 10.
(https://blogs.msdn.microsoft.com/windows_hardware_certification/2015/05/22/driver-compatibility-with-device-guard-in-windows-10/)

Without modifying the entire code, POOL_NX_OPTIN = 1 and ExInitializeDriverRuntime (DrvRtPoolNxOptIn) as described in the link below; And then loaded after the build
(https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/single-binary-opt-in-pool-nx-optin)
It failed with the same error code 87.

This driver is not loaded and can not be verified.
So there is no problem testing verifier (memory integrity) after building another driver with the above options.
So I do not think the build is wrong.

  1. How can I tell why the driver is not loaded (DriverEntry is not called)
  2. If the driver is successfully loaded, should we create two separate files for the driver for xp and the driver for windows 10?

Is your driver signed?

Do you have a kernel debugger connected and active?

Peter

Yes, My driver is signed.
Windbg is not connected, but debug mode is on.

I found a discussion with something similar to me.
https://community.osr.com/discussion/291104/asking-for-hints-to-get-some-kernel-output

Yes, My driver is signed.

HOW did you sign it? You ATTESTATION signed it via the Microsoft Dashboard, right? Not just “I signed it with my own certificate?”

I found a discussion with something similar to me.

Well, no? Mr. Leggieri’s problem was that he wasn’t using the /INTEGRITYCHECK switch. But you are.

Peter

Device guard is not the same as using the /INTEGRITYCHECK switch. To use the linker switch you need to follow the 64 bit signing requirement. This signing requirement is also required for 32 bit drivers that use this switch. ATTESTATION signing is not required.

Bill Wandel

ATTESTATION signing is not required

ATTESTATION signing is indeed required for the OP to load the driver on Windows 10, if the system has Secure Boot enabled… right? No knowing what the OP’s system has setup, right?

Peter

Peter_Viscarola_(OSR) wrote:

> ATTESTATION signing is not required
ATTESTATION signing is indeed required for the OP to load the driver on Windows 10, if the system has Secure Boot enabled… right? No knowing what the OP’s system has setup, right?

This is actually a very important point on which I’m not 100% clear.  Is
the attestation signing check done at INSTALL time, or is it done at
LOAD time?  If that check is done at LOAD time, then you’re absolutely
correct.  But if it is done at INSTALL time, as was my possibly mistaken
impression, then filter drivers would not require attestation – only
cross-signing.

OP: Let’s eliminate standard driver signing as your issue. Please hook up and active the debugger and try to load your driver.

If it works, its a conventional signing issue. If it doesn’t work, something else is wrong, but be sure, please, 50thst the debugger is actually attached and active.

Peter

HOW did you sign it? You ATTESTATION signed it via the Microsoft Dashboard, right? Not just “I signed it with my own certificate?”

Yes, I signed itvia the Microsoft Dashboard.

Well, no? Mr. Leggieri’s problem was that he wasn’t using the /INTEGRITYCHECK switch. But you are.

Oh! You are right! This is the opposite of my case.

In my case, I removed the /INTEGRITYCHECK switch and the driver I built was successfully loaded.
(However, I did not confirmed that the PsSetCreateProcessNotifyRoutineEx API was called successfully.)

If you don’t link with /INTEGRITYCHECK PsSetCreateNotifyRoutineEx will return ACCESS_DENIED.

Bill Wandel

Interesting question. I might be able to test later this week if I can load a file mini-filter on secure boot without it being attestation signed. All our drivers get attestation signed so this situation never comes up.

Bill Wandel

Agreed but Secure Boot and the integrity setting are not related to each other. Secure Boot requires attestation signing where just setting /INTEGRITY does not.

Bill Wandel

Secure Boot requires attestation signing where just setting /INTEGRITY does not.

Agreed. But the OP can’t load his driver…

In my case, I removed the /INTEGRITYCHECK switch and the driver I built was successfully loaded.

Soooo… It’s been signed, it’s even been atteststion signed. It loads without /INTEGEITYCHECK but not with it.

I have no clue. Seriously. That’s very puzzling.

Peter

I’m sorry. I do not know the terms. Does the term OP refer to me in context? :frowning:
I will understand that.

Let’s eliminate standard driver signing as your issue. Please hook up and active the debugger and try to load your driver.

Does it mean to try to debug the kernel with windbg without any signatures and see if it loads?

If you don’t link with /INTEGRITYCHECK PsSetCreateNotifyRoutineEx will return ACCESS_DENIED.

I think so.

Does the term OP refer to me

Sorry! Yes… “Original Poster” Google is your friend: Abbreviation OP

Does it mean to try to debug the kernel …

Yes. Enable debugging, hookup WinDbg and make sure it’s actively connected… and then load your driver. Signature enforcement is disabled when you have a debugger actively attached.

I’m trying to determine if you’re getting an ordinary signature enforcement problem, or something else.

Peter

I wrote a Dummy Driver (with only DriverEntry and unload functions).
One to build with / INTEGRITYCHECK and the other to build without / INTEGRITYCHECK.
So I tried to load it with osrloader.exe.

  1. Failing to load any unsigned driver with a message that both signs are wrong
  2. When loading after double signing (not ms sign, not EV) with sha1, sha2, the driver built with / INTEGRITYCHECK failed to load and the driver built without / INTEGRITY succeeded.

Does this mean / INTEGRITYCHECK has an impact on the driver’s load?

MS Blog site links are all broken.
So I reattach the link below.
For reference, the link below shows that the driver built with VS2005 and WDK 6000 should be compatible. If not, should this be confirmed by MS?

FYI.
What about existing drivers? Do I need to re-build these drivers to get them to work with Windows 10?

It depends. Many drivers are already compatible. If you are using the WDK and Visual Studio, the INIT section is marked as RWX. In Windows 10, however, it will automatically be stripped, so if this is the only issue, then the driver will be compatible.

https://docs.microsoft.com/en-us/windows-hardware/test/hlk/testref/driver-compatibility-with-device-guard

The result is the same with a SHA2 (EV) signed driver.
Error is 87(0x57) The parameter is Incorrect.

/INTEGRITYCHECK has to have an impact on driver loading. That is its purpose. I don’t know which cert it checks but it looks like it checks the MS cross cert.
All our drivers are signed with the MS cross cert. Our release drivers are also portal signed. They load on all OSes including those with secure boot enabled.

Bill Wandel