Driver reliability and security go hand in hand. That is, the design techniques that create reliable drivers also create drivers that are secure. Secure drivers help protect the system from malicious attacks.

The most important rule to follow when creating code that will execute in either user mode or kernel mode is the following:

In other words, don't assume you will always know which components will call your driver. Suppose you initially design a software component to operate in a seemingly well-defined environment in which a limited number of known, trusted components will call your component. In the future, new and untrusted components might be added to the environment, without your control or knowledge.

Based on the rule that the run-time environment should not be trusted, you should use the following guidelines when creating user-mode or kernel-mode code to support your device:

• Validate input parameters.

  Always validate all parameters received from other drivers, from operating system components, and from user-mode applications. Be especially careful of parameters that originate in user-mode applications. Test received values, to ensure that they are within expected ranges. Test the size of input buffers, to ensure that received data is not too large for the driver to handle. Test the size of output buffers, to ensure that the buffers are large enough to hold the data to be written.

• Validate registry contents.

  Validate registry contents before using them. Registry contents should always be treated as untrusted, user-modifiable data. For information about using the registry, see Registry Keys for Drivers.

• Use safe string functions.

  When writing code that manipulates text strings, use safe string functions instead of the string manipulation functions that are provided by C-language run-time libraries. Safe string functions are available for both user-mode and kernel-mode code, and they accept parameters that enable you to prevent buffer overrun errors.

• Provide secure device installations.

  System administrators should be able to control a user's access to a system's devices. This means that, generally, security for drivers should be set in INF files at installation time, instead of in drivers at execution time. For more information, see Creating Secure Device Installations.

For additional guidelines on creating kernel-mode drivers that are reliable and secure, see Creating Reliable Kernel-Mode Drivers.

Additionally, see the Windows Driver Kit (WDK) documentation for device-specific technologies for additional, device-specific, security guidelines.

For more information about developing secure software, and for general information about computer security issues, see the  Security Web site.