Inside Win2K Reliablity Enhancements, Part 2

Last month, I began this three-part series about enhancements in Windows 2000 (Win2K) that improve the OS's reliability. This month, I describe Win2K features that Microsoft designed to eliminate the necessity of using recovery tools. These features include driver signing, system file protection, and a powerful tool called the Driver Verifier that I'll focus on next month, in Part 3.

Driver Signing
As I mentioned last month, buggy device drivers are the leading cause of instability in Windows NT 4.0. Microsoft's Hardware Compatibility List (HCL) lists devices with their drivers that hardware vendors submit to Microsoft for testing; the devices on the HCL have passed numerous stress tests. Although device drivers for the hardware devices on the HCL aren't guaranteed to be bug-free, you are less likely to run into problems with them than with drivers that haven't passed through Microsoft HCL testing.

Even if you intend to keep non-HCL drivers off your system, you might not remember to check the HCL when you add a device. And if you stay current with a hardware vendor's latest drivers, you can find yourself at odds with the HCL: A device's original driver might be on the HCL, but the driver's update might not be. (For example, if a vendor rewrote a driver to get better performance, the driver update might include new bugs.) In addition, several systems administrators might manage a given system, which makes policing driver installation virtually impossible.

To help you keep your system loaded exclusively with drivers from the HCL, Microsoft introduced driver-signing technology into Win2K. Microsoft Internet Explorer (IE) has had support for Authenticode signing of ActiveX controls for several years, so you can configure IE to ask for approval before downloading a control. By checking a control's signature, IE can determine whether the control is signed and which company published the control. Driver signing in Win2K is virtually the same technology applied to device driver files. Because Microsoft signs only the drivers that the HCL lists, Win2K knows that when it doesn't find a valid signature for a driver, the driver is non-HCL.

Screen 1, page 56, shows the Driver Signing Options dialog box, which you access from the Hardware tab of the System applet in Control Panel. Using this dialog box, you can direct Win2K to react to a non-HCL driver in one of several ways. You can set Win2K to always install unsigned drivers without notice. (This behavior exists in NT 4.0.) Or, you can set Win2K to either ask to in-stall unsigned drivers or never install unsigned drivers.

What does it mean when Microsoft signs a driver? The first step the company takes when it signs a driver is to generate a hash of the driver file. This hash is a relatively short number that uniquely identifies a file's contents—no two driver files will have the same hash. Microsoft then has VeriSign (a company that provides digital authentication services) encrypt the hash with VeriSign's private key. The encrypted hash is the driver's signature, and it ships with the device driver. Anyone with access to VeriSign's public key can decrypt the encrypted hash. (To learn about private and public keys and digital authentication, see Tao Zhou, "Public Key Infrastructure in Windows 2000," January 1999.) For device drivers that the Win2K CD-ROM includes, Microsoft stores the driver signatures in catalog files that Win2K installs onto an installation's hard disk under \%systemroot%\system32\catroot. Device drivers that OEMs supply ship with the catalog file that Microsoft provides the vendor when the driver passes HCL testing. If you look under the Catroot directory, you'll see two files with the root name sysmast, and a subdirectory with a long name composed of letters and numbers. Sysmast is the master index of catalog files, and the subdirectory contains Win2K's built-in catalog files. Looking into the subdirectory reveals catalog files for different Win2K components. For example, fp.cat is the catalog of signatures for FrontPage's application files. Nt5.cat and nt5inf.cat store the signatures for Win2K system files.

You can install device drivers in Win2K in several ways. The most common way is for Win2K to attempt to install a device driver automatically when the Win2K Plug and Play (PnP) subsystem detects a new device. The user-mode Plug and Play Manager (UMPNPMGR), which \%systemroot%\system32\umpnp mgr.dll implements, waits for the PnP subsystem in the kernel to notify it that the subsystem has detected a new device. When you add a new device, UMPNPMGR locates the device driver's installation information file (INF). The INF is located either under \%systemroot%\INF, for drivers that the Win2K CD-ROM includes, or on the device driver's installation media (a 3.5" diskette or CD-ROM), for OEM drivers. INF files carry the .inf extension and are text files with somewhat complex instructions—including which files to copy from where to where, and what Registry settings to enable— that Win2K follows to install device drivers or software applications. Another way you can install a device driver is to use the Hardware Installation Wizard (HIW), implemented in \%systemroot%system32\newdev.dll. HIW follows steps similar to those UMPNPMGR takes to locate a driver's INF file.

UMPNPMGR and the HIW use services that the Setup API DLL (SETUPAPI—\%systemroot%\system32\setupapi.dll) implements to read in a driver's INF file. SETUPAPI processes instructions for installing a device driver file and checks the HKEY_LOCAL_MACHINE\ SOFTWARE\Microsoft\Driver Signing\Policy Registry value. If this value doesn't exist, SETUPAPI checks HKEY_CURRENT_USER\Software\Microsoft\Driver Signing\Policy. You set these values through the Driver Signing Options dialog box. When you direct the dialog to apply a setting as the administrative default, the dialog sets the Policy value under HKEY_LOCAL_MACHINE; otherwise, the dialog sets the value under HKEY_CURRENT_USER. UMPNPMGR checks the value under HKEY_LOCAL_ MACHINE first; if the value is set, the global policy overrides whatever individual administrators or users configure for their driver-signing policy. The 0 value directs UMPNPMGR to install unsigned drivers, a 1 value directs SETUPAPI to display a warning dialog box that asks a user for permission to install unsigned drivers, and a 2 value directs SETUPAPI not to install unsigned drivers.

If the driver-signing policy dictates that SETUPAPI must check for a signature, SETUPAPI locates the catalog file that corresponds to the driver. Then, SETUPAPI uses the cryptographic services that the CryptoAPI provides to generate a hash for the driver file and decrypts the driver's signature using VeriSign's public key. (For more information about Win2K's CryptoAPI function, see "Inside Encrypting File System, Part 1," June 1999, and "Inside Encrypting File System, Part 2," July 1999.) If the hash that the CryptoAPI generates from the driver file doesn't match the hash that SETUPAPI obtained from the driver's catalog file, or if the driver doesn't have a catalog file, SETUPAPI either asks the user whether driver installation should proceed or causes the installation to fail.

Windows File Protection
When Microsoft polled customers during Win2K's development about what problems caused system instability in NT 4.0 installations, a familiar response was "DLL hell." Many applications include versions of important system DLLs to ensure that the application will execute properly regardless of which versions a system has installed. For example, many applications that developers write to Microsoft Foundation Classes (MFC) C++ object library ship with a copy of mfc42.dll. Microsoft has released several versions of mfc42.dll, and some versions are incompatible with applications that expect a specific version. The DLL version problem even extends to core system DLLs, which some misbehaving applications try to replace.

Win2K introduces Windows File Protection (WFP), which is named System File Protector in Win2K versions earlier than and including Win2K beta 3. WFP acts as a watchdog over most Win2K system files, including DLLs, driver files, font files, INF files, and executable files. When WFP detects a change to one of the files it oversees, WFP updates the changed or removed file with a fresh copy of the original.

   Previous  [1]  2  Next