Re: CVS commit: src/lib/librumphijack
On Fri Mar 11 2011 at 03:34:47 +0300, Valeriy E. Ushakov wrote: On Thu, Mar 10, 2011 at 23:02:56 +, Antti Kantee wrote: Use rumphijack_dlsym() to figure out where __sysctl() is during init. Otherwise powerpc dlsym() DTWT and returns NULL. (now i have no idea why dlsym() it works from rcinit(), but i'll opt to not care) I don't remember if I brought this up here already, but I strongly suspect suspect that libexec/ld.elf_so/rtld.c revision 1.121 date: 2008/09/27 03:52:05; author: macallan; state: Exp; lines: +15 -3 avoid usind __builtin_return_address(0) on PowerPC because it fails in Xorg's module loader. Should fix PR37812 broke it (hi, Mac!). IIRC, it tries to work around dlsym in tail call position (badness!) and fixes it only by chance, causing grief elsewhere. If there only were a test, someone could try to fix things without worrying about reintroducing the original problem again ... -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src/lib/librumphijack
On Thu, Mar 10, 2011 at 23:02:56 +, Antti Kantee wrote: Use rumphijack_dlsym() to figure out where __sysctl() is during init. Otherwise powerpc dlsym() DTWT and returns NULL. (now i have no idea why dlsym() it works from rcinit(), but i'll opt to not care) I don't remember if I brought this up here already, but I strongly suspect suspect that libexec/ld.elf_so/rtld.c revision 1.121 date: 2008/09/27 03:52:05; author: macallan; state: Exp; lines: +15 -3 avoid usind __builtin_return_address(0) on PowerPC because it fails in Xorg's module loader. Should fix PR37812 broke it (hi, Mac!). IIRC, it tries to work around dlsym in tail call position (badness!) and fixes it only by chance, causing grief elsewhere. -uwe
Re: CVS commit: src/lib/librumphijack
On 03/09/11 16:03, Antti Kantee wrote: Module Name:src Committed By: pooka Date: Wed Mar 9 15:03:18 UTC 2011 Modified Files: src/lib/librumphijack: hijack.c Log Message: Add a bunch of process-wide hijack calls. Among other things, it's now possible to use unmodified userspace binaries (rpcbind, mountd, nfsd) to start a rump nfs service and mount file systems from it. pain-rustique:42:~ mount rumpfs on / type rumpfs (local) 10.1.1.1:/export on /mnt type nfs Cool. Is it possible to have anita booting NetBSD in qemu with root on nfs? Christoph
Re: CVS commit: src/lib/librumphijack
On Fri, Feb 25, 2011 at 16:01:42 +, Antti Kantee wrote:
Module Name: src
Committed By: pooka
Date: Fri Feb 25 16:01:42 UTC 2011
Modified Files:
src/lib/librumphijack: Makefile hijackdlsym.c
Log Message:
Ok, for reasons I can't begin to understand, the binaries I tested
yesterday on powerpc broke overnight. Apparently adding one more
function before the call to dlsym() fixes things again. I hope
I don't have to add another one tomorrow
To generate a diff of this commit:
cvs rdiff -u -r1.7 -r1.8 src/lib/librumphijack/Makefile
cvs rdiff -u -r1.1 -r1.2 src/lib/librumphijack/hijackdlsym.c
I think this is caused by revision 1.121 of rtld.c (hi, mac!) that
added hackish_return_address for ppc.
#ifdef __powerpc__
static void *
hackish_return_address(void)
{
return __builtin_return_address(1);
}
#endif
void *
dlsym(void *handle, const char *name)
{
...
#ifdef __powerpc__
retaddr = hackish_return_address();
#else
retaddr = __builtin_return_address(0);
#endif
...
}
hackish_return_address will be inlined (simple static function) and,
as far as I can tell, gcc does NOT adjust the level argument to
__builtin_return_address.
The net effect is that dlsym uses caller's caller address to detect
which module the call comes from, and if caller's caller is in a
different module wrong things happen.
That explains why you need an extra frame.
-uwe
Re: CVS commit: src/lib/librumphijack
On Sun, Feb 27, 2011 at 08:12:37 +0300, Valeriy E. Ushakov wrote:
On Fri, Feb 25, 2011 at 16:01:42 +, Antti Kantee wrote:
Module Name:src
Committed By: pooka
Date: Fri Feb 25 16:01:42 UTC 2011
Modified Files:
src/lib/librumphijack: Makefile hijackdlsym.c
Log Message:
Ok, for reasons I can't begin to understand, the binaries I tested
yesterday on powerpc broke overnight. Apparently adding one more
function before the call to dlsym() fixes things again. I hope
I don't have to add another one tomorrow
To generate a diff of this commit:
cvs rdiff -u -r1.7 -r1.8 src/lib/librumphijack/Makefile
cvs rdiff -u -r1.1 -r1.2 src/lib/librumphijack/hijackdlsym.c
I think this is caused by revision 1.121 of rtld.c (hi, mac!) that
added hackish_return_address for ppc.
#ifdef __powerpc__
static void *
hackish_return_address(void)
{
return __builtin_return_address(1);
}
#endif
void *
dlsym(void *handle, const char *name)
{
...
#ifdef __powerpc__
retaddr = hackish_return_address();
#else
retaddr = __builtin_return_address(0);
#endif
...
}
hackish_return_address will be inlined (simple static function) and,
as far as I can tell, gcc does NOT adjust the level argument to
__builtin_return_address.
The net effect is that dlsym uses caller's caller address to detect
which module the call comes from, and if caller's caller is in a
different module wrong things happen.
That explains why you need an extra frame.
Actually, the real reason behind PR 37812 (that was supposed to be
fixed by the hackish_return_address) might be similar to the issue
with rumphijack_dlsym.
If I read xorg-server/dist/hw/xfree86/loader correctly, you probably
end up with dlsym being tail-called. My knowledge of ppc asm/abi is
zero, so I can't really tell what goes on there or what went wrong in
the original scenario, but I'd guess your hackish return gets inlined
and with dlsym in tail-call position your caller's caller (unadjusted
level 1) is in the main program and then luck is on your side,
unless you do e.g. RTLD_NEXT.
PS: pooka this probably calls for some atf tests for dlsym co.
-uwe
re: CVS commit: src/lib/librumphijack
cvs rdiff -u -r1.7 -r1.8 src/lib/librumphijack/Makefile
cvs rdiff -u -r1.1 -r1.2 src/lib/librumphijack/hijackdlsym.c
I think this is caused by revision 1.121 of rtld.c (hi, mac!) that
added hackish_return_address for ppc.
#ifdef __powerpc__
static void *
hackish_return_address(void)
{
return __builtin_return_address(1);
}
#endif
void *
dlsym(void *handle, const char *name)
{
...
#ifdef __powerpc__
retaddr = hackish_return_address();
#else
retaddr = __builtin_return_address(0);
#endif
...
}
hackish_return_address will be inlined (simple static function) and,
as far as I can tell, gcc does NOT adjust the level argument to
__builtin_return_address.
The net effect is that dlsym uses caller's caller address to detect
which module the call comes from, and if caller's caller is in a
different module wrong things happen.
That explains why you need an extra frame.
ugh!
mac, what wasn't working that prompted you to do the above?
one hack to make it work would be to apply the noinline
gcc attribute
.mrg.
Re: CVS commit: src/lib/librumphijack
On Wed Feb 23 2011 at 01:31:51 +, YAMAMOTO Takashi wrote: On Mon Feb 21 2011 at 23:19:47 +, YAMAMOTO Takashi wrote: Module Name: src Committed By:pooka Date:Mon Feb 7 19:34:39 UTC 2011 Modified Files: src/lib/librumphijack: hijack.c Log Message: Force gcc to generate a stack frame for the call to dlsym(RTLD_NEXT). Without this hack at least amd64 -O2 just used jmp and The Wrong Thing happened. do you want -fno-optimize-sibling-calls ? Without doing a test-compile, looks like it. I guess I'll have to move that function to its own source module, or is there a way to enable it per-function? i don't think there's a way for our version of gcc to make it per-function. later versions have optimize function attribute. the real fix here would be an attibute for dlsym, not for a caller of it, tho. Proposing RTLD_NEXT-FROM-HANDLE was out of the scope of what I wanted to tackle here. If someone implements it, I'll be happy to use it, though ;) Anyway, i'm guessing things work more certainly now that i committed the -fno-sibling stuff. And if they don't (e.g. with other compilers), we have a test which lets us know. thanks -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src/lib/librumphijack
On Mon Feb 21 2011 at 23:19:47 +, YAMAMOTO Takashi wrote: Module Name:src Committed By: pooka Date: Mon Feb 7 19:34:39 UTC 2011 Modified Files: src/lib/librumphijack: hijack.c Log Message: Force gcc to generate a stack frame for the call to dlsym(RTLD_NEXT). Without this hack at least amd64 -O2 just used jmp and The Wrong Thing happened. do you want -fno-optimize-sibling-calls ? Without doing a test-compile, looks like it. I guess I'll have to move that function to its own source module, or is there a way to enable it per-function? -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src/lib/librumphijack
On Mon Feb 21 2011 at 23:19:47 +, YAMAMOTO Takashi wrote: Module Name: src Committed By: pooka Date: Mon Feb 7 19:34:39 UTC 2011 Modified Files: src/lib/librumphijack: hijack.c Log Message: Force gcc to generate a stack frame for the call to dlsym(RTLD_NEXT). Without this hack at least amd64 -O2 just used jmp and The Wrong Thing happened. do you want -fno-optimize-sibling-calls ? Without doing a test-compile, looks like it. I guess I'll have to move that function to its own source module, or is there a way to enable it per-function? i don't think there's a way for our version of gcc to make it per-function. later versions have optimize function attribute. the real fix here would be an attibute for dlsym, not for a caller of it, tho. YAMAMOTO Takashi -- dld karot toivorikkauttas, kyl rdtei ja lumpui piisaa
Re: CVS commit: src/lib/librumphijack
Module Name: src Committed By: pooka Date: Mon Feb 7 19:34:39 UTC 2011 Modified Files: src/lib/librumphijack: hijack.c Log Message: Force gcc to generate a stack frame for the call to dlsym(RTLD_NEXT). Without this hack at least amd64 -O2 just used jmp and The Wrong Thing happened. do you want -fno-optimize-sibling-calls ? YAMAMOTO Takashi To generate a diff of this commit: cvs rdiff -u -r1.31 -r1.32 src/lib/librumphijack/hijack.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
Re: CVS commit: src/lib/librumphijack
On Sun Feb 20 2011 at 04:34:02 +0100, Joerg Sonnenberger wrote: On Sat, Feb 19, 2011 at 07:54:25PM +0200, Antti Kantee wrote: On Sat Feb 19 2011 at 14:58:45 +0100, Joerg Sonnenberger wrote: On Sat, Feb 19, 2011 at 01:10:36PM +, Antti Kantee wrote: Module Name:src Committed By: pooka Date: Sat Feb 19 13:10:35 UTC 2011 Modified Files: src/lib/librumphijack: hijack.c Log Message: hijack __getcwd() Why? to make it work To make *what* work. What is using __getcwd directly and not the frontends. If this is yet another hack to deal with SSP, please apply the patch I send to tech-userlevel and test with that first. To make anything that uses the __getcwd() *system call* work, including, but definitely not limited to the getcwd() *library function*, cf. pain-rustique:1:~ wtf rumphijack rumphijack (3) - System call hijack library ^^^ I have no idea about ssp, it's not enabled on my nb5. As usual, I wrote tests so I wouldn't have to waste time guessing if things work or if they don't and so that others wouldn't have to waste their time guessing what some code was originally meant to do. -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src/lib/librumphijack
On Sat Feb 19 2011 at 14:58:45 +0100, Joerg Sonnenberger wrote: On Sat, Feb 19, 2011 at 01:10:36PM +, Antti Kantee wrote: Module Name:src Committed By: pooka Date: Sat Feb 19 13:10:35 UTC 2011 Modified Files: src/lib/librumphijack: hijack.c Log Message: hijack __getcwd() Why? to make it work -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src/lib/librumphijack
On Sat, Feb 19, 2011 at 01:10:36PM +, Antti Kantee wrote: Module Name: src Committed By: pooka Date: Sat Feb 19 13:10:35 UTC 2011 Modified Files: src/lib/librumphijack: hijack.c Log Message: hijack __getcwd() Why? Joerg
Re: CVS commit: src/lib/librumphijack
On Sat, Feb 19, 2011 at 07:54:25PM +0200, Antti Kantee wrote: On Sat Feb 19 2011 at 14:58:45 +0100, Joerg Sonnenberger wrote: On Sat, Feb 19, 2011 at 01:10:36PM +, Antti Kantee wrote: Module Name: src Committed By: pooka Date: Sat Feb 19 13:10:35 UTC 2011 Modified Files: src/lib/librumphijack: hijack.c Log Message: hijack __getcwd() Why? to make it work To make *what* work. What is using __getcwd directly and not the frontends. If this is yet another hack to deal with SSP, please apply the patch I send to tech-userlevel and test with that first. Joerg
Re: CVS commit: src/lib/librumphijack
On Wed, Feb 09, 2011 at 02:30:38AM +, Christos Zoulas wrote:
To get the layering correct, we could make the fortification code define
another prototype and use double rename, e.g.
ssize_t __real_read(int __fd, ...) __RENAME(read);
__ssp_inline ssize_t read(int __fd, ...) __RENAME(__ssp_read);
__sso_inline ssize_t read(int __fd, ...) {
__ssp_check(__buf, __lean, bos);
return __real_read(__fd, ...);
}
Yes, that would work. An extra level of indirection always works.
It isn't really. It is just tricking the compiler into creating the
right external symbols. The result is that using SSP doesn't change
which symbols end up being called.
Joerg
Re: CVS commit: src/lib/librumphijack
On Wed Feb 09 2011 at 02:32:17 +, Christos Zoulas wrote: And, on a tangent, it would really help if we had some mechanism for latest version of symbol exported by libc (cf. mess with select, pollts, kevent and socket). For working compat, I guess we'd need to bump rumphijack major every time one of them changes, but I can't think of a good mechanism for an application to automatically select the major that needs to be used. That would be useful. Oh, and one other related thing on my wishlist is having libc export all syscall stubs in WEAKASM _sys style so that use-fd-to-select-kernel can work on static linked binaries which cannot use RTLD_NEXT. I guess another option would be to compile local syscall stubs, but it seems easier to have them popping out of libc. -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src/lib/librumphijack
On Wed, Feb 09, 2011 at 14:06:08 +0200, Antti Kantee wrote: On Wed Feb 09 2011 at 02:32:17 +, Christos Zoulas wrote: And, on a tangent, it would really help if we had some mechanism for latest version of symbol exported by libc (cf. mess with select, pollts, kevent and socket). For working compat, I guess we'd need to bump rumphijack major every time one of them changes, but I can't think of a good mechanism for an application to automatically select the major that needs to be used. That would be useful. Oh, and one other related thing on my wishlist is having libc export all syscall stubs in WEAKASM _sys style so that use-fd-to-select-kernel can work on static linked binaries which cannot use RTLD_NEXT. I guess another option would be to compile local syscall stubs, but it seems easier to have them popping out of libc. Is source-changes-d really the right place for this discussion? -uwe
Re: CVS commit: src/lib/librumphijack
On Feb 8, 10:30pm, po...@cs.hut.fi (Antti Kantee) wrote: -- Subject: Re: CVS commit: src/lib/librumphijack | On Tue Feb 08 2011 at 15:03:11 -0500, Christos Zoulas wrote: | [explanation] | | In your c code then in hijack.c you need to define the body of _hijack_read. | You also end up needing to define the bodies of readlink and getcwd, but | that is easily done... | | I hope that helps. The trick to understand here is that you can only do | the ssp check in the inline function, because if you move the check in | the source file, you've lost the information from the caller about the | passed object. | | Please let me know if you have any more questions. | | E2MAGIC ;) | | Ok, so it was originally correct (or my code was broken on -current) | since hijack needs _sys_read or otherwise the #ifndef __ssp_weak_name | branch causes the 3rd party caller to have a reference to _sys_read | instead of read. Sorry for bursting out, been working on too many | branches and this stuff is fairly hard to tune to work flawlessly ... | (I still need to solve compat ... *hrr*) Yes, it is too complex. I understand. And I see the problem that callers of the rump code calling _sys_read instead of hijack read. | But, since the real caller already does the ssp check, why does it need | to be performed again in librumphijack where we, as you state above, | no longer have the necessary information. It does not do the check in hijack.c (there was one revision that did, but it has been corrected since). Still the problem remains, how do we stack the calls to insert the ssp check at the top level, without resorting to rtld tricks? christos
Re: CVS commit: src/lib/librumphijack
On Tue, Feb 08, 2011 at 03:34:54PM -0500, Christos Zoulas wrote:
Still the problem remains, how do we stack the calls to insert the ssp
check at the top level, without resorting to rtld tricks?
Let me try to summarize the situation to make sure I get it right:
The fortification code wants to provide an inline function read that
calls the real read after doing the argument checks.
rumphijack wants to override the read symbol, apply some magic and
call _sys_read for the real system call.
To get the layering correct, we could make the fortification code define
another prototype and use double rename, e.g.
ssize_t __real_read(int __fd, ...) __RENAME(read);
__ssp_inline ssize_t read(int __fd, ...) __RENAME(__ssp_read);
__sso_inline ssize_t read(int __fd, ...) {
__ssp_check(__buf, __lean, bos);
return __real_read(__fd, ...);
}
Joerg
Re: CVS commit: src/lib/librumphijack
On Tue Feb 08 2011 at 22:00:49 +0100, Joerg Sonnenberger wrote: On Tue, Feb 08, 2011 at 03:34:54PM -0500, Christos Zoulas wrote: Still the problem remains, how do we stack the calls to insert the ssp check at the top level, without resorting to rtld tricks? Let me try to summarize the situation to make sure I get it right: The fortification code wants to provide an inline function read that calls the real read after doing the argument checks. rumphijack wants to override the read symbol, apply some magic and call _sys_read for the real system call. No, it wants to override whatever is the symbol applications are resolved to. For -current this is _sys_read (on nb5 it's read). And, on a tangent, it would really help if we had some mechanism for latest version of symbol exported by libc (cf. mess with select, pollts, kevent and socket). For working compat, I guess we'd need to bump rumphijack major every time one of them changes, but I can't think of a good mechanism for an application to automatically select the major that needs to be used. -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src/lib/librumphijack
On Tue Feb 08 2011 at 23:22:44 +0200, Antti Kantee wrote: On Tue Feb 08 2011 at 22:00:49 +0100, Joerg Sonnenberger wrote: On Tue, Feb 08, 2011 at 03:34:54PM -0500, Christos Zoulas wrote: Still the problem remains, how do we stack the calls to insert the ssp check at the top level, without resorting to rtld tricks? Let me try to summarize the situation to make sure I get it right: The fortification code wants to provide an inline function read that calls the real read after doing the argument checks. rumphijack wants to override the read symbol, apply some magic and call _sys_read for the real system call. No, it wants to override whatever is the symbol applications are resolved to. For -current this is _sys_read (on nb5 it's read). umph, for this case it's always _sys_read since read is just an alias for _sys_read on all branches. However, on -current application linkage skips read() (apparently due to the ssp magic). -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src/lib/librumphijack
On Tue, Feb 08, 2011 at 11:22:44PM +0200, Antti Kantee wrote: On Tue Feb 08 2011 at 22:00:49 +0100, Joerg Sonnenberger wrote: On Tue, Feb 08, 2011 at 03:34:54PM -0500, Christos Zoulas wrote: Still the problem remains, how do we stack the calls to insert the ssp check at the top level, without resorting to rtld tricks? Let me try to summarize the situation to make sure I get it right: The fortification code wants to provide an inline function read that calls the real read after doing the argument checks. rumphijack wants to override the read symbol, apply some magic and call _sys_read for the real system call. No, it wants to override whatever is the symbol applications are resolved to. For -current this is _sys_read (on nb5 it's read). That's not what the library is doing according to nm. It defines read and not _sys_read. Joerg
Re: CVS commit: src/lib/librumphijack
On Tue Feb 08 2011 at 22:41:57 +0100, Joerg Sonnenberger wrote: On Tue, Feb 08, 2011 at 11:22:44PM +0200, Antti Kantee wrote: On Tue Feb 08 2011 at 22:00:49 +0100, Joerg Sonnenberger wrote: On Tue, Feb 08, 2011 at 03:34:54PM -0500, Christos Zoulas wrote: Still the problem remains, how do we stack the calls to insert the ssp check at the top level, without resorting to rtld tricks? Let me try to summarize the situation to make sure I get it right: The fortification code wants to provide an inline function read that calls the real read after doing the argument checks. rumphijack wants to override the read symbol, apply some magic and call _sys_read for the real system call. No, it wants to override whatever is the symbol applications are resolved to. For -current this is _sys_read (on nb5 it's read). That's not what the library is doing according to nm. It defines read and not _sys_read. Are you sure you're looking at a current version? pain-rustique:1:~ nm /usr/lib/librumphijack.so | grep read 29d4 T _sys_read U pthread_create U pthread_join 2a42 T readv -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src/lib/librumphijack
On Tue Feb 08 2011 at 23:04:35 +0100, Joerg Sonnenberger wrote: No, it wants to override whatever is the symbol applications are resolved to. For -current this is _sys_read (on nb5 it's read). That's not what the library is doing according to nm. It defines read and not _sys_read. Are you sure you're looking at a current version? pain-rustique:1:~ nm /usr/lib/librumphijack.so | grep read 29d4 T _sys_read U pthread_create U pthread_join 2a42 T readv I have different builds arounds. So why is _sys_read special and readv, write, writev etc are not? Like Christos wrote, only read/readlink/getcwd have been ssp'd. So if you take e.g. httpd which tests/lib/librumphijack/t_tcpip uses and run nm on it, you get: U _sys_read U write -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src/lib/librumphijack
In article 20110208210049.ga8...@britannica.bec.de,
Joerg Sonnenberger jo...@britannica.bec.de wrote:
On Tue, Feb 08, 2011 at 03:34:54PM -0500, Christos Zoulas wrote:
Still the problem remains, how do we stack the calls to insert the ssp
check at the top level, without resorting to rtld tricks?
Let me try to summarize the situation to make sure I get it right:
The fortification code wants to provide an inline function read that
calls the real read after doing the argument checks.
rumphijack wants to override the read symbol, apply some magic and
call _sys_read for the real system call.
Yes.
To get the layering correct, we could make the fortification code define
another prototype and use double rename, e.g.
ssize_t __real_read(int __fd, ...) __RENAME(read);
__ssp_inline ssize_t read(int __fd, ...) __RENAME(__ssp_read);
__sso_inline ssize_t read(int __fd, ...) {
__ssp_check(__buf, __lean, bos);
return __real_read(__fd, ...);
}
Yes, that would work. An extra level of indirection always works.
christos
Re: CVS commit: src/lib/librumphijack
In article 20110208220435.ga10...@britannica.bec.de, Joerg Sonnenberger jo...@britannica.bec.de wrote: On Tue, Feb 08, 2011 at 11:43:40PM +0200, Antti Kantee wrote: On Tue Feb 08 2011 at 22:41:57 +0100, Joerg Sonnenberger wrote: On Tue, Feb 08, 2011 at 11:22:44PM +0200, Antti Kantee wrote: On Tue Feb 08 2011 at 22:00:49 +0100, Joerg Sonnenberger wrote: On Tue, Feb 08, 2011 at 03:34:54PM -0500, Christos Zoulas wrote: Still the problem remains, how do we stack the calls to insert the ssp check at the top level, without resorting to rtld tricks? Let me try to summarize the situation to make sure I get it right: The fortification code wants to provide an inline function read that calls the real read after doing the argument checks. rumphijack wants to override the read symbol, apply some magic and call _sys_read for the real system call. No, it wants to override whatever is the symbol applications are resolved to. For -current this is _sys_read (on nb5 it's read). That's not what the library is doing according to nm. It defines read and not _sys_read. Are you sure you're looking at a current version? pain-rustique:1:~ nm /usr/lib/librumphijack.so | grep read 29d4 T _sys_read U pthread_create U pthread_join 2a42 T readv I have different builds arounds. So why is _sys_read special and readv, write, writev etc are not? readv should be. We don't bother with writes, because they cannot trash the stack (although we could and detect overflows). christos
Re: CVS commit: src/lib/librumphijack
On Mon Feb 07 2011 at 11:51:02 +, Antti Kantee wrote: Module Name: src Committed By: pooka Date: Mon Feb 7 11:51:02 UTC 2011 Modified Files: src/lib/librumphijack: hijack.c Log Message: Unbreak the ssp lossage from the default -current build by removing it. I still don't have any idea what the ssp stuff is supposed to do and how it's supposed to even begin to work. If someone wants to change this now, run tests/lib/librumphijack before commit so that I can avoid another multihour debugging session! In my debugging frenzy I thought that was the ssp stuff caused the problem, but in fact it didn't (it doesn't compile, so it cannot cause runtime problems). -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src/lib/librumphijack
In article 20110207124333.gg15...@cs.hut.fi, Antti Kantee po...@netbsd.org wrote: On Mon Feb 07 2011 at 11:51:02 +, Antti Kantee wrote: Module Name: src Committed By:pooka Date:Mon Feb 7 11:51:02 UTC 2011 Modified Files: src/lib/librumphijack: hijack.c Log Message: Unbreak the ssp lossage from the default -current build by removing it. I still don't have any idea what the ssp stuff is supposed to do and how it's supposed to even begin to work. If someone wants to change this now, run tests/lib/librumphijack before commit so that I can avoid another multihour debugging session! In my debugging frenzy I thought that was the ssp stuff caused the problem, but in fact it didn't (it doesn't compile, so it cannot cause runtime problems). It used to compile and it seemed fine. Does it still? christos
Re: CVS commit: src/lib/librumphijack
On Wed Jan 26 2011 at 13:48:32 -0500, Christos Zoulas wrote: Module Name: src Committed By: christos Date: Wed Jan 26 18:48:32 UTC 2011 Modified Files: src/lib/librumphijack: hijack.c Log Message: make SSP friendly Can you add a comment stating why readlink and getcwd are special cases? -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src/lib/librumphijack
In article 20110127140249.gd23...@cs.hut.fi, Antti Kantee po...@cs.hut.fi wrote: On Wed Jan 26 2011 at 13:48:32 -0500, Christos Zoulas wrote: Module Name: src Committed By:christos Date:Wed Jan 26 18:48:32 UTC 2011 Modified Files: src/lib/librumphijack: hijack.c Log Message: make SSP friendly Can you add a comment stating why readlink and getcwd are special cases? Just because as it happens they are the other 2 system calls that have been ssp'fied. We could add more. I thought about providing a mechanism to say which ones should have default implementations and which ones should be defined. I don't know how to make a weak inline though that is not visible :-) christos
