Message ID | 20240328224850.2785280-1-gustavo.romero@linaro.org |
---|---|
Headers |
Return-Path: <gdb-patches-bounces+patchwork=sourceware.org@sourceware.org> 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 0C4063857C4F for <patchwork@sourceware.org>; Thu, 28 Mar 2024 22:50:21 +0000 (GMT) X-Original-To: gdb-patches@sourceware.org Delivered-To: gdb-patches@sourceware.org Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) by sourceware.org (Postfix) with ESMTPS id 753853858D32 for <gdb-patches@sourceware.org>; Thu, 28 Mar 2024 22:49:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 753853858D32 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 753853858D32 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::636 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1711666185; cv=none; b=p4skwrYqHt3jtqvqBLkjwFU4noUCctaHDA6683rMAWUd0Dc5/B6/wa8O6A1nq2f7dcMV7voOzxS1eVpUfRH57Bykfq9GsNUk6Oga+oUscLDA/AaECPPbXzJHuv8Aq0KnlSwP/B5qBuiRABIb3s48tOjWDx+ZlF6QGgyTV7Q4zCk= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1711666185; c=relaxed/simple; bh=IcOybDyTpMzijvmXeM6YgSFhLSLLYcEGuaARjoXbHG0=; h=DKIM-Signature:From:To:Subject:Date:Message-Id:MIME-Version; b=VzxkxPolTkOBXPs3BWow0udi+I5jMQHuoHw2jwrTQhAkyAFv0iBuTEvsl4ntznWyktjVqPZeP5WUApqsvHdcPH/ZtU7XPnRX0cDh5IdpGVB+TBsebbEIdKmwMbBtSJcB5VTuUt7pbh3O9MmkVtVG+n4qx6STgeTt1Qxv+dy9Xbk= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-pl1-x636.google.com with SMTP id d9443c01a7336-1e00d1e13a2so11637905ad.0 for <gdb-patches@sourceware.org>; Thu, 28 Mar 2024 15:49:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1711666181; x=1712270981; darn=sourceware.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=Ut7WG7yFiB+QNtbG6uehIXCk7vvGlqnqOsRFgZ/Ce5k=; b=q6uyAHB3VON5Wqpj6l/d71ZOVz8X8v6Yq62v1mcGiADh/tcsaQFAAJaTiXiebMtddq G0kHRBwBAPDiziVxgQB8PuRivs7x2Ifug+Y2aXKdXYeSzUhxIYjIJpO752Uzq+GbN1+/ ipBwMEs/TjewyzxDKj4+vKtYNGEOJXQFrAz6aOHg5kgvDGgXofaQL26y1wG9WTkaRJb2 9BTrGZdv+jroUpziokjsCVUfKXb5leHPNHBkI2hr/KY2CF8TWegHb3gnv9i3ym+GkNHO x/3S8VRr7qfPMShJUofDZNNsGPDIZniMN1H2GpuURj5F3SQdMlbSnDFBUOG9EU97Cixa Jhsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711666181; x=1712270981; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Ut7WG7yFiB+QNtbG6uehIXCk7vvGlqnqOsRFgZ/Ce5k=; b=qFzL4y2DGf8XMcZEC3Tj4qWWcf8+VPjJoQA0d8NRGFmur/+RyKbuwufaEAzltNZchk iT6b7s9bn1wlRyvbOuy94I/ZtONfdQaaJNcbksfp1FiWlWxvSKA4BJ5pgVgoa34/evxa q5cFRs1/kF1tv2SR8lNCssYB5RA/H0J9UddFQhtuQcS4vflCy2uT8/1oisxY6DfPhG4e Hzb0i+g3qWqJPCRGkc59FifxA7psheok4MhBBn4LG8/Rp4nUOIAkvKxsGN/b0Xg6kGFX Llp4OVtYil3lMWwbla+y/fZXynOQjCXy88umi+cMcxu9/KgjOGn7yirJjZElO7VhQwOi Qs3Q== X-Gm-Message-State: AOJu0Yy9RLYxZu2qnD+MuRAMMsVKac3RjNuOczyWOlV+FXaOVw482/7W ReLczGC/8xMNIjvaeSOsh8gWOq8wuQT/MqSZI0u9sq+qgIBAEUcRloNjdjQlch9h9dEo7OLoD+Y K X-Google-Smtp-Source: AGHT+IFTFWwuCovBMvNgeTkHVmNPzBpSTkxeTtbn6LjAdV+OyBx1wbzoqai6wfS9gjNu3PXmYcHT1g== X-Received: by 2002:a17:903:2ca:b0:1e1:a54:1fe8 with SMTP id s10-20020a17090302ca00b001e10a541fe8mr1114310plk.53.1711666180891; Thu, 28 Mar 2024 15:49:40 -0700 (PDT) Received: from amd.. ([2804:7f0:b402:d0dc:3e7c:3fff:fe7a:e83b]) by smtp.gmail.com with ESMTPSA id t4-20020a170902e84400b001d8be6d1ec4sm2162999plg.39.2024.03.28.15.49.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 28 Mar 2024 15:49:40 -0700 (PDT) From: Gustavo Romero <gustavo.romero@linaro.org> To: gdb-patches@sourceware.org Cc: luis.machado@arm.com, thiago.bauermann@linaro.org, gustavo.romero@linaro.org Subject: [PATCH v2 0/4] Add another way to check for MTE-tagged addresses on remote targets Date: Thu, 28 Mar 2024 22:48:46 +0000 Message-Id: <20240328224850.2785280-1-gustavo.romero@linaro.org> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP 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 <gdb-patches.sourceware.org> List-Unsubscribe: <https://sourceware.org/mailman/options/gdb-patches>, <mailto:gdb-patches-request@sourceware.org?subject=unsubscribe> List-Archive: <https://sourceware.org/pipermail/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-request@sourceware.org?subject=help> List-Subscribe: <https://sourceware.org/mailman/listinfo/gdb-patches>, <mailto:gdb-patches-request@sourceware.org?subject=subscribe> Errors-To: gdb-patches-bounces+patchwork=sourceware.org@sourceware.org |
Series |
Add another way to check for MTE-tagged addresses on remote targets
|
|
Message
Gustavo Romero
March 28, 2024, 10:48 p.m. UTC
This series introduces a new method to check for MTE-tagged addresses on remote targets. A new remote packet, qMemTagAddrCheck, is introduced, along with a new remote feature associated with it, 'memory-tagging-check-add+'. Only when 'memory-tagging-check-add+' feature is advertised GDB will use the new packet to query if an address is tagged. This new mechanism allows for checking MTE addresses in an OS-agnostic way, which is necessary when debugging targets that do not support '/proc/<PID>/smaps', as the current method of reading the smaps contents fails in such cases. Since v1: - Fixed build error "no match for ‘operator!=’ (operand types are ‘packet_result’ and ‘packet_status’)" reported by Linaro CI bot, caused by a last-minute rebase; - Added instructions on how to test the series on a remote target using QEMU gdbstub (-g option) -- see below. ---- This series can be tested with the 'mte_t' binary found in: https://people.linaro.org/~gustavo.romero/gdb, using the GDB 'memory-tag print-allocation-tag' command to show the allocation tag for array pointer 'a'. To download mte_t: $ wget https://people.linaro.org/~gustavo.romero/gdb/mte_t $ chmod +x ./mte_t ... or build it from source: $ wget https://people.linaro.org/~gustavo.romero/gdb/mte_t.c $ gcc -march=armv8.5-a+memtag -static -g3 -O0 mte_t.c -o mte_t For example, testing the address check for the aarch64_linux_nat.c target: gromero@arm64:~/code$ ~/git/binutils-gdb_remote/build/gdb/gdb -q ./mte_t Reading symbols from ./mte_t... (gdb) run Starting program: /home/gromero/code/mte_t a[] address is 0xfffff7ffc000 a[0] = 1 a[1] = 2 0x100fffff7ffc000 a[0] = 3 a[1] = 2 Expecting SIGSEGV... Program received signal SIGSEGV, Segmentation fault Memory tag violation Fault address unavailable. 0x0000000000418658 in write () (gdb) bt #0 0x0000000000418658 in write () #1 0x000000000040a3bc in _IO_new_file_write () #2 0x0000000000409574 in new_do_write () #3 0x000000000040ae20 in _IO_new_do_write () #4 0x000000000040b55c in _IO_new_file_overflow () #5 0x0000000000407414 in puts () #6 0x000000000040088c in main () at mte_t.c:119 (gdb) frame 6 #6 0x000000000040088c in main () at mte_t.c:119 119 printf("...haven't got one\n"); (gdb) memory-tag print-logical-tag a $1 = 0x1 (gdb) memory-tag print-allocation-tag &a[16] $2 = 0x0 (gdb) # Tag mismatch (gdb) Testing address check on a core file: gromero@arm64:~/code$ ulimit -c unlimited gromero@arm64:~/code$ ./mte_t a[] address is 0xffffb3bcc000 a[0] = 1 a[1] = 2 0x900ffffb3bcc000 a[0] = 3 a[1] = 2 Expecting SIGSEGV... Segmentation fault (core dumped) gromero@arm64:~/code$ ~/git/binutils-gdb_remote/build/gdb/gdb -q ./mte_t ./core Reading symbols from ./mte_t... [New LWP 256036] Core was generated by `./mte_t'. Program terminated with signal SIGSEGV, Segmentation fault Memory tag violation Fault address unavailable. #0 0x0000000000418658 in write () (gdb) bt #0 0x0000000000418658 in write () #1 0x000000000040a3bc in _IO_new_file_write () #2 0x0000000000409574 in new_do_write () #3 0x000000000040ae20 in _IO_new_do_write () #4 0x000000000040b55c in _IO_new_file_overflow () #5 0x0000000000407414 in puts () #6 0x000000000040088c in main () at mte_t.c:119 (gdb) frame 6 #6 0x000000000040088c in main () at mte_t.c:119 119 printf("...haven't got one\n"); (gdb) memory-tag print-logical-tag a $1 = 0x9 (gdb) memory-tag print-allocation-tag &a[16] $2 = 0x0 (gdb) # Tag mismatch (gdb) And, finally, testing it on a remote target using QEMU gdbstub which supports the new 'memory-tagging-check-add+' feature (WIP). Clone and build QEMU: $ git clone --depth=1 --single-branch -b mte https://github.com/gromero/qemu.git $ mkdir qemu/build && cd qemu/build $ ../configure --target-list=aarch64-linux-user --disable-docs $ make -j $ wget https://people.linaro.org/~gustavo.romero/gdb/mte_t $ chmod +x ./mte_t $ ./qemu-aarch64 -g 1234 ./mte_t ... and connect to QEMU gdbstub from GDB: gromero@amd:~/git/binutils-gdb/build$ ./gdb/gdb -q (gdb) target remote localhost:1234 Remote debugging using localhost:1234 Reading /tmp/qemu/build/mte_t from remote target... warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead. Reading /tmp/qemu/build/mte_t from remote target... Reading symbols from target:/tmp/qemu/build/mte_t... (gdb) c Continuing. Program received signal SIGSEGV, Segmentation fault Memory tag violation Fault address unavailable. 0x0000000000407290 in puts () (gdb) bt #0 0x0000000000407290 in puts () #1 0x000000000040088c in main () at mte_t.c:119 (gdb) frame 1 #1 0x000000000040088c in main () at mte_t.c:119 119 (gdb) memory-tag print-allocation-tag a $1 = 0x2 (gdb) set debug remote on (gdb) memory-tag print-allocation-tag a [remote] Sending packet: $qMemTagAddrCheck:200400000802000#1f [remote] Received Ack [remote] Packet received: 01 [remote] Sending packet: $qMemTags:400000802000,1:1#6f [remote] Received Ack [remote] Packet received: m02 $2 = 0x2 (gdb) Cheers, Gustavo Gustavo Romero (4): gdb: aarch64: Remove MTE address checking from get_memtag gdb: aarch64: Move MTE address check out of set_memtag gdb: aarch64: Remove MTE address checking from memtag_matches_p gdb: Add new remote packet to check if address is tagged gdb/aarch64-linux-nat.c | 8 +++++ gdb/aarch64-linux-tdep.c | 22 +++----------- gdb/arch-utils.c | 2 +- gdb/arch-utils.h | 2 +- gdb/corelow.c | 8 +++++ gdb/gdbarch-gen.h | 4 +-- gdb/gdbarch.c | 2 +- gdb/gdbarch_components.py | 2 +- gdb/printcmd.c | 29 +++++++++++------- gdb/remote.c | 62 +++++++++++++++++++++++++++++++++++++++ gdb/target-delegates.c | 28 ++++++++++++++++++ gdb/target.c | 6 ++++ gdb/target.h | 6 ++++ 13 files changed, 147 insertions(+), 34 deletions(-)
Comments
Hi, On 3/28/24 22:48, Gustavo Romero wrote: > This series introduces a new method to check for MTE-tagged addresses on > remote targets. > > A new remote packet, qMemTagAddrCheck, is introduced, along with a new > remote feature associated with it, 'memory-tagging-check-add+'. Only > when 'memory-tagging-check-add+' feature is advertised GDB will use the > new packet to query if an address is tagged. > > This new mechanism allows for checking MTE addresses in an OS-agnostic > way, which is necessary when debugging targets that do not support > '/proc/<PID>/smaps', as the current method of reading the smaps contents > fails in such cases. > > Since v1: > - Fixed build error "no match for ‘operator!=’ (operand types are ‘packet_result’ and ‘packet_status’)" > reported by Linaro CI bot, caused by a last-minute rebase; > - Added instructions on how to test the series on a remote target using > QEMU gdbstub (-g option) -- see below. > > ---- > > This series can be tested with the 'mte_t' binary found in: > https://people.linaro.org/~gustavo.romero/gdb, using the GDB > 'memory-tag print-allocation-tag' command to show the allocation > tag for array pointer 'a'. To download mte_t: > > $ wget https://people.linaro.org/~gustavo.romero/gdb/mte_t > $ chmod +x ./mte_t > > ... or build it from source: > > $ wget https://people.linaro.org/~gustavo.romero/gdb/mte_t.c > $ gcc -march=armv8.5-a+memtag -static -g3 -O0 mte_t.c -o mte_t > > For example, testing the address check for the aarch64_linux_nat.c > target: > > gromero@arm64:~/code$ ~/git/binutils-gdb_remote/build/gdb/gdb -q ./mte_t > Reading symbols from ./mte_t... > (gdb) run > Starting program: /home/gromero/code/mte_t > a[] address is 0xfffff7ffc000 > a[0] = 1 a[1] = 2 > 0x100fffff7ffc000 > a[0] = 3 a[1] = 2 > Expecting SIGSEGV... > > Program received signal SIGSEGV, Segmentation fault > Memory tag violation > Fault address unavailable. > 0x0000000000418658 in write () > (gdb) bt > #0 0x0000000000418658 in write () > #1 0x000000000040a3bc in _IO_new_file_write () > #2 0x0000000000409574 in new_do_write () > #3 0x000000000040ae20 in _IO_new_do_write () > #4 0x000000000040b55c in _IO_new_file_overflow () > #5 0x0000000000407414 in puts () > #6 0x000000000040088c in main () at mte_t.c:119 > (gdb) frame 6 > #6 0x000000000040088c in main () at mte_t.c:119 > 119 printf("...haven't got one\n"); > (gdb) memory-tag print-logical-tag a > $1 = 0x1 > (gdb) memory-tag print-allocation-tag &a[16] > $2 = 0x0 > (gdb) # Tag mismatch > (gdb) > > > Testing address check on a core file: > > gromero@arm64:~/code$ ulimit -c unlimited > gromero@arm64:~/code$ ./mte_t > a[] address is 0xffffb3bcc000 > a[0] = 1 a[1] = 2 > 0x900ffffb3bcc000 > a[0] = 3 a[1] = 2 > Expecting SIGSEGV... > Segmentation fault (core dumped) > gromero@arm64:~/code$ ~/git/binutils-gdb_remote/build/gdb/gdb -q ./mte_t ./core > Reading symbols from ./mte_t... > [New LWP 256036] > Core was generated by `./mte_t'. > Program terminated with signal SIGSEGV, Segmentation fault > Memory tag violation > Fault address unavailable. > #0 0x0000000000418658 in write () > (gdb) bt > #0 0x0000000000418658 in write () > #1 0x000000000040a3bc in _IO_new_file_write () > #2 0x0000000000409574 in new_do_write () > #3 0x000000000040ae20 in _IO_new_do_write () > #4 0x000000000040b55c in _IO_new_file_overflow () > #5 0x0000000000407414 in puts () > #6 0x000000000040088c in main () at mte_t.c:119 > (gdb) frame 6 > #6 0x000000000040088c in main () at mte_t.c:119 > 119 printf("...haven't got one\n"); > (gdb) memory-tag print-logical-tag a > $1 = 0x9 > (gdb) memory-tag print-allocation-tag &a[16] > $2 = 0x0 > (gdb) # Tag mismatch > (gdb) > > > And, finally, testing it on a remote target using QEMU gdbstub > which supports the new 'memory-tagging-check-add+' feature (WIP). > > Clone and build QEMU: > > $ git clone --depth=1 --single-branch -b mte https://github.com/gromero/qemu.git > $ mkdir qemu/build && cd qemu/build > $ ../configure --target-list=aarch64-linux-user --disable-docs > $ make -j > $ wget https://people.linaro.org/~gustavo.romero/gdb/mte_t > $ chmod +x ./mte_t > $ ./qemu-aarch64 -g 1234 ./mte_t > > ... and connect to QEMU gdbstub from GDB: > > gromero@amd:~/git/binutils-gdb/build$ ./gdb/gdb -q > (gdb) target remote localhost:1234 > Remote debugging using localhost:1234 > Reading /tmp/qemu/build/mte_t from remote target... > warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead. > Reading /tmp/qemu/build/mte_t from remote target... > Reading symbols from target:/tmp/qemu/build/mte_t... > (gdb) c > Continuing. > > Program received signal SIGSEGV, Segmentation fault > Memory tag violation > Fault address unavailable. > 0x0000000000407290 in puts () > (gdb) bt > #0 0x0000000000407290 in puts () > #1 0x000000000040088c in main () at mte_t.c:119 > (gdb) frame 1 > #1 0x000000000040088c in main () at mte_t.c:119 > 119 > (gdb) memory-tag print-allocation-tag a > $1 = 0x2 > (gdb) set debug remote on > (gdb) memory-tag print-allocation-tag a > [remote] Sending packet: $qMemTagAddrCheck:200400000802000#1f > [remote] Received Ack > [remote] Packet received: 01 > [remote] Sending packet: $qMemTags:400000802000,1:1#6f > [remote] Received Ack > [remote] Packet received: m02 > $2 = 0x2 > (gdb) Out of curiosity, I see you exercised native, core and QEMU-based remote debugging. Did you give the gdbserver-based remote debugging a try? I think that is an important check given a gdb + gdbserver debugging session will also use the remote target, but will instead rely on accessing the remote smaps file.
Hi Luis, On 4/3/24 8:51 AM, Luis Machado wrote: > Hi, > > On 3/28/24 22:48, Gustavo Romero wrote: >> This series introduces a new method to check for MTE-tagged addresses on >> remote targets. >> >> A new remote packet, qMemTagAddrCheck, is introduced, along with a new >> remote feature associated with it, 'memory-tagging-check-add+'. Only >> when 'memory-tagging-check-add+' feature is advertised GDB will use the >> new packet to query if an address is tagged. >> >> This new mechanism allows for checking MTE addresses in an OS-agnostic >> way, which is necessary when debugging targets that do not support >> '/proc/<PID>/smaps', as the current method of reading the smaps contents >> fails in such cases. >> >> Since v1: >> - Fixed build error "no match for ‘operator!=’ (operand types are ‘packet_result’ and ‘packet_status’)" >> reported by Linaro CI bot, caused by a last-minute rebase; >> - Added instructions on how to test the series on a remote target using >> QEMU gdbstub (-g option) -- see below. >> >> ---- >> >> This series can be tested with the 'mte_t' binary found in: >> https://people.linaro.org/~gustavo.romero/gdb, using the GDB >> 'memory-tag print-allocation-tag' command to show the allocation >> tag for array pointer 'a'. To download mte_t: >> >> $ wget https://people.linaro.org/~gustavo.romero/gdb/mte_t >> $ chmod +x ./mte_t >> >> ... or build it from source: >> >> $ wget https://people.linaro.org/~gustavo.romero/gdb/mte_t.c >> $ gcc -march=armv8.5-a+memtag -static -g3 -O0 mte_t.c -o mte_t >> >> For example, testing the address check for the aarch64_linux_nat.c >> target: >> >> gromero@arm64:~/code$ ~/git/binutils-gdb_remote/build/gdb/gdb -q ./mte_t >> Reading symbols from ./mte_t... >> (gdb) run >> Starting program: /home/gromero/code/mte_t >> a[] address is 0xfffff7ffc000 >> a[0] = 1 a[1] = 2 >> 0x100fffff7ffc000 >> a[0] = 3 a[1] = 2 >> Expecting SIGSEGV... >> >> Program received signal SIGSEGV, Segmentation fault >> Memory tag violation >> Fault address unavailable. >> 0x0000000000418658 in write () >> (gdb) bt >> #0 0x0000000000418658 in write () >> #1 0x000000000040a3bc in _IO_new_file_write () >> #2 0x0000000000409574 in new_do_write () >> #3 0x000000000040ae20 in _IO_new_do_write () >> #4 0x000000000040b55c in _IO_new_file_overflow () >> #5 0x0000000000407414 in puts () >> #6 0x000000000040088c in main () at mte_t.c:119 >> (gdb) frame 6 >> #6 0x000000000040088c in main () at mte_t.c:119 >> 119 printf("...haven't got one\n"); >> (gdb) memory-tag print-logical-tag a >> $1 = 0x1 >> (gdb) memory-tag print-allocation-tag &a[16] >> $2 = 0x0 >> (gdb) # Tag mismatch >> (gdb) >> >> >> Testing address check on a core file: >> >> gromero@arm64:~/code$ ulimit -c unlimited >> gromero@arm64:~/code$ ./mte_t >> a[] address is 0xffffb3bcc000 >> a[0] = 1 a[1] = 2 >> 0x900ffffb3bcc000 >> a[0] = 3 a[1] = 2 >> Expecting SIGSEGV... >> Segmentation fault (core dumped) >> gromero@arm64:~/code$ ~/git/binutils-gdb_remote/build/gdb/gdb -q ./mte_t ./core >> Reading symbols from ./mte_t... >> [New LWP 256036] >> Core was generated by `./mte_t'. >> Program terminated with signal SIGSEGV, Segmentation fault >> Memory tag violation >> Fault address unavailable. >> #0 0x0000000000418658 in write () >> (gdb) bt >> #0 0x0000000000418658 in write () >> #1 0x000000000040a3bc in _IO_new_file_write () >> #2 0x0000000000409574 in new_do_write () >> #3 0x000000000040ae20 in _IO_new_do_write () >> #4 0x000000000040b55c in _IO_new_file_overflow () >> #5 0x0000000000407414 in puts () >> #6 0x000000000040088c in main () at mte_t.c:119 >> (gdb) frame 6 >> #6 0x000000000040088c in main () at mte_t.c:119 >> 119 printf("...haven't got one\n"); >> (gdb) memory-tag print-logical-tag a >> $1 = 0x9 >> (gdb) memory-tag print-allocation-tag &a[16] >> $2 = 0x0 >> (gdb) # Tag mismatch >> (gdb) >> >> >> And, finally, testing it on a remote target using QEMU gdbstub >> which supports the new 'memory-tagging-check-add+' feature (WIP). >> >> Clone and build QEMU: >> >> $ git clone --depth=1 --single-branch -b mte https://github.com/gromero/qemu.git >> $ mkdir qemu/build && cd qemu/build >> $ ../configure --target-list=aarch64-linux-user --disable-docs >> $ make -j >> $ wget https://people.linaro.org/~gustavo.romero/gdb/mte_t >> $ chmod +x ./mte_t >> $ ./qemu-aarch64 -g 1234 ./mte_t >> >> ... and connect to QEMU gdbstub from GDB: >> >> gromero@amd:~/git/binutils-gdb/build$ ./gdb/gdb -q >> (gdb) target remote localhost:1234 >> Remote debugging using localhost:1234 >> Reading /tmp/qemu/build/mte_t from remote target... >> warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead. >> Reading /tmp/qemu/build/mte_t from remote target... >> Reading symbols from target:/tmp/qemu/build/mte_t... >> (gdb) c >> Continuing. >> >> Program received signal SIGSEGV, Segmentation fault >> Memory tag violation >> Fault address unavailable. >> 0x0000000000407290 in puts () >> (gdb) bt >> #0 0x0000000000407290 in puts () >> #1 0x000000000040088c in main () at mte_t.c:119 >> (gdb) frame 1 >> #1 0x000000000040088c in main () at mte_t.c:119 >> 119 >> (gdb) memory-tag print-allocation-tag a >> $1 = 0x2 >> (gdb) set debug remote on >> (gdb) memory-tag print-allocation-tag a >> [remote] Sending packet: $qMemTagAddrCheck:200400000802000#1f >> [remote] Received Ack >> [remote] Packet received: 01 >> [remote] Sending packet: $qMemTags:400000802000,1:1#6f >> [remote] Received Ack >> [remote] Packet received: m02 >> $2 = 0x2 >> (gdb) > > Out of curiosity, I see you exercised native, core and QEMU-based remote debugging. Did you give the gdbserver-based remote debugging a try? > > I think that is an important check given a gdb + gdbserver debugging session will also use the remote target, but will instead rely on accessing the remote smaps file. Nope. I'll give it a try before sending v3 today. Cheers, Gustavo
On 4/3/24 15:29, Gustavo Romero wrote: > Hi Luis, > > On 4/3/24 8:51 AM, Luis Machado wrote: >> Hi, >> >> On 3/28/24 22:48, Gustavo Romero wrote: >>> This series introduces a new method to check for MTE-tagged addresses on >>> remote targets. >>> >>> A new remote packet, qMemTagAddrCheck, is introduced, along with a new >>> remote feature associated with it, 'memory-tagging-check-add+'. Only >>> when 'memory-tagging-check-add+' feature is advertised GDB will use the >>> new packet to query if an address is tagged. >>> >>> This new mechanism allows for checking MTE addresses in an OS-agnostic >>> way, which is necessary when debugging targets that do not support >>> '/proc/<PID>/smaps', as the current method of reading the smaps contents >>> fails in such cases. >>> >>> Since v1: >>> - Fixed build error "no match for ‘operator!=’ (operand types are ‘packet_result’ and ‘packet_status’)" >>> reported by Linaro CI bot, caused by a last-minute rebase; >>> - Added instructions on how to test the series on a remote target using >>> QEMU gdbstub (-g option) -- see below. >>> ---- >>> >>> This series can be tested with the 'mte_t' binary found in: >>> https://people.linaro.org/~gustavo.romero/gdb, using the GDB >>> 'memory-tag print-allocation-tag' command to show the allocation >>> tag for array pointer 'a'. To download mte_t: >>> >>> $ wget https://people.linaro.org/~gustavo.romero/gdb/mte_t >>> $ chmod +x ./mte_t >>> >>> ... or build it from source: >>> >>> $ wget https://people.linaro.org/~gustavo.romero/gdb/mte_t.c >>> $ gcc -march=armv8.5-a+memtag -static -g3 -O0 mte_t.c -o mte_t >>> >>> For example, testing the address check for the aarch64_linux_nat.c >>> target: >>> >>> gromero@arm64:~/code$ ~/git/binutils-gdb_remote/build/gdb/gdb -q ./mte_t >>> Reading symbols from ./mte_t... >>> (gdb) run >>> Starting program: /home/gromero/code/mte_t >>> a[] address is 0xfffff7ffc000 >>> a[0] = 1 a[1] = 2 >>> 0x100fffff7ffc000 >>> a[0] = 3 a[1] = 2 >>> Expecting SIGSEGV... >>> >>> Program received signal SIGSEGV, Segmentation fault >>> Memory tag violation >>> Fault address unavailable. >>> 0x0000000000418658 in write () >>> (gdb) bt >>> #0 0x0000000000418658 in write () >>> #1 0x000000000040a3bc in _IO_new_file_write () >>> #2 0x0000000000409574 in new_do_write () >>> #3 0x000000000040ae20 in _IO_new_do_write () >>> #4 0x000000000040b55c in _IO_new_file_overflow () >>> #5 0x0000000000407414 in puts () >>> #6 0x000000000040088c in main () at mte_t.c:119 >>> (gdb) frame 6 >>> #6 0x000000000040088c in main () at mte_t.c:119 >>> 119 printf("...haven't got one\n"); >>> (gdb) memory-tag print-logical-tag a >>> $1 = 0x1 >>> (gdb) memory-tag print-allocation-tag &a[16] >>> $2 = 0x0 >>> (gdb) # Tag mismatch >>> (gdb) >>> >>> >>> Testing address check on a core file: >>> >>> gromero@arm64:~/code$ ulimit -c unlimited >>> gromero@arm64:~/code$ ./mte_t >>> a[] address is 0xffffb3bcc000 >>> a[0] = 1 a[1] = 2 >>> 0x900ffffb3bcc000 >>> a[0] = 3 a[1] = 2 >>> Expecting SIGSEGV... >>> Segmentation fault (core dumped) >>> gromero@arm64:~/code$ ~/git/binutils-gdb_remote/build/gdb/gdb -q ./mte_t ./core >>> Reading symbols from ./mte_t... >>> [New LWP 256036] >>> Core was generated by `./mte_t'. >>> Program terminated with signal SIGSEGV, Segmentation fault >>> Memory tag violation >>> Fault address unavailable. >>> #0 0x0000000000418658 in write () >>> (gdb) bt >>> #0 0x0000000000418658 in write () >>> #1 0x000000000040a3bc in _IO_new_file_write () >>> #2 0x0000000000409574 in new_do_write () >>> #3 0x000000000040ae20 in _IO_new_do_write () >>> #4 0x000000000040b55c in _IO_new_file_overflow () >>> #5 0x0000000000407414 in puts () >>> #6 0x000000000040088c in main () at mte_t.c:119 >>> (gdb) frame 6 >>> #6 0x000000000040088c in main () at mte_t.c:119 >>> 119 printf("...haven't got one\n"); >>> (gdb) memory-tag print-logical-tag a >>> $1 = 0x9 >>> (gdb) memory-tag print-allocation-tag &a[16] >>> $2 = 0x0 >>> (gdb) # Tag mismatch >>> (gdb) >>> >>> >>> And, finally, testing it on a remote target using QEMU gdbstub >>> which supports the new 'memory-tagging-check-add+' feature (WIP). >>> >>> Clone and build QEMU: >>> >>> $ git clone --depth=1 --single-branch -b mte https://github.com/gromero/qemu.git >>> $ mkdir qemu/build && cd qemu/build >>> $ ../configure --target-list=aarch64-linux-user --disable-docs >>> $ make -j >>> $ wget https://people.linaro.org/~gustavo.romero/gdb/mte_t >>> $ chmod +x ./mte_t >>> $ ./qemu-aarch64 -g 1234 ./mte_t >>> >>> ... and connect to QEMU gdbstub from GDB: >>> >>> gromero@amd:~/git/binutils-gdb/build$ ./gdb/gdb -q >>> (gdb) target remote localhost:1234 >>> Remote debugging using localhost:1234 >>> Reading /tmp/qemu/build/mte_t from remote target... >>> warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead. >>> Reading /tmp/qemu/build/mte_t from remote target... >>> Reading symbols from target:/tmp/qemu/build/mte_t... >>> (gdb) c >>> Continuing. >>> >>> Program received signal SIGSEGV, Segmentation fault >>> Memory tag violation >>> Fault address unavailable. >>> 0x0000000000407290 in puts () >>> (gdb) bt >>> #0 0x0000000000407290 in puts () >>> #1 0x000000000040088c in main () at mte_t.c:119 >>> (gdb) frame 1 >>> #1 0x000000000040088c in main () at mte_t.c:119 >>> 119 >>> (gdb) memory-tag print-allocation-tag a >>> $1 = 0x2 >>> (gdb) set debug remote on >>> (gdb) memory-tag print-allocation-tag a >>> [remote] Sending packet: $qMemTagAddrCheck:200400000802000#1f >>> [remote] Received Ack >>> [remote] Packet received: 01 >>> [remote] Sending packet: $qMemTags:400000802000,1:1#6f >>> [remote] Received Ack >>> [remote] Packet received: m02 >>> $2 = 0x2 >>> (gdb) >> >> Out of curiosity, I see you exercised native, core and QEMU-based remote debugging. Did you give the gdbserver-based remote debugging a try? >> >> I think that is an important check given a gdb + gdbserver debugging session will also use the remote target, but will instead rely on accessing the remote smaps file. > > Nope. I'll give it a try before sending v3 today. Awesome. Thanks. I'll do some checking locally with system emulation.
On 4/3/24 11:39 AM, Luis Machado wrote: > On 4/3/24 15:29, Gustavo Romero wrote: >> Hi Luis, >> >> On 4/3/24 8:51 AM, Luis Machado wrote: >>> Hi, >>> >>> On 3/28/24 22:48, Gustavo Romero wrote: >>>> This series introduces a new method to check for MTE-tagged addresses on >>>> remote targets. >>>> >>>> A new remote packet, qMemTagAddrCheck, is introduced, along with a new >>>> remote feature associated with it, 'memory-tagging-check-add+'. Only >>>> when 'memory-tagging-check-add+' feature is advertised GDB will use the >>>> new packet to query if an address is tagged. >>>> >>>> This new mechanism allows for checking MTE addresses in an OS-agnostic >>>> way, which is necessary when debugging targets that do not support >>>> '/proc/<PID>/smaps', as the current method of reading the smaps contents >>>> fails in such cases. >>>> >>>> Since v1: >>>> - Fixed build error "no match for ‘operator!=’ (operand types are ‘packet_result’ and ‘packet_status’)" >>>> reported by Linaro CI bot, caused by a last-minute rebase; >>>> - Added instructions on how to test the series on a remote target using >>>> QEMU gdbstub (-g option) -- see below. >>>> ---- >>>> >>>> This series can be tested with the 'mte_t' binary found in: >>>> https://people.linaro.org/~gustavo.romero/gdb, using the GDB >>>> 'memory-tag print-allocation-tag' command to show the allocation >>>> tag for array pointer 'a'. To download mte_t: >>>> >>>> $ wget https://people.linaro.org/~gustavo.romero/gdb/mte_t >>>> $ chmod +x ./mte_t >>>> >>>> ... or build it from source: >>>> >>>> $ wget https://people.linaro.org/~gustavo.romero/gdb/mte_t.c >>>> $ gcc -march=armv8.5-a+memtag -static -g3 -O0 mte_t.c -o mte_t >>>> >>>> For example, testing the address check for the aarch64_linux_nat.c >>>> target: >>>> >>>> gromero@arm64:~/code$ ~/git/binutils-gdb_remote/build/gdb/gdb -q ./mte_t >>>> Reading symbols from ./mte_t... >>>> (gdb) run >>>> Starting program: /home/gromero/code/mte_t >>>> a[] address is 0xfffff7ffc000 >>>> a[0] = 1 a[1] = 2 >>>> 0x100fffff7ffc000 >>>> a[0] = 3 a[1] = 2 >>>> Expecting SIGSEGV... >>>> >>>> Program received signal SIGSEGV, Segmentation fault >>>> Memory tag violation >>>> Fault address unavailable. >>>> 0x0000000000418658 in write () >>>> (gdb) bt >>>> #0 0x0000000000418658 in write () >>>> #1 0x000000000040a3bc in _IO_new_file_write () >>>> #2 0x0000000000409574 in new_do_write () >>>> #3 0x000000000040ae20 in _IO_new_do_write () >>>> #4 0x000000000040b55c in _IO_new_file_overflow () >>>> #5 0x0000000000407414 in puts () >>>> #6 0x000000000040088c in main () at mte_t.c:119 >>>> (gdb) frame 6 >>>> #6 0x000000000040088c in main () at mte_t.c:119 >>>> 119 printf("...haven't got one\n"); >>>> (gdb) memory-tag print-logical-tag a >>>> $1 = 0x1 >>>> (gdb) memory-tag print-allocation-tag &a[16] >>>> $2 = 0x0 >>>> (gdb) # Tag mismatch >>>> (gdb) >>>> >>>> >>>> Testing address check on a core file: >>>> >>>> gromero@arm64:~/code$ ulimit -c unlimited >>>> gromero@arm64:~/code$ ./mte_t >>>> a[] address is 0xffffb3bcc000 >>>> a[0] = 1 a[1] = 2 >>>> 0x900ffffb3bcc000 >>>> a[0] = 3 a[1] = 2 >>>> Expecting SIGSEGV... >>>> Segmentation fault (core dumped) >>>> gromero@arm64:~/code$ ~/git/binutils-gdb_remote/build/gdb/gdb -q ./mte_t ./core >>>> Reading symbols from ./mte_t... >>>> [New LWP 256036] >>>> Core was generated by `./mte_t'. >>>> Program terminated with signal SIGSEGV, Segmentation fault >>>> Memory tag violation >>>> Fault address unavailable. >>>> #0 0x0000000000418658 in write () >>>> (gdb) bt >>>> #0 0x0000000000418658 in write () >>>> #1 0x000000000040a3bc in _IO_new_file_write () >>>> #2 0x0000000000409574 in new_do_write () >>>> #3 0x000000000040ae20 in _IO_new_do_write () >>>> #4 0x000000000040b55c in _IO_new_file_overflow () >>>> #5 0x0000000000407414 in puts () >>>> #6 0x000000000040088c in main () at mte_t.c:119 >>>> (gdb) frame 6 >>>> #6 0x000000000040088c in main () at mte_t.c:119 >>>> 119 printf("...haven't got one\n"); >>>> (gdb) memory-tag print-logical-tag a >>>> $1 = 0x9 >>>> (gdb) memory-tag print-allocation-tag &a[16] >>>> $2 = 0x0 >>>> (gdb) # Tag mismatch >>>> (gdb) >>>> >>>> >>>> And, finally, testing it on a remote target using QEMU gdbstub >>>> which supports the new 'memory-tagging-check-add+' feature (WIP). >>>> >>>> Clone and build QEMU: >>>> >>>> $ git clone --depth=1 --single-branch -b mte https://github.com/gromero/qemu.git >>>> $ mkdir qemu/build && cd qemu/build >>>> $ ../configure --target-list=aarch64-linux-user --disable-docs >>>> $ make -j >>>> $ wget https://people.linaro.org/~gustavo.romero/gdb/mte_t >>>> $ chmod +x ./mte_t >>>> $ ./qemu-aarch64 -g 1234 ./mte_t >>>> >>>> ... and connect to QEMU gdbstub from GDB: >>>> >>>> gromero@amd:~/git/binutils-gdb/build$ ./gdb/gdb -q >>>> (gdb) target remote localhost:1234 >>>> Remote debugging using localhost:1234 >>>> Reading /tmp/qemu/build/mte_t from remote target... >>>> warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead. >>>> Reading /tmp/qemu/build/mte_t from remote target... >>>> Reading symbols from target:/tmp/qemu/build/mte_t... >>>> (gdb) c >>>> Continuing. >>>> >>>> Program received signal SIGSEGV, Segmentation fault >>>> Memory tag violation >>>> Fault address unavailable. >>>> 0x0000000000407290 in puts () >>>> (gdb) bt >>>> #0 0x0000000000407290 in puts () >>>> #1 0x000000000040088c in main () at mte_t.c:119 >>>> (gdb) frame 1 >>>> #1 0x000000000040088c in main () at mte_t.c:119 >>>> 119 >>>> (gdb) memory-tag print-allocation-tag a >>>> $1 = 0x2 >>>> (gdb) set debug remote on >>>> (gdb) memory-tag print-allocation-tag a >>>> [remote] Sending packet: $qMemTagAddrCheck:200400000802000#1f >>>> [remote] Received Ack >>>> [remote] Packet received: 01 >>>> [remote] Sending packet: $qMemTags:400000802000,1:1#6f >>>> [remote] Received Ack >>>> [remote] Packet received: m02 >>>> $2 = 0x2 >>>> (gdb) >>> >>> Out of curiosity, I see you exercised native, core and QEMU-based remote debugging. Did you give the gdbserver-based remote debugging a try? >>> >>> I think that is an important check given a gdb + gdbserver debugging session will also use the remote target, but will instead rely on accessing the remote smaps file. >> >> Nope. I'll give it a try before sending v3 today. > > Awesome. Thanks. The fallback mechanism works when tested against the gdbserver. I'll paste the results into the cover letter for v3. That's a nice test, thanks! Cheers, Gustavo