Messages in this thread | | | From | Dmitry Vyukov <> | Date | Wed, 9 Mar 2016 12:19:55 +0100 | Subject | Re: [RESEND PATCH 0/5] perf core: Support overwrite ring buffer |
| |
On Wed, Mar 9, 2016 at 11:53 AM, Borislav Petkov <bp@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.
| |