On Wed, Mar 9, 2016 at 11:53 AM, Borislav Petkov <b...@alien8.de> wrote:
> On Tue, Mar 08, 2016 at 04:54:23PM +0100, Ingo Molnar wrote:
>> triton:~/go/src/github.com/google/syzkaller> cat perf.cfg
>> {
>>         "http": "localhost:50000",
>>         "workdir": "/home/mingo/go/src/github.com/google/syzkaller/workdir",
>>         "syzkaller": "/home/mingo/go/src/github.com/google/syzkaller",
>>         "vmlinux": "-",
>>         "type": "local",
>>         "count": 1,
>>         "procs": 16,
>>         "nocover": true,
>>         "nodropprivs": true,
>>         "enable_syscalls": [
>>                 "getpid",
>>                 "perf_event_open",
>
> Btw, is there a way to specify range of arguments to feed into
> perf_event_open? Like, limit @attr_uptr to single or multiple event IDs
> or so, for example?


No, there is no _that_ level of granularity in the config.

If you really-really want that, then you can alter description of the
perf_event_open syscall in sys/perf.txt file:

https://github.com/google/syzkaller/blob/master/sys/perf.txt

to be more restrictive. For example, you can limit set of values
passed in a particular argument, or even set some args/fields to const
values.
Then you will need to do:

$ make generate LINUX=/path/to/fresh/linux/checkout
$ make

But I would suggest to not do that. That perf config already limits
set of syscalls to a very small set. The fuzzer should be able to
examine all interesting combinations of arguments for these syscalls
in a reasonable time (provided that you use CONFIG_KCOV). And in the
end you don't know where the bugs. They are usually where you don't
expect them. So I would suggest the opposite: describe and more
perf-related syscalls, describe arguments in greater detail, enable
other syscalls that can have effect on perf subsystem. And then just
run it for longer using more machines.

Reply via email to