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

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

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.