linux-kernel - Re: [PATCH 07/12] perf_events: add LBR software filter support for Intel X86

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]

Date:	Tue, 11 Oct 2011 21:59:32 +0900
From:	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	Ingo Molnar <mingo@...e.hu>, Peter Zijlstra <peterz@...radead.org>,
	Stephane Eranian <eranian@...gle.com>,
	linux-kernel@...r.kernel.org, acme@...hat.com,
	ming.m.lin@...el.com, robert.richter@....com, ravitillo@....gov
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@...achi.com
--
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/