Share via

Device Manager Security

Other versions of this page are also available for the following:

Windows Mobile SupportedWindows Embedded CE Supported


Device Manager validates all input and output buffers passed to DeviceIoControl.

For Windows Embedded CE

Aa930910.collapse(en-US,WinEmbedded.60).gifInput/Output Buffer Validation

In Windows Embedded CE 6.0, the kernel performs a full access check on first level buffer pointer parameters. This access check eliminates the need for validation to be performed by the device driver. However, a driver must still verify that the caller has access to memory addressed by embedded pointers using CeOpenCallerBuffer and CeCloseCallerBuffer. For additional information, see the Migrating a Windows Embedded CE Driver to Windows Embedded CE 6.0.**

For Windows Mobile

Aa930910.collapse(en-US,WinEmbedded.60).gifInput/Output Buffer Validation

Device Manager calls the MapCallerPtr ** function to validate all input and output buffers passed to DeviceIoControl. Because Device Manager validates these buffers, individual drivers that use DeviceIoControl do not need to validate their input and output buffers. The following Device Manager code excerpt shows when and how Device Manager validates the input and output buffers.

BOOL DM_DevDeviceIoControl(
  fsopendev_t *fsodev,
  DWORD dwIoControlCode,
  LPVOID lpInBuf,
  DWORD nInBufSize,
  LPVOID lpOutBuf,
  DWORD nOutBufSize,
  LPDWORD lpBytesReturned,
  LPOVERLAPPED lpOverlapped)
  BOOL retval = FALSE;
  DWORD dodec = 0;

  lpInBuf = MapCallerPtr(lpInBuf,nInBufSize);
  lpOutBuf = MapCallerPtr(lpOutBuf,nOutBufSize);
  //  End of code excerpt.

Aa930910.collapse(en-US,WinEmbedded.60).gifEnforced Privileged Caller Access to Certain Devices

Certain classes of devices should only be accessed by privileged callers. For example, block drivers should only be directly accessed by the file system or the Power Manager. Some platforms implement drivers whose only role is to provide services to other drivers. GPIO manipulation and I2C services are two examples of this category of devices.

You can restrict access to individual drivers or instances of a driver through the registry. Device Manager provides a mechanism through the registry that restricts access to specific drivers by privileged code only. The mechanism is the DEVFLAGS_TRUSTEDCALLERONLY Flags value that Device Manager reads from device activation registry keys. When DEVFLAGS_TRUSTEDCALLERONLY is set, Device Manager rejects attempts by normal code to open a handle to the device. Device Manager sets the ERROR_ACCESS_DENIED error code when it rejects an attempt to open a handle to the device from normal code. The access rights are checked when a handle is created. After access rights are checked, and the handle is created, the handle is assumed to be valid. Because the handle is assumed to be valid, performance is not negatively affected due to checking permissions each time a device driver is accessed.

The following list shows some things to keep in mind when using the DEVFLAGS_TRUSTEDCALLERONLY flag:

  • Perform a security audit on any custom device drivers.
  • Remove the DEVFLAGS_TRUSTEDCALLERONLY bit from the registry if you want to add a normal IOCTL to a Windows Mobile device driver. Then add appropriate calls to PSLGetCallerTrust in the various device driver entry points.
  • Set this flag only on drivers that legitimately need to be accessed by privileged code only. Use this flag with caution, and thoroughly test any drivers that use this flag.
  • Be aware of possible backward compatibility issues that may arise due to setting this flag.

See Also



Other Resources