From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id BnDqOQJoDWYnhyEAWB0awg (envelope-from ) for ; Wed, 03 Apr 2024 10:30:26 -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=m7DDMlBp; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id DC0C91E0C0; Wed, 3 Apr 2024 10:30:26 -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 A61E31E030 for ; Wed, 3 Apr 2024 10:30:24 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 2AD6138460A2 for ; Wed, 3 Apr 2024 14:30:24 +0000 (GMT) Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) by sourceware.org (Postfix) with ESMTPS id 5AA4F3846405 for ; Wed, 3 Apr 2024 14:29:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5AA4F3846405 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 5AA4F3846405 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::42b ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712154600; cv=none; b=YL4gIwHJ6GBh87xNi2xHB1xW/9HikViuUFK8JmfoSRyXr23Y3mgFq/ufev4bXqaEAlw3/amr6zJiWto4ZrmaBZ5Uva2pYk7lgEgFERwILbnJxbN+1Rpj0eRU40MaUI3SNE+Q4U95Ezw7uLMZ8dGILCcB9ImOw5xi9FUcELehm0s= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712154600; c=relaxed/simple; bh=S6ZfxGy3l4/+iZ+Q8wuvO1WFctwxZeFUBbGzsT/rSeQ=; h=DKIM-Signature:Subject:To:From:Message-ID:Date:MIME-Version; b=Qiz8ZnZ6hKBrQLM2UWocRxssSrvegjwf8lTt/0vuoN85V7KPieN/GrtI0XLXoKuO/Ue20XkApTEPsa2sAoNRD2G8vEhhpfbn/ZactGSLzzQOiYFWB0VBk9W8QHy32s4H7m8lZuKQTkTkr9ArK/77tyF5GbPGQhUDOUrBLfNEfDw= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-pf1-x42b.google.com with SMTP id d2e1a72fcca58-6ea838bf357so5245905b3a.0 for ; Wed, 03 Apr 2024 07:29:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1712154597; x=1712759397; 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=FcpDFlpch7uXhQhl1VcJ3ZQFw5aWTLg7DXmtLa7g+2o=; b=m7DDMlBp7Y7Hik15hWFxIZVLchf517CDwRG+tU2NFGYZWbwVxRioLPovNWJVn9TOx0 bqsg9q9H8g8At2zKdJXF4O5v+sOYaP/VgaeMUPeV2Gj9RGOIffyjt9D/0eGhCpzznmdE duFdYM/Tdx75X0NZaPbKhK+DRP56go7CAwn2F/BMbGu5TpRColJmbetFAiNoBOSoOgE+ OnaGTdgk8NRdY18ZkOXmELoEsQkMcxknd1kQNsBQcIEZAC2ivNb3R+QqR0ex5TjQffTy mKEIwexudhidM0EN4dV10nC1jAbJA7nTsRobp9CUzHC3UcgG/9PPZ+SLuOkEq4Ok4XzI cOHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712154597; x=1712759397; 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=FcpDFlpch7uXhQhl1VcJ3ZQFw5aWTLg7DXmtLa7g+2o=; b=a1HN0C/S+22Ubo9r8kYyZ+x/0tYZntC8m4VS7hCJwOWJdDZF1LFXXtLWGvn7rXJG+7 uXDNfG3Gw3D1P6/NPZtd28lkWS5eGPZA0BaWTeaL6dxce5NbRTCpMFsB2aZfGfDMK0P0 RmHFMgJgM2r/MbEVM5gqkPVAm74KHAtUz01H+Et8YqZz2r7nh72wx40syZLkqWggIvHW VzEIVBlT0hGNGaRsZuGuygOLSpnDDrHVg8KAJjrc64Yf/oo0Ae92h63Mc3CGNaT7I/AI kt84g8yddcaIWWSnZw04DmhHoZ3wmM54BZDsK0TOlmpKGQB0YzJkTBwwRGjZjGpORIA/ 7Sbg== X-Forwarded-Encrypted: i=1; AJvYcCV3pq82iXS4sDEaYmBflWbDs3/6ffT4RBOCKnKA/1XUmyBQQ0eCrcpdMxWWuEZtddWyYonxIXfBjzWHcQjywvk5ye6BNsv4/sgXWw== X-Gm-Message-State: AOJu0YxJplfbT6Xa4/LtzL7UuoJ84sfyr7flYhs1gsmVV1GFBk10w3xa we/Q8OhBADy9vzJyLEXRZZa1fEnibQ3OoELpvPn85czG2C1UCrw+bza8q7iTtoKRK29iDtR71TO K X-Google-Smtp-Source: AGHT+IHvYNU1Zs52sSmHsMNsayHqlMk89cCW0fTv4IwPl1KNA+6XT75xzG9Q28Cagc0HcflPOH25Tw== X-Received: by 2002:a05:6a00:194c:b0:6ea:c43c:a650 with SMTP id s12-20020a056a00194c00b006eac43ca650mr17219293pfk.32.1712154597256; Wed, 03 Apr 2024 07:29:57 -0700 (PDT) Received: from [192.168.20.108] (201-68-109-119.dsl.telesp.net.br. [201.68.109.119]) by smtp.gmail.com with ESMTPSA id fk15-20020a056a003a8f00b006e6c74eac34sm11782575pfb.151.2024.04.03.07.29.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 03 Apr 2024 07:29:56 -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> From: Gustavo Romero Message-ID: Date: Wed, 3 Apr 2024 11:29:54 -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: <3d9dfd09-739d-45c9-a16c-9459734a4685@arm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no 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 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. Cheers, Gustavo