ProPolice and FreeBSD
From: Jeremie Le Hen (jeremie_at_le-hen.org)
Date: 06/30/05
- Previous message: Nikos Ntarmos: "Re: hot path optimizations in uma_zalloc() & uma_zfree()"
- Next in thread: Jeremie Le Hen: "Re: ProPolice and pthreads (was: ProPolice and FreeBSD)"
- Reply: Jeremie Le Hen: "Re: ProPolice and pthreads (was: ProPolice and FreeBSD)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 30 Jun 2005 18:50:17 +0200 To: freebsd-hackers@FreeBSD.org
Hello,
maybe this question should be asked on -threads@, I'm not sure. If it
is, please tell me and I will redirect my mail.
I'm working on upgrading the ProPolice/SSP patch [1] to -CURRENT. I
initially used the patch against FreeBSD 5.1 to know which file I
should modify and in which way in the source tree, but I used the
newest patch against gcc 3.4.1 for gcc specific stuffs.
After a little work, I got a full FreeBSD built with SSP functions
compiled in libc (it is also possible to compile it in libgcc but,
AFAIU, this would require the SSP stuff to be statically built in
all binaries since FreeBSD doesn't provide a shared libgcc). I also
read somewhere that some guys of the hardened Debian project have made
a libssp, but I find this a little bit overkill (comments ?).
I recompiled host(1), libc and libpthread with debugging symbol.
Now the questions. All binaries linked against libpthread immediately
get a SIGSEGV :
%%%
coyote:libc# gdb /usr/bin/host
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd"...
(gdb) r
Starting program: /usr/bin/host
warning: Unable to get location for thread creation breakpoint: generic error
[New LWP 100135]
Program received signal SIGSEGV, Segmentation fault.
[Switching to LWP 100135]
_thr_cancel_enter (thread=0x0)
at /usr/src/lib/libpthread/thread/thr_cancel.c:269
269 THR_THREAD_LOCK(thread, thread);
(gdb) bt full
#0 _thr_cancel_enter (thread=0x0)
at /usr/src/lib/libpthread/thread/thr_cancel.c:269
No locals.
#1 0x282dd51b in __open (path=0x281bc0c0 "ÀÀ\033( \220\033(", flags=0)
at /usr/src/lib/libpthread/thread/thr_open.c:53
curthread = (struct pthread *) 0x0
ret = 0
mode = 0
#2 0x2838f40b in __guard_setup ()
at /usr/src/lib/libc/sys/stack_protector.c:51
fd = 0
#3 0x283cbe22 in lseek () from /lib/libc.so.6
No symbol table info available.
#4 0x28316dd1 in _init () from /lib/libc.so.6
No symbol table info available.
#5 0x281b8000 in ?? ()
No symbol table info available.
#6 0x281ad6fc in ?? () from /libexec/ld-elf.so.1
No symbol table info available.
#7 0xbfbfeca8 in ?? ()
No symbol table info available.
#8 0x2818cc79 in find_symdef () from /libexec/ld-elf.so.1
No symbol table info available.
#9 0x2818b759 in _rtld () from /libexec/ld-elf.so.1
No symbol table info available.
#10 0x2818a98e in .rtld_start () from /libexec/ld-elf.so.1
No symbol table info available.
%%%
__guard_setup() is the constructor of the SSP patch, it generates a
random cookie for the application runtime :
%%%
static void __guard_setup(void) __attribute__ ((constructor));
static void
__guard_setup(void)
{
int fd;
if (__guard[0]!=0) return;
fd = open ("/dev/urandom", 0);
if (fd != -1) {
ssize_t size = read (fd, (char*)&__guard, sizeof(__guard));
close (fd) ;
if (size == sizeof(__guard)) return;
}
/* If a random generator can't be used, the protector switches the guard
to the "terminator canary" */
((char*)__guard)[0] = 0; ((char*)__guard)[1] = 0;
((char*)__guard)[2] = '\n'; ((char*)__guard)[3] = 255;
}
%%%
I am neither a gcc hacker nor a thread guru, so I have no clue on how to
resolve this issue. Advices are welcome.
Thanks.
Regards,
[1] http://www.trl.ibm.com/projects/security/ssp/
-- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
- Previous message: Nikos Ntarmos: "Re: hot path optimizations in uma_zalloc() & uma_zfree()"
- Next in thread: Jeremie Le Hen: "Re: ProPolice and pthreads (was: ProPolice and FreeBSD)"
- Reply: Jeremie Le Hen: "Re: ProPolice and pthreads (was: ProPolice and FreeBSD)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
