What's going on? Will the newlyĬompiled glibc work with your patch in the kernel? Q: I've just compiled glibc 2.1.x on my system, but "make check" fails Glibc, only the "localedef" program, but not glibc itself, uses GCC Privileged processes with executable stack. Likely also want to enable trampoline call emulation to avoid running Q: What about glibc and non-executable stack?Ī: You have to enable trampoline autodetection when using glibc 2.0.x, Reality, this also requires a register to be set to the address, and Instruction and making this CALL pass control onto the stack (in Note that in someĬases such autodetection can be fooled by RET'ing to a CALL WhenĬalling a trampoline, the instruction is a CALL. The instruction to pass control onto the stack has to be a RET. Q: How do you differ a trampoline call from an exploit attempt?Ī: Since many buffer overflow exploits overwrite the return address, You can find an example in stacktest.c, included with this Is that GCC puts trampolines onto the stack (as they're generated at Pointer), something needs to provide the stack frame. Outside of the one it was declared in (that is, via a function You'll have to useĬhstk on the program you're debugging in order to use this feature ofĪ: Trampolines are needed to fully support one of the GNU CĮxtensions, nested functions. What's going on?Ī: The changes made in Linux 2.2 didn't let me port my old workaroundįor this from the Linux 2.0 version of the patch. Q: When I'm trying to use "print f()" in gdb on a Linux 2.2+ system Q: Will GCC-compiled programs that use trampolines work with the README? Please try again with a known-clean source tree. Q: I've applied the patch, and now my kernel doesn't compile?Ī: Are you sure you've applied the patch exactly as shown in the With a real solution (beancounters), so I'm not trying to get them Rlimit restrictions I have here are temporary hacks, to be replaced Things happen, the security is in fact relaxed, not improved.
#Callnote linux software
Software they maintain just because of these kernel features. Then decide against fixing a hole on a system they administer or in One of the reasons for this is that thoseįeatures could result in a false sense of security.
It is, however, true that the security "hardening" features of the Security problems in the kernel itself are typically getting fixed. Now the patch forĢ.2.13 is once again smaller than its last 2.2.12 version. Was smaller than it used to be in the 2.0.33 days. Older versions of the patch (or equivalent, but different, fixes) are Q: Why don't they make it into the standard kernel?Ī: This is not a trivial question to answer. Q: Are there any issues with the patch on SMP boxes?Ī: None that I am currently aware of. In fact, I've released some minor updates of the patch after testing The patch has been tested and is used on other architectures as well. Q: I only have the patch for Linux 2.0.x or 2.2.x, where do I get aĪ: Only the non-executable stack feature of the patch is x86-specific. Q: Where can I find other versions of the patch? We have no plans for a hardening patch for newer kernels.
This is the FAQ for the patch only, be sure to read the README first.Ī: This is a discontinued project.
0 kommentar(er)
