Maxim
Sun Apr 22 06:16:47 CDT 2007
> I know that for commercial use, drivers need some kind of license, and
> I've heard of WHQL and Verisign.
This is not "licensing".
> Can someone please tell me which one of the licenses does NDIS IM
> need? Is Verisign should be enough?
No. WHQL only. This means - you:
a) deploy DTM in your lab - warning! complex and 3 physical machines involved,
one must be with a server Windows flavour, must IIRC have MSSQLServer installed
and IIRC must be a domain controller.
The reason is that DTM is a large industrial test suite for large test labs (10
* N machines) used as an internal tool within MS. They shipped their internal
tool to customers without any "hairdressing" it to be of a market quality
(usability etc), thus the issues.
For large lab, DTM is fine, and not only for Windows drivers - its advantages
of "large lab support" outweight its drawbacks of "bad usability and hard to
install with pitfalls". For small lab, the product is bad - exactly due to
these pitfalls.
b) run the DTM tests of a proper category over your driver.
c) do the WHQL submission of the driver package (INFs and DLLs included) to
MS's WinQual team and pay around USD 2000 for each submission. Yes, a minor
bugfixing release will also cost 2000.
I expect that you must provide the source code to WinQual team too, so they
will ensure that the code is PREFast-clean.
d) MS's WinQual team will run the same DTM tests in their lab, and, if the
driver will pass them, they will sign it with a WinQual's digital signature.
e) drivers with such a signature are installed silently in Windows. Drivers
without such a signature give warnings and require the admin user to approve
their installation.
The whole idea under this is - MS will do the testing of some 3rd party drivers
in-house, and only the drivers tested by MS this way will be installed silently
to Windows, as also possibly included to Windows Update. This does not prohibit
you from writing unsigned drivers, they will just give the warning about "This
driver was not tested by MS, do you want to continue?" during their
_installation_ (INF execution).
For me, this whole idea of WHQL - introduced in 2000 with w2k - is dead. The
reason is wanting money for each new build testing and signing. Even large
companies are irritated enough to skip this in minor bugfixing releases, and so
the WHQLed (major version) builds of, say, nVidia Detonator are often _buggier
and worse_ then the subsequent releases (minor version bugfixing builds, not
WHQLed).
More so. Installing the new updated version of the same Detonator off Windows
Update can worsen your 3D performance and introduce the bugs. For instance -
old version of Detonator do not load the CPU while running the 3D OpenGl screen
saver, you install the new version from Windows Update and - voila! - 100% CPU
load while running a screen saver.
With Vista, MS relaxed this a lot. Vista has an option of "always trust the
system software from this vendor", and, if you will switch this on, then WHQL
warnings about this vendor's drivers will disappear forever.
_Vista 64bit kernel-mode code signing_ is absolutely another song, having
nothing to do with WHQL. Its main purpose is not Windows "quality" ("being
tested in MS's labs"), but DRM and struggle with hackers, crackers and malware
authors.
Differences:
- WHQL is for w2k up, Vista 64bit signing is only 64bit and only Vista (maybe
Longhorn Server betas too).
- for 64bit signing, you do not need to pay and do not need to submit anything
to MS.
- for 64bit signing, no requirements of tests being passed is imposed.
- WHQL signing is only for some classes of drivers, and is bypassable - you can
install a kernel mode binary using CreateService and skip WHQL checks at all.
WHQL is de-facto only for real hardware drivers, NDIS IMs and some anti-virus
FS filters, any other kernel modules have no WHQL tests for them and no WHQL
signatures. They can be installed using CreateService.
On the other hand, 64bit signature is checked _on load_ and you cannot load
unsigned module in Vista 64. Just plain and simple - cannot, except the OS is
turned to debug mode (WinDbg attached or F8 hit a boot - each boot).
- only MS can sign with WHQL signatures. With 64bit signing, you sign yourself,
the only thing you need is the proper company certificate from Verisign or
several other authorities and the MS WDK toolkit.
64bit code signing adds the following features:
- one more protection against pirates and crackers. Changing a single byte in
your driver - which the crackers do - will break the signature. So, the life of
DRM crackers (they are criminally liable in the US according to DMCA) - is
harder.
- one more protection against kernel-mode malware. The malware author will need
to sign the binary, and the signature needs Verisign or the similar cert, and
this cert - with the corporate identity - can be used as an obvious first step
to prosecute the malware author legally.
According to what I know from inside MS, 64bit signing was introduced mainly
due to DRM reasons for Windows to be compatible with the DRM schemes introduced
by the media companies for new high-definition audio and video. This is not a
question of Windows stability and testing, and this is a political issue and
not technical one.
--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com