Re[3]: X64 Windows Vista to require signed drivers

Huh ?

How come I dont have that right ? So I cant decide what to install on my
machine as SW ? You dont use illegal SW.

----- Original Message -----
From: “Ray Trent”
Newsgroups: ntdev
To: “Windows System Software Devs Interest List”
Sent: Wednesday, January 25, 2006 8:45 PM
Subject: Re:[ntdev] X64 Windows Vista to require signed drivers

> Dan Partelly wrote:
>> You forget one thing: the USER right to install anything he wants on
>> the computer and the OS.
>
> Sounds good in theory, but in practice you’ve never had that right in the
> first place. There are numerous cases of illegal software, as well as
> cases where license agreements disallow parties to install various things
> on various machines.
> –
> Ray
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@rdsor.ro
> To unsubscribe send a blank email to xxxxx@lists.osr.com

I don’t think that “signed” is the primary contention here. One of the
biggest beefs is that we have to go to Verisign to get the certificate,
and that is being changed to “corporate” which could influence tax status
in a given US state, possibly other countries as well. Limiting the
certificate vendor to one entity is a bit on the foolish side of things.
Great for Verisign though, but should Verisign go belly up??? And don’t
say won’t happen. Ever heard of Pan AM? Or Enron?

Gary G. Little

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@congruent.com
Sent: Wednesday, January 25, 2006 12:33 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] X64 Windows Vista to require signed drivers

So, how should Microsoft change their policy?

Is it ok to require signing as long as other signing authorities besides
Verisign are allowable?

If signed drivers are optional, can any functionality be contingent only
using signed drivers? What about support tied to signed drivers?

-----Original Message-----
From: Roddy, Mark [mailto:xxxxx@stratus.com]
Sent: Wednesday, January 25, 2006 7:45 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] X64 Windows Vista to require signed drivers

As soon as somebody connected DRM to Vista signing policy it became
clear to me that this is a done deal. The misnamed ‘wired home’, meaning
control over the licensed media stream into everybody’s
home/car/earplug, is where the money is, and the fate of lowly driver
developers and low box-count specialized platforms is not going to cause
anyone with decision making power in Redmond to lose sleep.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Wednesday, January 25, 2006 10:25 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] X64 Windows Vista to require signed drivers

Wow! It even beat the rootkit thread?

Don’t you OSR folks have some influence in Redmond? Can you start a
dialog with them about this? It clearly affects a large part of the
driver developing community (and consumers in the long run, but they
won’t know it until it’s too late to do anything about it except maybe
switch to Linux)

Beverly

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Tuesday, January 24, 2006 6:30 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] X64 Windows Vista to require signed drivers

And with that, ladies and gentlemen, this thread becomes tied with the
discussion about ddkbuild.bat for the most replies to any thread in past
year.

This reply makes 66 replies total, plus the original post, thereby
putting it in the lead. I’m not sure I can stand the excitement.

Peter
OSR


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: bbrown@mc.com To unsubscribe
send a blank email to xxxxx@lists.osr.com


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@seagate.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

The problem is not the concept. It is the implentation.

  1. The requirement for using only one certificate authority (can you say
    “monopoly” or “anti-trust”?) has been discussed as a major problem for
    some.

  2. The fact that an independent developer cannot get a certificate is
    another. It could put those developers out of business. (And some of
    them are very skilled driver developers - well-known and well-respected
    in the community)

  3. The fact that there is no automated way to get around this policy so
    that automated tests will work is a MAJOR problem. My company is not
    prepared to pay a lab monkey to sit and hit the F8 key every time the
    system reboots as part of an overnight automated test in order for the
    driver under test to be loaded.

  4. Why target 64-bit vista with this policy? Driver availability is
    already a problem that is getting in the way of widespread adoption of
    the 64-bit platform. Why make that process any harder?

  5. What about the learning process - people offering driver-development
    classes with hands-on labs? Will those training companies need to allow
    their students to use their PIC to sign the drivers they develop in
    class? Or how about people who simply want to learn Windows driver
    development as a marketable skill?

  6. Shouldn’t the administrator of a system have ultimate control over
    whether they want to allow an unsigned driver onto the system? With UAP
    in vista? Sometimes a small in-house driver is required for the purposes
    of testing other things (hardware diagnostics comes to mind). Why should
    that type of driver need a signature?

  7. As someone else mentioned there are small vertical markets that will
    be greatly impacted by this as well. Customers in this market space
    don’t require a signed driver. They can only get the driver from one
    place so they know who it came from. Perhaps the concept of “small
    vertical market” makes you think “not much money will be lost there if
    they switch to a different platform”. Have you thought about the sum
    total of all such markets? I bet that would be significant.

