From patchwork Wed Feb 21 20:28:40 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Pedro Alves X-Patchwork-Id: 86195 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 2B9DD3858289 for ; Wed, 21 Feb 2024 20:29:17 +0000 (GMT) X-Original-To: gdb-patches@sourceware.org Delivered-To: gdb-patches@sourceware.org Received: from mail-wr1-f46.google.com (mail-wr1-f46.google.com [209.85.221.46]) by sourceware.org (Postfix) with ESMTPS id 04531385843B for ; Wed, 21 Feb 2024 20:28:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 04531385843B Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 04531385843B Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=209.85.221.46 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1708547326; cv=none; b=LGXjQYa3Eckh1J27a3JKwVXlf0gfkwxasrNuZIHpi3jaBZIDeIqt90Ae5SQvZexSU0HSOqdii6/r4ADawNVYtqWuCaIUR4nQiG81BxS3f7PPRVYlThEkNrEjTfZ0Z5Z92AiOCcKdPKSDXq6MPEqj9uhz31v6w6iwLv/btDXpCIU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1708547326; c=relaxed/simple; bh=25AjBF5VQiLhHUqCG2GdecTPaOe5DJzgfpnfPr4VFhM=; h=From:To:Subject:Date:Message-ID:MIME-Version; b=jfHYErQ8O6VJNnyPhWKJjW44aFmd1zwqVO4I/i8a9e5Q3Uo+0BxfrZu9GzGFrh/1EstKamIXAjATY//oIGirKCntAcdKQv9zHR2SoeBg/Gp26iReTzuXB/24XfC3JgLUwHpK46I3geSefp1OjrHm4HXIQ2qC9ua528JDDwxmcR0= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-wr1-f46.google.com with SMTP id ffacd0b85a97d-33d44d78e5fso1992441f8f.1 for ; Wed, 21 Feb 2024 12:28:43 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708547322; x=1709152122; h=content-transfer-encoding:mime-version:message-id:date:subject:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=9j6bLissWPEzyVxk4wKHHPEzy6OKz0YUe0j9105bdxg=; b=GzOHdL+SKeLWyertR9B4Xkjby2/Sz/kb3nVCMGScS0GdvS89R5mYi0nomSrbi725Ul EQKatZFeFXMJnY9L4OR1q+L+U4bwcrSQWoHwMMd/pvFmCFPYn0GMLw6KJmt7ynRqFLx2 BQtTXvq7/2ig4AcXyqj2QfsqdOpMaN1cTOvHCsMSThxN5gtFHewIZ63kBkK/fr9zB3ct TNBlhHj+GDU4B2qTWqaI0IWamFCQtgEnXGMyqyWbKtsOszXiJXRtfDOaQTtT4JBG2R2E qctkNFO8fGlIB+nqlmilomCN/vUr9YbvHjUO/BPhO5qOXcrPyAlPj3vDct3W2ctrKcJL MGAQ== X-Gm-Message-State: AOJu0Yyn4SU/KCBUNW3akGsl4A3WHDvPSdBRh6nQwc/J9BojyPc6BSmN 983S9k2jiNPITKYENUbFyHDnl3fffcuzhtiLjaL07ZmrTJN7re1DQlKJ9SipqeI= X-Google-Smtp-Source: AGHT+IEBA+Kc+fy3u7eQ0IVWkEifJRb7QD5Ul4XzJaR8xXWXKFvw9DOs7XOiYChAtwc/7XeoLyoggw== X-Received: by 2002:a05:6000:d87:b0:33d:108e:bcc3 with SMTP id dv7-20020a0560000d8700b0033d108ebcc3mr11932670wrb.35.1708547322235; Wed, 21 Feb 2024 12:28:42 -0800 (PST) Received: from localhost ([2001:8a0:f918:ab00:e0e8:3620:43e9:e37a]) by smtp.gmail.com with UTF8SMTPSA id k14-20020a5d428e000000b0033ce5b3390esm17942055wrq.38.2024.02.21.12.28.41 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 21 Feb 2024 12:28:41 -0800 (PST) From: Pedro Alves To: gdb-patches@sourceware.org Subject: [PATCH] gdb/linux-nat.c: Add "Accessing inferior memory" section Date: Wed, 21 Feb 2024 20:28:40 +0000 Message-ID: <20240221202840.772802-1-pedro@palves.net> X-Mailer: git-send-email 2.43.2 MIME-Version: 1.0 X-Spam-Status: No, score=-10.3 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, GIT_PATCH_0, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces+patchwork=sourceware.org@sourceware.org This commit adds a new "Accessing inferior memory" comment section to gdb/linux-nat.c that explains why we prefer /proc/pid/mem over alternatives. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30453 Change-Id: I575b21ed697a85f3ff4c0ec58c04812db5005b76 --- gdb/linux-nat.c | 58 ++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 57 insertions(+), 1 deletion(-) base-commit: 23acbfee6a82cc147b04b74a89d5b34b47c150f4 diff --git a/gdb/linux-nat.c b/gdb/linux-nat.c index e91c57ba239..21928c681ef 100644 --- a/gdb/linux-nat.c +++ b/gdb/linux-nat.c @@ -180,7 +180,63 @@ execing thread, the leader will be zombie, and the execing thread will be in `D (disc sleep)' state. As soon as all other threads are reaped, the execing thread changes its tid to the tgid, and the previous (zombie) leader vanishes, giving place to the "new" -leader. */ +leader. + +Accessing inferior memory +========================= + +To access inferior memory, we strongly prefer /proc/PID/mem. We +fallback to ptrace if and only if /proc/PID/mem is not writable, as a +concession for obsolescent kernels (such as found in RHEL6). For +modern kernels, the fallback shouldn't trigger. GDBserver does not +have the ptrace fallback already, and at some point, we'll consider +removing it from native GDB too. + +/proc/PID/mem has a few advantages over alternatives like +PTRACE_PEEKTEXT/PTRACE_POKETEXT or process_vm_readv/process_vm_writev: + +- Because we can use a single read/write call, /proc/PID/mem can be + much more efficient than banging away at + PTRACE_PEEKTEXT/PTRACE_POKETEXT, one word at a time. + +- /proc/PID/mem allows writing to read-only pages, which we need to + e.g., plant breakpoint instructions. process_vm_writev does not + allow this. + +- /proc/PID/mem allows memory access even if all threads are running. + OTOH, PTRACE_PEEKTEXT/PTRACE_POKETEXT require passing down the tid + of a stopped task. This lets us e.g., install breakpoints while the + inferior is running, clear a displaced stepping scratch pad when the + thread that was displaced stepping exits, print inferior globals, + etc., all without having to worry about temporarily pausing some + thread. + +- /proc/PID/mem does not suffer from a race that could cause us to + access memory of the wrong address space when the inferior execs. + + process_vm_readv/process_vm_writev have this problem. + + E.g., say GDB decides to write to memory just while the inferior + execs. In this scenario, GDB could write memory to the post-exec + address space thinking it was writing to the pre-exec address space, + with high probability of corrupting the inferior. Or of GDB decides + instead to read memory just while the inferior execs, it could read + bogus contents out of the wrong address space. + + ptrace used to have this problem too, but no longer has since Linux + commit dbb5afad100a ("ptrace: make ptrace() fail if the tracee + changed its pid unexpectedly"), in Linux 5.13. (And if ptrace were + ever changed to allow access memory via zombie or running threads, + it would better not forget to consider this scenario.) + + We avoid this race with /proc/PID/mem, by opening the file as soon + as we start debugging the inferior, when it is known the inferior is + stopped, and holding on to the open file descriptor, to be used + whenever we need to access inferior memory. If the inferior execs + or exits, reading/writing from/to the file returns 0 (EOF), + indicating the address space is gone, and so we return + TARGET_XFER_EOF to the core. We close the old file and open a new + one when we finally see the PTRACE_EVENT_EXEC event. */ #ifndef O_LARGEFILE #define O_LARGEFILE 0