Talk:PaX

Questions?

Anyone have any need for knowledge that I didn't fill? This is a basic rundown of what PaX is and does, and I'm no expert.

PaX bad for non-C programs

It should be noted that PaX breaks a lot of applications that try to manage their own heap, i.e. by using a garbage collector. Notable examples include SBCL and CMUCL which try to setup a heap layout that conflicts with address space randomization of PaX. The funny thing is that PaX is completely worthless for these Lisp compilers, as it is practically not possible to produce buffer or integer overflows. --Boelthorn 22:55, 18 July 2006 (UTC)

Anon author; not good?

"PaX at the time of this writing is not in the mainline kernel because The PaX Team does not wish to advocate it for mainline inclusion at this time."

... not to mention that, in the wake of the recent unpleasantness, the chances of Torvalds accepting an anonymous patch are zero? That was the very first thing that sprang to my mind when I saw the authors were playing anonymity games. I mean, wtf? Why the anonymity? There's going to be something relevant to discuss there. This is not normal practice, at all - David Gerard 06:46, 15 Jul 2004 (UTC)

It's ok to be anonymous

Whether I'm SCO Group, Jason Voorhees, or John Moser, the same rules apply: I release my work, I license my work, I hold the copyright. If an anonymous contributor releases his work under the GPL or BSD license, he has as much a chance of suing you as a non-anonymous contributor. It's the license you need to worry about, not the man's name.

Also, it's perfectly acceptable to remain anonymous; I didn't give up my name until a few months back. He shouldn't be forced to give up his by the open source community; although it's up to Linus if he wants to put PaX in the kernel.

--Bluefox Phoenix Lucid 16:39, 16 Jul 2004 (UTC)

BUT, anonymity looks suspicious, and in the absence of anything sensible to do, going after the suspicious looking always tempting. Thus, it's not entirely irrelevant in practice. ww 19:14, 21 Jul 2004 (UTC)

--WpZurp 06:43, 11 Aug 2004 (UTC)

Or, to be more blunt, anonymous contributors are not necessarily the creators of the source code. The anonymous contributors could have swiped the source code from someone else and, thus, aren't even legally entitled to place the work under GPL. To be even more paranoid, SCO could covertly leak source code to these anonymous contributors and then entrap Linux for copyright violation after including PaX. Wikipedia is safe (we hope) because contributions come in dribs and drabs but including a substantial project like PaX into the Linux kernal is like being offered a poisoned apple.

A good legal (though paranoid legal) point. Since legal paranoia is an important aspect of legal reality, it's a significant one. In this case, however, Linux (Linus) could presumably demonstrate a lack of intent which would militate against the worst (most paranoid) penalties. On the other hand, it could be claimed that acceptance of the anonymous (though un permissioned) code demonstrated a lack of reasonable diligence against this sort of possibility. Insufficient paranoid practice by Linus, in effect. Which would militate for increased penalties.

I sound like a lawyer don't I? On the one hand..., on the other hand..., and so on. The only thing missing is the large billing. It may be that in many respects, Shakespeare had it right.

On a related subject, it does appear -- as nearly as my sensors can penetrate the fog of litigation (Clauswitz should have been a lawyer) -- that SCO (nee Caldera and so on) is digging a deeper and deeper hole for themselves. And the collapse will be most spectacular, and vastly amusing, when it comes. Soon, soon... ww 13:42, 11 Aug 2004 (UTC)

clarity edits

Blue, I got some time sort of free and went through the first couple of sections doing clarity edits. I trust I haven't so grossly misunderstood something that I've lost meaning. And I hope that clarity has been increased; some unfelicities of language are at least corrected. The cost (aside from time) is some additional verbiage giving some of the background the less than expert might find useful. Tell me what you think. ww 19:14, 21 Jul 2004 (UTC)

Needs work ;)

Pretty good. You've been helpful :) Though, you or the other editors have added factual and grammerical errors, or misleading statements; whoever said "no data is lost" is FLAT WRONG, because you can't save application data in the middle of a PaX kill ;) But the stuff is salvagable and mouldable into a better form than before :)

I guess I"ll have to give this a hard re-read later and clean up :)

--John Moser 16:12, 22 Jul 2004 (UTC)

copied from featured article cand comments

