Talk:NX bit

untitled

The new version of NX remuddled everything I had split out into an unreadable mess, again. I prefer to have a sorted list of technologies from most recent to oldest rather than a huge lug of a paragraph that appears unorganized.

If nobody objects, in 3 days I'll reorganize it by pulling the old stuff back into the page, adding the new information to it, and adding in the new paragraph (ExecShield). Don't come in behind me and remuddle it again without giving proper justification, or I'll have to claim an edit war.

--Bluefox Phoenix Lucid 18:14, 11 Jul 2004 (UTC)

If you're going to rework the article, fine, but Wikipedia editors must act cooperatively. Claiming edit wars would not be a Good Thing to do. Dysprosia 00:50, 12 Jul 2004 (UTC)

in response to Bluefoxicy

If you will notice the date on my edit (16 Jun 2004) and the date on the 2.6 forward port of PaX (25 Jun 2004) you will see that I wrote it before PaX for 2.6 came out. At the time, the grsecurity project lost some sponsorship and claimed that development would cease untill a new sponsor was located. PaX is part of grsecurity and grsecurity is dead. Since I can't find any mention of PaX being forward ported, this tells me PaX is dead.

Exec-shield was introduced to LKML and Linus Torvalds himself stated that it should be included with NX turned on by default in the Kernel. Redhat funds the developer of exec-shield and it is given Linus's blessing minus the randomization feature. This tells me exec-shield is good.

Now, Grsecurity found new sponsorship and PaX was forward ported to 2.6. Additionally, I was wrong in stating that PaX does not support hardware NX. Yes, I am admitting fault. However, "threatening" to edit what I wrote and suggesting the start of an edit war is childish. I doubt the admins will smile on this behavior. I already have someone who agrees with me so please edit it to make it NPOV. This is just my 3¢

Response

I'm not disputing that ExecShield is good; I am disputing the way you presented the information. The page is difficult to read in comparison to the previous version, and has several pieces of information discarded.

Also, I made no threats; I took the nature of the edit on this article, which reduces the amount of information and the clarity of presentation, as hostile for reasons that need not be brought to public. I only intended to make clear that if I restructure the data again, I expect to not see the changes reverted, as I will not be removing or poorly conveying information. I would be forced to bring higher administration in if these changes were reversed, because I would prefer to avoid a dispute on how the data will be presented.

Thank you, however, for handing me the keys. I apologize if any of my behavior seemed irrasional or offensive.

As for the release dates, PaX has been around for 2.6 kernels for several months. It has been in existence for several years.

My opinions for several reasons are that PaX is the better technology; however, I only aim to present all data I have immediate access to in a clear and concise way in articles (discussion on "which is better" is appropriate for talk :). I'm certain that the better technology will be seen as such.

Also, you should note that although very old and complete, and in active development, PaX is not known widespread. If you enter a Linux channel such as #mandrake, #rehdat, #linux, or others, many people will ask, "What the hell is pax," when you ask a question about it. Thus, we can't comment that one is better than the other on the basis that Linus decided to add NX to the tree.

--Bluefox Phoenix Lucid 00:53, 13 Jul 2004 (UTC)

EDIT: NX is not Exec Shield :)

Data Organization

Somehow this page has to be organized. I'm thinking that a flat data organization would look like this:

== OS Name ==
=== NX_TECH Name ===

• Hardware Supported Processors: IA-32 (x86), AMD64, X86-64
• Emulation: No | Architecture Independant | IA-32 (x86)
• Standard Distribution: No | Yes | With versions/distributions: Redhat, Debian, SuSE
• Release Date: Jan 1, 9999

To do this in paragraph form, we'd need all the data, else it'd look choppy (as it does now). I'm throwing this in the current, but eh. It's ugly; of course in this case, it's nice to have a good view at first glance.

EDIT: OK, did that. We need to list ALL the processors that Exec Shield, PaX, W^X, and SP2 support. Also, need to find out more on the standard Linux NX emulation and the supported emulation archs PaX uses. Exec Shield itself doesn't emulate NX; it uses the NX patch Molnar made for that.

---

somebody else

So it took me about 12 times reading "For some technologies, there is a summary which gives the major features each technology supports. The summary is structured as below." to understand wtf was going on. It seems you are trying to summarise the differences in NX tech between different operating systems. I would suggest having a look at this page: https://wiki.riteme.site/wiki/Table_(information)

I am not sure why you it was thought that splitting all this across as many lines as possible was deemed a good idea, but I don't care enough to make it useful.

---

nobody

Take a good, hard look

I'm not sure on the current data under Linux in this article now. It's partly from something i'm discussing with someone else, and partly stuff that was already there, none of which I can personally verify. Take a good, hard look, and fix up anything invalid.

--John Moser 22:33, 17 Jul 2004 (UTC)

Removed Star Trek reference

