1. 23 May, 2010 1 commit
  2. 14 Oct, 2008 1 commit
  3. 24 May, 2008 3 commits
    • Pekka Paalanen's avatar
      x86 mmiotrace: move files into arch/x86/mm/. · ff3a3e9b
      Pekka Paalanen authored
      
      Signed-off-by: default avatarPekka Paalanen <pq@iki.fi>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      ff3a3e9b
    • Pekka Paalanen's avatar
      x86: mmiotrace full patch, preview 1 · 0fd0e3da
      Pekka Paalanen authored
      
      
      kmmio.c handles the list of mmio probes with callbacks, list of traced
      pages, and attaching into the page fault handler and die notifier. It
      arms, traps and disarms the given pages, this is the core of mmiotrace.
      
      mmio-mod.c is a user interface, hooking into ioremap functions and
      registering the mmio probes. It also decodes the required information
      from trapped mmio accesses via the pre and post callbacks in each probe.
      Currently, hooking into ioremap functions works by redefining the symbols
      of the target (binary) kernel module, so that it calls the traced
      versions of the functions.
      
      The most notable changes done since the last discussion are:
      - kmmio.c is a built-in, not part of the module
      - direct call from fault.c to kmmio.c, removing all dynamic hooks
      - prepare for unregistering probes at any time
      - make kmmio re-initializable and accessible to more than one user
      - rewrite kmmio locking to remove all spinlocks from page fault path
      
      Can I abuse call_rcu() like I do in kmmio.c:unregister_kmmio_probe()
      or is there a better way?
      
      The function called via call_rcu() itself calls call_rcu() again,
      will this work or break? There I need a second grace period for RCU
      after the first grace period for page faults.
      
      Mmiotrace itself (mmio-mod.c) is still a module, I am going to attack
      that next. At some point I will start looking into how to make mmiotrace
      a tracer component of ftrace (thanks for the hint, Ingo). Ftrace should
      make the user space part of mmiotracing as simple as
      'cat /debug/trace/mmio > dump.txt'.
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      0fd0e3da
    • Pekka Paalanen's avatar
      x86: mmiotrace - trace memory mapped IO · 8b7d89d0
      Pekka Paalanen authored
      
      
      Mmiotrace is a tool for trapping memory mapped IO (MMIO) accesses within
      the kernel. It is used for debugging and especially for reverse
      engineering evil binary drivers.
      
      Mmiotrace works by wrapping the ioremap family of kernel functions and
      marking the returned pages as not present. Access to the IO memory
      triggers a page fault, which will be handled by mmiotrace's custom page
      fault handler. This will single-step the faulted instruction with the
      MMIO page marked as present. Access logs are directed to user space via
      relay and debug_fs.
      
      This page fault approach is necessary, because binary drivers have
      readl/writel etc. calls inlined and therefore extremely difficult to
      trap with with e.g. kprobes.
      
      This patch depends on the custom page fault handlers patch.
      Signed-off-by: default avatarPekka Paalanen <pq@iki.fi>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      8b7d89d0