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

[Gustavo Romero <gustavo.romero@linaro.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/<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