OSRLogo
OSRLogoOSRLogoOSRLogo x Seminar Ad
OSRLogo
x

Everything Windows Driver Development

x
x
x
GoToHomePage xLoginx
 
 

    Wed, 13 Dec 2017     115626 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

Service Pack or Dot Release? -- Test With XP SP2 Now

Unless you’ve been vacationing on Mars, you’ve certainly have heard that Windows XP Service Pack 2 (XP SP2) will be released later this year. "What do I care?" you say. "I write drivers, I don’t worry about service pack releases."

Sorry, wrong answer, chum. XP SP2 is more like a dot release for XP than an ordinary service pack. The good news is that if you write quality drivers, and test them thoroughly with Driver Verifier, you probably won’t have any problems with XP SP2. On the other hand, if you like living on the edge and bypassing the operating system whenever you feel like it, you might have some work ahead of you.

Let’s look at the two changes in XP SP2 that are most significant to driver writers.

Pool Overrun Checking

If you’ve read the memo from Hector on OSR Online® you already know about this new feature. Starting with XP SP2, ExFreePoolWithTag (you are using the "WithTag" variants of the pool allocation functions, right?) was enhanced to check the integrity of the header used by the pool block following the one being returned. If the header is corrupted, the system will immediately blue screen. I think we can all agree that catching pool corruption is a good thing.

What you might not realize is that during beta testing, a number of drivers were discovered that blue screened because of this new pool corruption check. The only problem was that they blue screened while running at customer sites. Personally, I’d say this is good for the driver community, and pretty bad for the dev who wrote and shipped those drivers without testing them first.

If you regularly run your drivers with Driver Verifier enabled, including special pool, you’re doing your due diligence. Your drivers are almost certainly safe. But do take a few minutes to try out your driver code under XP SP2 just to be sure.

As for those devs who don’t test their drivers with Verifier before they ship them, well…. You boneheads don’t read this publication anyhow. I mean, why would you take the time to read a free publication that might help you increase the quality of your drivers if you don’t use the free tools that are to help avoid turning your customers into QA testers?

No Execute Page Support

I bet you’re curious about how setting "no execute" protection on data pages could possibly make a difference to driver writers. While I guess it’s possible that you have a driver that generates code at run time and then executes it, but I’m thinkin’ that this isn’t likely to be an issue.

No friends, the real problem for certain drivers is what has to be done to enable no execute protection. NX is only available on processors that support it and then only when the system is run in Physical Address Extension (PAE) mode.

Presently, the only processors that support NX are the AMD Athlon64 and Opteron. And, yes, we’re talking about running these processors in their 32-bit mode (in case you haven’t noticed, these processors are among the most popular CPUs on the market these days - even without a shipping version of Windows 64).

PAE mode expands the addressing capability of the processor from 32-bits of physical memory to 36-bits. It does this by increasing the size of the page table and page directory entries to 64 bits, and creating a third-level page table. PAE mode was previously only supported on Windows Server products, and only enabled on 32-bit Windows systems that had more than 4GB of physical memory installed.

What this means is that starting with XP SP2, there will be 32-bit Windows XP systems with less than 4GB of physical memory that will be run in PAE mode so that NX can be used. This creates problems for drivers that:

Think they’re smart enough to directly manipulate page tables ("I’m running on XP, or a system with less than 4GB of physical memory, therefore I know the PTE layout.")?

Check to see if the system is running in PAE mode, and if it so, do something "different."

I don’t even want to think about why some drivers may try to understand the layout of the system page tables. But apparently, there are drivers that do. It makes me feel dirty. But, if you do it… now at least you’ve been warned.

There may be drivers that check to see if PAE mode is enabled and then refuse to load. This is usually because the driver has been written with certain inherent restrictions, such as no support for DMA to addresses longer than 32 bits. These drivers will have to be modified to take into account the fact that PAE mode can be enabled on systems with less than 4GB of physical memory. Note that we’re talking only about driver restrictions here. Whether or not your device is 64-bit DMA capable is an entirely different story (the HAL has always handled that for a well written driver).

The good news here is that if your driver doesn’t play with the page tables, or explicitly check for PAE mode so that it can change its behavior, you’re likely to have no problems with XP SP2. You might also be pleased to know that enabling PAE mode in Windows XP does not cause the intermediate buffering of 32-bit DMA transfers that would be previously unbuffered, or further limit the number of map registers that are available to

your driver. You can thank the guys who write the HAL for these changes. Oh, one more thing: Even when PAE mode is enabled, Windows XP systems are still limited to less than 4GB of physical memory.

Summary

To sum up, if your driver is well written and well tested, you probably don’t have anything to worry about. I don’t know how many times we have to say this: If you follow the rules, write a well-engineer driver, don’t try cute tricks to bypass the operating system, and test your driver thoroughly using Driver Verifier, your driver problems will be minimized. No matter, if I were you, I’d probably get a couple AMD systems, install XP with SP2, and make sure my driver works the way it should. Here at OSR, we’ve already done that - We know we’re in the clear.

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

"Thanks"
The information about NX is very helpful because I had thought to dynamic generate code in one of my drivers. Now it looks like I have to give up the idea.

However, just like we can enable write on a code page by remapping the page. I do think it is necessary to provide a similar scheme to enable execution on data pages.

I once ported 'Detour' from Microsoft research from user mode to kernel to implement a performance tune tool. But... XP SP2 is the end to this tool?

Rating:
05-May-04, Xinhai Kang


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