Hello List,
I was thinking about writing some memory R/W access monitor. The only
concern I'm
having is whether it is doable, or are there any already existing and
working solutions like
that for Linux?
The initial concept was to set up some special page fault handler and
mark monitored
memory pages as non present. The monitor pagefault handler would check
if the page
is within monitored location and if yes it would switch to
singlestepping mode and
step the instruction which invoked the pagefault and log the value
which was read/written from
certain address. Afterwards the whole page would be marked as non present again.
Is it possible to succeed with such an approach? Would it work for
memory range mapped to some devices?
kind regards,
Mateusz Berezecki
On Sun, Mar 05, 2006 at 06:00:34PM +0100, Mateusz Berezecki wrote:
> I was thinking about writing some memory R/W access monitor. The only
> concern I'm
> having is whether it is doable, or are there any already existing and
> working solutions like
> that for Linux?
Most CPUs implement memory breakpoints of some sort, although they're
usually limited to specific address instead of ranges. See gdb's
watch/awatch/rwatch commands.
> which was read/written from certain address. Afterwards the whole page
> would be marked as non present again.
Use mprotect() and do it in userspace by catching SIGSEGV. Doing it for
the kernel is non-trivial and will hit upon arch specific issues like
double fault handlers. Given that the same sort of debugging can be done
in userspace with UML and gdb, there isn't terribly much incentive to do
the work to make something like this happen.
-ben
--
"Time is of no importance, Mr. President, only life is important."
Don't Email: <[email protected]>.
Hello Benjamin
On 3/6/06, Benjamin LaHaise <[email protected]> wrote:
> On Sun, Mar 05, 2006 at 06:00:34PM +0100, Mateusz Berezecki wrote:
> > I was thinking about writing some memory R/W access monitor. The only
> > concern I'm
> > having is whether it is doable, or are there any already existing and
> > working solutions like
> > that for Linux?
>
> Most CPUs implement memory breakpoints of some sort, although they're
> usually limited to specific address instead of ranges. See gdb's
> watch/awatch/rwatch commands.
Yes but again this is userspace. I was thinking about solution used
back in the old days in SoftICE kernel level debugger.
It had a BPR command (breakpoint on range) which could monitor
up to 400000 bytes of memory range. Unfortunately for me this command
works in very old versions of _that_ other OS.
>
> > which was read/written from certain address. Afterwards the whole page
> > would be marked as non present again.
>
> Use mprotect() and do it in userspace by catching SIGSEGV. Doing it for
> the kernel is non-trivial and will hit upon arch specific issues like
> double fault handlers. Given that the same sort of debugging can be done
> in userspace with UML and gdb, there isn't terribly much incentive to do
> the work to make something like this happen.
I thought about UML or maybe even playing with Xen would be better (is
host kernel
transparent to Xen ? ie. does Xen have access to the same hardware as
host kernel?)
but in the end I'd go for kernel page fault handler anyways.
M
On Mon, Mar 06, 2006 at 12:31:29AM +0100, Mateusz Berezecki wrote:
> Yes but again this is userspace. I was thinking about solution used
> back in the old days in SoftICE kernel level debugger.
> It had a BPR command (breakpoint on range) which could monitor
> up to 400000 bytes of memory range. Unfortunately for me this command
> works in very old versions of _that_ other OS.
If it is in userspace, then you don't need anything from the kernel.
mprotect() and catch the resulting SIGSEGV.
-ben
--
"Time is of no importance, Mr. President, only life is important."
Don't Email: <[email protected]>.
On Ne 05-03-06 18:32:02, Benjamin LaHaise wrote:
> On Mon, Mar 06, 2006 at 12:31:29AM +0100, Mateusz Berezecki wrote:
> > Yes but again this is userspace. I was thinking about solution used
> > back in the old days in SoftICE kernel level debugger.
> > It had a BPR command (breakpoint on range) which could monitor
> > up to 400000 bytes of memory range. Unfortunately for me this command
> > works in very old versions of _that_ other OS.
>
> If it is in userspace, then you don't need anything from the kernel.
> mprotect() and catch the resulting SIGSEGV.
SoftICE worked on kernel, too. Not sure how it was hacked up.
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...