Red Hat Introduces NX Software Support For Linux

abertoll writes "In this story at ZDnet, Red Hat has apparently added NX support to Linux. NX security technology is a hardware attempt at stopping malicious code." (We recently posted about Transmeta's announcement that its chips will incorporate the NX bit as well.)

Per-segment vs. per-page

[tepples]

Standard 386 protected mode controls per segment, where CS (code segment) is executable and DS (data segment) is writable. However, many 32-bit operating systems use a so-called "tiny" memory model, setting CS = DS, and the 386 allows for turning off read and write privileges per page but not execute privileges (if you can read a page in an executable segment, you can execute from it).

However, true W^X (shorthand for "no segment is both writable and executable") support won't work for applications that depend on self-modifying code, such as JIT-compiling virtual machines for Java and .NET platforms.

Re:Difference between NX and protected mode bits?

[Isomer]

the i386 has no hardware support for an "execute" bit. It just has a read bit and a write bit. If you have read access to a page then you can execute that code. The "NX" bit is the implementation of the "execute" bit, except when it's /set/ it prevents execution as opposed to the expected reverse, which is why it's called "NX" not "X" :)

Re:Difference between NX and protected mode bits?

[the_greywolf]

the bits you're referring to are the execute permission for segment descriptors.

the NX bit operates at page level - within segments. it is bit 63 of the Page-Translation-Table entry, and is only available in PAE mode. it is enabled by the NXE bit of the EFER ("Extended Feature Enable Register"). and it applies to all execution rings.

Re:Difference between NX and protected mode bits?

[tepples]

There's absolutely no thing as the execute bit in 386

There is, but it works on segments and not pages. Unfortunately, some i386 operating systems' ABIs are defined such that CS = DS.

The 386 architecture has one bit for access:

Your one-bit write protection applies to pages.

Comment removed

[account_deleted]

Comment removed based on user account deletion

calling it a "technology"...

[dekeji]

Calling it a "technology" I suppose detracts from the fact that the lack of an executable bit in x86 page tables is a deficiency. You see, this "feature" has been around since, oh, the middle of the last century, and many processors other than x86 have supported it without even considering it worth mentioning.

Kernel 2.6.6 included a x86_64 NX patch

[Anonymous Coward]

This new patch is to support NX in 32-bit processors or 64-bit processors running in 32-bit mode.

The 2.6.6 kernel already included an NX patch for x86_64. Details are in the "Non-Exec stack patches" LKML thread here [seclists.org].

Re:Difference between NX and protected mode bits?

[AKAImBatman]

People, do yourselves a favor and read the Intel specs. Please? There is in fact, a bit for defining code segments. These code segments can be marked as read only or execute only. The problem (as I managed to wrangle out of people the LAST time this thing was posted) is that a data block can also be executed without exception. The NX flag merely prevents data blocks from ever executing code.

Here you go...

[SoSueMe]

Some legitimate programs, such as Java compilers that perform just-in-time code generation, execute instructions within data areas -- and will have to be rewritten for Service Pack 2. But the most common exploiters of x86 architecture's porous program and data boundaries are applications (called, as a matter of fact, exploits) that perform buffer overrun attacks -- one-two punches that first flood a program's input area with more data than it's designed to handle, then deliver a poisonous executable payload. ..........

Software developers will be able to selectively disable execution protection for 32-bit applications, using a DisableNX fix in SP2's compatibility toolkit, and end users will be able to switch the feature on and off for the entire system or for individual applications (like those Java compilers) via a new Control Panel dialog box, similar to those for SP2's beefed-up firewall .

Re:no execute support new? Nonsense !

[tepples]

From what I've read, NX support on older i386 CPUs either 1) puts all of a process's code below the code segment limit (1 GB) and all data above that, with an unmapped gap in between [neohapsis.com], or 2) hooks into the translation lookaside buffer (the cache for virtual memory page table lookups) at a speed cost.

definitely helpful but no silver bullet

[The_Bagman]

This is basically an "execute / no-execute" bit in the page-table entries. It means the OS can mark portions of an application's virtual address space as non-executable - such as pages in the heap or the stack. It'll help against buffer-overflow attacks that put new assembly code in the stack and return into it. It won't help against buffer-overflow attacks that return into existing code (e.g., to do a system call). It won't help against worms that take advantage of meta-character expansion vulnerabilities. It won't help against scripting flaws (such as javascript, active-x, or visual-basic/outlook vulnerabilities). It won't help against weaknesses in the OS itself.

Think of this as raising the bar. Of course, the "clever" attackers will still find flaws, and still write code for the script kiddies to use to exploit them.

Re:Difference between NX and protected mode bits?

[AdamInParadise]

I beg to differ.

All modern architectures implement all 3 different protections bits (read, write, execute). It should have been implemented a long, long time ago, and you definitely cannot emulate it perfectly in software.
I don't known why it wasn't implemented from the begining or at least when the 386 was released, but it was sorely missed by everyone working on improving the security of an OS. I guess Intel didn't think that this architecture would survive in the 21th century.