please ensure that comments and changes are entered at Wikipedia featured article candidates, it is not sufficient to do so only here.

From the FAC:

=== PaX (Linux) ===

Contested -- July 13

self-nomination

PaX is an article about a security patch for Linux. I enjoy using PaX, and wished to show my support by writing an article on it. As the article is well written, and work that I am particularly proud of, I felt I could nominate PaX for FA.

The article is very accurate, as I've written most of it from my experience and from data I've read on PaX, and have had the developer run over it for me to make sure there were no factual issues.

Even though I am a hardcore PaX supporter, I leave my personal feelings about PaX out of the article. I believe that I can best support PaX and the diffusion of information about it by avoiding any propagandist slur or influence in the article itself. My goals are to present a complete and concise description of what PaX is and what it does, and I believe that I have achieved this in PaX.

I believe that the article is written in such a way that it only presents the user with complete and concise information about what PaX is and what it does, and leaves him with only deep technical questions which can be answered by visiting the PaX homepage--linked to in PaX--and reading through the several pages of technical documentation. This is exactly what an encyclopedia is supposed to do.

--Bluefox Phoenix Lucid 04:10, 14 Jul 2004 (UTC)

• Object. My general impression is that this is a long way off from being a feature-worthy encyclopedia article and currently reads like a piece of technical documentation. I'd recommend a spell on Wikipedia:Peer Review first. Some specific problems: 1) Who is the author of the patch? The article should mention this. 2) The lead section is incomprehensible to a non-specialist, even to a computer science graduate. It's OK for a Featured Article to be technical, but the lead section should provide an overview, and provide definitions or wikilinks to essential concepts which might be unfamiliar for the reader. 3) Moreover, throughout the article, more links need to be given to technical concepts mentioned, even if the articles don't yet exist. 4) Any famous users of this patch? — Matt 04:34, 14 Jul 2004 (UTC)
  • Explain (2) please. Do computer science graduates not know what occurs inside a computer? Particularly, do they not understand the basic concepts of memory managment and virtual memory? Or does "Least Privilage" confuse people? Nonetheless, I concede that somehow I managed to spit out incomprehensible gibberish grammerically. This has been rewritten. --Bluefox Phoenix Lucid
    • Sure; computer science graduates do indeed have at least a vague idea of what goes on inside a computer. However, there's probably few who could understand "Executable Space Protections to take advantage of or emulate the functionality of an NX bit; and Address Space Layout Randomization to obfuscate ret2libc" without further explanation, and the article currently offers no way of finding out the meaning of the undefined technical terms. — Matt 19:45, 14 Jul 2004 (UTC)
      • Check my work, I've added a wikilink but the page doesn't exist. Also, check currently section 1.1. --Bluefox Phoenix Lucid
  • I think I satisfied (2) and (3). Please check my work and strike if you agree. --Bluefox Phoenix Lucid
  • (1) and (4) I've satisfied. --Bluefox Phoenix Lucid
• Object. I agree with the above objections. Also, the article is lacking a discussion of why PaX is significant. The feeling I get from the article is almost that PaX is just one security patch that implements several ideas implemented by other people. Does PaX make a technical contribution? Is there a significance to how it affects society? What's the impact? Without being POV, of course, the article needs to make the argument. Zashaw 05:06, 14 Jul 2004 (UTC)
  • I can't help your "feelings" that you get from the article. I show what PaX supplies. It supplies a lot, and there's no reason why supplying more than one thing should imply that you stole the ideas or code from everyone else. The best I can say is, look at the date given in section 3 for when PaX came around. It grew from there. --Bluefox Phoenix Lucid
  • Added section 1. --Bluefox Phoenix Lucid
    • I'm comfortable withdrawing my objection. I found section 1 very helpful. One thing it doesn't address is how PaX differs from other security patches or schemes, both for Linux and other OSs. I know little about the area, but would think that there must be other similar patches, and something contrasting PaX somewhat more would be nice. On a related note, it'd be nice to know if the schemes that PaX implements are new to PaX, or if they've been around before, but were just integrated into PaX. Zashaw 21:11, 23 Jul 2004 (UTC)
