After I had enabled some grsec features in the kernel recently, w3m suddenly segfaulted immediately on startup. gdb showed that the crash actually happened inside libgc. These are the relevant kernel configuration options: CONFIG_GRKERNSEC=y # CONFIG_GRKERNSEC_LOW is not set # CONFIG_GRKERNSEC_MID is not set # CONFIG_GRKERNSEC_HI is not set CONFIG_GRKERNSEC_CUSTOM=y # CONFIG_GRKERNSEC_PAX_NOEXEC is not set CONFIG_GRKERNSEC_PAX_ASLR=y CONFIG_GRKERNSEC_PAX_RANDUSTACK=y CONFIG_GRKERNSEC_PAX_RANDMMAP=y # CONFIG_GRKERNSEC_KMEM is not set CONFIG_GRKERNSEC_PROC_MEMMAP=y CONFIG_GRKERNSEC_HIDESYM=y # CONFIG_GRKERNSEC_ACL_HIDEKERN is not set CONFIG_GRKERNSEC_ACL_MAXTRIES=3 CONFIG_GRKERNSEC_ACL_TIMEOUT=30 # CONFIG_GRKERNSEC_PROC is not set CONFIG_GRKERNSEC_LINK=y CONFIG_GRKERNSEC_FIFO=y CONFIG_GRKERNSEC_CHROOT=y # CONFIG_GRKERNSEC_CHROOT_MOUNT is not set CONFIG_GRKERNSEC_CHROOT_DOUBLE=y CONFIG_GRKERNSEC_CHROOT_PIVOT=y CONFIG_GRKERNSEC_CHROOT_CHDIR=y # CONFIG_GRKERNSEC_CHROOT_CHMOD is not set CONFIG_GRKERNSEC_CHROOT_FCHDIR=y # CONFIG_GRKERNSEC_CHROOT_MKNOD is not set CONFIG_GRKERNSEC_CHROOT_SHMAT=y CONFIG_GRKERNSEC_CHROOT_UNIX=y CONFIG_GRKERNSEC_CHROOT_FINDTASK=y CONFIG_GRKERNSEC_CHROOT_NICE=y CONFIG_GRKERNSEC_CHROOT_SYSCTL=y CONFIG_GRKERNSEC_CHROOT_CAPS=y # CONFIG_GRKERNSEC_AUDIT_GROUP is not set # CONFIG_GRKERNSEC_EXECLOG is not set CONFIG_GRKERNSEC_RESLOG=y # CONFIG_GRKERNSEC_CHROOT_EXECLOG is not set # CONFIG_GRKERNSEC_AUDIT_CHDIR is not set CONFIG_GRKERNSEC_AUDIT_MOUNT=y # CONFIG_GRKERNSEC_AUDIT_IPC is not set CONFIG_GRKERNSEC_SIGNAL=y CONFIG_GRKERNSEC_FORKFAIL=y CONFIG_GRKERNSEC_TIME=y CONFIG_GRKERNSEC_EXECVE=y # CONFIG_GRKERNSEC_DMESG is not set CONFIG_GRKERNSEC_RANDPID=y # CONFIG_GRKERNSEC_TPE is not set CONFIG_GRKERNSEC_RANDNET=y CONFIG_GRKERNSEC_RANDISN=y CONFIG_GRKERNSEC_RANDID=y CONFIG_GRKERNSEC_RANDSRC=y CONFIG_GRKERNSEC_RANDRPC=y CONFIG_GRKERNSEC_RANDPING=y # CONFIG_GRKERNSEC_SOCKET is not set CONFIG_GRKERNSEC_SYSCTL=y CONFIG_GRKERNSEC_FLOODTIME=10 CONFIG_GRKERNSEC_FLOODBURST=4 I suspect that the address space randomization features break some of the assumptions libgc makes. - -- System Information: Debian Release: testing/unstable Architecture: powerpc Kernel: Linux thor 2.4.21-ben1-ck3-aa #14 Fri Jun 27 11:36:36 CEST 2003 ppc Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 Versions of packages libgc6c102 depends on: ii libc6 2.3.1-16 GNU C Library: Shared libraries an ii libgcc1 1:3.3-2 GCC support library ii libstdc++5 1:3.3-2 The GNU Standard C++ Library v3 - -- no debconf information iD8DBQE/CAI4WoGvjmrbsgARAoREAJ47bqujPSRZ3/HkpWpMKxdGf2DNQwCghQfH Lzi/R1aY95HvG8QsrUJpwks= =BqBG -----END PGP SIGNATURE-----
I suspect that you are correct, and that there is probably no fix planned to work around it. Hans?
Sorry for the delayed response. It's not obvious to me why this should fail. Is the main data segment split into pieces? The stack base should be determined from either __libc_stack_end, or /proc on PowerPC/Linux. I assume those would continue to be correct. How the main data segment is found may depend on the precise GC version. I expect that it's either walking backwards from _end until it encounters inaccessible memory, or it's just looking at the dynamic library list. If _end is accurate, I'm not sure why either should fail unless there are unexpected holes somehow. More information would be helpful. I assume it's failing in GC_mark_from? The fault address, the output of GC_dump(), and /proc/nnn/maps for the offending process would be useful. Hans
Thanks for your followup. Unfortunately, I'm running a very different kernel now and can't provide this information. I hope somebody else who stumbles upon this problem will be able to.
Elmar Hoffmann <elho@elho.net> wrote[1]: Adam ENDRODI <borso@vekoll.saturnus.vein.hu> wrote[2]: This is only an issue on Linux. Starting with 7.1, -DNO_PROC_STAT will avoid checking /proc/self/stat, using instead __libc_stack_end (if also -DUSE_LIBC_PRIVATES) or HEURISTIC2. According to comments in include/private/gcconfig.h and reading of the relevant parts in os_dep.c, it may be preferable to avoid HEURISTIC* when possible. However, USE_LIBC_PRIVATES will fail for prelinked executables (see prelink(8) man page) and is also glibc specific. It is noted that HEURISTIC2 may fail on some architectures e.g. IA64. The most conservative is to check for __libc_stack_end in configure and -DUSE_LIBC_PRIVATES if so. Failure will still happen with some grsecurity kernels *and* not using glibc. Without some thorough validation and testing of HEURISTIC2, I do not believe using -DNO_PROC_STAT is a safe fallback for non-glibc situations. [1] <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=301714#5> [2] <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=312314#10>