So adding the NX is a long overdue fix which should really improve the security of PCs, if it is used correctly by the OS.

Regards,
David

Re:Fine No Execute

[0racle]

NX is not a new thing, and neither Intel or AMD did it first. SPARC's, UltraSPARC's and Alpha's have had this for some time, and it wouldn't surprise me if its in the Power chips as well.

As far as it not being on older processors, I assume you mean older ia32's, and surprisingly this was brought up in a MS TechNet event I was at on Thursday. I don't know all the details, but he presenter said it was in older chips, at least back to the original Pentium if I remember, but with the way ia32 chips do paging, it was never implemented in the OS's until recently, which i can only assume the Athalon64, Opeteron and Itanium do this differently, but don't quote me on that.

Personally, I'm just wondering exactly what ia32 chips will Linux and OpenBSD use NX on.

Re:Difference between NX and protected mode bits?

[astroboscope]

Ultimately in the end, we will lose performance because they are adding overhead to general processing.

Point taken, but if NX cuts down on the worm/virus/virus notice email we get because of infected Windoze systems, it'll be a performance boost for us UNIX users.

Re:no execute support new? Nonsense !

[sirsnork]

For the record. Only AMD64 based CPU's currently have support for this on x86. Intel and Transmeta's next generation chips will also support it. No previous CPU's will.

Re:JIT Compilation/Interpreters

[Anonymous Coward]

The JIT Compiler writes its output into a writeable data segment. Then the JIT controller makes an operating system call to change the mode of that segment from "writeable data" to "unwriteable code". Then the JIT interpreter runs the "unwriteable code".

Exciting news...

[rice_burners_suck]

I'm glad support for this is finding its way into Linux. I think OpenBSD has had this for a while now, as part of ProPolice... I'm not sure about that though.

From what I've read, it certainly makes sense to break a few apps for this functionality, as you can always run them in a build without it. Things should be a lot safer, as crap like buffer overruns from carefully formatted input strings can no longer contain executable code.

I think this should be available for individual programs to set the NX bit on memory pages that should only contain data, so, for example, when you download a file, it is impossible to execute it (say, while in memory) until you save it and explicitely set the execute bit. In other words, there is a completely non-executable path for all untrusted code from its inception until the user explicitly makes it run. Now, when some Joe Luser clicks an email attachment virus made for Linux, if this ever happens, it will be very difficult for him to make it run, and hence, it won't. Add to that the protections inherent in all Linux systems (multiuser permissions, heterogeneous configurations, etc.), and it's very unlikely that Linux users will experience the kind of crap that Windows users have to put up with on a daily basis, even if Linux somehow gains a huge market share on the desktop.

These are exciting times.

Re:A Problem or Not?

[lachlan76]

The malicious code is the code which runs in an area of memory where it shouldn't be (meaning executes a buffer-overflow attack).

Re:no execute support new? Nonsense !

[Anonymous Coward]