• In addition to that, it needs information about 'why the patch is needed'. Why isn't it in the mainline kernel? Morwen - Talk 06:22, 14 Jul 2004 (UTC)
  • As I understand it, the author isn't ready to advocate PaX for mainline yet, as it doesn't work on all architectures. --Bluefox Phoenix Lucid
  • I noted this on the article now in section 1. --Bluefox Phoenix Lucid
• Object as of this date's version. The article covers a signficant approach to a serious problem, has more than merely Linux relevance, and deserves a WP article. There is, buried in the version of this date, a possible featured quality article. The technical issues cannot be described without some obscurity to the previously unexposed and so this is acceptable in such an article. However, even so technical an article can be structured as to help such a Reader. This version is not. Newspaper pyramid structure is redundant, overly wordy and repeats too much, but it does put the most approachable account right at the top. This article does not do so, and for so technical a topic, this is a major problem for the Reader not already familiar with the topic. There is some discussion of the virtues of good 'narrative arc' in articles on technical topics at Talk:Secret sharing which may help illuminate my objection. ww 20:24, 14 Jul 2004 (UTC)
  • OK, this interests me. Would you be willing to help with this? The most important part of an article is its factual accuracy (which implies NPOV), but a very close second (almost a gemini) is how well it conveys the information to the reader. If I'm missing on one of these points (you say the second), that's bad. Should I move section 1, Why PaX is significant, to the top? --Bluefox Phoenix Lucid
• Illustration needed. A diagram helping explain the concept to the less technical reader would do nicely. - David Gerard 21:34, 14 Jul 2004 (UTC)
  • Bask in the awesomeness of my obvious lack of drawing skills :) --Bluefox Phoenix Lucid
  • I misread the instructions earlier and have been striking out peoples' objections as I satisfy them. Please strike this one if you find the diagrams adequite. --Bluefox Phoenix Lucid
    • Those are just what I was thinking of :-) Now I would like a shrubbery something theoretically main-page-friendly. That's not an objection to FAC status, btw, just a request for a nice bit of eyecandy. - David Gerard 10:32, 15 Jul 2004 (UTC)
      • I'll see if he'll let me use the PaX Tux.  :) --Bluefox Phoenix Lucid
      • Anyone is free to prettify my diagrams; but you should note that the simplistic display brings more attention to what it is rather than "ooh eye candy. . . wtf was this supposed to be?" Go ahead and make wavy, curvy, 3D cute things if you like; but try not to make it less point-in-face.  :) Also try to keep the same size. --Bluefox Phoenix Lucid 16:17, 16 Jul 2004 (UTC)
• Not an objection: A bit more on why the authors want to remain anon would be appropriate. Particularly given that, in the wake of the recent unpleasantness, the chance of an anonymous patch ever getting into the kernel is zero. This sort of behaviour from an open source author is more than just somewhat odd, it's distinctly weird - David Gerard 10:32, 15 Jul 2004 (UTC)
  • He says, "tell him 'just because' ;P" --Bluefox Phoenix Lucid
    • How convincingly childish of him - David Gerard 20:11, 15 Jul 2004 (UTC)
      • No law says he has to give you his name. I've only recently released my name to the public. --Bluefox Phoenix Lucid
        • FIGHT THE POWER!!!1!1!!!!11! FUCK YOU I WON'T DO MY HOMEWORK! as the band sang. No, but it has helped form my opinion of him - David Gerard 22:10, 16 Jul 2004 (UTC)
          • Now you're just being childish. --John Moser 05:17, 17 Jul 2004 (UTC)
  • He also says, "also tell him that i don't want to get pax into the kernel," which is noted in the article --Bluefox Phoenix Lucid
