* memory range R/W triggered breakpoints in kernel ?
@ 2006-03-05 17:00 Mateusz Berezecki
2006-03-05 23:16 ` Benjamin LaHaise
0 siblings, 1 reply; 5+ messages in thread
From: Mateusz Berezecki @ 2006-03-05 17:00 UTC (permalink / raw)
To: Linux Kernel Mailing List
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: memory range R/W triggered breakpoints in kernel ?
2006-03-05 17:00 memory range R/W triggered breakpoints in kernel ? Mateusz Berezecki
@ 2006-03-05 23:16 ` Benjamin LaHaise
2006-03-05 23:31 ` Mateusz Berezecki
0 siblings, 1 reply; 5+ messages in thread
From: Benjamin LaHaise @ 2006-03-05 23:16 UTC (permalink / raw)
To: Mateusz Berezecki; +Cc: Linux Kernel Mailing List
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: <dont@kvack.org>.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: memory range R/W triggered breakpoints in kernel ?
2006-03-05 23:16 ` Benjamin LaHaise
@ 2006-03-05 23:31 ` Mateusz Berezecki
2006-03-05 23:32 ` Benjamin LaHaise
0 siblings, 1 reply; 5+ messages in thread
From: Mateusz Berezecki @ 2006-03-05 23:31 UTC (permalink / raw)
To: Benjamin LaHaise; +Cc: Linux Kernel Mailing List
Hello Benjamin
On 3/6/06, Benjamin LaHaise <bcrl@kvack.org> 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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: memory range R/W triggered breakpoints in kernel ?
2006-03-05 23:31 ` Mateusz Berezecki
@ 2006-03-05 23:32 ` Benjamin LaHaise
2006-03-06 22:00 ` Pavel Machek
0 siblings, 1 reply; 5+ messages in thread
From: Benjamin LaHaise @ 2006-03-05 23:32 UTC (permalink / raw)
To: Mateusz Berezecki; +Cc: Linux Kernel Mailing List
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: <dont@kvack.org>.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: memory range R/W triggered breakpoints in kernel ?
2006-03-05 23:32 ` Benjamin LaHaise
@ 2006-03-06 22:00 ` Pavel Machek
0 siblings, 0 replies; 5+ messages in thread
From: Pavel Machek @ 2006-03-06 22:00 UTC (permalink / raw)
To: Benjamin LaHaise; +Cc: Mateusz Berezecki, Linux Kernel Mailing List
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 (www.sf.net/projects/suspend) wanted...
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2006-03-06 22:00 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-03-05 17:00 memory range R/W triggered breakpoints in kernel ? Mateusz Berezecki
2006-03-05 23:16 ` Benjamin LaHaise
2006-03-05 23:31 ` Mateusz Berezecki
2006-03-05 23:32 ` Benjamin LaHaise
2006-03-06 22:00 ` Pavel Machek
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).