Source-Changes-D archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: CVS commit: src/lib/librumphijack



On Feb 8,  5:01pm, pooka%cs.hut.fi@localhost (Antti Kantee) wrote:
-- Subject: Re: CVS commit: src/lib/librumphijack

| On Tue Feb 08 2011 at 05:15:39 +0000, Christos Zoulas wrote:
| > In article <20110207124333.GG15892%cs.hut.fi@localhost>,
| > Antti Kantee  <pooka%netbsd.org@localhost> wrote:
| > >On Mon Feb 07 2011 at 11:51:02 +0000, 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?
| 
| I never understood what the ssp code was supposed to do and still don't.
| 
| If read is changed to _hijack_read() 3rd party callers will not resolved
| here, and therefore the hijack lib does not do the one thing it is
| expected to do.

So the way it works, is that the ssp code hijacks read, via the inline
call in <ssp/unistd.h> (the macro expansion), and that inline call,
expands to buffer checking plus calling the original function you've defined
in libc _sys_read(), in your case _hijack_read().

so:

<ssp/unistd.h>
__ssp_redirect0(ssize_t, read, (int __fd, void *__buf, size_t __len), \
    (__fd, __buf, __len));

<ssp/ssp.h>

rtype __ssp_weak_name(fun) args; \
__ssp_inline rtype fun args; \ 
__ssp_inline rtype fun args { \
        __ssp_check(__buf, __len, bos); \
        return __ssp_weak_name(fun) call; \
}

by you defining __ssp_weak_name -> _hijack_read(), you end up expanding
in <ssp/unistd.h>

ssize_t _hijack_read(int __fd, void *__buf, size_t __len);

inline ssize_t read(int __fd, void *__buf, size_t __len);
inline ssize_t read(int __fd, void *__buf, size_t __len) {
        __ssp_check(__buf, __len, bos);
        return _hijack_read(__fd, __buf, __len);
}

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.

christos


Home | Main Index | Thread Index | Old Index