• Object. There's been some good work on this article, and its improved loads. I particularly like the "Address space layout randomization" diagrams. However, I still think there's a few problems: 1) The "History" section is currently just a snippet from a HISTORY log file; could we rework this into an actual narrative paragraph? It would also be useful to have some dates in the lead section, too. 2) What's a ret2libc attack? 3) Do we know why it's not advocated for Kernel inclusion at this time? Does it need further development? 4) What other patches are available that do the same work as PaX? 5) How effective is PaX at preventing shellcode and "ret2libc" attacks? Completely? Mostly? — Matt 00:42, 20 Jul 2004 (UTC)
  • I'll do quick answers for now, back to the article later. --John Moser
    • The snippet from the history logfile is a primary source, I thought that would be nice in leui of a wordy paragraph about how old PaX is.
    • Dates in the lead section. You mean the section before Section 1, right?
    • ret2libc hasn't been written; but the term basically means, "Return To libc." The idea is that you overflow a buffer, write the address of, say, mprotect() (hence the restrictions to mprotect()) or memcpy() (nasty idea: memcpy() repetedly to call memcpy() and cause an infinite loop or data corruption) to the return address. When the function exits, that function is called. This is not injecting code.
    • The PaX Team does not wish to advocate. I believe they have their own reasons; but the most I've heard is something about it only working on a handfull of architectures (see NX) instead of *ALL* architectures (see every arch Linux supports).
    • Try "See Also," you'll see Exec Shield. That's only similar, though.
    • Shellcode/code injection, completely with full restrictions. Ingo Molnar (author of Exec Shield) repetedly states in e-mail that PaX is "finegrained protection;" rather than just supply an NX bit, it supplies a policy that basically ammounts to, "You will not have any memory executable after it's been writable. This is not negotiable." This policy removes the possibility of executing any memory that can't be guaranteed to have never been writable in the life of the process, which is essential to code injection. The restrictions disallow W|X as well as adding PROT_EXEC (aka 'X') where it didn't previously exist. Logically, this is 100% effective UNLESS the attacker can create a shared library and then mmap() it in with executable permissions (if he can, he's good).
      • The "Executable space protections" section is now clearer on this. It explains the policy on memory that PaX implements, and leads the reader to the conclusion (which is also handed to them) that code can not be injected into the program. --John Moser 07:33, 21 Jul 2004 (UTC)
    • As for ret2libc attacks, you have to find some odd way to map out the executable space remotely to succeed, or else have God on your side, severely. If you have local access, there's /proc/(pid)/maps; but there's a patch that blots out all the useful information from THAT as well. Unfortunately, this patch "doesn't belong in PaX" :) Interestingly enough, if the attacker can't find various libc functions to do a ret2libc attack, he's pretty much scrsewed on the above idea of creating a shared lib and mmap()ing it in.