Beverly

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Henry Gabryjelski
Sent: Wednesday, January 25, 2006 12:13 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] X64 Windows Vista to require signed drivers

(Disclaimer: I have no internal knowledge of this, and all opinions
below are strictly my own and not necessarily Microsoft’s.)

Has anyone considered that malware, spyware, and rootkits are
increasingly loading in the kernel and becoming harder to detect? No
more kernel-based rootkits that aren’t trackable back to a corporation?
It just seems to me that having all kernel-mode bits signed seems like
it could greatly reduce this attack vector.

I’m just surprised this hasn’t come up already on the discussions.

.

-----Original Message-----
From: Roddy, Mark [mailto:xxxxx@stratus.com]
Sent: Tuesday, January 24, 2006 7:46 AM
Subject: RE: X64 Windows Vista to require signed drivers

Microsoft, along with everybody else in the consumer computer industry,
is focused on replacing that thing on top of your tv with something that
they build/manage that streams content into your home that is licensed
and generates revenue. Lots of revenue. From this discussion it is clear
that the downside of this is that other uses of their OS, from general
purpose server systems to various forms of low box count specialized
systems are going to lose out when decisions are made and there are
conflicting goals.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Tuesday, January 24, 2006 9:52 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] X64 Windows Vista to require signed drivers

This paragraph from the document sure does seem to support that:

“* Drivers must be signed for devices that stream protected
content. This includes audio drivers that use Protected User Mode Audio
(PUMA) and Protected Audio Path (PAP), and video device drivers that
handle protected video path-output protection management (PVP-OPM)
commands.”

As soon as I read that, I thought “So that’s the reason they’re doing
this.” I hate DRM. It protects a few media publishers and side effects
of things that get put in place to support DRM cripple everybody else -
ultimatley giving the consumer fewer choices which will lead to less
quality in the long run.

It seems to me that they could make this a requirement for only those
devices, though. Leave the rest of us alone.

Beverly

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tony Mason
Sent: Tuesday, January 24, 2006 9:13 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] X64 Windows Vista to require signed drivers

Someone pointed out to me yesterday (in an offline conversation) that
the real issue here is NOT related to drivers, but rather to DRM.
Microsoft has to lock down the set of certificates in order to implement
their strong DRM policy (otherwise, you could add your own certs and use
them to bypass the DRM apparently.) I’m not certain if that’s correct,
but the person who said this to me is reliable - and it makes a certain
type of sense. It explains why they won’t use just any root cert (which
certainly doesn’t matter for drivers, but doe matter for DRM).

I’m sure the folks at Microsoft did speak to their customers to
determine the impact this would have. After all, it is difficult to
imagine that one could make such a fundamental decision like this
without consulting with key customers (imagine the sheer embarrassment
factor if you need to recant after taking a strong policy position such
as this one.) So, while it will be inconvenient for us, they have
apparently determined that this is an acceptable cost (and if you don’t
like it, please refer to “Figure 1” :wink: )

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Peter G. Viscarola
Sent: Monday, January 23, 2006 2:29 PM
To: ntdev redirect
Subject: RE:[ntdev] X64 Windows Vista to require signed drivers

