> (1) Maybe Microsoft should NOT allow any driver to be installed on a machine
unless it is Digitally Signed that may pass the problem to Microsoft and
help the public too with less busy code.
Would make development a little difficult though 
What Windows really needs is an environment that makes it friendly to
run without having to be continuously logged in as administrator,
making any concept of security almost meaningless (Open a word
document and almost anything can happen).
As has been discussed numerous times — the number of non-WHQL-able drivers
versus WHQL-able drivers is leaning towards the non side. I’m currently
developing a driver that will NEVER be sold over the counter but only
installed in a controlled environment. So why should I waste time and money
getting the silly thing WHQL’d when most likely WHQL can’t WHQL it in the
first place and if they could WHQL it, it wouldn’t WHQL in the first place.
If as you suggest that a driver has to be WHQL’d to install how would you
then propose that us developers load and install our drivers that we are
developing? They haven’t been WHQL’d yet because they haven’t been
developed, but they can’t be installed because they haven’t been WHQL’d.
Ouch … my head hurts.
–
Gary G. Little
Seagate Technologies, LLC
“Robert Newton” wrote in message
news:xxxxx@ntdev…
> > (1) Maybe Microsoft should NOT allow any driver to be installed on a
machine
> > unless it is Digitally Signed that may pass the problem to Microsoft and
> > help the public too with less busy code.
>
> Would make development a little difficult though
>
> What Windows really needs is an environment that makes it friendly to
> run without having to be continuously logged in as administrator,
> making any concept of security almost meaningless (Open a word
> document and almost anything can happen).
>
> Rob
> xxxxx@telusplanet.net
>
>
>
Gary, are you asking which came first - the chicken or the egg? 
Of course, you could get a test signature that would give you all you
need to installed signed drivers that you compile several times a day.
It is expensive, or so I hear.
“Gary G. Little” wrote in message
news:xxxxx@ntdev…
> As has been discussed numerous times — the number of non-WHQL-able
drivers
> versus WHQL-able drivers is leaning towards the non side. I’m
currently
> developing a driver that will NEVER be sold over the counter but only
> installed in a controlled environment. So why should I waste time and
money
> getting the silly thing WHQL’d when most likely WHQL can’t WHQL it in
the
> first place and if they could WHQL it, it wouldn’t WHQL in the first
place.
>
> If as you suggest that a driver has to be WHQL’d to install how would
you
> then propose that us developers load and install our drivers that we
are
> developing? They haven’t been WHQL’d yet because they haven’t been
> developed, but they can’t be installed because they haven’t been
WHQL’d.
>
> Ouch … my head hurts.
>
> –
> Gary G. Little
> Seagate Technologies, LLC
>
> “Robert Newton” wrote in message
> news:xxxxx@ntdev…
> > > (1) Maybe Microsoft should NOT allow any driver to be installed on
a
> machine
> > > unless it is Digitally Signed that may pass the problem to
Microsoft and
> > > help the public too with less busy code.
> >
> > Would make development a little difficult though
> >
> > What Windows really needs is an environment that makes it friendly
to
> > run without having to be continuously logged in as administrator,
> > making any concept of security almost meaningless (Open a word
> > document and almost anything can happen).
> >
> > Rob
> > xxxxx@telusplanet.net
> >
> >
> >
>
>
>
On Mon, 2004-02-02 at 19:21, David J. Craig wrote:
Gary, are you asking which came first - the chicken or the egg?
Of course, you could get a test signature that would give you all you
need to installed signed drivers that you compile several times a day.
It is expensive, or so I hear.
Could theoretically also do something like was done with system file
protection, requiring a debugger to be attached to disable the signature
checks. That’d get developers where they need to go, while virtually
eliminating the chance that a home/enterprise user could install it.
-sd
> ----------
From:
xxxxx@positivenetworks.net[SMTP:xxxxx@positivenetworks.net]
Reply To: xxxxx@lists.osr.com
Sent: Tuesday, February 03, 2004 3:19 AM
To: xxxxx@lists.osr.com
Subject: Re: Re:[ntdev] Re[2]: WHQL CertificationOn Mon, 2004-02-02 at 19:21, David J. Craig wrote:
> Gary, are you asking which came first - the chicken or the egg?
>
> Of course, you could get a test signature that would give you all you
> need to installed signed drivers that you compile several times a day.
> It is expensive, or so I hear.Could theoretically also do something like was done with system file
protection, requiring a debugger to be attached to disable the signature
checks. That’d get developers where they need to go, while virtually
eliminating the chance that a home/enterprise user could install it.
Technically it would be possible (and there would be ways how to circumvent
it as with WFP). But why, please? It is user’s decision if s/he allows to
install unsigned driver. The warning is discouraging enough; it is almost
unfair. There won’t be any benefit but problems for all of us. Think about
quick bugfixes for example. Renewing WHQL signature takes several days or
weeks (end of the last year). There can be a fatal bug even in signed driver
which needs to be fixed immediatelly. You may need to give customer a debug
version of driver just for test. And so on.
Best regards,
Michal Vodicka
STMicroelectronics Design and Application s.r.o.
[michal.vodicka@st.com, http:://www.st.com]
On Mon, 2004-02-02 at 20:56, Michal Vodicka wrote:
> Could theoretically also do something like was done with system file
> protection, requiring a debugger to be attached to disable the signature
> checks. That’d get developers where they need to go, while virtually
> eliminating the chance that a home/enterprise user could install it.
>
Technically it would be possible (and there would be ways how to circumvent
it as with WFP). But why, please? It is user’s decision if s/he allows to
install unsigned driver.
The problem is that it isn’t the user’s decision yet. There are ways
around the dialog. We could all list a few if we thought about it for a
second.
The warning is discouraging enough; it is almost
unfair. There won’t be any benefit but problems for all of us. Think about
quick bugfixes for example. Renewing WHQL signature takes several days or
weeks (end of the last year). There can be a fatal bug even in signed driver
which needs to be fixed immediatelly. You may need to give customer a debug
version of driver just for test. And so on.
I agree with this line of logic. I see the point that is made by the
“signing is good” crowd, too - we all look bad whenever a box
bluescreens, and MS in particular has a business imperative to not crash
– it costs them too much in goodwill.
In the end, this is another race - MS vs the hackers - and I am no fan
of races like these. Reminds me of the hooking thread also running
atm…
-sd
> ----------
From:
xxxxx@positivenetworks.net[SMTP:xxxxx@positivenetworks.net]
Reply To: xxxxx@lists.osr.com
Sent: Tuesday, February 03, 2004 4:04 AM
To: xxxxx@lists.osr.com
Subject: RE: Re:[ntdev] Re[2]: WHQL CertificationThe problem is that it isn’t the user’s decision yet. There are ways
around the dialog. We could all list a few if we thought about it for a
second.
Yes. Which implies there always will be a way. Impossible to avoid until we
redefine the role of administrator. I mean, everything worse would only
cause more problems for developers who “play fair” and won’t stop others.
Similarly as with CD copy protection and other nonsense.
I agree with this line of logic. I see the point that is made by the
“signing is good” crowd, too - we all look bad whenever a box
bluescreens, and MS in particular has a business imperative to not crash
– it costs them too much in goodwill.
But I agree, signing is good. Just don’t want it totally mandatory. There
should be a choice. For both users and developers. Current state is
suitable.
BTW, I’m sure you know signature doesn’t stop driver from crashing. I just
have one; passed all tests and properly signed with (my) stupid bug
included. BSOD under some rare timing conditions, reproducible on one kind
of computers only. It is almost impossible to make reliable tests which
would ensure driver is quite stable. How to simulate all possible race
conditions?
Best regards,
Michal Vodicka
STMicroelectronics Design and Application s.r.o.
[michal.vodicka@st.com, http:://www.st.com]
On Mon, 2004-02-02 at 21:48, Michal Vodicka wrote:
> The problem is that it isn’t the user’s decision yet. There are ways
> around the dialog. We could all list a few if we thought about it for a
> second.
>
Yes. Which implies there always will be a way. Impossible to avoid until we
redefine the role of administrator. I mean, everything worse would only
cause more problems for developers who “play fair” and won’t stop others.
Similarly as with CD copy protection and other nonsense.
Palladium… I still haven’t wrapped my brain around the implications of
fritz chips and the like, but trusted drivers are certainly among them.
It is almost impossible to make reliable tests which
would ensure driver is quite stable. How to simulate all possible race
conditions?
Of course this is impossible; WHQL is more valuable as a way to ensure
good behavior. Finding my (ample) supply of bugs is up to me.
Maybe I’ve carried this a bit off-topic at this point…
-sd
First WHQL does NOT guarantee “good behaviour”. All it REALLY does is say
that on this given hardware running this given software set that this driver
played nicely in the the system. It cannot “guarantee” good behaviour. It
MIGHT provide assurance to a user that there is a good chance that in any
give system failure it probably isn’t that driver causing the problem. It is
absolutely impossible to test every driver in every hardware/software
combination so they test in a representative sample, and certify drivers as
playing in that representative sample. Also note that there are MANY classes
of drivers for which HCT test do not exist, and as such cannot be WHQL’d.
Driver signing requirements are changing even as we speak, and not knowing
what has and has not presented by Microsoft I can’t say a lot. Some of it is
for the better, but at the same time, some of it is still “undefined”, at
least from the discussions we had at the Driver DevCon back in November.
Even I gave grudging nod that some of the proposals to be implemented may
work, or at least be tolerable.
–
Gary G. Little
Seagate Technologies, LLC
> quick bugfixes for example. Renewing WHQL signature takes several days or
weeks (end of the last year). There can be a fatal bug even in signed driver
which needs to be fixed immediatelly. You may need to give customer a debug
This often occured with nVidia’s drivers in the old days of 2000. WHQLed driver
build was buggy, while non-WHQLed was not.
After I saw the WHQLed version of Intel Application Accelerator who failed the
easy PnP test of “Scan For Hardware Changes” in the Device Manager - failed by
reporting the surprise removal of IDE disk and crashing the OS - I disbelieve
WHQL.
Another issue. The SiS Ethernet chip in Asus S200 notebook. WHQLed for sure.
And so what? Go to hibernate, disconnect the cable, then awaken from
hibernate - and observe 100% CPU load from System process. The driver in fact
requires full reboot after each cable connect/disconnect - otherwise, the
following hibernate will cause this picture. Very, very bad for notebooks, I
would say.
Now compare this to Tecom Bluetooth dongle with WIDCOMM driver stack and
Tecom’s firmware. No drivers are WHQLed there (around 15 dialog boxes during
install) - but works like a charm. No PnP and PM issues.
I think this idea already dis-credited itself. MS WHQL team seems to a) bend
down to loud names like Intel b) put signatures on buggy drivers, while the
other - non-buggy - build of the driver is not WHQLed.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
> First WHQL does NOT guarantee “good behaviour”. All it REALLY does is say
Their test suites seems to be severely broken.
They “pass” the NDIS miniport which does not handle well a combination of cable
disconnect + hibernate/awaken.
And - in the same time, they put huge attention so that the developer did not
call the undocumented function (which is existing and stable in all known NTs,
like PsLookupProcessByProcessId, and not documented only due to lack of good
will at MS).
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com