Newsgroup: it.comp.hardware.cpu
Titolo: Execute Disable Bit in Intel Core 2 Duo processor

Hi,
It seems that Intel's Execute Disable Bit functionality can
help prevent certain classes of malicious buffer overflow
attacks by allowing the processor to classify areas in memory
by where application code can execute and where it cannot.
But, isn't it a normal functionality present in almost many
of the processors that have memory classification as
Read Only Memory and Read/Write Memory areas ?
What is so special with 'Execute Disable Bit' option and
why is it hightlighted so explicity in the Intel Core 2 Duo
processors ? Any ideas ?
Thx in advans,
Karthik Balaguru

 processors ? Any ideas ?
They do make a fuss about a single bit don't they. In a sense it is a
fix to a problem that didn't need to exist. Each code segment could
have been prevented from overlapping with data but it wasn't. As much
to the point, operating systems could have been more secure but they
weren't. For example, why should execution of any unprivileged code
whether it's in a buffer or not be able to subvert a system? Or why
should a buffer overflow be able to overwrite privileged code or data?
Neither should be possible.
Due to issues such as buffer overflow attacks the execute disable bit
has gained a marked presence in the mind of many. This single bit
definition has become a big selling point for CPUs from both AMD and
Intel. Check the Intel processor manuals for full details. I think
they are easier to read than AMDs.
By the way, I've never found a simple list of which processors support
the bit. The official answer is to use the cpuid instruction to test
for its presence.
James

for its presence.
Thanks very much for taking a moment.  I learned something about some
of the newer processors.
Jon

 Neither should be possible.
In general it cannot.  Injecting code into applications is quite
enough to do damage.

 Neither should be possible.
In general, it can't. On both Windows NT and Unix, a buffer overflow can
only subvert that process; however, that still means that an attacker can
run code under the account in question.
Windows 95/98/ME had problems due to the bottom 1MiB of physical memory
needing to be writable by all applications, so that legacy real-mode 8086
applications worked.
OTOH, "classic" Macs  (i.e. prior to the Unix-based OSX) didn't have *any*
memory protection, yet buffer overflows were relatively uncommon, mostly
due to the use of objective-C rather than C/C++.
Linux/x86 has supported a non-executable stack since before the NX bit
was added, by making the code segment shorter than the data segment (the
stack is at the top of the user-mode address space), but this doesn't work
for the heap (which is at the bottom of the address space). However, a
non-executable stack caused problems for code which uses trampolines
(this was quite common for objective-C code), and for some emulators, so
many distributions disabled this feature.
Various compiler features can guard against buffer overflows, but they
either have a memory penalty (inserting guard pages between stack frames)
or a performance penalty (inserting canary words which are checked before
restoring the saved PC from the stack).