• Object. After reading the article, I can't tell if PaX has anything beyond emulation of the NX bit. The intro seems to say it also marks program memory as non-writeable. Is that different from the NX bit? How? How does PaX compare to the other NX implementations like W^X? and Exec Shield? Also, understanding of one of the major features of PaX as you have written it is dependent on knowing what a ret2libc attack is and even what ret2libc itself is. - Taxman 01:09, Jul 20, 2004 (UTC)
  • PaX, as stated above, implements a finegrained memory protection policy which goes beyond the other two. The point of PaX isn't to just add an NX bit; it's to keep little 12 year old bastards who think they're l33t because they can download some bash script and crash your webserver OFF your computer. PaX has an effect even if there already is an NX bit, as indicated by PAGEEXEC: "PAGEEXEC uses or emulates an NX bit." I guess I should repeat that it uses a hardware NX bit if available. I'll have to mention this in the article I guess. --John Moser 06:53, 21 Jul 2004 (UTC)
    • The "Executable space protections" section is now clearer on this; it's not a direct answer, because I want to stay away from "PaX Is God, ES and W^X suck" on the article. --John Moser 07:33, 21 Jul 2004 (UTC)
      • That kind of advocacy is not what is called for. But a concise section mentioning the basic differences between the approaches is fairly critical to the article. How is PaX "beyond the other two"? We are after all talking about approving this as one of Wikipedia's best articles and that should be a pretty high standard. - Taxman 20:08, Jul 21, 2004 (UTC)
        • Ingo Molnar points out in an e-mail conversation that on i386, the emulation ("approximation") tracks the upper code segment limit, and that mprotect()ing a high memory address (the stack) takes away ALL protections on lower memory. Also, he notes that PaX is more fine grained. In short, I can't really do it without pointing out that PaX is simply more secure. Molnar says that Exec Shield breaks less; but really, the toolchain has to mark binaries with PT_GNU_STACK/HEAP (we can make the toolchain do this for PaX, too) to provide a by-default nonexecutable stack. Very little breaks, under either situation. When things break under PaX, someone (the person writing the Makefiles for the apps, the distro provider, or the system administrator) has to mark the binaries with chpax and/or paxctl. --John Moser 04:33, 22 Jul 2004 (UTC)
        • It can be noted that PAGEEXEC uses the same technique now as Exec Shield, as a PERFORMANCE BOOST; and then falls back to the original, high overhead method under situations where Exec Shield would lose protection. SEGMEXEC I still (unoficially) measured at 0.6% scalar overhead. Again, I'm basically saying, PaX is more secure and accurate than ES, which basically means that ES sucks (from a security standpoint). --John Moser 04:33, 22 Jul 2004 (UTC)
        • OK, there's a new section added before the History section. --John Moser 05:43, 22 Jul 2004 (UTC)
          • All that is good stuff. Still nothing on W^X and whether PaX offers anything that isn't in OpenBSD by default, or at least how the approach differs and advantages/disadvantages. For a patch that is not in the main kernel and no likelihood of it, you've set a high bar for what the article needs to cover in order to be featured. Good work so far though. Just try not to get frustrated at criticism of your article. It is what can make it a great article. Besides, I'm not asking for 5 paragraphs. One or two concise ones would do. - Taxman 22:34, Jul 22, 2004 (UTC)
            • Heh, gimme a break here man.  :) W^X is OpenBSD, PaX and ES are both Linux. I think trying to compare with W^X may be a little out of scope; Exec Shield could actually be viewed as a competitor of sorts, whereas W^X could no more compete with PaX than PaX could compete with Windows XP SP2's NX code. Also, W^X and Exec Shield are similar technologies; but I know even less particulars about W^X than about Exec Shield (which I gathered my data about over e-mails with Ingo Molnar). --John Moser 22:54, 22 Jul 2004 (UTC)
  • What a ret2libc attack is is outside the scope of the article. I don't define shellcode or virtual memory or anything else. The article doesn't exist for ret2libc? I can write a stub, but that's it. --John Moser 06:53, 21 Jul 2004 (UTC)
    • That stub is fine, we just need something in that case. As I look at it again, the lead sentences in What does PaX offer does give the gist of what ret2libc attacks are all about. - Taxman 20:08, Jul 21, 2004 (UTC)

suggested dab improvement

jm, References in the article to system calls or library calls might be well if they were set off typographically. I suggest that they be put into a monospaced typeface, which is a sort of standard for executable code in the book design world. I understand this will be a bit of work, but with an article of this technical nature, everything that can help the reader's mind get around the material is worthwhile. In fact, that's the writer's burden regardless of the article. Anyway, I thought I pass on the thought. ww 13:34, 23 Jul 2004 (UTC)

Monospacing

Sure, how do you do monospacing?

Also, nice with the clarity; although I need to keep up behind you for things that you keep getting wrong or making bad grammar out of :p It's really helpful despite the rough edges though.

--John Moser 01:25, 25 Jul 2004 (UTC)

jm, Sorry about errors. I've been trying for conceptual clarity not absolute precision, as is evident. As for grammar, I trust (fervently hope, really) that they're typos. As for monospacing, it's something like (from memory now...) stuff . A look at one of the programming examples (eg, sort algorithms) will betray the trick exactly. ww 19:12, 26 Jul 2004 (UTC)

Impact on performance ?

I saw you request for peer review. I kind of remember that some programmers use (or used ?) self-modifying programs to improve the performance of critical codes. I guess that this would be impossible with PaX. Shouldn't it be discussed in the article ? Or is it just an old technique that nobody uses anymore ? Pcarbonn 19:21, 28 Jul 2004 (UTC)

Pcarbonn, Some languages allow self-modifying code (eg, changes in calling parameters, jump sequences, etc) but the dangers inherent with humans using such techniques has made such languages far less popular than they used to be in former times (when dinosaurs roamed the machine rooms). Some hardwae architectures (eg, at lease one early HP series) depended on self modifiying object code as well; if I recall correctly, the subroutine mechanism worked that way on those machines. The problem is that it's hard enough to get non mutable code working right; changing code on the fly is much trickier. The position that such code is more efficient (in time or resources) is no longer tenable. Memory is cheap (size, cost, power consumption, ...), and easily available (cost, power consumption, ...) processor speeds are such that such arguments rarely make economic sense anymore.

