Win10 Build 14271 and Code Integrity Enforcement

Mark_Roddy

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

Ugh.

Mark Roddy

Tom_McDermott

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_User

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_McDermott

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_Berhan

<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_Kazakevich

> 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_User

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)

<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

Mark_Roddy

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én

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_Jones

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_Jones

Correction: Code 52, not code 31.

Tom_McDermott

<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_Roddy

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-2

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én

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-2

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]