public inbox for libc-help@sourceware.org
 help / color / mirror / Atom feed
From: Florian Weimer <fweimer@redhat.com>
To: Andreas Fink via Libc-help <libc-help@sourceware.org>
Subject: Re: Hooking execve for an LD_PRELOAD library
Date: Mon, 18 Jan 2021 11:39:49 +0100	[thread overview]
Message-ID: <87sg6yr0ju.fsf@oldenburg.str.redhat.com> (raw)
In-Reply-To: <0LgHf2-1lmY0O29NE-00ngvl@smtp.web.de> (Andreas Fink via Libc-help's message of "Sun, 17 Jan 2021 12:28:03 +0100")

* Andreas Fink via Libc-help:

> Ok, if I understood you correctly this is the expected behaviour. I was
> afraid of it, but ok I can live with it.
> Assuming I want to hook the whole exec-family, it seems easy to just
> add hooks for the execv* functions while forwarding all arguments to
> the corresponding glibc implementation.

You will also have to deal with system, popen, posix_spawn,
posix_spawnp.

> Forwarding the execl* functions seems a bit more involved, as I would
> have to bend the va_list to an array, or is there some way to forward
> the arguments to the glibc function without unwrapping the va_list?

I don't think this is possible in general.  GCC has __builtin_apply and
__builtin_apply_args, but I don't know if they work with variadic
functions on all architectures.

> Kernel-based mechanism (in my case that's Linux) sounds also interesting
> as it is one level lower I guess, but honestly speaking I have no idea
> where to start to look at. Do you know of an example (not necesserily
> execve, but any system call where this is done)?

You can find examples for ptrace system call interception and emulation
on the web.  Niels Provos' systrace also has a ptrace backend, which
could serve as a source of inspiration.

> I guess glibc must do this of course, but I could not directly find
> for example the real implementation of execve.

glibc doesn't do this, not even in its test suite.  (We probably should
use this for testing obscure kernel features, but as far as I know, we
currently don't.)

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill


  reply	other threads:[~2021-01-18 10:39 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-17  7:07 Andreas Fink
2021-01-17  8:30 ` Florian Weimer
2021-01-17 11:28   ` Andreas Fink
2021-01-18 10:39     ` Florian Weimer [this message]
2021-01-20 11:00       ` Andreas Fink

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87sg6yr0ju.fsf@oldenburg.str.redhat.com \
    --to=fweimer@redhat.com \
    --cc=libc-help@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).