I think the point about special-purpose drivers that are used in-house
or by third party companies in very specific markets is a good one.

There are TONS of these drivers, and requiring them to be signed is
nothing but a DISincentive for people to move to 64-bit Windows.

Sigh… I’m glad Microsoft is thinking about issues of driver security
and reliability, but I really wish they would enter into a dialog with
the community about these policies before mandating them. I dare say
that even THEY can’t think of every consequence of every proposed
policy.

Peter
OSR


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@osr.com To unsubscribe
send a blank email to xxxxx@lists.osr.com


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com


I, personally, think it’s a huge mistake for Microsoft to not come up with some way to allow standard Authenticode-signed drivers (signable with the DDK and requiring the cert to be installed) to be installed on Vista64. There’s no particularly good excuse for not allowing this.

[/quote]



I don’t think that “signed” is the primary contention here.

[/quote]


PRECISELY!

As far as I can tell, the issues that most people are objecting too (myself included) are:

1) Signing that requires ONE SPECIFIC Root Certification Authority, with no authenticode-like equivalent.

2) Apparently no option at all for turning off the signing requirement, either on a per-system or a per-driver basis.

Like I said, so many messages ago: Signing driver packages is a good thing. It ensures (a) the creator of the driver package is who they claim to be, and (b) that the driver package has not been modified someplace between the creator and the end-user. These are both valuable, and long over due.

But no possible bypass? AT ALL? Bad idea.

Finally, I caution folks not to jump to too many conclusions based on a single paper published on WHDC. This paper is lacking in detail, and was almost certainly not written from the perspective of a developer. For example, the exception that mentions “a kernel debugger attached” might mean specifically that, or (much more likely, it seems to me) it might mean a system “started with debugging enabled, whether or not a debugger is actually attached.”

I do know for a fact that folks at Microsoft are pulling-together more information for the community, based on the feedback in this forum. I do know know when we can expect to see that information, however.

Peter
OSR

Your post and Peter’s most recent one sum it up nicely. However, there are a
few more issue that needs to be brought up concerning driver install in
general… :frowning:

The current Windows driver installation mechanism disables some essential OS
functionality for unsigned drivers. In particular (at least for unsigned
NDIS IM drivers), unsigned drivers cannot be updated without uninstalling
and re-installing the driver. The unsigned driver’s version and timestamp is
ignored. In addtion, the NDIS NotifyObject (something like a co-installer)
is not called systematically when new adapters are installed.

IOW, if your driver isn’t signed, it doesn’t work correctly.

The advice is always “Get It Signed, Stupid!”.

But…

I have to deliver it tomorrow!!!

An unsigned driver SHOULD work correctly if the Administrator allowed it to
be installed. It should be treated no differently than a signed driver after
this decision is made.

I also feel that whatever the policy, it should probably apply to both
32-bit and 64-bit Windows versions. It seems silly to make a
differentiation.

Thomas F. Divine, Windows DDK MVP

P.S. I sure wish they would fix XP’s unsigned driver behavior while they are
thinking about it…

Thos

“Brown, Beverly” wrote in message news:xxxxx@ntdev…
The problem is not the concept. It is the implentation.

1. The requirement for using only one certificate authority (can you say
“monopoly” or “anti-trust”?) has been discussed as a major problem for
some.

2. The fact that an independent developer cannot get a certificate is
another. It could put those developers out of business. (And some of
them are very skilled driver developers - well-known and well-respected
in the community)

3. The fact that there is no automated way to get around this policy so
that automated tests will work is a MAJOR problem. My company is not
prepared to pay a lab monkey to sit and hit the F8 key every time the
system reboots as part of an overnight automated test in order for the
driver under test to be loaded.

4. Why target 64-bit vista with this policy? Driver availability is
already a problem that is getting in the way of widespread adoption of
the 64-bit platform. Why make that process any harder?

