DriverSigning Selection of Windows Versions?

Hi,

While the authority on the subject are here, there is another issue that has confused me lately (I may have asked in the past). When you submit for signing, you have the option to sign for various windows versions. 1607, RS2, RS3, RS4, etc… (I don’t even know what is meant by the RSx version, but know it works on all the latest windows versions and insider preview versions, looking it up looks like a new naming style for the various releases), but the question is, do you have to check the box for all the OS versions for the driver to work on on those versions or can you say select the lowest supported version and that works on all the newer versions?

TIA!!

On Tue, Jun 12, 2018 at 1:36 PM, xxxxx@terabyteunlimited.com
wrote:
> Hi,
>
> While the authority on the subject are here, there is another issue that has confused me lately (I may have asked in the past). When you submit for signing, you have the option to sign for various windows versions. 1607, RS2, RS3, RS4, etc… (I don’t even know what is meant by the RSx version, but know it works on all the latest windows versions and insider preview versions, looking it up looks like a new naming style for the various releases), but the question is, do you have to check the box for all the OS versions for the driver to work on on those versions or can you say select the lowest supported version and that works on all the newer versions?
>

A past response indicated the driver would be brought forward properly
if you only checked the oldest version, at least for Windows 10.
Someone might be able to provide a citation or the behavior of other
releases.

xxxxx@terabyteunlimited.com wrote:

When you submit for signing, you have the option to sign for various windows versions. 1607, RS2, RS3, RS4, etc… (I don’t even know what is meant by the RSx version,

The first release of Windows 10 was codenamed Threshold.  You saw that
referred to in internal documents as TH.  The first update was TH2.

The first big refresh of Windows 10 was codenamed RedStone.  Its
releases were RS1, RS2, etc.

There does seem to be a bit of schizophrenia in terms of version
naming.  We used to have service packs and build numbers; now we have
codenames, marketing names (“Creator’s Update”), builds, and date codes.


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

Okay that’s good info, but if I choose to sign for TH2, then does that mean the signature will be good to to that version and the newer ones? The first response seems to recall that, was just looking for clarification.

I believe so. But, why not do what WE do… select them all. Collect the whole set!

Peter
OSR
@OSRDrivers

> …if I choose to sign for TH2, then does that mean the signature

will be good to to that version and the newer ones?

The only known effect that I’m aware of is the OS attribute that gets
created in the .CAT file, which Windows will use to declare whether
the .CAT file is suitable for installation on the running version of
Windows.

For example on a .CAT signed during RS3 release time frame with all
available platforms selected, the .CAT ended up with an OS attribute
of “_v100, _v100_X64, _v100_RS1, _v100_X64_RS1, _v100_RS2,
_v100_X64_RS2, _v100_RS3, _v100_X64_RS3”.

My empirical test was to sign one of our product builds by selecting
only the TH1 1507 platform (OS = “_v100, _v100_X64”), and then
attempting to install the signed product on the then-current RS3
platform. This worked, as expected.

By “as expected” I mean that I expect any version of Windows 10 to
accept a Microsoft-signed driver even if it was only signed and
OS-attributed for a Windows 8.1 or earlier platform; let alone simply
an earlier version of Windows 10 itself. Backwards compatibility
demands that this be true where ever possible.

Neither the HLK process nor the attested signing process require that
we “re-sign and re-publish our drivers every time a new Windows 10
platform is released.” Hence the expectation that signing with only
the oldest TH1 1507 platform would be accepted for all subsequent
platforms, too. Because at some point in the past, TH1 was the only
platform we even COULD select during attested signing, and those
drivers are still able to be installed and used on today’s platforms.

I’m not aware of any compelling reason NOT to select all platforms
you’re compatible with, similar to what Peter recommended. But at
least in my software-only non-PnP driver case, there is no known
benefit to selecting anything other than the oldest platform, either.

Alan Adams
Client for Open Enterprise Server
Micro Focus
xxxxx@microfocus.com

Correct me if I am wrong…

The idea of selecting supported versions is that Windows will automatically ‘adapt’ to a down-level driver. Thus, if you say you are compatible with RS2, for instance, a newer version of Windows will ensure that your driver doesn’t see anything that is new in RS3, for example, that might break it.

This is certainly the way it happens with manifests on user mode programs.

* Bob

? Bob Ammerman
? xxxxx@ramsystems.biz
? 716.864.8337

138 Liston St
Buffalo, NY 14223
www.ramsystems.biz

-----Original Message-----
From: xxxxx@lists.osr.com On Behalf Of Alan Adams
Sent: Wednesday, June 13, 2018 10:53 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] DriverSigning Selection of Windows Versions?

> …if I choose to sign for TH2, then does that mean the signature will
> be good to to that version and the newer ones?

The only known effect that I’m aware of is the OS attribute that gets created in the .CAT file, which Windows will use to declare whether the .CAT file is suitable for installation on the running version of Windows.

For example on a .CAT signed during RS3 release time frame with all available platforms selected, the .CAT ended up with an OS attribute of “_v100, _v100_X64, _v100_RS1, _v100_X64_RS1, _v100_RS2, _v100_X64_RS2, _v100_RS3, _v100_X64_RS3”.

My empirical test was to sign one of our product builds by selecting only the TH1 1507 platform (OS = “_v100, _v100_X64”), and then attempting to install the signed product on the then-current RS3 platform. This worked, as expected.

By “as expected” I mean that I expect any version of Windows 10 to accept a Microsoft-signed driver even if it was only signed and OS-attributed for a Windows 8.1 or earlier platform; let alone simply an earlier version of Windows 10 itself. Backwards compatibility demands that this be true where ever possible.

Neither the HLK process nor the attested signing process require that we “re-sign and re-publish our drivers every time a new Windows 10 platform is released.” Hence the expectation that signing with only the oldest TH1 1507 platform would be accepted for all subsequent platforms, too. Because at some point in the past, TH1 was the only platform we even COULD select during attested signing, and those drivers are still able to be installed and used on today’s platforms.

I’m not aware of any compelling reason NOT to select all platforms you’re compatible with, similar to what Peter recommended. But at least in my software-only non-PnP driver case, there is no known benefit to selecting anything other than the oldest platform, either.

Alan Adams
Client for Open Enterprise Server
Micro Focus
xxxxx@microfocus.com


NTDEV is sponsored by OSR

Visit the list online at: http:

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:</http:></http:></http:>

xxxxx@ramsystems.biz wrote:

The idea of selecting supported versions is that Windows will automatically ‘adapt’ to a down-level driver. Thus, if you say you are compatible with RS2, for instance, a newer version of Windows will ensure that your driver doesn’t see anything that is new in RS3, for example, that might break it.

Nope, it doesn’t work that way in the kernel.  The CAT file is used when
the driver is installed – you’ll get a warning that "this driver is not
compatible with this version of Windows – but after the driver is
installed, the CAT file is never used again.  It stays in the driver
store, and is not part of driver loading.

What that means is that the kernel has an enormously painful burden to
maintain backward compatibility.  The RS3 kernel simply cannot introduce
any service changes that break XP drivers.  It can introduce NEW
services, and the CAT file will insure that a driver that needs those
new services won’t install on a system that doesn’t have them, but it
can’t break existing services.


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