Ingo Molnar announced the availablity of support for AMD’s NX, or “no execute” bit for the x86 architecture. Originally introduced by AMD with their Athlon 64 and Opteron processors and marketed as Enhanced Virus Protection, Ingo notes that support for this new bit was also announced by Intel, Transmeta and VIA.
Linux: x86 No Execute Support
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
The Linux kernel gets hardened a little bit more. Good news.
Note that the nx bit was present in the original x86 architecture, but it took Andi Kleen’s (chief developer of the x86-64 Linux port) foresight to get the first implementation up and running.
The good thing is that this extra security is now available on my “lowly” 32-bit Athlon Linux box.
Does the NX bit really differ much from the per page execution permissions present in SPARC, SPARC64, Alpha, etc.?
>The good thing is that this extra security is now available on my “lowly” 32-bit Athlon Linux box.
No, it isn’t. Athlon’s don’t have per page execute settings. The PAX project on Linux and W^X on OpenBSD acomplish something similar, but it’s not the same. If you want per page execute settings get an AMD64 or, better, a Power5 box
x86 has segment based permissions. Not as good as the per page permissions, but it’s something. PaX and OpenBSD support it to varying degrees.
If you want per page execute settings get an AMD64
or 32-bit Athlon based on AMD64 tech. AMD said they were going to release those, and I think HP are selling them in their system.
Pretty sure those aren’t out yet. socket 754 32bit athlons should be out sometime, and socket a low end processors should also have NX in the future. But not yet.
now as soon as the market gets flooded with chips that fully support this feature it’ll be great news
x86 has had a no execute bit in protected mode since the 286. I know that’s per segment, not per page, as the developers seem to want it, but what’s wrong with per segment? Make your code segments r-x and your data (and stack) segments rw- and you’re cool. What am I missing?
Ok, maybe I should have put that more accurately.
In protected mode, a segment is either code or not. Code segments are always executable, but never writeable. Non-code segments can be writable, but are never executable. Other architectures have permissions set on a per-page basis. My question is what makes the per-page approach so much superior to the per-segment approach.
Take a look at some of the PaX documentation, that should explain it thoroughly. But I think the big thing is the granularity of the control. Segment based just does not provide the support that per page execution permissions do.
Back in the days of the 286, segments were limited to 64k due to the 286 being a 16 bit processor. Around that time, there were various non-Intel 32 bit chips, none of which supported segments. Around that time, everyone made the following associations in their heads:
segments = 16 bit = bad
paging = 32 bit = good
The 386 offered 32 bit segmentation, and also supported paging as an afterthought. Because of those previous associations, everyone ignored the segmentation and went with paging. Nobody really cared that 32 bit segmentation is really powerful, and that Intel’s paging implementation blows (notice the lack of a no execute bit until now).
Thanks, I stand corrected.
BTW the link to the PAX project page is:
http://pax.grsecurity.net/
Yeah but will there ever be some way to keep my co-workers, parents, and newbie user friends from opening & running every attachment they get in their mail and installing every piece of shit banzai buddy thing they can get hands on?