instruction-analysis API(s)

[Masami Hiramatsu]

Hi Jim,

I'm also interested in the instruction decoder.
If you don't mind, could we share the API specification?
I'd like to port djprobe on it.

Thanks!

Jim Keniston wrote:
> 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).
> 

-- 
Masami Hiramatsu

Software Engineer
Hitachi Computer Products (America) Inc.
Software Solutions Division

e-mail: mhiramat at redhat.com