PaX makes the assumption (at the operating system memory management level) that some areas in memory can be known at process setup time (and later on as memory is assigned and freed) to be read only for some process(s), and that preventing such access by others improves system security. Given the ubiquity and persistence of malware and malware writers, this is a sensible apprehension. A process remains free, under PaX (as I understand the intent) to keep code in a read/write portion of its assigned memory and self-modify at will. If it goes west and tries to scribble where it shouldn't, the OS gets told and kills it; that your code did such a thing is your problem -- back to the debugger! The memory model used by most modern languages makes self modification (ie, doing exotic things with pointers) difficult when programs written in those langauges are running under PaX type supervision, but that's not really a PaX level issue; it's trying to keep the operating system from crashing and programs (including malware) from interfering with each other. You weren't supposed to be doing that sort of thing anyway, there being no language support for it in most cases.

Thus, the efficiency hit you envision isn't an issue for programs written in most modern languages. PaX imposes no program execution time overhead and little program setup time overhead, as I follow it. Its main running time overhead load is at the kernel level, and resource overhead lies in using a little memory to keep track of its charges. A program written in a self modifying language whose runtime package is willing to work in a PaXified environment ought not to even notice.

In general, if you want maximum run time efficiency (minimum execution time, minimum memory use) you should avoid general purpose operating systems altogether. But embedded programming like that isn't within the PaX brief at all. Maybe this clarifies things a bit? ww 16:56, 29 Jul 2004 (UTC)

PaX does the exact opposite of "A process remains free, under PaX (as I understand the intent) to keep code in a read/write portion of its assigned memory and self-modify at will." Code can not be in a read/write portion of assigned memory; you'll never be allowed to execute it if it's writable. Only combinations of (read/write) or (read/execute) are allowed; (execute) also cannot be added if it is not already set on a page. Thus, code can never self-modify. Programs that try to self-modify with PaX restrictions in place are terminated immediately.

PaX does not protect processes from other processes; it protects them from themselves. It'd be comparable to if a night patrol walked around your neighborhood after say 10pm and made sure to lock your front door and roll up your car window and lock your car doors if you forgot to. The times when this breaks programs would be comparable to when you leave your keys in your car. It tries damn hard to stay out of your way, just don't do anything broken.

PaX will recognize trampolines, and "emulate" them by some method unknown to me. Short version, it just does. If you want to know how, go read the docs--which the article links to because it's not made to go into the deep technical aspects of PaX, more just to touch the surface. It won't allow blocks of code to be generated at runtime (like Java); Executable space protections pretty much makes this clear (esp. paragraph 4).

As for performance, there are no current official measurements. I got 0.67% (I think it was 0.67, I know it was 0.6 something) measured on x86 with a k7 Athlon XP with SEGMEXEC. This is <1%, so it's low; it's also a scalar (it's a percentage, pretty CPU independent), so it's the same everywhere. PAGEEXEC used on systems supporting HW NX would be pretty much effectively 0%; it's variable, but a trick noted in the PAGEEXEC segment brings it down to below SEGMEXEC's overhead on x86 in many situations. When this trick fails, the overhead can rocket up to 5%, 20%, whatever, high high levels.

--John Moser 23:05, 29 Jul 2004 (UTC)

Clearly we see here a limitation in my understanding of PaX operation. I apologize for getting inverted on this one. However, as self-modifying code is generally thought (and experience shows) to be a Bad Thing, Pax's actual behavior (as stated by jm above) is sensible however much I missed something. Sorry about that. ww 14:00, 30 Jul 2004 (UTC)

Ah, good, you understand now. That means my work here is done :) --John Moser 00:51, 2 Aug 2004 (UTC)

Featured Article!!! :D

This page is now a Featured Article!

Special thanks go to all of those who objected at the first FAC run and those who contributed, including Matt Crypto, Raul654, Ww, Taxman, Kate, Goplat, Timwi, David Gerard, and the rest of you who helped that I may have missed. Although I undertook getting this article up to FA status as a personal goal, it could not have been done without the input, clarity, simplification, and spell checking of the Wikipedia community.