5. What about the learning process - people offering driver-development
classes with hands-on labs? Will those training companies need to allow
their students to use their PIC to sign the drivers they develop in
class? Or how about people who simply want to learn Windows driver
development as a marketable skill?

6. Shouldn’t the administrator of a system have ultimate control over
whether they want to allow an unsigned driver onto the system? With UAP
in vista? Sometimes a small in-house driver is required for the purposes
of testing other things (hardware diagnostics comes to mind). Why should
that type of driver need a signature?

7. As someone else mentioned there are small vertical markets that will
be greatly impacted by this as well. Customers in this market space
don’t require a signed driver. They can only get the driver from one
place so they know who it came from. Perhaps the concept of “small
vertical market” makes you think “not much money will be lost there if
they switch to a different platform”. Have you thought about the sum
total of all such markets? I bet that would be significant.

Beverly

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Henry Gabryjelski
Sent: Wednesday, January 25, 2006 12:13 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] X64 Windows Vista to require signed drivers

(Disclaimer: I have no internal knowledge of this, and all opinions
below are strictly my own and not necessarily Microsoft’s.)

Has anyone considered that malware, spyware, and rootkits are
increasingly loading in the kernel and becoming harder to detect? No
more kernel-based rootkits that aren’t trackable back to a corporation?
It just seems to me that having all kernel-mode bits signed seems like
it could greatly reduce this attack vector.

I’m just surprised this hasn’t come up already on the discussions.

.

-----Original Message-----
From: Roddy, Mark [mailto:xxxxx@stratus.com]
Sent: Tuesday, January 24, 2006 7:46 AM
Subject: RE: X64 Windows Vista to require signed drivers

Microsoft, along with everybody else in the consumer computer industry,
is focused on replacing that thing on top of your tv with something that
they build/manage that streams content into your home that is licensed
and generates revenue. Lots of revenue. From this discussion it is clear
that the downside of this is that other uses of their OS, from general
purpose server systems to various forms of low box count specialized
systems are going to lose out when decisions are made and there are
conflicting goals.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Tuesday, January 24, 2006 9:52 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] X64 Windows Vista to require signed drivers

This paragraph from the document sure does seem to support that:

“* Drivers must be signed for devices that stream protected
content. This includes audio drivers that use Protected User Mode Audio
(PUMA) and Protected Audio Path (PAP), and video device drivers that
handle protected video path-output protection management (PVP-OPM)
commands.”

As soon as I read that, I thought “So that’s the reason they’re doing
this.” I hate DRM. It protects a few media publishers and side effects
of things that get put in place to support DRM cripple everybody else -
ultimatley giving the consumer fewer choices which will lead to less
quality in the long run.

It seems to me that they could make this a requirement for only those
devices, though. Leave the rest of us alone.

Beverly

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tony Mason
Sent: Tuesday, January 24, 2006 9:13 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] X64 Windows Vista to require signed drivers

Someone pointed out to me yesterday (in an offline conversation) that
the real issue here is NOT related to drivers, but rather to DRM.
Microsoft has to lock down the set of certificates in order to implement
their strong DRM policy (otherwise, you could add your own certs and use
them to bypass the DRM apparently.) I’m not certain if that’s correct,
but the person who said this to me is reliable - and it makes a certain
type of sense. It explains why they won’t use just any root cert (which
certainly doesn’t matter for drivers, but doe matter for DRM).

I’m sure the folks at Microsoft did speak to their customers to
determine the impact this would have. After all, it is difficult to
imagine that one could make such a fundamental decision like this
without consulting with key customers (imagine the sheer embarrassment
factor if you need to recant after taking a strong policy position such
as this one.) So, while it will be inconvenient for us, they have
apparently determined that this is an acceptable cost (and if you don’t
like it, please refer to “Figure 1” :wink: )

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Peter G. Viscarola
Sent: Monday, January 23, 2006 2:29 PM
To: ntdev redirect
Subject: RE:[ntdev] X64 Windows Vista to require signed drivers

