Keith Owens wrote: > On Thu, 19 Feb 2004 03:15:54 +0100, > Carl-Daniel Hailfinger <[EMAIL PROTECTED]> wrote: > >>How scriptable is kdb? Looking at the docs and google did not really help >>me find an answer, but feel free to point me to some docs I overlooked. > > > Not at all. You can define your own commands using defcmd in > kdb/kdb_cmds but those commands are not interactive, nor can they test > conditions.
Thanks. Will take a look at that. >>What I want is the ability to log all accesses to a certain memory area > >>from inside the kernel. AFAICS, breakpoints will not help me here because > >>there are too few of them available (hardware limitation on i386). >>So I thought I could just unmap the page with the problematic memory area >>in it and catch all faults accessing this area with kdb, map the area >>again, execute the tripping instruction, unmap the area again and continue >>execution. >> >>I suspect a certain driver accessing the mmapped config space of a device >>it should leave alone. Unfortunately, reading from there can have side >>effects, otherwise I could have just made the covering page readonly. >> >>Is this possible with kdb or can I at least extend kdb in some way to >>achieve my goal? > > > kdb stops all cpus every time it is invoked, which is required for > debugging but is far too heavyweight to do for each page fault. How > often is the suspect driver believed to be accessing the config space? > How often does legitimate code access that config space? The illegitimate accesses are probably roughly as often as legitimate accesses. Actually, I can't say for sure as long as I don't have any data yet. I had planned to modify arch/i386/mm/fault.c:do_page_fault so that only accesses which would trigger an oops anyway would get intercepted by kdb. Since the illegitimate accesses all occur from kernel space (triggering an oops if the page is not mapped), this would mean no overhead for the normal userspace page fault case. So we check in do_page_fault if the access was in the watched config space. If not, proceed normally (that is, let the kernel oops). If we caught a suspicious access, record the IP of the offender, disassemble the instruction, store the instruction and its associated register contents in a buffer for later examination, map the config space again to grant access (we don't know whether it was the good or the bad driver), execute only the tripping instruction, unmap the page again and continue execution. Oh, and I want to set I/O breakpoints in case the evil driver mucks with the reserved ports, too. So, I need kdb mainly for stetting I/O breakpoints and live disassembly of the instruction causing the page fault (or I/O breakpoint) and storing the disassembly along with the associated registers. For example, if mov eax,[ebx] tripped the page fault, I want to store - "mov eax,[ebx]" - eax, ebx - cs, ip, ds in my protocol. Based on the ip of the instruction I can later figure out whether it was the good or the bad driver. The disassembly helps me find the instruction in the bad driver module in case I have no source for it. Thanks for your help. Carl-Daniel --------------------------- Use http://oss.sgi.com/ecartis to modify your settings or to unsubscribe.
