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:
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: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.
More information regarding developer implications can be found at:Code:STATUS_ACCESS_VIOLATION (0xC0000005).
Okay... now what about you Linux folks? Well, have no fear, because the kernel has a way to take advantage of the NX bit via a patch, and is also ready for the Fedora Core...
Awesome.we'd like to announce the availability of the following kernel patch:
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
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
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.
and Linus Torvalds makes an interesting query along with a pretty good answer: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:
the kernel-2.6.6-1.411 rpms have the NX patch applied.
here's a quickstart to recompile the vanilla kernel from source with the
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....On Wed, Jun 02, 2004 at 02:13:13PM -0700, Linus Torvalds wrote:
> On Wed, 2 Jun 2004, Ingo Molnar wrote:
> > If the NX feature is supported by the CPU then the patched kernel turns
> > on NX and it will enforce userspace executability constraints such as a
> > no-exec stack and no-exec mmap and data areas. This means less chance
> > for stack overflows and buffer-overflows to cause exploits.
> Just out of interest - how many legacy apps are broken by this? I assume
> it's a non-zero number, but wouldn't mind to be happily surprised.
based on execshield in FC1.. about zero.
> And do we have some way of on a per-process basis say "avoid NX because
> this old version of Oracle/flash/whatever-binary-thing doesn't run with
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.
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....
and of course AMD's whitepapers.... oh so long....