linux-kernel - [RFC PATCH] x86: mmiotrace

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080127195536.50809974@daedalus.pq.iki.fi>
Date:	Sun, 27 Jan 2008 19:55:36 +0200
From:	Pekka Paalanen <pq@....fi>
To:	mingo@...hat.com
Cc:	Pekka Paalanen <pq@....fi>, linux-kernel@...r.kernel.org
Subject: [RFC PATCH] x86: mmiotrace - trace memory mapped IO

Hello,

the patch itself is slightly bigger than recommended for LKML, so
it is available at:
http://jumi.lut.fi/~paalanen/scratch/mmio24/0002-x86-mmiotrace-trace-memory-mapped-IO.patch.txt

This seems to work fine on UP machine, I have not tested yet with
with an SMP machine. Originally mmio-trace was UP-only, so there
probably still are SMP issues. Mmio-trace has existed with its current
purpose for about a year now.

The following is a copy of the patch description:

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.

---

More information on mmio-trace can be found at
http://nouveau.freedesktop.org/wiki/MmioTrace
and the out-of-three module with user space parts is at
http://gitweb.freedesktop.org/?p=users/pq/mmio-trace.git;a=summary

The out-of-tree git does not include all changes I made for the
in-tree version.

Mmiotrace does not appear to procude excruciating slowness when used.
Starting X with traced nvidia binary drivers takes a couple of seconds
longer than normally. Starting X, running glxgears for a moment and
shutting down X results in an mmio-trace log of roughly 1.5 million
events. Replace glxgears by running Quake3-demo's first demo play
twice and end up with 3.5 million events. Quake3-demo framerate with
mmio-traced driver goes down to 59 fps, compared to the normal 83 fps.

I know of one bad failure case with mmio-trace. It may trigger a
complete system freeze when tracing a certain nvidia driver version
on a machine with an 8000-series (nv50) graphics chip. Netconsole,
serial console and NMI watchdog have so far been useless, and I
am starting to believe that it is the nvidia driver that does
something bad to make mmio-trace fall over. I have heard that more
recent nvidia drivers do not make it crash anymore.

I'm hoping mmiotrace could be included in 2.6.25. It would help
FOSS driver projects (Nouveau, maybe madwifi, too) to gather the
information they need. Very often the information comes from
ordinary users, for whom going through kernel patching would be
a major struggle.

Thanks,
Pekka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/