I think the point about special-purpose drivers that are used in-house
or by third party companies in very specific markets is a good one.

There are TONS of these drivers, and requiring them to be signed is
nothing but a DISincentive for people to move to 64-bit Windows.

Sigh… I’m glad Microsoft is thinking about issues of driver security
and reliability, but I really wish they would enter into a dialog with
the community about these policies before mandating them. I dare say
that even THEY can’t think of every consequence of every proposed
policy.

Peter
OSR


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@osr.com To unsubscribe
send a blank email to xxxxx@lists.osr.com


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Perhaps I should have said that it’s clearly not an unalienable right.
You can give it away by means of a contract. And you usually do, whether
you realize it or not.

Dan Partelly wrote:

Huh ?

How come I dont have that right ? So I cant decide what to install on my
machine as SW ? You dont use illegal SW.

----- Original Message ----- From: “Ray Trent”

> Newsgroups: ntdev
> To: “Windows System Software Devs Interest List”
> Sent: Wednesday, January 25, 2006 8:45 PM
> Subject: Re:[ntdev] X64 Windows Vista to require signed drivers
>
>
>> Dan Partelly wrote:
>>> You forget one thing: the USER right to install anything he wants on
>>> the computer and the OS.
>>
>> Sounds good in theory, but in practice you’ve never had that right in
>> the first place. There are numerous cases of illegal software, as well
>> as cases where license agreements disallow parties to install various
>> things on various machines.
>> –
>> Ray
>>
>> —
>> Questions? First check the Kernel Driver FAQ at
>> http://www.osronline.com/article.cfm?id=256
>>
>> You are currently subscribed to ntdev as: xxxxx@rdsor.ro
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>


Ray

> ----------

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Dan Partelly[SMTP:xxxxx@rdsor.ro]
Reply To: Windows System Software Devs Interest List
Sent: Wednesday, January 25, 2006 6:33 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] X64 Windows Vista to require signed drivers

>> Right. That’s exactly the point. Validated and signed drivers will not
>> ALLOW you to deal with “unauthorized” content. Today, you can do so,
>> but you have to feel guilty about it. Tomorrow, it will simply be
>> impossible.

Hahaha. Like if I really want to doit, whats to stop me to install
BSD or Linux or whatever other OS ?

Nothing nowadays. In the future it can be hardware and then laws. This direction is really stupid but dinosaurs don’t want to give up easily.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

>> Nothing nowadays. In the future it can be hardware and then laws. This

> direction is really stupid but dinosaurs don’t want to give up easily.

That day, in the future, Ill ask for asylum in Russia or China :stuck_out_tongue:

----- Original Message -----
From: “Michal Vodicka”
To: “Windows System Software Devs Interest List”
Sent: Thursday, January 26, 2006 2:01 AM
Subject: RE: [ntdev] X64 Windows Vista to require signed drivers

> ----------
> From:
> xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com]
> on behalf of Dan Partelly[SMTP:xxxxx@rdsor.ro]
> Reply To: Windows System Software Devs Interest List
> Sent: Wednesday, January 25, 2006 6:33 PM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] X64 Windows Vista to require signed drivers
>
> >> Right. That’s exactly the point. Validated and signed drivers will
> >> not
> >> ALLOW you to deal with “unauthorized” content. Today, you can do so,
> >> but you have to feel guilty about it. Tomorrow, it will simply be
> >> impossible.
>
> Hahaha. Like if I really want to doit, whats to stop me to install
> BSD or Linux or whatever other OS ?
>
Nothing nowadays. In the future it can be hardware and then laws. This
direction is really stupid but dinosaurs don’t want to give up easily.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Won’t matter… at that point, all the content will be encrypted and
only openable by the aforementioned hardware.

