If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

SP2 to use AMD x86_64 and Opteron NX flag

MS has dumped Palladium and instead opts to "link" to AMD's NX flag in the X86_64 and Opteron processors. Why? It seems not too many people opted to use MS's Palladium (or nicely renamed to NGSCB because that name was used elsewhere according to The Register: http://www.theregister.co.uk/2003/01...es_trigger_ms/ ) because either existing code will need to be changed:

Juarez said the project is being shelved because customers and ISV partners didn't want to rewrite their applications using the NGSCB API set....

...Though Microsoft plans to use the NGSCB "compartmentalizing" technology in future versions of Windows, the company is moving swiftly to support No Execute (NX) security technology in newer AMD and Intel processors. NX reduces memory buffer overruns that many hackers exploit to insert malicious code into Windows and allows developers to mark pages as nonexecutable.

However, for some developers that use programming languages that can use this memory space need to rethink and use the heap allocated to avoid memory access exceptions such as:

which makes use of the 'NX' x86 feature pioneered in AMD64 CPUs and for
which support has also been announced by Intel. (other x86 CPU vendors,
Transmeta and VIA announced support as well. Windows support for NX has
also been announced by Microsoft, for their next service pack.) The NX
feature is also being marketed as 'Enhanced Virus Protection'. This
patch makes sure Linux has full support for this hardware feature on x86
too.

What does this patch do? The pagetable format of current x86 CPUs does
not have an 'execute' bit. This means that even if an application maps a
memory area without PROT_EXEC, the CPU will still allow code to be
executed in this memory. This property is often abused by exploits when
they manage to inject hostile code into this memory, for example via a
buffer overflow.

The NX feature changes this and adds a 'dont execute' bit to the PAE
pagetable format. But since the flag defaults to zero (for compatibility
reasons), all pages are executable by default and the kernel has to be
taught to make use of this bit.

Awesome.

Arjan van de Ven has also provided lots of feedback and he has
integrated the patch into the Fedora Core 2 kernel. Test rpms are
available for download at:

and Linus Torvalds makes an interesting query along with a pretty good answer:

On Wed, Jun 02, 2004 at 02:13:13PM -0700, Linus Torvalds wrote:
&gt;
&gt;
&gt; On Wed, 2 Jun 2004, Ingo Molnar wrote:
&gt; &gt;
&gt; &gt; If the NX feature is supported by the CPU then the patched kernel turns
&gt; &gt; on NX and it will enforce userspace executability constraints such as a
&gt; &gt; no-exec stack and no-exec mmap and data areas. This means less chance
&gt; &gt; for stack overflows and buffer-overflows to cause exploits.
&gt;
&gt; Just out of interest - how many legacy apps are broken by this? I assume
&gt; it's a non-zero number, but wouldn't mind to be happily surprised.

based on execshield in FC1.. about zero.

&gt;
&gt; And do we have some way of on a per-process basis say "avoid NX because
&gt; this old version of Oracle/flash/whatever-binary-thing doesn't run with
&gt; it"?

yes those aren't compiled with the PT_GNU_STACK elf flag and run with the
stack executable just fine. GCC will also emit a "make the stack executable"
flag when it emits code that puts stack trampolines up.

So it is just not SP2 to be making strides to better guard itself against buffer overflows and worms, but also for the Linux Kernel as well....

happy patching.

Oh one more thing... in case you programmers wanna know more about this NX bit, check out some places I am reading up on right now....