|
From: Julian S. <js...@ac...> - 2004-07-17 12:21:30
|
Greetings, all. I'm trying to get 2.1.2 out the door very shortly (ideally this weekend). Does anyone have any outstanding changes which need to go in before it ships? J |
|
From: Nicholas N. <nj...@ca...> - 2004-07-17 12:48:28
|
On Sat, 17 Jul 2004, Julian Seward wrote: > Greetings, all. I'm trying to get 2.1.2 out the door very shortly > (ideally this weekend). Does anyone have any outstanding changes > which need to go in before it ships? I'll do one last one, which just checks the result of some mmap() and munmap() calls in coregrind/ume.c. This will fix bug 82722. (I will try to add a regression test eventually, but that can wait.) N |
|
From: Robert W. <rj...@du...> - 2004-07-17 14:10:26
|
> Greetings, all. I'm trying to get 2.1.2 out the door very shortly > (ideally this weekend). Does anyone have any outstanding changes > which need to go in before it ships? Nothing on this end. I'm doing some minor experimental stuff that isn't release-critical (code injection being one of them.) Regards, Robert. --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |
|
From: Robert W. <rj...@du...> - 2004-07-17 15:28:03
|
> > I'm doing some minor experimental stuff that isn't release-critical=20 > > (code injection being one of them.) >=20 > What is code injection? It's not function wrapping, is it? Cos that=20 > would be really cool to have. Yup. "At the start of this function, or at this address here, when this condition is true, do this", where "do this" can be a bunch of different things, including executing arbitrary code, etc. I haven't gotten very far yet, though. Too many other things to do, especially at work after coming back from a 3-week vacation. Sigh. Might be a better way of doing library call interception. Regards, Robert. --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |
|
From: Nicholas N. <nj...@ca...> - 2004-07-17 16:08:13
|
On Sat, 17 Jul 2004, Robert Walsh wrote: > Yup. "At the start of this function, or at this address here, when this > condition is true, do this", where "do this" can be a bunch of different > things, including executing arbitrary code, etc. Neat. Would it give access to function arguments, or would you have to ferret around and get them yourself? N |
|
From: Tom H. <th...@cy...> - 2004-07-17 15:41:39
|
In message <109...@dr...>
Robert Walsh <rj...@du...> wrote:
> > What is code injection? It's not function wrapping, is it? Cos that
> > would be really cool to have.
>
> Yup. "At the start of this function, or at this address here, when this
> condition is true, do this", where "do this" can be a bunch of different
> things, including executing arbitrary code, etc. I haven't gotten very
> far yet, though. Too many other things to do, especially at work after
> coming back from a 3-week vacation. Sigh.
Can it manage doing things at the end of the function as well?
It sounds like what we need in order to continue tracking mutexes
and things if we dump our libpthread and use the glibc one.
> Might be a better way of doing library call interception.
Well we already have an interception system for doing full
replacement, what's missing is way of adding code while still
using the original function implementation - something like
the advice system in emacs lisp.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2004-07-17 16:09:22
|
On Sat, 17 Jul 2004, Tom Hughes wrote: > Well we already have an interception system for doing full > replacement, what's missing is way of adding code while still > using the original function implementation - something like > the advice system in emacs lisp. ld's --wrap option is exactly what we want, I think. N |
|
From: Tom H. <th...@cy...> - 2004-07-17 16:14:36
|
In message <Pin...@he...>
Nicholas Nethercote <nj...@ca...> wrote:
> On Sat, 17 Jul 2004, Tom Hughes wrote:
>
> > Well we already have an interception system for doing full
> > replacement, what's missing is way of adding code while still
> > using the original function implementation - something like
> > the advice system in emacs lisp.
>
> ld's --wrap option is exactly what we want, I think.
Except that would require the user to build their program using
that option if I'm reading the manual page correctly.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2004-07-17 16:18:05
|
On Sat, 17 Jul 2004, Tom Hughes wrote: >> ld's --wrap option is exactly what we want, I think. > > Except that would require the user to build their program using > that option if I'm reading the manual page correctly. Sorry, I should have been clearer: we want to do ourselves exactly what ld --wrap does. Ie. function replacement as we do now, but be able to call the original function within the replacement. N |
|
From: Jarrod G. <gr...@cs...> - 2004-07-18 05:18:18
|
On Sat, 17 Jul 2004, Nicholas Nethercote wrote: > Sorry, I should have been clearer: we want to do ourselves exactly what > ld --wrap does. Ie. function replacement as we do now, but be able to > call the original function within the replacement. > > N I wonder if you could use some ideas like those in detours from M$ Research: http://research.microsoft.com/research/sn/detours/ & http://research.microsoft.com/~galenh/Publications/HuntUsenixNt99.pdf Most COTS rootkits use detours like techniques to inject code into functions. Jarrod |
|
From: Nicholas N. <nj...@ca...> - 2004-07-17 15:05:48
|
On Sat, 17 Jul 2004, Robert Walsh wrote: > I'm doing some minor experimental stuff that isn't release-critical > (code injection being one of them.) What is code injection? It's not function wrapping, is it? Cos that would be really cool to have. N |