Re: [PATCH v1] kernel: add a simple timer based software watchpoint
From: Feng Tang
Date: Mon Jun 29 2026 - 04:35:51 EST
On Fri, Jun 26, 2026 at 05:31:09PM +0200, Thomas Gleixner wrote:
> On Fri, Jun 26 2026 at 22:33, Feng Tang wrote:
> > As HW jtag debugger is expensive and not generally available for
> > software developer, also many production hardware don't have their
> > jtag interface open for security reason, I think monitoring the
> > abnormal changes to dram/mmio is convenient for debugging memory
> > corruption issues. Could you help to give some suggestion on
> > how to redesign this? Many thanks!
>
> If you can reproduce in a VM, you have qemu + gdb, which allows you
> even to debug the BIOS.
Yes. I use this in normal work, for issues which can be reproduced in
QEMU.
> If it's bare metal you can use kgdb or perf events. All of those allow
> you to set watchpoints, data breakpoints etc.
Thanks for the suggestion! I have never used kgdb before, but rely more
on printk/trace_printk :). I went checked it and tried kdb in QEMU, and
think it's great and will surely use it.
I read some code about kgdb and HW spec for arm-debug. IIUC, some
architectures support watching 'write' to memory, but few supports
watchpoint by 'physical address'.
V1 patch's title about 'watchpoint' is misleading, while the RFC's is
more explicit about detecting memory corruption (to dram/mmio by
physical address, from devices, broken silicon, BIOS and kernel), which
has no dependency over other kernel modules or hardware. It works very
basically as long as 'timer' works.
Also I failed to explain the issues clearly, let me try again. There
are 3 issues discussed:
1. 'zero page' corrupted inside OS due to BIOS enables wrong HW feature,
triggering 'segmentation fault' randomly.
2. BIOS runtime service corrupts ACPI_ENABLE register
3. kernel static array overflow issue.
For 2 and 3, they can be solved without this patch, which may accelerate
the debug though. Only for 3, the patch is necessary as physical address
watchpoint is not supported by hardware.
Anyway I'll explore more in this area. Thanks for your time reviewing!
- Feng
> If you end up with no hit on a watch/breakpoint then you're lost in that
> case as you can't debug the BIOS w/o a hardware debugger, but that's not
> any different than with your magic hack.
>
> The tools are all there you just have to use them correctly, no?
>
> Thanks,
>
> tglx
>
>
>
>