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

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

DriverSigning Selection of Windows Versions?

David_F.David_F. Posts: 161
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!!

Comments

  • R0b0t1R0b0t1 Posts: 130
    On Tue, Jun 12, 2018 at 1:36 PM, xxxxx@terabyteunlimited.com
    <xxxxx@lists.osr.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.
  • Tim_RobertsTim_Roberts Posts: 12,615
    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.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • David_F.David_F. Posts: 161
    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.
  • <quote>
    choose to sign for TH2, then does that mean the
    signature will be good to to that version and the newer ones
    </quote>

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

    Peter
    OSR
    @OSRDrivers

    Peter Viscarola
    OSR
    @OSRDrivers

  • Alan_Adams-2Alan_Adams-2 Posts: 46
    > ...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 <xxxxx@lists.osr.com> On Behalf Of Alan Adams <xxxxx@novell.com>
    Sent: Wednesday, June 13, 2018 10:53 AM
    To: Windows System Software Devs Interest List <xxxxx@lists.osr.com>
    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://www.osronline.com/showlists.cfm?list=ntdev>;

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

    To unsubscribe, visit the List Server section of OSR Online at <http://www.osronline.com/page.cfm?name=ListServer>;
  • Tim_RobertsTim_Roberts Posts: 12,615
    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.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!