OpenBSD is able to do this a Sparc and Sparc64 (and AMD64), since they support a per page no execute bit. Through devious cleverness, they were able to achieve similar functionality (not quite as good, but certainly an big jump on other OSs on the same architecture) even on i386 (which doesn't have a per page execute bit).

Re:Here you go...

[m_pll]

Some legitimate programs, such as Java compilers that perform just-in-time code generation, execute instructions within data areas -- and will have to be rewritten for Service Pack 2.

Of course, if those programs were written correctly in the first place they wouldn't need to be fixed to work on NX platforms.

Win32 has always had PAGE_EXECUTE flag [microsoft.com], and if you wanted to execute dynamically generated code you were supposed to include this flag when allocating memory [microsoft.com] (or use VirtualProtect afterwards).

Most people didn't bother with PAGE_EXECUTE because it wasn't enforced on x86. But technically it's always been required.

Re:NX and Self Modifying code

[Animats]

Modern x86 CPUs go to incredible lengths to support self-modifying code. PowerPCs, by comparison, don't support it at all; they have separate instruction and data caches. If you modify code in a PowerPC, you have to flush the instruction cache or it won't work. There are system calls for this under the MacOS. And nobody notices. In fact, the PPC 601 didn't even have the instruction cache flush instruction. For some years, Linux for PPCs had to flush the cache by preventing interrupts and loading a big block of junk data to invalidate the entire data cache. About the only time this is done is during fork/exec sequences.

There's some history of self-modifying code from the 16-bit DOS world, but it's probably time to kill that off.

It's been a long time since self-modifying code improved performance. Today, self-modifying code on an x86 machine works something like this.

• The processor is going along, fetching ahead perhaps ten instructions, and executing as many as possible simulataneously. Ten to twenty instructions may be in the pipelines. The retirement unit is running ten to twenty cycles behind the execution units, committing results back into cached memory and registers once all possibility of trouble has passed.
• Trouble usually comes in the form of mispredicted branches, which are handled reasonably efficiently using cached bits that record which way the branch went the last few times. Less common is an exception, like a floating point overflow, which looks like a forced branch. Least common is a modified instruction.
• The superscalar x86 machines (Pentium Pro/2/3/4 and later) check for modified instructions. Storing into an instruction immediately ahead will be handled properly. People on the Pentium Pro team sweat blood over making this work right. And it does work. But not rapidly. The retirement unit views the instruction as an "operand" for collision detection purposes, so a change to that "operand" invalidates all the results that depend on it.
• The CPU then has to deal with the mess. Retirement stops. Instruction fetching stops. The pipelines are flushed. The functional units are idled. Instruction fetching is backed up to the modified instruction and restarted. The CPU pipelines refill with the new program. After a few tens of cycles have been lost, instruction execution is moving forward again.
• In AMD land, it's even worse. AMD's approach to superscalar CPU design involves expanding instructions into a RISC-like fixed length form at cache load time. Storing into an instruction not only requires flushing the CPU, but the whole block of instructions has to be reparsed.

So, in general, self-modifying code is not going to help performance. Generating blocks of code and then making them executable is fine, but changing code you're about to execute went out with "ALTER paragraph-name TO PROCEED THROUGH paragraph-name" in COBOL.

Re:Fine No Execute

[kasperd]

somehow there will be an override and the day the override is used the virus

First of all you shouldn't expect the NX bit to do any good against a virus. A worm OTOH might be stoped by the NX bit. OK I'll assume you mean the worm would use a way to override it. If it could be disabled per executable like execshield on Linux, you could only exploit vulnurable programs with the security feature disabled. So if the vulnurable service is running with the security feature enabled, you cannot disable it, unless you already control the machine. So it doesn't help a worm gaining control.

What are the chances the vulnurable service would run with this security feature disabled? Not large, because you would only disable it, if the service didn't work otherwise. And the number of programs breaking in case of Linux is not large. Fedora Core 1 has exec shield which does a best effort at implementing this without specific hardware support. Arjan van de Ven explains [google.com] that hardly any program broke. Ingo Molnar explains [google.com] in a bit more detail, that the X module loader was the only program breaking. (Some other programs broke for other reasons). So when it is only one program breaking, you fix it, rather than starging to disable this security feature.

However as Linus has explained, there are ways to exploit a vulnurable service in spite of NX. This specific attack relies on using /bin/sh, which means it wouldn't work against Windows. But anybody who knows as much about Windows as Linus knows about Linux would surely be able to come up with a similar attack against a Windows service. For example there is probably a function you can call to change the protection bits on a memory range. So you first fill code in the buffer, which cannot be executed at the moment, the return address you overwrite with a pointer to this function call, and you provide it parameters specifying to make the buffer executable. The return address from the function call then just needs to point to the buffer.

Re:Difference between NX and protected mode bits?

[awkScooby]

People, do yourselves a favor and read the Intel specs. Please? There is in fact, a bit for defining code segments.

Linux, Windows, BSD, etc. don't use segments, but instead use paging. Intel has dragged their feet on adding NX support because the feature "already exists", but the reality is that hardly anyone uses segments.

Ok, technically everyone uses segments -- they just create a single segment which covers all of the memory space. The GDT (Global Descriptor Table) must be configured when you switch to protected mode. Paging is optional.

The NX flag prevents a page (typically 4k) from executing. By marking all stack pages as NX, buffer overflow attacks won't be able to remotely execute arbitrary code. I assume that an exception will be generated when an attempt is made to execute from an NX page, which will probably cause the running program to halt. So, remote explots turn into DOS attacks.

Buffer overflow attacks have been known about for decades, and solutions such as NX have been known for quite some time too. As has been mentioned elsewhere on /., this does not remove the responsibility of developers to write good, secure code. But, as history has shown, they will probably continue with the long standing practice of writing insecure code.

NX will prevent buffer overflow attacks. NX will not be able to determine whether a program you choose to execute is good or evil. Viruses existed and managed to propogate back in the days before the Internet or even networking were in common use. NX won't solve all security problems, but it is a good tool to help reduce the possibility of remote exploits.

The NX flag isn't new, it's just new to the x86 world. Kudos to AMD for being the first to add this to the x86!

Re:Fine No Execute

[IamTheRealMike]

Personally, I'm just wondering exactly what ia32 chips will Linux and OpenBSD use NX on.

New ones. People will buy them because they want "Enhanced Virus Protection".

In the case of older chips: well, that is what exec-shield is for.

Re:NX and Self Modifying code

[Alan Cox]

Under Linux at least you can ask for executable mapped pages. This is what the fixed X loader does for x86 now. Most non x86 processors have execute bits on page table entries and POSIX/SuSv2 therefore have a MAP_EXEC bit in mmap so you can say "I want to run this"

Re:Per-segment vs. per-page

[Alan Cox]

NX is page table level. It is very hard to make use of segment based protecting in operating systems using 32bit flat paging modes (like all of the modern ones). Solar Designer produced some patches that try and do this at least for non exec stack but they require magic kernel side exception fixups.