OSRLogo
OSRLogoOSRLogoOSRLogo x Subscribe to The NT Insider
OSRLogo
x

Everything Windows Driver Development

x
x
x
GoToHomePage xLoginx
 
 

    Wed, 13 Dec 2017     115635 members

   Login
   Join


 
 
Contents
  Online Dump Analyzer
OSR Dev Blog
The NT Insider
Downloads
ListServer / Forum
Driver Jobs
  Express Links
  · The NT Insider Digital Edition - May-June 2016 Now Available!
  · Windows 8.1 Update: VS Express Now Supported
  · HCK Client install on Windows N versions
  · There's a WDFSTRING?
  · When CAN You Call WdfIoQueueP...ously

Sidebar Discussion -- Nt vs. Zw Continued

One of the most fun things about writing for The NT Insider is the ability to generate comment and controversy around what you write. We exchanged a few emails as a result of last issue’s article Nt vs. Zw - Clearing Confusion On The Native API.

In that article we recommended that driver writers use the Zw variants of the routines so that their kernel mode credentials and buffers are properly handled. This of course assumes that you are servicing a request on behalf of a kernel mode component and are passing in kernel mode buffers. We wanted to emphasize that there are in fact many times when you might need to service a request on behalf of a user mode component, using the supplied user mode credentials and buffers. In these cases, it is much more desirable to use the Nt variant of the system service call because doing so places the onus of checking the user’s parameters on the Windows system service code. Remember, it’s your responsibility to validate buffers passed into a Zw call!

Some folks have gone so far as to suggest that, even though the Nt form of the system service calls aren’t specifically documented (and the prototypes aren’t supplied), they should be the version you use by default. In fact, we tend to agree that this is the most conservative course. This is at least slightly controversial, however, and even our friends up at Microsoft don’t necessarily agree on which approach is best.

Another point we’d like to emphasize has to do with the use of kernel handles. Not only does using kernel handles allow for access to the handles from all process contexts, it also adds increased security. If you do not specify OBJ_KERNEL_HANDLE when creating a handle, the handle is valid in the current process context and accessible from that process. A malicious or buggy application could delete the handle or replace it to point off to something that it should not be able to access. However, as was pointed out in the article and sample code, user mode components have no access to kernel handles so using OBJ_KERNEL HANDLE closes this security hole.

User Comments
Rate this article and give us feedback. Do you find anything missing? Share your opinion with the community!
Post Your Comment

Post Your Comments.
Print this article.
Email this article.

Writing WDF Drivers I: Core Concepts
LAB

Nashua (Amherst), NH
15-19 May 2017

Writing WDF Drivers II: Advanced Implementation Techniques
LAB

Nashua (Amherst), NH
23-26 May 2017

Kernel Debugging and Crash Analysis
LAB

Dulles (Sterling), VA
26-30 Jun 2017

Windows Internals and Software Driver Development
LAB

Nashua (Amherst), NH
24-28 Jul 2017

 
 
 
 
x
LetUsHelp
 

Need to develop a Windows file system solution?

We've got a kit for that.

Need Windows internals or kernel driver expertise?

Bring us your most challenging project - we can help!

System hangs/crashes?

We've got a special diagnostic team that's standing by.

Visit the OSR Corporate Web site for more information about how OSR can help!

 
bottom nav links