| Message ID | cover.1782766548.git.fweimer@redhat.com (mailing list archive) |
|---|---|
| Headers |
Return-Path: <libc-alpha-bounces~patchwork=sourceware.org@sourceware.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 4D20A4BA23FE for <patchwork@sourceware.org>; Mon, 29 Jun 2026 21:07:33 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4D20A4BA23FE Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=iveKzJON X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTP id 2EE604BA23D6 for <libc-alpha@sourceware.org>; Mon, 29 Jun 2026 21:07:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2EE604BA23D6 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 2EE604BA23D6 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1782767222; cv=none; b=cBKfj4xMU4pqCBPyEF7hUIvcnjhA3n7pIfy6czzFo8SVFUczrne6cGE3VZp5+il+tmD8YFikIMLBgs5dzqT6NzIg7yu4gYyLC/NyZ4J5xHfltXLRmBoJzaTN74lrH5N5Rrfw0lwvRc/Yk/+cCNDC2UaDQ/ybu4R5sGpasZIDTQI= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1782767222; c=relaxed/simple; bh=r7hJV1JiW5QlZuNIc+dDZbsuifebQsi3ub1LP/EDVME=; h=DKIM-Signature:From:To:Subject:Message-ID:Date:MIME-Version; b=xoKN9XW4k2yAwybfPuV1H1gXrK29t0Fko/zcsXgbkOqmloEkU4ltIo1CbdPr9ZfpDv7RIbc9W9daLkQFn2YTo197/gQNn/FLzE2oD3LmAblrDTQyajXA27ziVwTzhTIt7EFiBqIASbj2V+ZlN68j/e6AxmCJPqLFfyC7VQndYy8= ARC-Authentication-Results: i=1; sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=iveKzJON DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2EE604BA23D6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1782767221; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type; bh=+aBP2rywgRV50y/3BR0D/bLzcYbTEEtMgK9hkZMky9w=; b=iveKzJON9SRNevcySTnm70AHS9YXmQAdvwUKnMw9cxplfwQeB40MsBhTDsipDtCUxIQLE+ 12Lc6tk8YZ+DgCY5pFhzjQIaLT9H4SgnjlpkY42GxseynMxoCxHAYhvjZkvkI+QD1m5YAU XtSbEzzFPll6qmev1R1e138FZFa201E= Received: from mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-532-asdg1_jRPjiKcnzcbT3kPQ-1; Mon, 29 Jun 2026 17:06:58 -0400 X-MC-Unique: asdg1_jRPjiKcnzcbT3kPQ-1 X-Mimecast-MFC-AGG-ID: asdg1_jRPjiKcnzcbT3kPQ_1782767217 Received: from mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.93]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 3656518E6A42; Mon, 29 Jun 2026 21:06:57 +0000 (UTC) Received: from fweimer-oldenburg.csb.redhat.com (unknown [10.44.48.121]) by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id A243F18005A3; Mon, 29 Jun 2026 21:06:53 +0000 (UTC) From: Florian Weimer <fweimer@redhat.com> To: libc-alpha@sourceware.org Cc: Simon Marchi <simark@simark.ca>, Andrew Burgess <aburgess@redhat.com>, Wilco Dijkstra <Wilco.Dijkstra@arm.com>, Yury Khrustalev <Yury.Khrustalev@arm.com>, Thiago Jung Bauermann <thiago.bauermann@linaro.org>, Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>, Carlos O'Donell <carlos@redhat.com>, Muhammad Kamran <muhammad.kamran@arm.com> Subject: [PATCH 0/2] Work around GDB bug overwriting __libc_malloc Message-ID: <cover.1782766548.git.fweimer@redhat.com> X-From-Line: 5fde182125e1e9d8a4c428a81b71aa78342a9836 Mon Sep 17 00:00:00 2001 Date: Mon, 29 Jun 2026 23:06:46 +0200 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.93 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: -KskLThFHlPiHISjHAVtjJr2iqjpmH8BrbUFoRsNJxc_1782767217 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, RCVD_IN_SBL_CSS, SPF_HELO_PASS, SPF_NONE, TXREP shortcircuit=no autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Libc-alpha mailing list <libc-alpha.sourceware.org> List-Unsubscribe: <https://sourceware.org/mailman/options/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=unsubscribe> List-Archive: <https://sourceware.org/pipermail/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-request@sourceware.org?subject=help> List-Subscribe: <https://sourceware.org/mailman/listinfo/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=subscribe> Errors-To: libc-alpha-bounces~patchwork=sourceware.org@sourceware.org |
| Series |
Work around GDB bug overwriting __libc_malloc
|
|
Message
Florian Weimer
June 29, 2026, 9:06 p.m. UTC
This is a workaround for a GDB bug where it overwrites __libc_malloc (yes, the code) with user-supplied string literals during inferior function call evaluation. [PATCH v3 0/2] gdb: Fix internal inferior calls through GNU IFUNCs <https://inbox.sourceware.org/gdb-patches/20260629153203.10142-1-muhammad.kamran@arm.com> It works by recognizing on-stack and AT_ENTRY trampoline call sites in the malloc IFUNC resolver. If a call by GDB is detect, malloc is invoked directly from the IFUNC resolver (returning a heap pointer), instead of returning the __libc_malloc address. An alternative approach would involve a flag in the TCB that is set and cleared around the IFUNC resolver call. It's perhaps cleaner, but it adds a tiny overhead to every IFUNC resolution. We could also special-case malloc and redirect its resolution without the IFUNC mechanism. However, I expect this requires that the implementation that GDB sees through the symbol tables remains sufficiently compatible with the one selected via the IFUNC-like mechanism (unless GDB reads non-IFUNC symbol values from relocations, too, which I doubt). I fear we need something like this if we want to switch to IFUNCs for malloc any time soon because we don't control the pace at which users update their GDB version. Thanks, Florian Florian Weimer (2): elf: Record original entry point in GLRO(dl_entry) aarch64: Add workaround for GDB bug handling string literals elf/rtld.c | 1 + sysdeps/aarch64/multiarch/malloc-ifuncs.c | 60 +++++++++++++++++------ sysdeps/generic/ldsodefs.h | 4 ++ 3 files changed, 51 insertions(+), 14 deletions(-) base-commit: ccd4cd5324caaaea1bb12bc8cef073170da51a19
Comments
Am Dienstag, 30. Juni 2026, 06:06:46 Japanische Normalzeit schrieb Florian Weimer: > This is a workaround for a GDB bug where it overwrites __libc_malloc > (yes, the code) with user-supplied string literals during inferior > function call evaluation. > > [PATCH v3 0/2] gdb: Fix internal inferior calls through GNU IFUNCs > <https://inbox.sourceware.org/gdb-patches/20260629153203.10142-1-muhammad.kamran@arm.com> > > It works by recognizing on-stack and AT_ENTRY trampoline call sites in > the malloc IFUNC resolver. If a call by GDB is detect, malloc is > invoked directly from the IFUNC resolver (returning a heap pointer), > instead of returning the __libc_malloc address. This is the kind of kludge one adds once and then never dares to remove... In general it's much easier to update gdb than to update glibc. Do we really need this? > > An alternative approach would involve a flag in the TCB that is set and > cleared around the IFUNC resolver call. It's perhaps cleaner, but it > adds a tiny overhead to every IFUNC resolution. > > We could also special-case malloc and redirect its resolution without > the IFUNC mechanism. However, I expect this requires that the > implementation that GDB sees through the symbol tables remains > sufficiently compatible with the one selected via the IFUNC-like > mechanism (unless GDB reads non-IFUNC symbol values from relocations, > too, which I doubt). > > I fear we need something like this if we want to switch to IFUNCs for > malloc any time soon because we don't control the pace at which users > update their GDB version. > > Thanks, > Florian > > Florian Weimer (2): > elf: Record original entry point in GLRO(dl_entry) > aarch64: Add workaround for GDB bug handling string literals > > elf/rtld.c | 1 + > sysdeps/aarch64/multiarch/malloc-ifuncs.c | 60 +++++++++++++++++------ > sysdeps/generic/ldsodefs.h | 4 ++ > 3 files changed, 51 insertions(+), 14 deletions(-) > > > base-commit: ccd4cd5324caaaea1bb12bc8cef073170da51a19 >