This is the FAQ for the patch only, be sure to read the README first.

Q: Where can I find new versions of the patch?
Q: I only have the patch for Linux 2.0, where do I get a version for
Linux 2.2 (or vice versa)?
A: http://www.openwall.com/linux/

Q: Will you be updating the patch for the new kernel version 2.0.x?
A: If a 2.0.40 is ever released, I will likely support it.

Q: What about 2.2.x?
A: I will definitely support future 2.2.x versions of the kernel.

Q: What about 2.4.x?
A: I will likely start supporting these kernels 15 revisions after
2.4.0.  My advice is to use 2.2 on "production" systems until then.

Q: Is the patch x86-specific?
A: Only the non-executable stack feature of the patch is x86-specific.
The patch has been tested and is used on other architectures as well.
In fact, I've released some minor updates of the patch after testing
them on Alpha only in the past.

Q: Are there any issues with the patch on SMP boxes?
A: None that I am currently aware of.  I've been running all versions
of the patch since 2.0.33 on SMP.

Q: Why don't they make it into the standard kernel?
A: This is not a trivial question to answer.  First, some parts of older
versions of the patch (or equivalent, but different, fixes) are in fact
in the kernel now.  This is the reason the patch for 2.0.36 was smaller
than it used to be in the 2.0.33 days.  Now the patch for 2.2.13 is once
again smaller than its last 2.2.12 version. :-)  So, security problems in
the kernel itself are typically getting fixed.  It is, however, true that
the security "hardening" features of the patch are not getting in.  One
of the reasons for this is that those features could result in a false
sense of security.  Someone could then decide against fixing a hole on a
system they administer or in software they maintain just because of these
kernel features.  If such things happen, the security is in fact relaxed,
not improved.  The rlimit restrictions I have here are temporary hacks,
to be replaced with a real solution (beancounters), so I'm not trying to
get them into the kernel.  Finally, there are some features here that I
think could get included (don't know of a good reason against doing so),
such as the fd 0-2 fix.

Q: I've applied the patch, and now my kernel doesn't compile?
A: Are you sure you've applied the patch exactly as shown in this README?
Please, try again with a known-clean source tree.

Q: Will GCC-compiled programs that use trampolines work with the non-exec
stack part of the patch?
A: Yes, if you enable the support.

Q: When I'm trying to use 'print f()' in gdb on a Linux 2.2 system with
your patch, my program crashes.  What's going on?
A: The changes made in Linux 2.2 didn't let me port my old workaround for
this from the Linux 2.0 version of the patch.  You'll have to use chstk.c
on the program you're debugging in order to use this feature of gdb.

Q: What does GCC use trampolines for?
A: Trampolines are needed to fully support one of the GNU C extensions,
nested functions.  When a nested function is called from outside of the
one it was declared in (that is, via a function pointer), something needs
to provide the stack frame.  The bad thing is that GCC puts trampolines
onto the stack (as they're generated at runtime).  You can find an example
in stacktest.c, included with this patch.

Q: How do you differ a trampoline call from an exploit attempt?
A: Since most buffer overflow exploits overwrite the return address, the
instruction to pass control onto the stack has to be a RET.  When calling
a trampoline, the instruction is a CALL.  Note that in some cases such
autodetection can be fooled by RET'ing to a CALL instruction and making
this CALL pass control onto the stack (in reality, this also requires a
register to be set to the address, and only works this way on Linux 2.0).
Read help for the 'Autodetect GCC trampolines' configuration option.

Q: What about glibc and non-executable stack?
A: You have to enable trampoline autodetection when using glibc 2.0.x, or
the system won't even boot.  If you're running Linux 2.0, you will likely
also want to enable trampoline call emulation to avoid running privileged
processes with executable stack.

Q: I've just compiled glibc on my system, but "make check" fails while
trying to load testobj1.so.  What's going on?  Will the newly compiled
glibc work with your patch in the kernel?
Q: What's the deal with glibc-2.1.3-cvs-20000504-dl-open.diff?
A: The non-executable stack part of the patch changes the default address
shared libraries are mmap()ed at.  Unfortunately, some parts of glibc
depend on this address being above ELF sections.  This is a bug.  The good
thing is that the problem is only likely to show up with the little used
ORIGIN feature, and only when the dynamic linker is run as a standalone
program.  It is thus highly unlikely that this will cause anything other
than "make check" to break.  You can, however, use the fix included with
this patch.

Q: What does the procps-2.0.6-ow1.diff patch do?  Is it required for the
kernel patch to work?
A: This procps patch updates the stale utmp entry check, so that w(1) in
procps 2.0.x up to 2.0.6 works correctly on systems with the restricted
/proc option.  If you don't experience any problems with w(1), you don't
need to install the procps patch.

Q: What is chstk.c for?
A: The patch adds an extra flag to ELF and a.out headers, which controls
whether the program will be allowed to execute code on the stack or not,
and chstk.c is what you should use to manage the flag.  You might find it
useful if you choose to disable the GCC trampolines autodetection.  BTW,
setting the flag also restores the original address shared libraries are
mmap()'ed at, in case the program depends on that.

Q: What if an attacker uses chstk.c on a buffer overflow exploit?
A: Nothing changes.  It's the vulnerable program being exploited that needs
executable stack, not the exploit.  The attacker would need write access
to this program's binary to use chstk.c successfully.

Q: Do I have to reboot with an unpatched kernel to try out a new overflow
exploit to see if I'm vulnerable?
A: No, you can use chstk.c on the vulnerable program to temporarily allow
it to execute code on the stack.  Just don't forget to reset the flag back
when you're done.  Also, be careful with relying on such tests: typically,
they can't prove that you're not vulnerable, they can only sometimes prove
the opposite.  Note that setting the flag on Linux 2.2 systems will change
the default stack location to be 8 MB lower than where many exploits expect
it to be.

Q: Are any applications known to require executable stack and/or the
traditional default mmap() address?
A: Yes.  JDK 1.3 and XFree86 4.0.1 (only with the commercial nVidia GeForce
drivers) have been reported to not work unless chstk'ed.  Many Win32
applications and DLL's (such as video codecs) are non-relocateable and
must be loaded at their default address which mustn't be already taken
by the shared libraries of a Linux application such as Wine or MPlayer.
Simply chstk'ing the "wine" and "mplayer" binaries solves this problem.

Q: Why did you modify signal handler return code?
A: Originally the kernel put some code onto the stack to return from signal
handlers.  Now signal handler returns are done via the GPF handler instead
(an invalid magic return address is put onto the stack).

Q: What to do if a program needs to follow a symlink in a +t directory for
its normal operation (without introducing a security hole)?
A: Usually such a link needs to be created only once, so create it as root
(or the directory owner, if it's not root).  Such links are followed even
when the patch is enabled.

Q: What will happen if someone does:
	ln -s /etc/passwd ~/link
	ln -s ~/link /tmp/link
and the vulnerable program runs as root and writes to /tmp/link?
A: The patch is not looking at the target of the symlink in /tmp, it only
checks if the symlink itself is owned by the user that vulnerable program
is running as, and doesn't follow the link if not (like in this example).

Q: Is there some performance impact of using the patch?
A: Well, normally the only thing affected is signal handler returns.  I
didn't want to modify the sigreturn syscall, so there is some extra code to
setup its stack frame.  I don't think this has a noticeable effect on the
performance (and my benchmarks prove that): saved context checks and other
signal handling stuff are taking much more time.  Executing code on the
stack was not fast anyway.  Also, programs using GCC trampolines will run
slower if trampoline calls are emulated.  However, I don't know of any
program that uses trampolines where the performance is critical (would be a
stupid thing to do so anyway).
