Re: [PATCH v2 0/4] Add another way to check for MTE-tagged addresses on remote targets

[Luis Machado <luis.machado@arm.com>]

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.