Hi, Roland. Back in a conference call in December, we discussed
approaches to refactoring utrace-related code such as uprobes, to
make some of the services provided there more generally available.
In particular, you suggested an "instruction analysis" service that
various subsystems could exploit -- kprobes and uprobes/ubp at first,
and eventually perhaps gdb, perfmon, kvm, ftrace, and djprobes.
I decided to survey the kernel for subsystems that parse and/or analyze
CPU instructions. I hoped to review the various approaches -- perhaps
finding one that's widely accepted -- and to evaluate possible clients
for our instruction-analysis service.
The results were discouraging, as summarized below. I see no
promise of an architecture-agnostic instruction-analysis API.
Within each architecture, I think the best we could do would be an
(architecture-specific) instruction-parsing API. (And even within
an architecture, different subsystems look at different aspects of
an instruction.)
Srikar Dronamraju and I are exploring two different approaches to an
x86 instruction-parsing service. Since x86 kvm seems to have one of
the most systematic and thorough approaches, Srikar is prototyping a
generalization of kvm's x86_decode_insn() to make it support kprobes,
and eventually uprobes. (Note that kvm does NOT appear to be a good
starting place on powerpc and s390.) Approaching from the minimalist
side, I've implemented an x86 instruction-parsing API with just enough
smarts (so far) to support kprobes and uprobes.
We'd be interested to know whether these efforts are consistent
with what you have in mind.
See more details below.
Jim
Intro
-----
"Instruction analysis" refers to the analysis of a CPU instruction
in the kernel or a user program. Typically, the instruction must
be analyzed so that it can be properly emulated (in the case of
SSOL, by executing the same instruction at a different address),
or so a fault caused by the instruction can be properly handled.
There are other uses as well -- see below.
Possible Clients of an Instruction-Analysis Service
---------------------------------------------------
Where in the kernel is instruction analysis currently used?
- kprobes (arm, avr32, ia64, mn10300, powerpc, s390, sh, sparc, x86)
- uprobes (ia64, powerpc, s390, x86)
- hypervisors:
- kvm (ia64, powerpc, s390, x86)
- powerpc Cell Beat hypervisor
- floating-point unit emulation (arm, s390, sparc, x86)
- exception handling:
- page fault (powerpc, x86)
- illegal instruction (s390)
- unaligned trap (ia64)
- vm86 fault (x86)
- disassembly (powerpc, s390)
- powerpc: xmon, code patching (for crash dump?)
- ia64: emulation of brl instruction
- x86: alternative-instruction patching (replacing instructions that are
inappropriate for the CPU rev), fault injection
- djprobes (not in kernel, not sure of status)
Note: I looked in detail only at the architectures that implement
kprobes: arm, avr32, ia64, mn10300, powerpc, s390, sh, sparc, and x86.
And I note in passing that sh does a lot of instruction analysis --
as does mips -- but I skipped sh for now.
Note: Roland also listed gdb, perfmon, and ftrace as subsystems that
do instruction analysis. I think that oprofile has also been suggested.
- I haven't investigated gdb, but I have no reason to think Roland is
wrong about it.
- I've looked briefly at the various components of perfmon[2] and
oprofile, but I don't see any instruction analysis per se; and the
perfmon/oprofile expert I asked (IBM's Carl Love) isn't aware of any.
- Similarly, I don't see instruction analysis per se in ftrace.
Prospects/Problems
------------------
What are the prospects for adapting these various subsystems to use
a common instruction-analysis service? Typically, not very good.
Here are some of the problems:
- Different architectures have very different instruction-analysis
needs.
- Different architectures have very different instruction formats and
instruction attributes. Consequently, the opportunities for common
code shared by multiple architectures are few.
- Different subsystems are interested in different instruction
attributes, and/or classify instructions differently.
- Some subsystems are interested in only certain instructions.
- Some subsystems, such as fault handlers, want to maximize efficiency
by examining as little of the instruction as possible; while others,
such as *probes, take a more leisurely approach (e.g., reading enough
bytes to capture the largest possible instruction, even if that means
faulting in a page).