I removed the Star Trek reference added by User:Mulad as being entirely irrelevant. This page is "NX bit", and the NX prefix in Star Trek has nothing to do with bits. I created a redirect page from NX (Star Trek) to NCC (Star Trek). If someone wants to create an NX disambiguation page, it could reasonably have links to NX bit and NX (Star Trek). --Brouhaha 17:04, 12 Oct 2004 (UTC)

NX introduction

I think that the article should say that the purpose of the NX is basically to turn code execution exploits into denial-of-service exploits. --Myria 16:47, 30 Oct 2004 (UTC)

I don't agree with that if it is worded that generally. Not all code-execution exploits become denial-of-service exploits when NX is used. For instance, suppose you attempted to such an exploit against a telnet daemon on a typical Unix or Linux system. The specific process would segfault, but there would be no denial-of-service to any other user of the telnet service or any other service on the machine.

NX also has some uses other than protecting against malicious code exploits. It can be a very useful debugging tool, both to catch cases where the code has "gone into the weeds", and by temporarily marking pages that actually are executable as NX to detect whether execution reaches those pages. --Brouhaha 18:05, 30 Oct 2004 (UTC)

this is no't very good

Any Mac OS X specific info?

I see Windows, BSD, and Linux mentioned in the software section, but nothing about Mac OS X. Could someone please add relevant info?

Windows XP Professional x64 Edition

I've added Windows XP Professional x64 Edition to the list of Windows' standard distributions because even though it was built off of Windows 2003 SP1 it is a unique version of Windows from those already listed. --Atlanta800 23:55, 23 July 2006 (UTC)

404

links at bottom of article to MSDN are no more valid Try for example links like http://support.microsoft.com/kb/875352 http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/sp2mempr.mspx

-- The "ARM Architecture Reference Manual" under the references is no up on that URL anymore, http://www.arm.com/miscPDFs/14128.pdf Nickoe (talk) 06:17, 15 May 2012 (UTC)

Default disabled in Windows is wrong

Regarding the existing sentence "Microsoft Windows uses NX protection on critical Windows services exclusively by default."

This is wrong - or true only for Windows XP. I know that Windows Server 2008 has it enabled for ALL programs by default. I don't know what's the default for Windows Server 2003. —Preceding unsigned comment added by 80.218.235.74 (talk) 21:56, 11 December 2008 (UTC)

> Therefore, Intel introduced a fresh marketing ploy by providing NX

Explain me, what does it mean, that intel introduced NX, when they just licensed AMD-conceived feature and are clear followers on this matter ? —Preceding unsigned comment added by 94.25.118.46 (talk) 06:37, 21 May 2009 (UTC)

Why this page and executable space protection?

There's the general notion of preventing modification of code and preventing execution of modifiable memory, there's the particular notion of implementing this with page-level write-enable/write-protect and execute-enable/execute-prevent bits, and there's the particular page-level execute-prevent bit on x86-64 and later x86-32 called the "NX bit" or "XD bit". I think executable space protection should describe the general concept, as well as describing various techniques to implement it, including the Burroughs Large Systems descriptors and tags, page-level write/execute control bits, and various segment-level, etc. mechanisms used to implement it on some processors that don't have the page-level bits, and this page should either discuss the page-level execute-enable/execute-prevent bits or the x86-64/x86 bit in particular. Alternatively, perhaps the two pages should be combined, under the name "executable space protection", with "NX bit" being a redirection to that page. Guy Harris (talk) 04:53, 19 March 2010 (UTC)

I agree they should either be merged or NX bit should refer only to the 386-mode and AMD64 way of providing executable space protection (and other architectures that use that specific term) while the other article should be about all architectures with this feature. Right now, the entire "OS implementations" section in both articles is identical except for minor edits and the articles are covering the same concept. 69.54.60.34 (talk) 20:36, 30 September 2011 (UTC)

Please see Talk:Executable space protection § Proposed merger with Data Execution Prevention for a related discussion. This might be a good opportunity to finally decide what should we do with these three articles (Executable space protection, NX bit, and Data Execution Prevention). — Dsimic (talk | contribs) 11:51, 9 March 2015 (UTC)

The merger is still under discussion but I'll delete the Os Implementations section as it is a copy of the content on ESP. I suggest we MERGE the Functional comparison of implementations section only, so that tis article is about the hardware feature and ESP is about the OS implementations that use NX-bit. WikiWisePowder (talk) 21:27, 3 March 2016 (UTC)

The hardware feature (page-level execution permission) in general, or the hardware feature on the particular instruction set where it's called the "NX bit" by the first vendor to introduce it? Guy Harris (talk) 22:41, 3 March 2016 (UTC)

Page-level execution permission in general (see Talk:Executable space protection). WikiWisePowder (talk) 23:43, 3 March 2016 (UTC)

Please discus this merger request at Talk:Executable space protection#Proposed merger of NX bit#Software emulation of feature and NX bit#Functional comparison of technologies into this article.