Special thanks also goes to The PaX Team for looking over the article and checking for accuracy several times. It should be noted that there hasn't been an examination by them since the last bits of deep technical information were added (although the changes since then are supported by the information already gathered, or are not strongly technical); if something turns out to be inaccurate-- which should not be the case, but we are all human-- the fault would not lay on them.  :)

Again, thanks to you all for your contributions; now I don't have to spend 10 hours explaining PaX to newbies :D

--John Moser 06:31, 11 Aug 2004 (UTC)

Request for references

Hi, I am working to encourage implementation of the goals of the Wikipedia:Verifiability policy. Part of that is to make sure articles cite their sources. This is particularly important for featured articles, since they are a prominent part of Wikipedia. The Fact and Reference Check Project has more information. If some of the external links are reliable sources and were used as references (as I believe is the case with this article), they can be placed in a References section too. See the cite sources link for how to format them. Thank you, and please leave me a message when a few references have been added to the article. - Taxman 19:39, Apr 22, 2005 (UTC)

Dead link

During several automated bot runs the following external link was found to be unavailable. Please check if the link is in fact down and fix or remove it in that case!

• http://lists.netsys.com/pipermail/full-disclosure/2005-March/032240.html
  • In PaX on Mon Jul 17 14:41:55 2006, Socket Error: (110, 'Connection timed out')
  • In PaX on Thu Jul 27 00:36:42 2006, Socket Error: (110, 'Connection timed out')

---

maru (talk) contribs 04:36, 27 July 2006 (UTC)

Orders of magnitude

PaX#Randomized mmap() base says On 32-bit systems, this amounts to 16 orders of magnitude; that is, the chances of success are recursively halved 16 times.. If an amount is halved 16 times it gets 2^16 = 65536 times smaller, which is 5 orders of magnitude, not 16. Orders of magnitude states that sometimes powers of 2 are used instead of powers of 10, but that's so uncommon that in my opinion "65536 times" should be used instead. // Duccio (write me) 23:01, 24 August 2006 (UTC)

On Portal:Free software, PaX is currently the selected article

Hopefully Portal:Free_software can attract some people here to help improve the article so that it doesn't lose its featured article status. For one thing, I recommend that people add references to this article. It will remain on the portal for a week or so. The previous selected article was Emacs. Gronky 23:02, 11 June 2007 (UTC)

Well, I can't say it helped much. Anyway, the selected article has moved on again and is now OpenWrt. Gronky 15:39, 20 June 2007 (UTC)

Data execution prevention

Am I right to think that PaX's executable space protection is analogous to Windows SP2 and later's data execution prevention feature? Would it be relevant to mention this in the article? RW 02:57, 9 July 2007 (UTC)

Needs references

This article's only reference is the documentation of the subject, with no inline citations. Is anyone interested enough in this article to improve it to the current featured article standard? Pagrashtak 01:06, 27 October 2007 (UTC)

Attack against PaX requiring brute forcing only 16 bits (up to 20 maximum)

On the Effectiveness of Address-Space Randomization demonstrates an attack on PaX ASLR from 2004 that requires brute forcing 16 bits (with an upper bound of 20 bits) of randomness for systems with 32-bit address spaces. Probably worth a mention in the article, but I don't know how future work on it turned out.

Swolchok (talk) 22:22, 27 January 2009 (UTC)

External links modified

Hello fellow Wikipedians,

I have just added archive links to one external link on PaX. Please take a moment to review my edit. If necessary, add {{cbignore}} after the link to keep me from modifying it. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether. I made the following changes:

• Added archive http://web.archive.org/web/20070926222018/http://packetstorm.linuxsecurity.com/0503-exploits/paxomatic.c to http://packetstorm.linuxsecurity.com/0503-exploits/paxomatic.c

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—^{cyberbot II}_{Talk to my owner:Online} 14:25, 28 February 2016 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified one external link on PaX. 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/20070928120508/http://fist.immunitysec.com/pipermail/dailydave/2005-March/001619.html to http://fist.immunitysec.com/pipermail/dailydave/2005-March/001619.html

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 14:41, 20 May 2017 (UTC)

Notability?

As grsecurity was deleted too, is this single patch from that patchset any more notable than the patchset itself? --ilmaisin (talk) 22:57, 19 August 2021 (UTC)