Device Gaurd Windwows 10

Hi,

I have some question related Device Gaurd.

For device gaurd Windows 10 has the following test.

DeviceGaurd DriverCompatibility test in WLK which required to be passed to
get the WHQL certification.

what about the driver signed by using Attestation signing , so if i have a
driver which is non pnp and attestation signed will it work in device gaurd
configured environment.
(SafeBoot on + 64 bit+ devicegaurd enabled) ?

Or WHQL is must for device gaurd environment?

Rahul Kumar wrote:

I have some question related Device Gaurd.

For device gaurd Windows 10 has the following test.

DeviceGaurd DriverCompatibility test in WLK which required to be
passed to get the WHQL certification.

what about the driver signed by using Attestation signing , so if i
have a driver which is non pnp and attestation signed will it work in
device gaurd configured environment.

It’s configurable. There is a Device Guard rule to require a WHQL
signature. If that rule is enabled, then attestation signing is not enough.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

@Tim is referring to configurable code integrity. What must be understood is that for drivers, the driver must first pass “regular” code integrity check before it is passed on to the configurable code integrity check, if such is enabled. If HVCI is enabled as part of Device Guard, then HVCI is what the driver must pass, whether it has an Attestation signature or a WHQL signature.

Thanks for replying!

I understand that its configurable and is applicable For x64 system only
with secure boot enabled and by using the following tools/test we can make
sure that our driver is compatible.

  1. Use Driver Verifier with the new Code Integrity compatibility checks
    enabled
  2. Test the driver on a system with virtualization-based isolation of Code
    Integrity enabled.
  3. Run the HyperVisor Code Integrity Readiness Test
    https:
    in
    the Windows HLK.
    4. Use the Device Guard Readiness Tool
    https:
    .

    My question is for attestation signing MS do not need any .hlk logs , how
    Microsoft will make sure that our driver has passed the HVCI test unless
    its WHQL?
    will they run anything on the submitted Attestation package to check
    whether it support HVCI?

    Actually we do not want WHQL signing so if after making our driver
    compatible to HVCI we just do attestation signing will that be enough to
    run on Device Gaurd enabled system?

    Or Device Gaurd enabled system will run only driver those are WHQL signed?

    On Sat, Feb 25, 2017 at 1:02 AM, wrote:

    > @Tim is referring to configurable code integrity. What must be understood
    > is that for drivers, the driver must first pass “regular” code integrity
    > check before it is passed on to the configurable code integrity check, if
    > such is enabled. If HVCI is enabled as part of Device Guard, then HVCI is
    > what the driver must pass, whether it has an Attestation signature or a
    > WHQL signature.
    >
    > —
    > NTDEV is sponsored by OSR
    >
    > Visit the list online at: http:> showlists.cfm?list=ntdev>
    >
    > MONTHLY seminars on crash dump analysis, WDF, Windows internals and
    > software drivers!
    > Details at http:
    >
    > To unsubscribe, visit the List Server section of OSR Online at <
    > http://www.osronline.com/page.cfm?name=ListServer&gt;
    ></http:></http:></https:></https:>

Rahul Kumar wrote:

Actually we do not want WHQL signing so if after making our driver
compatible to HVCI we just do attestation signing will that be
enough to run on Device Gaurd enabled system? Or Device Gaurd
enabled system will run only driver those are WHQL signed?

Device Guard may be configured to block any drivers and applications
that are not in a white list, even if they have WHQL signatures.
So, it depends. See the message #2 from Tim Roberts:

“It’s configurable. There is a Device Guard rule to require a WHQL signature.
If that rule is enabled, then attestation signing is not enough”.

In my opinion, the main compatibility problem is the HVCI, not
Device Guard, because HVCI changes a behavior of the Windows kernel.
Some functions works differently in HVCI mode.

To be sure that your driver is 100% compatible with HVCI you need a
real or virtual computer configured appropriately. The Driver Verifier
is a great tool, but it unable to detect some problems related to HVCI
(for example, modifying of a CR0 register).

They don’t run any tests, and they don’t know. Thy just sign the submission.

Basically, you “attest” (that is “certify formally”) that the driver works, and if it doesn’t work, you “attest” that you’ll fix it.

That is all.

Peter
OSR
@OSRDrivers