From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id dqjnOjg8DmZ1riIAWB0awg (envelope-from ) for ; Thu, 04 Apr 2024 01:35:52 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=linaro.org header.i=@linaro.org header.a=rsa-sha256 header.s=google header.b=MT7S+ANh; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id DEAC61E0C0; Thu, 4 Apr 2024 01:35:52 -0400 (EDT) Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id BF4C21E08C for ; Thu, 4 Apr 2024 01:35:50 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 3EEA9385840C for ; Thu, 4 Apr 2024 05:35:50 +0000 (GMT) Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) by sourceware.org (Postfix) with ESMTPS id B726F3858D34 for ; Thu, 4 Apr 2024 05:35:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B726F3858D34 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 B726F3858D34 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::634 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712208932; cv=none; b=qEeSGVgObmQRD3P5iP4rHRB8En/Uld1J9fk71qQLc91Z07cgap/xTxg2J6jELxwI6zo3t/i6tzsu4stB+q1n+re9dK6Avs/s0VPTKV32c1yjNx2JpZe0gZyBYXLNkHYNfrvDxmTgLtZS9ZGN700uuVoZi8JB3EeSkb6on0b+vS0= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712208932; c=relaxed/simple; bh=KaXRsnsCmIhDHYJErWwGMWfo511moD1gEpvP+2r8VZQ=; h=DKIM-Signature:Subject:To:From:Message-ID:Date:MIME-Version; b=qjodyGRUj0bMcZC3ivcvbJAXTCA+1mL1T49Eq7X33fAai3+Kdcbq4n34AMCZ3pwcYCvvn8e5Xg12dWd76wOnJ1ug2QpHAAztoP5wEwhgwLfvm6SqeN5YbNXoJeO7DNFwHDYhpqd4tegBaZS9zW30Pg4jE84MLH3M8TRoZP6OU1o= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-pl1-x634.google.com with SMTP id d9443c01a7336-1e0b889901bso5087965ad.1 for ; Wed, 03 Apr 2024 22:35:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1712208929; x=1712813729; darn=sourceware.org; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:cc:to:subject:from:to:cc :subject:date:message-id:reply-to; bh=KBOWXF1wV+PrrMXF2Fe74HfveSfhb7oA8Jxkp2qZKA0=; b=MT7S+ANhgp1xTUq63XNKWK48IvqkkLEVzzt758Q3JBeFWmMC1mvv4Q3g+87SW3vvnf rCzfOLA+D/7Mhnh0SIDZP94jgxgla5iuhT4SwM+zmzcP7NCUhrpt5TlGGQA3AFhOHyPi ajacNDvv2NOcf3K6jFEHjPf+VxAIFUh+H8cK4SX7IpIc0gk+zoAw4NujrWBLcgixZ4tM da+Arhi6pN+Mgr7T42aWEnrbYoCjWApq9dWAqe41hZRZ7yZ6MAri+RoxIYzVI0Tw5KXR 3Eplm5l02PxCjBcf9xGaqKuxqL7X8HCKeFWKykvrjswEQM76nsHQiCGDgB1thrxlPn1B kUAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712208929; x=1712813729; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:cc:to:subject :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=KBOWXF1wV+PrrMXF2Fe74HfveSfhb7oA8Jxkp2qZKA0=; b=FMhBka7DH+OBuzwpoOk+G6b0snYrsLlvIG4Rt2qvZtcclCOgp0v/FXIsLjU/MxgbCo Y3PxL0YP8LzSrVuIYnMGza/jxJC/w8wLiUVMSHzMJ6Lt+CUSheUHbuY1at8y+0RXdk0v WN2ab2IVQQetzia3sPaFrY8ryPu4qU6v5HlGyGzb7ytBSmTmi+sQBGNuCJRcILRbpKhF 6wVL+oLncCj6fLfePGZUtG1U6RIZVdW66Hgz+pJnLHEFhjX9h6UhgfIU2gaUzI+c4wjd oUCrBypyIbM/vEumKW9M1HhhwL2MYsQxXRzXrtHE2HuzwVX1ojszOZpQba3YhaGtnptC ou1A== X-Forwarded-Encrypted: i=1; AJvYcCXBdZ2edwoYdVQE8kkikldZIQ9tHKDTGjjIspGmYAH0AyyT37Avw3RzS/qBq5A53xLYsEDfjowtHMp1CoACDIs7Gf5xLDIaQfCT0g== X-Gm-Message-State: AOJu0YyrJkwf49j77v9cgtcOQaoAJZYtzIcsCfb0E9/0yOOtlCs/3/2w clWsVDVQQpWyPSXArOsLHUPXzzjLip7a1PiRP9sjbBJsT22QBW/9TtBtfDu5amyoiPYWD5ePQrQ M X-Google-Smtp-Source: AGHT+IGLDFO+v6iO0wDf9xmITCOu4wgc5tb/gYdOoPQOwh8n4iO+5DFU1lPRSgj1+fOZCESiQ0p/8w== X-Received: by 2002:a17:90a:c696:b0:2a2:a5c7:8ac4 with SMTP id n22-20020a17090ac69600b002a2a5c78ac4mr1484338pjt.37.1712208928633; Wed, 03 Apr 2024 22:35:28 -0700 (PDT) Received: from ?IPv6:2804:7f0:b402:d0dc:4f31:e30e:9a7a:2717? ([2804:7f0:b402:d0dc:4f31:e30e:9a7a:2717]) by smtp.gmail.com with ESMTPSA id pd18-20020a17090b1dd200b002a2c3529127sm681476pjb.15.2024.04.03.22.35.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 03 Apr 2024 22:35:28 -0700 (PDT) Subject: Re: [PATCH v2 0/4] Add another way to check for MTE-tagged addresses on remote targets To: Luis Machado , gdb-patches@sourceware.org Cc: thiago.bauermann@linaro.org References: <20240328224850.2785280-1-gustavo.romero@linaro.org> <3d9dfd09-739d-45c9-a16c-9459734a4685@arm.com> <68dbd5f3-d303-4be6-90a5-b9b3aacb8928@arm.com> From: Gustavo Romero Message-ID: <0d645666-3aa0-bf7a-90da-6010874d2d0d@linaro.org> Date: Thu, 4 Apr 2024 02:35:24 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <68dbd5f3-d303-4be6-90a5-b9b3aacb8928@arm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.6 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org 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//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