eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
A big part of the brain surgery Microsoft is performing on Windows XP Service Pack 2 is support for new “NX” features in x86 processors. These features allow software (the Windows OS in this case) to mark certain areas of program memory as non-executable. Since a large number of remote attacks—Blaster and Sasser, for example—rely on executing code from areas not intended to hold executable code, proper use of this feature should prevent a large percentage of attacks.
The processor companies, and I suppose Intel in particular, are getting away a little easy on this. Its all hindsight, but why havent we had this feature for years? Buffer overflows have been a big problem for a long, long time, yet weve barely begun to see CPUs from the x86 world that implement the feature.
According to Microsofts explanation of “Execution Protection,” the companys name for NX support in Windows, the whole problem has to do with executing code out of areas of the program, basically the stack and heaps, that are reserved for data. This would generally be considered good software engineering practice anyway, but there are a few applications where it could present problems. For software that must manipulate code in a data area and then execute it, Microsoft provides a mechanism to mark the areas as executable.
The classic example, cited by Microsoft, is a just-in-time compiler, or JIT, most famous in the Java Virtual Machine (JVM). I asked Sun about it, and they said changes were made to the JVM for Version 1.5 to support NX and then they backported these changes to the latest 1.4.2_05 release, to be released this summer. Both the 32- and 64-bit VMs support NX.
But not all low-level software requires changes. I asked Sophos, which makes anti-virus software and also owns ActiveState, maker of Perl. Perl is interpreted rather than JIT-ed, so theres little chance it would have a problem. Their anti-virus products arent affected. Its possible to imagine certain debugger techniques causing problems, but there are workarounds for all these cases, and the tools will all be updated to mark pages as executable.
Next page: Idea not a new one.
Page Two
Its not like the idea of marking areas non-executable is a new one. Intels old 16-bit segmented model prior to the 386 had features for marking segments non-executable. Because of the nature of segments, this probably would have been worthless as a security feature, but clearly they were thinking about it over 20 years ago.
All is not perfect with NX yet. Microsoft says, for reasons I dont understand, that in 32-bit NX systems they will protect only the Windows stack, not the paged pool and other data areas. Incidentally, Linux has supported NX on AMD processors for a while now, although Im not sure whether the heap is protected.
I used to study microprocessors pretty closely, and NX seems like an obvious feature for page-level protection. The Page Table Entry (PTE), the data structure that describes a page, has lots of free “reserved” bits, and theyve been there for almost 20 years. Meanwhile, in an era where multigigahertz PCs cost less than $500 so that users can surf the Web and do word processing as fast as they could before, a major problem that could affect everyone went ignored. What other problems are being ignored like this one?
Intel especially should be ashamed. They had to be embarrassed into supporting NX in their upcoming Prescott processors after AMD added it to their own CPUs. And at first they resisted, expressing pointless concerns over compatibility problems that pale in comparison to the benefits of NX. Intel needs to take a good hard look at how they can make their processors better, rather than just faster.
Security Center Editor Larry Seltzer has worked in and written about the computer industry since 1983.
Be sure to add our eWEEK.com security news feed to your RSS newsreader or My Yahoo page:
More from Larry Seltzer