Why Was Intel a No-Show on No Execute?

By Larry Seltzer  |  Posted 2004-05-25 Print this article Print

Windows XP SP2 will include support for NX features in newer processors. Why only the newer ones? The CPU companies let us down on this.

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.

Larry Seltzer has been writing software for and English about computers ever since—,much to his own amazement—,he graduated from the University of Pennsylvania in 1983.

He was one of the authors of NPL and NPL-R, fourth-generation languages for microcomputers by the now-defunct DeskTop Software Corporation. (Larry is sad to find absolutely no hits on any of these +products on Google.) His work at Desktop Software included programming the UCSD p-System, a virtual machine-based operating system with portable binaries that pre-dated Java by more than 10 years.

For several years, he wrote corporate software for Mathematica Policy Research (they're still in business!) and Chase Econometrics (not so lucky) before being forcibly thrown into the consulting market. He bummed around the Philadelphia consulting and contract-programming scenes for a year or two before taking a job at NSTL (National Software Testing Labs) developing product tests and managing contract testing for the computer industry, governments and publication.

In 1991 Larry moved to Massachusetts to become Technical Director of PC Week Labs (now eWeek Labs). He moved within Ziff Davis to New York in 1994 to run testing at Windows Sources. In 1995, he became Technical Director for Internet product testing at PC Magazine and stayed there till 1998.

Since then, he has been writing for numerous other publications, including Fortune Small Business, Windows 2000 Magazine (now Windows and .NET Magazine), ZDNet and Sam Whitmore's Media Survey.

Submit a Comment

Loading Comments...
Manage your Newsletters: Login   Register My Newsletters

Rocket Fuel