From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id 382EA3857C7A for ; Mon, 18 Jan 2021 10:39:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 382EA3857C7A Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-139-Rp_eDsvXOV-pHjfM51hWAw-1; Mon, 18 Jan 2021 05:39:56 -0500 X-MC-Unique: Rp_eDsvXOV-pHjfM51hWAw-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id E833A100F351; Mon, 18 Jan 2021 10:39:54 +0000 (UTC) Received: from oldenburg.str.redhat.com (ovpn-112-110.ams2.redhat.com [10.36.112.110]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 1ED7B60936; Mon, 18 Jan 2021 10:39:53 +0000 (UTC) From: Florian Weimer To: Andreas Fink via Libc-help Subject: Re: Hooking execve for an LD_PRELOAD library References: <1MiMEW-1lf4081KQ2-00fS4y@smtp.web.de> <878s8srmnh.fsf@oldenburg.str.redhat.com> <0LgHf2-1lmY0O29NE-00ngvl@smtp.web.de> Date: Mon, 18 Jan 2021 11:39:49 +0100 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") Message-ID: <87sg6yr0ju.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-help@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-help mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2021 10:39:59 -0000 * 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