Re: [PATCH v17 00/13] tracing: wprobe: x86: Add wprobe for watchpoint

[Li Pengfei <ljdlns1987@gmail.com>]

We have made a preliminary ARM64 port of the v17 wprobe series and
validated the basic paths on a real Android ARM64 device.

The device is:

  Kernel: 6.12.69-android16-6-4k
  Architecture: arm64

The relevant configuration includes:

  CONFIG_HAVE_POST_BREAKPOINT_HOOK=y
  CONFIG_HAVE_MODIFY_LOCAL_HW_BREAKPOINT_ADDR=y
  CONFIG_WPROBE_EVENTS=y
  CONFIG_WPROBE_TRIGGERS=y

The following paths passed on the real device:

  - fixed-address read watchpoint;
  - fixed-address write watchpoint;
  - tracepoint -> set_wprobe;
  - dynamic ARM64 watchpoint address update;
  - tracepoint -> clear_wprobe;
  - no further wprobe records after clear_wprobe.

For the dynamic test, we used the ptr field from the kmem:kmalloc
tracepoint:

  set_wprobe:dyn_watch_log:ptr:count=1

The trigger changed the ARM64 hardware watchpoint address to the
dynamically obtained pointer and generated 6 wprobe access records. We
then used a sched_process_exit trigger to execute:

  clear_wprobe:dyn_watch_log:count=1

The wprobe state changed from 1* to 0*. The hit count remained 6 after
the clear operation, confirming that no additional wprobe records were
generated after clearing. No BUG, Oops, panic, or wprobe-related warning
was observed during this test.

We also exercised the basic ARM64 watchpoint hit and post-watchpoint
single-step path on QEMU. The real-device result is the more important
validation.

There are two limitations worth mentioning:

  1. The current Android device does not enable CONFIG_FPROBE_EVENTS, so
     the fprobe -> set_wprobe path has not been tested on this device.

  2. kprobe -> set_wprobe is currently rejected by design. The device
     reports:

       Wprobe trigger is not supported on kprobe event

     We understand and respect this restriction, and we are not proposing
     to remove it in this series.

Our use case for a possible future extension is more specific than
monitoring every kmalloc return value. A selected kernel function may call
kmalloc() internally, store the returned pointer in a register, stack slot,
local variable, or structure field, and then access fields of the newly
allocated object. We would like to monitor the object produced by that
particular allocation call site, rather than re-arm wprobe for every
kmalloc in the system.

One possible design would be a restricted, call-site-specific
kprobe-to-wprobe interface:

  - a kprobe is placed at a selected instruction offset in the caller;
  - a user-space frontend resolves the pointer source from the matching
    vmlinux, BTF/DWARF, and disassembly;
  - the frontend supplies an explicit register/stack/field fetch;
  - the kernel arms a wprobe on the resolved object or one of its fields.

In this model, the user-space frontend would handle symbol resolution,
disassembly, call-site selection, pointer-source analysis, structure-field
resolution, and tracefs setup. The kernel would not need to parse arbitrary
compiler local variables. It would only need to provide a restricted and
safe mechanism for consuming an already-resolved pointer and updating the
hardware watchpoint.

We are not suggesting that an arbitrary kprobe handler should directly
perform unrestricted set_wprobe operations. We understand that kprobes,
ARM64 debug exceptions, single-step handling, tracing recursion, and
cross-CPU watchpoint updates require a separate safety design.

As an additional limitation, a high-frequency test that repeatedly
re-armed the watchpoint from kmem:kmalloc showed a non-zero missed count.
The controlled one-shot set/clear test passed, but the high-frequency case
needs further investigation.

The complete real-device log and test script are available if useful.

Best regards,

Pengfei