I doubt very many “can’t run Linux” PCs will actually get built, but
that won’t matter as far as the DRM is concerned.

Of course, DRM is break-once-works-anywhere in general, so you’ll still
be able to find the content… DRM is doomed to failure. I’m sure MS
knows that and doesn’t have a lot of illusions, BTW… they just want to
be the ones that content vendors encode for…

Dan Partelly wrote:

>> Nothing nowadays. In the future it can be hardware and then laws.
>> This direction is really stupid but dinosaurs don’t want to give up
>> easily.

That day, in the future, Ill ask for asylum in Russia or China :stuck_out_tongue:

----- Original Message ----- From: “Michal Vodicka”

> To: “Windows System Software Devs Interest List”
> Sent: Thursday, January 26, 2006 2:01 AM
> Subject: RE: [ntdev] X64 Windows Vista to require signed drivers
>
>
>> ----------
>> From:
>> xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com]
>> on behalf of Dan Partelly[SMTP:xxxxx@rdsor.ro]
>> Reply To: Windows System Software Devs Interest List
>> Sent: Wednesday, January 25, 2006 6:33 PM
>> To: Windows System Software Devs Interest List
>> Subject: Re: [ntdev] X64 Windows Vista to require signed drivers
>>
>> >> Right. That’s exactly the point. Validated and signed drivers
>> will >> not
>> >> ALLOW you to deal with “unauthorized” content. Today, you can do so,
>> >> but you have to feel guilty about it. Tomorrow, it will simply be
>> >> impossible.
>>
>> Hahaha. Like if I really want to doit, whats to stop me to install
>> BSD or Linux or whatever other OS ?
>>
> Nothing nowadays. In the future it can be hardware and then laws. This
> direction is really stupid but dinosaurs don’t want to give up easily.
>
> Best regards,
>
> Michal Vodicka
> UPEK, Inc.
> [xxxxx@upek.com, http://www.upek.com]
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>


Ray

> Well first in the paper Microsoft refers to a BCDedit (the replacement for

boot.ini) switch that will be removed from production releases. The switch
allows untrusted modules similar to the way you can choose NX protection is
current OS’es. This is for in-house use, but if the in-house folks feel
they need it, shouldn’t they ask if others do also?

Second, have an alternate signing authority, that will work with the
independents, students, etc.

Third they are restricting what can be boot start, this is going to break
existing products and mean that a lot of common techniques are not allowed.
They need a wayt to allow any class of driver to be boot start, assuming if
follows the signing policy of the first point.

I should note this is my paraphrase of Max Shatskih excellent post on an MVP
private newsgroup. I fully support all that Max suggested.

Yes, I would emphasize these 3 points at public now:

  1. allow the user to switch it off (by bcdedit or so). Yes, the default can be
    on. Yes, the machine can spit irritating baloon messages if this is off. But
    nevertheless let the user decide.

  2. allow the freedom of choice in signing authority. There must be choice,
    there must be cert authorities available to individuals and, BTW, to
    non-Americans too (even if this will require the non-American to apply for a
    visa and go on personally to some American office with non-American passport -
    this must be available in principle).

  3. Do not impose technical restrictions of what can be boot-start and what
    cannot. Any kernel module properly signed, regardless of its PnP participation,
    INF file presence, DifX, class GUIDs etc - must be boot-loadable. It should be
    enough to just register it in SC registry with Start = 0 and reboot.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

> If signed drivers are optional, can any functionality be contingent only

using signed drivers? What about support tied to signed drivers?

This is not a WinQual/WHQL signing. The former is for years, and requires
passing the technical tests at MS. WHQL is for some degree of stability
guarantees.

This new signing is to disable anonymously-written kernel mode code. It does
not have any quality-related stuff. It is more about the author’s name being
known as a legal evidence (perhaps Verisign ID has a legal power at court). DRM
and malware protection seems to be the motivation under this new signing
initiative.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

> in a given US state, possibly other countries as well. Limiting the

certificate vendor to one entity is a bit on the foolish side of things.
Great for Verisign though, but should Verisign go belly up??? And don’t
say won’t happen. Ever heard of Pan AM? Or Enron?

Surely. Why IE allows a choice of root certs, and even allows the user to
install his/her own root certs?

And note that IE’s code signing serves the same purposes - block anonymous code
and DRM (not a quality purpose like WHQL).

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

> Finally, I caution folks not to jump to too many conclusions based on a
single

paper published on WHDC. This paper is lacking in detail, and was almost

I personally believe that this paper is a draft. MS are known to change their
minds often, sometimes very late before release.

So, I consider the paper to be the draft, with a purpose of collecting
opinions. So, let’s expess them - maybe it will have some feedback.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

> That day, in the future, Ill ask for asylum in Russia or China :stuck_out_tongue:

Ooooh, Russia is possibly the freeest country in the world if we are speaking
about DRM :slight_smile: well, maybe Brasil too. China too.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

> ----------

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Maxim S. Shatskih[SMTP:xxxxx@storagecraft.com]
Reply To: Windows System Software Devs Interest List
Sent: Thursday, January 26, 2006 4:58 AM
To: Windows System Software Devs Interest List
Subject: Re: Re:[ntdev] X64 Windows Vista to require signed drivers

  1. allow the user to switch it off (by bcdedit or so). Yes, the default can be
    on. Yes, the machine can spit irritating baloon messages if this is off. But
    nevertheless let the user decide.

  2. allow the freedom of choice in signing authority. There must be choice,
    there must be cert authorities available to individuals and, BTW, to
    non-Americans too (even if this will require the non-American to apply for a
    visa and go on personally to some American office with non-American passport -
    this must be available in principle).

  3. Do not impose technical restrictions of what can be boot-start and what
    cannot. Any kernel module properly signed, regardless of its PnP participation,
    INF file presence, DifX, class GUIDs etc - must be boot-loadable. It should be
    enough to just register it in SC registry with Start = 0 and reboot.

Good points. Especially #1 is important but if DRM is the main reason, we’ll probably have to wait until some hackers make patched kernel binaries to prove how the whole signed only idea was stupid.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

> 2) allow the freedom of choice in signing authority. There must be choice,

