On Tue, 2009-03-10 at 15:57 -0400, Masami Hiramatsu wrote: > Hi Jim, ... > > > > I tested with vmlinux, libc, and libm on both an i686 system and an > > x86_64 system. ... > > Thank you for fixing it. > BTW, it might have to support vm86 mode(especially, for user code).
I have a vague idea of what vm86 mode is, but I don't really understand what the implications are for instruction analysis or probing. My understanding is that its use is rare (e.g., for DOS emulators), so it hasn't been a requirement for uprobes so far. > > > There are some other cases where insn_get_length() doesn't match up with > > the disassembly, but I don't consider them bugs: > > - 0x9b is an instruction (fwait), but the disassembler treats it as a > > prefix. For example 9b df ... can be disassembled as > > fstsw ... // wait, then store status word > > or > > fwait // wait > > fnstsw ... // store status word without waiting > > Perhaps it's relevant to investigate whether a single-step of 9b df ... > > would execute just the fwait or the whole fstsw. Anyway, this explains > > the "failures" of finit and fstsw that I mentioned to you. I also saw > > this with fstcw and fclex. > > FYI, there is a single wait/fwait instruction described at Intel software > developers manual vol.2B p.399. Yes, I tried probing an fclex instruction -- which is really fwait + fnclex -- and the single-step stopped after the fwait. So our instruction analysis is correct. (Of course, I had to adjust uprobes not to reject the 0x9b opcode -- need to check that in. PR 5273 is about this sort of thing.) > > > - Illegal instruction sequences, such as an x86_64 instruction that > > starts with 0x40, or a misplaced 0x65 prefix. Typically, we see these > > when disassembling data. I just filtered out (via egrep) instructions > > whose disassembly starts with "rex" or includes "(bad)". > > Sure, I think insn_* should return -EINVAL or set insn.invalid = 1 > if we found those invalid ops. E.g. kernel use BUG() macro, it adds > some raw numbers after ud2, in that case, those raw numbers might > be decoded as an illegal instruction. It could be useful to provide a function to determine whether the byte sequence is a valid instruction, but I don't think we should make that check by default. Here are some reasons: 1. It costs execution time. For some instructions, you have to examine the prefixes and/or modrm byte as well as the opcode(s). 2. It takes time to code it 100% right. In particular, mistakenly rejecting a valid instruction can be a nuisance. 3. Intel and AMD may not completely agree on which instructions are valid in which modes. I've always consulted the AMD manuals, since they're online and appear complete, but I'm not really sure whether what they say applies without exception to (say) Pentium and EM64T. 4. kprobes and uprobes have gotten along fine without such a test. (Uprobes's test is far from complete, and deliberately screens out some valid instructions, such as sysenter, that we suspect may produce weird results when single-stepped.) The assumption is that the address provided points to the first byte of a valid instruction. Since on x86, most random byte sequences look like some kind valid instruction, catching obviously invalid sequences wouldn't buy us very much. Jim
