Messages in this thread | | | Date | Tue, 11 Oct 2011 21:59:32 +0900 | From | Masami Hiramatsu <> | Subject | Re: [PATCH 07/12] perf_events: add LBR software filter support for Intel X86 |
| |
(2011/10/10 23:45), Andi Kleen wrote: >> Ah, nice. Maybe we need another test binary, since current one is >> just ensuring the output of objdump and decoder is same. >> anyway it's not so difficult if it feeds random binaries to >> ensure the decoder doesn't access bad address. > > Pure /dev/urandom is not good because it cannot be ever reproduced. > Better use a PRNG with random seed from urandom, but print the seed.
Sure,
> In addition to random I would do fuzzing: take an existing stream > and just corrupt some bits and groups of bits. This will exercise different > paths. In fact fuzzing is probably better than random for most tests. > > Not sure it's needed to run on every build though, just checks > now and then should be sufficient.
I made a test for that, and I didn't hit any random bytes which can not be decoded after I've tested 100,000,000. (with previous hardening patch)
since the number of the combination is 2^128 (MAX_INSN_SIZE is 16), too huge to check all of them. Of course, the real number of possible combination should be smaller than that.
- Because this decoder don't evaluate but just decode, we can skip immediates and operands. - If we hit the non-oprand opcode, mod/rm, sib, or displacement in the middle of byte stream, we can stop trying decode tail bytes.
So I think there is smarter way to cover all possible combination for the decoder than feeding random bytes.
Anyway, the decoder code can evolve in the future, I think it should be put into the linux kernel.
Thank you,
-- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu.pt@hitachi.com
| |