there must be cert authorities available to individuals and, BTW, to
non-Americans too (even if this will require the non-American to apply for
a
visa and go on personally to some American office with non-American
passport -
this must be available in principle).

So you expect all non american driver developers to physically go to the
states and apply for a cert?

kind regards,
Bruno

> One more thing! btw I dont understand one thing, Is this policy really

enforcable to the extent that no one can break it? I mean what it will
take to patch the kernel mode crypto code to let pass everything! As
long as memory is not shadowed or protected one can always do this
although it will be much harder! remember all PCs (to the best of
my knowledge!) start in the real mode so if one really wants to
bring down this signing mechanism, what I mean to say is that
all these mechanisims are NOT enforcable and not resistant
to patching ofcourse!

If you read the AMD docs on their upcoming virtualization architecture there
is also documentation on a facility to allow the processor to shift from an
unverified mode, to a verified mode. This basically works by having an
instruction that takes a signed code block. The signed code block’s
signature is checked by the processor (actually I believe a security
coprocessor) and control is transferred to it. You can bet there will not be
many ways to get that core chunk of secure code signed. Once you are
executing guaranteed secure code, it can verify the signature on other
kernel components.

I’d have to investigate further if this can protect memory from things like
bus master DMA. It could prevent loading a bus master driver for hardware
that didn’t do “secure” bus mastering. They could also have a way to lock
the secure code in the cache, with no snooped changes. A little help from
the motherboard chipset could further lock down a system, by making all DMA
go through “map registers”. The OS could then absolutely control what memory
could be accessed/changed by devices by only allowing a secure part of the
OS to program those map registers (aren’t you glad you called the Windows
DMA functions and didn’t just cheat on DMA programming).

