Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Home NTDEV

Before Posting...

Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


Win10 Build 14271 and Code Integrity Enforcement

Mark_RoddyMark_Roddy Member - All Emails Posts: 4,534
Perhaps I missed the discussion here but it appears that recent insider
builds of Win10 client have turned on signing enforcement.

Ugh.

Mark Roddy

Comments

  • Tom_McDermottTom_McDermott Member Posts: 57
    Build 14271 is an early release of Redstone 1. Microsoft has selected Windows 10 Redstone 1 release as the vehicle where they will begin enforcement of the previously announced Attestation policy, with a slight twist.

    If the Win10 RS1 target is an upgrade, it will accept any driver that already
    installs and loads correctly. ONLY if the RS1 installation is a new
    installation will non-Microsoft drivers be blocked if they were signed with a
    cert issued after July 29th, 2015.
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    I have Build [Version 10.0.14279] inside Virtualbox (VM) and it still works with my cross signed drivers that I just compiled today (3/4/16) and signed with a certificate that was issued 11/15? Not sure what that means, but it boots and the drivers pass.



    -----Original Message-----
    From: [email protected] [mailto:[email protected]] On Behalf Of [email protected]
    Sent: Friday, March 04, 2016 5:26 PM
    To: Windows System Software Devs Interest List
    Subject: RE:[ntdev] Win10 Build 14271 and Code Integrity Enforcement

    Build 14271 is an early release of Redstone 1. Microsoft has selected Windows 10 Redstone 1 release as the vehicle where they will begin enforcement of the previously announced Attestation policy, with a slight twist.

    If the Win10 RS1 target is an upgrade, it will accept any driver that already installs and loads correctly. ONLY if the RS1 installation is a new installation will non-Microsoft drivers be blocked if they were signed with a cert issued after July 29th, 2015.


    ---
    NTDEV is sponsored by OSR

    Visit the list online at: <http://www.osronline.com/showlists.cfm?list=ntdev&gt;

    MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
    Details at <http://www.osr.com/seminars&gt;

    To unsubscribe, visit the List Server section of OSR Online at <http://www.osronline.com/page.cfm?name=ListServer&gt;
  • Tom_McDermottTom_McDermott Member Posts: 57
    Tim, perhaps it is because earlier versions of the same drivers were already installed pre-Redstone, thus it considers not only the OS to be an upgrade, but also your pre-existing drivers to be just an upgrade, and bypasses the enforcement.

    Just a guess on my part. In any event, MSFT has managed to make an already confusing issue even more confusing.
  • Mike_BerhanMike_Berhan Member - All Emails Posts: 14
    <quote>If the Win10 RS1 target is an upgrade, it will accept any driver that
    already installs and loads correctly. ONLY if the RS1 installation is a new
    installation will non-Microsoft drivers be blocked if they were signed with
    a cert issued after July 29th, 2015.</quote>

    Is there an ISO available for a new installation? I can upgrade to build
    14279, but I would like to try a clean install. The Microsoft URL now
    redirects to the standard Windows 10 download:

    https://www.microsoft.com/en-us/software-download/windowsinsiderpreviewiso
  • Aleh_KazakevichAleh_Kazakevich Member Posts: 86
    > Mark Roddy wrote:
    >
    > Perhaps I missed the discussion here but it appears that recent insider
    > builds of Win10 client have turned on signing enforcement.

    Thanks for the information.
    Indeed, Windows 10 build 14279 cannot load cross-signed driver, error 577.
    But with my old certificate issued in the 2013 everything works fine.
    Tested on the Hyper-V Generation-2 with Secure Boot enabled.
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    Is there a clean ISO out there someplace? I have the latest and my cross signed drivers still load. But, I've just been upgrading it since Windows 7 in the VM. I don't have my drivers loaded as I use a clean copy and then test off copies loading the drivers. But, Windows has been upgraded never the less and it would be nice to have a clean build that demonstrates this behavior.

    -----Original Message-----
    From: [email protected] [mailto:[email protected]] On Behalf Of [email protected]
    Sent: Saturday, March 05, 2016 12:17 PM
    To: Windows System Software Devs Interest List
    Subject: RE:[ntdev] Win10 Build 14271 and Code Integrity Enforcement

    > Mark Roddy wrote:
    >
    > Perhaps I missed the discussion here but it appears that recent
    > insider builds of Win10 client have turned on signing enforcement.

    Thanks for the information.
    Indeed, Windows 10 build 14279 cannot load cross-signed driver, error 577.
    But with my old certificate issued in the 2013 everything works fine.
    Tested on the Hyper-V Generation-2 with Secure Boot enabled.

    ---
    NTDEV is sponsored by OSR

    Visit the list online at: <http://www.osronline.com/showlists.cfm?list=ntdev&gt;

    MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
    Details at <http://www.osr.com/seminars&gt;

    To unsubscribe, visit the List Server section of OSR Online at <http://www.osronline.com/page.cfm?name=ListServer&gt;
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,984
    <quote>
    Is there a clean ISO out there someplace?
    </quote>

    I don't know if this helps, but I'm not aware of a public ISO that's available for download from Microsoft for ANY Redstone build.

    What's MOST frustrating about this is the lack of clear and timely communication on this topic from Redmond. We have to figure this out as we go? C'mon boys... Can the PM who's making the calls on this not just... TWEET something? Put a couple of lines in a blog somewhere? Throw a web page up on SYSDEV? SOMEthing? Just imagine how much time, effort, and annoyance is being unnecessarily expended by community members world-wide trying to figure this out. Worse, it's not engendering good feelings for MSFT in the community.

    Last summer, James Murray was kind enough to offer up his valuable time to answer questions for us. That was outstanding, super helpful, and I was glad to be able to help with communications. But is that really how we all want to be handling communication on this important policy issue? (I smell a blog post borne of frustration percolating).

    Peter
    OSR
    @OSRDrivers

    Peter Viscarola
    OSR
    @OSRDrivers

  • Mark_RoddyMark_Roddy Member - All Emails Posts: 4,534
    New information from our testing indicates that signing enforcement is only
    enabled in secure boot mode. If secure boot is off whql/attestation-only is
    not being enforced, even on new installs. It would really be helpful if
    MSFT would clearly state what the policy is and when it is going be
    enforced.

    Mark Roddy

    On Sat, Mar 5, 2016 at 3:47 PM, wrote:

    >
    > Is there a clean ISO out there someplace?
    >
    >
    > I don't know if this helps, but I'm not aware of a public ISO that's
    > available for download from Microsoft for ANY Redstone build.
    >
    > What's MOST frustrating about this is the lack of clear and timely
    > communication on this topic from Redmond. We have to figure this out as we
    > go? C'mon boys... Can the PM who's making the calls on this not just...
    > TWEET something? Put a couple of lines in a blog somewhere? Throw a web
    > page up on SYSDEV? SOMEthing? Just imagine how much time, effort, and
    > annoyance is being unnecessarily expended by community members world-wide
    > trying to figure this out. Worse, it's not engendering good feelings for
    > MSFT in the community.
    >
    > Last summer, James Murray was kind enough to offer up his valuable time to
    > answer questions for us. That was outstanding, super helpful, and I was
    > glad to be able to help with communications. But is that really how we all
    > want to be handling communication on this important policy issue? (I smell
    > a blog post borne of frustration percolating).
    >
    > Peter
    > OSR
    > @OSRDrivers
    >
    > ---
    > NTDEV is sponsored by OSR
    >
    > Visit the list online at: <
    > http://www.osronline.com/showlists.cfm?list=ntdev&gt;
    >
    > MONTHLY seminars on crash dump analysis, WDF, Windows internals and
    > software drivers!
    > Details at
    >
    > To unsubscribe, visit the List Server section of OSR Online at <
    > http://www.osronline.com/page.cfm?name=ListServer&gt;
    >
  • Bo_BranténBo_Brantén Member Posts: 104
    On Mon, 7 Mar 2016, Mark Roddy wrote:

    > New information from our testing indicates that signing enforcement is only
    > enabled in secure boot mode. If secure boot is off whql/attestation-only is
    > not being enforced, even on new installs. It would really be helpful if
    > MSFT would clearly state what the policy is and when it is going be
    > enforced.

    That the new type of signing only is enforced when secure boot is turned
    on was mentioned by Microsoft Program Manager James Murray in the OSR Q&A
    with him in July 2015:
    https://www.osr.com/blog/2015/07/24/questions-answers-windows-10-driver-signing/

    Bo Branten
  • Gabe_JonesGabe_Jones Member Posts: 96
    To add my experiences: I updated to build 14279 on a Secure Boot-capable PC. I then went into the "Reset this PC" setting and told it to reset, preserving nothing, hoping that this is equivalent to a "new install." I installed one of our drivers that was signed in the traditional manner using our EV cert that was issued after Win 10 RTM. It failed to load with a Code 31. I then updated the driver to one that I had signed using the portal. It loaded successfully.
  • Gabe_JonesGabe_Jones Member Posts: 96
    Correction: Code 52, not code 31.
  • Tom_McDermottTom_McDermott Member Posts: 57
    <quote>
    I don't know if this helps, but I'm not aware of a public ISO that's available
    for download from Microsoft for ANY Redstone build.

    What's MOST frustrating about this is the lack of clear and timely communication
    on this topic from Redmond. We have to figure this out as we go? C'mon boys...
    Can the PM who's making the calls on this not just... TWEET something? Put a
    couple of lines in a blog somewhere? Throw a web page up on SYSDEV? SOMEthing?
    Just imagine how much time, effort, and annoyance is being unnecessarily
    expended by community members world-wide trying to figure this out. Worse, it's
    not engendering good feelings for MSFT in the community.
    </quote>

    Peter, I agree that the documentation of these signing policy issues has been at best horrible, and mostly nonexistent. The only reason I have any inkling of what's coming is that we happen to have an open support ticket with WDK Support. But the information that we do receive is never presented with any certainty, but is always "very fluid and subject to change". As to a clean installable build of Redstone, even the support group is claiming that they themselves are unable to get their hands on one to test this issue. Hard to believe, isn't it?
  • Mark_RoddyMark_Roddy Member - All Emails Posts: 4,534
    Great! perhaps one web page with ALL THE RULEZ instead of a mishmash of
    byzantium proportions would be a good idea?

    Mark Roddy

    On Mon, Mar 7, 2016 at 10:37 AM, Bo Branten wrote:

    > On Mon, 7 Mar 2016, Mark Roddy wrote:
    >
    > New information from our testing indicates that signing enforcement is only
    >> enabled in secure boot mode. If secure boot is off whql/attestation-only
    >> is
    >> not being enforced, even on new installs. It would really be helpful if
    >> MSFT would clearly state what the policy is and when it is going be
    >> enforced.
    >>
    >
    > That the new type of signing only is enforced when secure boot is turned
    > on was mentioned by Microsoft Program Manager James Murray in the OSR Q&A
    > with him in July 2015:
    > https://www.osr.com/blog/2015/07/24/questions-answers-windows-10-driver-signing/
    >
    > Bo Branten
    >
    >
    >
    > ---
    > NTDEV is sponsored by OSR
    >
    > Visit the list online at: <
    > http://www.osronline.com/showlists.cfm?list=ntdev&gt;
    >
    > MONTHLY seminars on crash dump analysis, WDF, Windows internals and
    > software drivers!
    > Details at
    >
    > To unsubscribe, visit the List Server section of OSR Online at <
    > http://www.osronline.com/page.cfm?name=ListServer&gt;
    >
  • Alan_Adams-2Alan_Adams-2 Member Posts: 46
    Bo Branten <[email protected]> wrote:

    > On Mon, 7 Mar 2016, Mark Roddy wrote:
    >
    > > New information from our testing indicates that signing enforcement is only
    > > enabled in secure boot mode. If secure boot is off whql/attestation-only is
    > > not being enforced, even on new installs. It would really be helpful if
    > > MSFT would clearly state what the policy is and when it is going be
    > > enforced.
    >
    > That the new type of signing only is enforced when secure boot is turned
    > on was mentioned by Microsoft Program Manager James Murray in the OSR Q&A
    > with him in July 2015:
    > https://www.osr.com/blog/2015/07/24/questions-answers-windows-10-driver-signing/

    So is the correct conclusion here that what's /actually/ changing in
    Build 14271 and later is that Secure Boot will be enabled by default,
    if the machine is Secure Boot capable? Or am I still missing a piece
    of that picture. Maybe that it applies to all editions rather than
    just Enterprise, or similar? Or applies to more drivers than just
    boot-mode drivers?

    Because isn't Secure Boot -- if enabled on a machine where the
    firmware supports it -- /always/ rejecting non-Microsoft-signed
    boot-mode drivers? Meaning it's "the point" of that feature, and true
    even if we were discussing Windows 8.1 instead of Windows 10? Meaning
    the fact that Secure Boot would do that is not what's new; the fact
    that Secure Boot applies is what's actually new?

    Alan Adams
    Client for Open Enterprise Server
    Micro Focus
    [email protected]
  • Bo_BranténBo_Brantén Member Posts: 104
    On Thu, 10 Mar 2016, Alan Adams wrote:

    >> https://www.osr.com/blog/2015/07/24/questions-answers-windows-10-driver-signing/

    > So is the correct conclusion here that what's /actually/ changing in
    > Build 14271 and later is that Secure Boot will be enabled by default,
    > if the machine is Secure Boot capable?

    To be more clear; if secure boot is enabled from the beginning is up to
    the manufaturer, what is new in build 14271 is that Microsoft does check
    if the driver is portal signed and not only cross signed, whoever this
    extended check is only done on systems that has secure boot enabled as
    was told in the OSR Q&A.


    Bo Branten
  • Alan_Adams-2Alan_Adams-2 Member Posts: 46
    Bo Branten <[email protected]> wrote:

    > On Thu, 10 Mar 2016, Alan Adams wrote:
    >
    > >> https://www.osr.com/blog/2015/07/24/questions-answers-windows-10-driver-signing/
    >
    > > So is the correct conclusion here that what's /actually/ changing in
    > > Build 14271 and later is that Secure Boot will be enabled by default,
    > > if the machine is Secure Boot capable?
    >
    > To be more clear; if secure boot is enabled from the beginning is up to
    > the manufaturer, what is new in build 14271 is that Microsoft does check
    > if the driver is portal signed and not only cross signed, whoever this
    > extended check is only done on systems that has secure boot enabled as
    > was told in the OSR Q&A.

    Thanks for the additional clarifications. That "cross-signed" had
    previously qualified (not just actual Microsoft-signed drivers) sounds
    like a significant point I was incorrect on as well.

    Alan Adams
    Client for Open Enterprise Server
    Micro Focus
    [email protected]
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. Sign in or register to get started.

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Writing WDF Drivers 12 September 2022 Live, Online
Internals & Software Drivers 23 October 2022 Live, Online
Kernel Debugging 14 November 2022 Live, Online
Developing Minifilters 5 December 2022 Live, Online