Talk:Executable-space protection

message: On google "data execution prevention" returns 356K hits while "executable space protection" returns 2700 hits. Whereas this article says that basically DEP is Windows implementation of ESP, I think it's pretty clear from Google that DEP is by far the most common term for this technique for all OS. 76.119.30.87 (talk) 18:10, 3 March 2015 (UTC)
replies: text: Just to make it clear, I don't support the original proposal to merge Executable space protection into Data Execution Prevention, but the opposite merger direction.  The fact that search for "data execution prevention" returns far more hits means nothing by itself, as the feature is widely known as "NX bit" which yields about 35,000,000 search results.  Speaking of that, we should also consider what to do with the NX bit as a separate article.  Thoughts? — Dsimic (talk | contribs) 11:44, 9 March 2015 (UTC)
thread_title:  Proposed merger with Data Execution Prevention 

message: I propose (this is a modified version of an earlier proposal btw) that we merge NX bit#Software emulation of feature and NX bit#Functional comparison of technologies into this article, so that this article is about OS implementations of executable space protection, and NX bit is about the hardware feature. Granted, this would make NX Bit a stub but it should be easily expandable. I already deleted a section of that article that was a copy of the OS Implementations section in this article. WikiWisePowder (talk) 22:07, 3 March 2016 (UTC)
replies: text: So would NX bit discuss the general notion of hardware page-level execute permission, or would it discuss only the implementation on a particular instruction set architecture that came late to the party? Guy Harris (talk) 22:38, 3 March 2016 (UTC)
replies: text:  In my opinion it should discus the general idea, as well as notable implementations. I don't think a page move would be necessary, but if it was proposed i don't oppose it. Also, what other instructuction sets (other than ARM's XN which is mentioned in the lead) suport an NX bit and under what name? WikiWisePowder (talk) 22:54, 3 March 2016 (UTC)
replies: text: I'm fine calling it "NX bit" for now, as long as it's not restricted to x86.  Other architectures that support it include Alpha, SPARC (SPARC doesn't require a particular MMU, but the SPARC v8 Reference MMU supports "read/execute/no-write" and "read/no-execute/write" permissions, and the SPARC v9 spec says that if you have an MMU it must be told whether an operation is a data or instruction reference), PowerPC (for at least some MMUs), and IA-64.  See NX bit#Hardware background - some more work may be needed on that section (PA-RISC?  VAX?  Details for ISAs that don't specify the MMU?). Guy Harris (talk) 00:02, 4 March 2016 (UTC)

text:  I think the best plan is to keep the name until the article covers the other architectures evenly and the move it. Right now I assume you suport merging those two sections right? WikiWisePowder (talk) 00:09, 4 March 2016 (UTC)
replies: text: Yes.  If people want to know about a specific hardware feature, they should go to NX bit.  If people want to know about the general concept, as implemented in a combination of hardware and software, they should go to executable space protection.  If they want to argue that "NX bit" refers to software implementations on platforms that lack hardware per-page execute permission flags, they should go to, err, umm, somebody who can explain why overly broadening the meaning of "NX bit" causes stuff such as duplication of content between executable space protection and NX bit. :-) Guy Harris (talk) 00:24, 4 March 2016 (UTC)

text:  OK, so do i merge now or wait and see if anyone else shows up? WikiWisePowder (talk) 00:30, 4 March 2016 (UTC)
replies: text: I'd wait a few days and, if nobody objects, go for it. Guy Harris (talk) 01:16, 4 March 2016 (UTC)

text: Marge started draft at User:WikiWisePowder/sandbox/ESP Merge  —Preceding undated comment added 23:37, 5 March 2016 (UTC)
thread_title:  Proposed merger of [[NX bit#Software emulation of feature]] and [[NX bit#Functional comparison of technologies]] into this article. 

message: Hello fellow Wikipedians,
I have just added archive links to  on Executable space protection. Please take a moment to review my edit. You may add  after the link to keep me from modifying it, if I keep adding bad data, but formatting bugs should be reported instead. Alternatively, you can add  to keep me off the page altogether, but should be used as a last resort. I made the following changes:
*Attempted to fix sourcing for http://www.tortall.net/projects/yasm/manual/html/objfmt-win32-safeseh.html
When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at ).
Cheers.—cyberbot IITalk to my owner:Online 19:14, 29 March 2016 (UTC)
thread_title:  External links modified 

message: Hello fellow Wikipedians,
I have just modified one external link on Executable space protection. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
*Added archive https://web.archive.org/web/20160304110012/http://dsecrg.com/files/pub/pdf/Writing%20JIT-Spray%20Shellcode%20for%20fun%20and%20profit.pdf to http://dsecrg.com/files/pub/pdf/Writing%20JIT-Spray%20Shellcode%20for%20fun%20and%20profit.pdf
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
Cheers.—InternetArchiveBot (Report bug) 03:56, 26 September 2017 (UTC)
thread_title:  External links modified 

message: So, NX is basically available when enabling PAE mode, which can be used on suitable processors, even if one wants to use only 32-bit of physical address space. This does change slightly page tables and page directories, but only a bit.
However, since 386, segmentation in protected mode, still allowed to protect against executing non-executable segments. There is a bit in GDT/LDT entries in GDT/LDT tables. (Also in IDT actually), that marks if the segment is executable or not. I believe this was used in Linux since day 0, on 386, and is still used to this day on 32-bit x86 machines. (This method can't be used on x86-64 because amd64 does forces flat memory model, and things like CS, DS, ES, SS are all set to zero, and GDT/LDT are not inspected when loading values into registers. FS, GS still do trigger checks in GDT/LDT. But, because all x86-64 uses PAE anyway, it can use NX bit in page tables to achieve the same). 81.6.34.185 (talk) 15:01, 12 January 2021 (UTC)
thread_title:  NX vs GDT/LDT entry excutableness on x86