Another attack would be to run the OS on an emulated processor. Of course an
emulated processor would not know the proper key to decrypt the initial
secure code block, so it could never start the OS.

Whoever controls the root crypto key will have ultimate control over what
code runs or not. This absolutely could prevent unapproved OS’s from
running, by having the BIOS code shift into secure mode. You might also
allow both secure (Windows) and non-secure (Linux) OS’s to run, but only
secure OS’s could run secure kernel components, and play DRM protected
media. This could be extended to only allowing DRM secure systems access to
the Internet. I’ve always believed a potential solution to Internet security
is strong authentication. Spam only works because you can’t easily prove its
source. I have zero problem always accessing the Internet as an
authenticated me. Actually, since I use a static IP address, I already am
traceable (ok not me absolutely, but my household). This seems like an
opportunity for Microsoft to badly hurt Linux, and all they have to do is
get on the DRM bandwagon with the media companies. This way it’s Disney who
hurt Linux, not Microsoft. Disney has valid business reasons to protect
their content, and as soon as Linux delivers DRM secure capability, they
will be Disney’s friend too. I’d be all for a secure OS if it means I don’t
have to renew my antivirus subscription ever again.

If you were AMD or Intel, you might be able to slice open the processor chip
and use your electron microscope (or whatever) to read the secure key,
although your typical teenage hacker would not have facilities like this.
There is quite a bit known about designing secure processors, and assume AMD
and Intel could easily apply those techniques. Or there is a separate secure
coprocessor on the motherboard.

None of this is really a problem for developers. You could have the secure
DRM components only allow access to test DRM protected content when in
development mode. You could also have some DRM protected content with a
production key that its owners didn’t care about protecting, so you could
eliminate the argument of not testing REAL content. Patching the code in
development mode is useless, as the patched binary will no longer run. The
public security key is stored in the secure coprocessor, NOT in any files on
your computer. It’s computationally impossible (until we get quantum
computers) to figure out the private key based on having the signature, so
properly implemented, it can’t be bypassed.

Being a relative old timer in the computer industry (I’m 48 now), I’ve seen
people get comfy and grumble at even the slightest change to the status quo,
over and over. I WANT computers to evolve, things are REALLY broken right
now. We know how to make better information systems, let’s do so. It’s
REALLY cheap to have the tools needed to write software, next time you get
an MRI, consider what it would be like if kernel debuggers cost what MRI
machines cost (about $2 million bucks).

  • Jan

>Good points. Especially #1 is important but if DRM is the main reason, we’ll

probably have to wait until some hackers make patched kernel binaries to prove
how the whole signed only idea was stupid.

Doing this for DRM will not hit the target in fact. People will do open-source
software which will decode the DRMed stuff, and this is not punisheable by the
law in many countries (remember DeCSS?). Then people will convert the stuff to
public format like DivX using open source tools on Linux - and go on.

Even a smart (not to say brilliant) people at MS (both Redmond and MS Russia)
are rather agnostic about non-MS possibilities existing. Open source, for
instance. So, this “agnosticism” could be the cause of such a strange DRM
measure. The authors of the paper can just not know Linux at all.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

> So you expect all non american driver developers to physically go to the

states and apply for a cert?

  1. Some non-US developers (like me) are working for American companies. So, no
    problem.
  2. Some cert authorities can have offices outside America and issue certs to
    non-Americans.

These are the most possible ways for non-American. Going physically - well,
this can also be a way.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

> None of this is really a problem for developers. You could have the secure

DRM components only allow access to test DRM protected content when in
development mode. You could also have some DRM protected content with a

For me, the road to DRM is hardware, so that software - even the system-level
one - will never ever see un-encrypted media stream.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com