Coverage, corbus and syscalls reports for arm64 only work with -debug flag

165 views
Skip to first unread message

Jukka Kaartinen

unread,
Dec 18, 2019, 4:35:34 AM12/18/19
to syzkaller
Hi,

I'm running syzkaller on qemu environment for kernel 4.14.
Coverage and the executed syscalls list was not working at all. I have enabled needed configurations from the kernel I'm sure of it.
I debugged the issue and it turned out that syzkaller was calling objdump, nm and addr2line that did not work for arm64 binaries. I have made small work around for that. (I guess setting up PATH and symbolic links would also work but I didn't tried it.)

But it was still not working correctly.
The thing is that coverage reporting(http://localhost:15692/cover), corbus (http://localhost:15692/corpus) and executed syscalls list (http://localhost:15692/syscalls) are only working if I run syzkaller with -debug -flag!

Any pointers how to debug this? Any idea is this host or target size issue?


My syzkaller version:
HEAD: 0ae38e44 (origin/master, origin/HEAD) sys/linux: minor improvements for USB descriptions

I'm using qemu-system-aarch64


-Jukka


 pkg/cover/report.go          | 2 +-
 pkg/symbolizer/nm.go         | 2 +-
 pkg/symbolizer/symbolizer.go | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/pkg/cover/report.go b/pkg/cover/report.go
index 9268f733..701a1bc5 100644
--- a/pkg/cover/report.go
+++ b/pkg/cover/report.go
@@ -346,7 +346,7 @@ func objdumpAndSymbolize(obj, arch string) ([]symbolizer.Frame, error) {
                }
                errc <- err
        }()
-       cmd := osutil.Command("objdump", "-d", "--no-show-raw-insn", obj)
+       cmd := osutil.Command("aarch64-linux-gnu-objdump", "-d", "--no-show-raw-insn", obj)
        stdout, err := cmd.StdoutPipe()
        if err != nil {
                return nil, err
diff --git a/pkg/symbolizer/nm.go b/pkg/symbolizer/nm.go
index caa24662..ad6fa899 100644
--- a/pkg/symbolizer/nm.go
+++ b/pkg/symbolizer/nm.go
@@ -18,7 +18,7 @@ type Symbol struct {
 
 // ReadSymbols returns list of text symbols in the binary bin.
 func ReadSymbols(bin string) (map[string][]Symbol, error) {
-       cmd := osutil.Command("nm", "-Ptx", bin)
+       cmd := osutil.Command("aarch64-linux-gnu-nm", "-Ptx", bin)
        stdout, err := cmd.StdoutPipe()
        if err != nil {
                return nil, err
diff --git a/pkg/symbolizer/symbolizer.go b/pkg/symbolizer/symbolizer.go
index f6c6dbe7..d3e94afa 100644
--- a/pkg/symbolizer/symbolizer.go
+++ b/pkg/symbolizer/symbolizer.go
@@ -65,7 +65,7 @@ func (s *Symbolizer) getSubprocess(bin string) (*subprocess, error) {
        if sub := s.subprocs[bin]; sub != nil {
                return sub, nil
        }
-       cmd := osutil.Command("addr2line", "-afi", "-e", bin)
+       cmd := osutil.Command("aarch64-linux-gnu-addr2line", "-afi", "-e", bin)
        stdin, err := cmd.StdinPipe()
        if err != nil {
                return nil, err
-- 
2.17.1

Dmitry Vyukov

unread,
Dec 18, 2019, 4:44:09 AM12/18/19
to Jukka Kaartinen, syzkaller
On Wed, Dec 18, 2019 at 10:35 AM Jukka Kaartinen
<jukka.k...@unikie.com> wrote:
>
> Hi,
>
> I'm running syzkaller on qemu environment for kernel 4.14.
> Coverage and the executed syscalls list was not working at all. I have enabled needed configurations from the kernel I'm sure of it.
> I debugged the issue and it turned out that syzkaller was calling objdump, nm and addr2line that did not work for arm64 binaries. I have made small work around for that. (I guess setting up PATH and symbolic links would also work but I didn't tried it.)
>
> But it was still not working correctly.
> The thing is that coverage reporting(http://localhost:15692/cover), corbus (http://localhost:15692/corpus) and executed syscalls list (http://localhost:15692/syscalls) are only working if I run syzkaller with -debug -flag!
>
> Any pointers how to debug this? Any idea is this host or target size issue?

Hi Jukka,

What do you mean "not working"? What happens? Does it crash or what?
Does manager work otherwise? Execute programs, collect coverage and
build corpus?
Does it work if you set "procs" parameter to 1 and number of VMs to 1
in the configs file? That's mainly what -debug does.

We accept contributions as github pull requests, please see
https://github.com/google/syzkaller/blob/master/docs/contributing.md
for contribution guidelines.
Thanks
> --
> You received this message because you are subscribed to the Google Groups "syzkaller" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller/f81ce0d8-7ef9-41f4-a9b6-a78370c45e00%40googlegroups.com.

jukka.k...@unikie.com

unread,
Dec 18, 2019, 5:03:25 AM12/18/19
to syzkaller
There is no crash. The links that I posted only have the template content.
I think manager is working and it is finding problems. Looks like the DB is not getting saved or something like that.

And yes setting "procs" parameter to 1 and number of VMs to 1 works as well.


I'm planning at least upload PR for additional documentation and some issues that I found.

> To unsubscribe from this group and stop receiving emails from it, send an email to syzk...@googlegroups.com.

Dmitry Vyukov

unread,
Dec 18, 2019, 5:23:20 AM12/18/19
to jukka.k...@unikie.com, syzkaller
On Wed, Dec 18, 2019 at 11:03 AM <jukka.k...@unikie.com> wrote:
>
> There is no crash. The links that I posted only have the template content.
> I think manager is working and it is finding problems. Looks like the DB is not getting saved or something like that.

I still don't fully understand what exactly happens. Maybe a 1 hour
manager log would help.
But this looks similar in symptoms to the recent issues with mips64le:
https://github.com/google/syzkaller/pull/1536#issuecomment-564989898
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller/7fa93c9b-6241-4387-a98e-63911bf4bccc%40googlegroups.com.

jukka.k...@unikie.com

unread,
Dec 18, 2019, 5:52:22 AM12/18/19
to syzkaller
Yes it seems to be the same issue. I have already talked with Jouni. We are working in the same project.


Here is small trace from the syz-manager.

./bin/syz-manager -config=vm.cfg
2019/12/18 12:03:52 loading corpus...
2019/12/18 12:03:52 serving http on http://127.0.0.1:15692
2019/12/18 12:03:52 serving rpc on tcp://[::]:39063
2019/12/18 12:03:52 booting test machines...
2019/12/18 12:03:52 wait for the connection from test machine...
2019/12/18 12:08:40 machine check:
2019/12/18 12:08:40 syscalls                : 1125/2961
2019/12/18 12:08:40 code coverage           : enabled
2019/12/18 12:08:40 comparison tracing      : ioctl(KCOV_TRACE_CMP) failed: invalid argument
2019/12/18 12:08:40 extra coverage          : extra coverage is not supported by the kernel
2019/12/18 12:08:40 setuid sandbox          : enabled
2019/12/18 12:08:40 namespace sandbox       : enabled
2019/12/18 12:08:40 Android sandbox         : /sys/fs/selinux/policy does not exist
2019/12/18 12:08:40 fault injection         : enabled
2019/12/18 12:08:40 leak checking           : enabled
2019/12/18 12:08:40 net packet injection    : enabled
2019/12/18 12:08:40 net device setup        : enabled
2019/12/18 12:08:40 concurrency sanitizer   : /sys/kernel/debug/kcsan does not exist
2019/12/18 12:08:40 devlink PCI setup       : PCI device 0000:00:10.0 is not available
2019/12/18 12:08:40 corpus                  : 0 (0 deleted)
2019/12/18 12:08:42 VMs 1, executed 0, cover 0, crashes 0, repro 0
2019/12/18 12:08:52 VMs 1, executed 0, cover 0, crashes 0, repro 0
2019/12/18 12:09:02 VMs 1, executed 0, cover 0, crashes 0, repro 0
2019/12/18 12:09:12 VMs 1, executed 1, cover 0, crashes 0, repro 0
2019/12/18 12:09:22 VMs 1, executed 1, cover 0, crashes 0, repro 0
2019/12/18 12:09:32 VMs 1, executed 1, cover 0, crashes 0, repro 0
2019/12/18 12:09:42 VMs 1, executed 1, cover 0, crashes 0, repro 0
2019/12/18 12:09:52 VMs 1, executed 1, cover 0, crashes 0, repro 0
2019/12/18 12:10:02 VMs 1, executed 1, cover 0, crashes 0, repro 0
2019/12/18 12:10:12 VMs 1, executed 2, cover 0, crashes 0, repro 0
2019/12/18 12:10:22 VMs 1, executed 2, cover 0, crashes 0, repro 0
2019/12/18 12:10:32 VMs 1, executed 2, cover 0, crashes 0, repro 0
2019/12/18 12:10:42 VMs 1, executed 2, cover 0, crashes 0, repro 0
2019/12/18 12:10:52 VMs 1, executed 2, cover 0, crashes 0, repro 0
2019/12/18 12:11:02 VMs 1, executed 2, cover 0, crashes 0, repro 0
2019/12/18 12:11:12 VMs 1, executed 3, cover 0, crashes 0, repro 0
2019/12/18 12:11:22 VMs 1, executed 3, cover 0, crashes 0, repro 0
2019/12/18 12:11:32 VMs 1, executed 3, cover 0, crashes 0, repro 0
2019/12/18 12:11:42 VMs 1, executed 3, cover 0, crashes 0, repro 0
...

executed and crashes value is getting bigger and cover stays at 0. We have also got some reproducers.

jukka.k...@unikie.com

unread,
Dec 18, 2019, 6:50:58 AM12/18/19
to syzkaller
Some update:
procs: 2 vm: 1 works.
procs: 2 vm: 2 works.

procs: 2 vm: 3 does not work
procs: 2 vm: 4 does not work

Let me debug this a bit more. Maybe I can find out something on my own.

Dmitry Vyukov

unread,
Dec 18, 2019, 7:00:22 AM12/18/19
to jukka.k...@unikie.com, syzkaller
On Wed, Dec 18, 2019 at 12:51 PM <jukka.k...@unikie.com> wrote:
>
> Some update:
> procs: 2 vm: 1 works.
> procs: 2 vm: 2 works.
>
> procs: 2 vm: 3 does not work
> procs: 2 vm: 4 does not work
>
> Let me debug this a bit more. Maybe I can find out something on my own.

I would first try to bump this timeout:
https://github.com/google/syzkaller/pull/1536#issuecomment-566483564

Theoretically you can also hack -debug mode to not reduce number of
VMs/procs to see more output.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller/68d1d2b0-83c7-4290-9de6-3c8569fb54ea%40googlegroups.com.

jukka.k...@unikie.com

unread,
Dec 18, 2019, 8:25:23 AM12/18/19
to syzkaller
Here are logs from not working version and working. (I added JK in front of some the prints) Looks like difference is that in the working version there are logs: "new input from vm-0 for syscall openat (signal=589, cover=535)" would the timeout increment have effect on this? I will try to find the line where to increase the timeout.

Does not work:
2019/12/18 15:14:44 loading corpus...
2019/12/18 15:14:44 serving http on http://127.0.0.1:15691
2019/12/18 15:14:44 serving rpc on tcp://[::]:38835
2019/12/18 15:14:44 booting test machines...
2019/12/18 15:14:44 wait for the connection from test machine...
2019/12/18 15:16:16 machine check:
2019/12/18 15:16:16 syscalls                : 1124/2961
2019/12/18 15:16:16 code coverage           : enabled
2019/12/18 15:16:16 comparison tracing      : ioctl(KCOV_TRACE_CMP) failed: invalid argument
2019/12/18 15:16:16 extra coverage          : extra coverage is not supported by the kernel
2019/12/18 15:16:16 setuid sandbox          : enabled
2019/12/18 15:16:16 namespace sandbox       : enabled
2019/12/18 15:16:16 Android sandbox         : /sys/fs/selinux/policy does not exist
2019/12/18 15:16:16 fault injection         : enabled
2019/12/18 15:16:16 leak checking           : enabled
2019/12/18 15:16:16 net packet injection    : enabled
2019/12/18 15:16:16 net device setup        : enabled
2019/12/18 15:16:16 concurrency sanitizer   : /sys/kernel/debug/kcsan does not exist
2019/12/18 15:16:16 devlink PCI setup       : PCI device 0000:00:10.0 is not available
2019/12/18 15:16:16 corpus                  : 0 (0 deleted)
JK poll from vm-0: candidates=0 inputs=0 maxsignal=0
JK poll from vm-0: candidates=0 inputs=0 maxsignal=0
2019/12/18 15:16:24 VMs 1, executed 3, cover 0, crashes 0, repro 0
2019/12/18 15:16:34 VMs 1, executed 3, cover 0, crashes 0, repro 0
JK poll from vm-0: candidates=0 inputs=0 maxsignal=0
2019/12/18 15:16:44 VMs 1, executed 10, cover 0, crashes 0, repro 0
JK poll from vm-0: candidates=0 inputs=0 maxsignal=0
2019/12/18 15:16:54 VMs 1, executed 10, cover 0, crashes 0, repro 0
JK poll from vm-0: candidates=0 inputs=0 maxsignal=0
2019/12/18 15:17:04 VMs 1, executed 10, cover 0, crashes 0, repro 0
JK poll from vm-0: candidates=0 inputs=0 maxsignal=0
2019/12/18 15:17:14 VMs 1, executed 10, cover 0, crashes 0, repro 0
JK poll from vm-0: candidates=0 inputs=0 maxsignal=0
2019/12/18 15:17:24 VMs 1, executed 10, cover 0, crashes 0, repro 0
2019/12/18 15:17:34 VMs 1, executed 10, cover 0, crashes 0, repro 0
JK poll from vm-0: candidates=0 inputs=0 maxsignal=0
2019/12/18 15:17:44 VMs 1, executed 18, cover 0, crashes 0, repro 0
JK poll from vm-0: candidates=0 inputs=0 maxsignal=0
2019/12/18 15:17:54 VMs 1, executed 18, cover 0, crashes 0, repro 0
JK poll from vm-0: candidates=0 inputs=0 maxsignal=0
2019/12/18 15:18:04 VMs 1, executed 18, cover 0, crashes 0, repro 0
JK poll from vm-0: candidates=0 inputs=0 maxsignal=0
2019/12/18 15:18:14 VMs 1, executed 18, cover 0, crashes 0, repro 0

Here it works:
2019/12/18 15:14:53 loading corpus...
2019/12/18 15:14:53 serving http on http://127.0.0.1:15692
2019/12/18 15:14:53 serving rpc on tcp://[::]:43639
2019/12/18 15:14:53 booting test machines...
2019/12/18 15:14:53 wait for the connection from test machine...
2019/12/18 15:16:43 machine check:
2019/12/18 15:16:43 syscalls                : 1124/2961
2019/12/18 15:16:43 code coverage           : enabled
2019/12/18 15:16:43 comparison tracing      : ioctl(KCOV_TRACE_CMP) failed: invalid argument
2019/12/18 15:16:43 extra coverage          : extra coverage is not supported by the kernel
2019/12/18 15:16:43 setuid sandbox          : enabled
2019/12/18 15:16:43 namespace sandbox       : enabled
2019/12/18 15:16:43 Android sandbox         : /sys/fs/selinux/policy does not exist
2019/12/18 15:16:43 fault injection         : enabled
2019/12/18 15:16:43 leak checking           : enabled
2019/12/18 15:16:43 net packet injection    : enabled
2019/12/18 15:16:43 net device setup        : enabled
2019/12/18 15:16:43 concurrency sanitizer   : /sys/kernel/debug/kcsan does not exist
2019/12/18 15:16:43 devlink PCI setup       : PCI device 0000:00:10.0 is not available
2019/12/18 15:16:43 corpus                  : 156 (0 deleted)
JK poll from vm-0: candidates=5 inputs=0 maxsignal=0
JK poll from vm-0: candidates=0 inputs=0 maxsignal=0
2019/12/18 15:16:53 VMs 1, executed 0, cover 0, crashes 0, repro 0
JK poll from vm-0: candidates=0 inputs=0 maxsignal=0
2019/12/18 15:17:03 VMs 1, executed 2, cover 0, crashes 0, repro 0
JK poll from vm-0: candidates=0 inputs=0 maxsignal=0
2019/12/18 15:17:13 VMs 1, executed 2, cover 0, crashes 0, repro 0
JK poll from vm-0: candidates=0 inputs=0 maxsignal=0
2019/12/18 15:17:23 VMs 1, executed 2, cover 0, crashes 0, repro 0
JK poll from vm-0: candidates=0 inputs=0 maxsignal=0
2019/12/18 15:17:33 VMs 1, executed 2, cover 0, crashes 0, repro 0
JK new input from vm-0 for syscall openat (signal=589, cover=535)
JK skipped cover vm-0 vs. vm-0
JK new input from vm-0 for syscall syz_open_dev (signal=615, cover=612)
JK skipped cover vm-0 vs. vm-0
JK poll from vm-0: candidates=5 inputs=0 maxsignal=0
JK poll from vm-0: candidates=0 inputs=0 maxsignal=0
2019/12/18 15:17:43 VMs 1, executed 10, cover 831, crashes 0, repro 0
JK new input from vm-0 for syscall ftruncate (signal=80, cover=21)

Dmitry Vyukov

unread,
Dec 19, 2019, 4:04:44 AM12/19/19
to Jukka Kaartinen, syzkaller
On Wed, Dec 18, 2019 at 2:25 PM <jukka.k...@unikie.com> wrote:
>
> Here are logs from not working version and working. (I added JK in front of some the prints) Looks like difference is that in the working version there are logs: "new input from vm-0 for syscall openat (signal=589, cover=535)" would the timeout increment have effect on this?

Hard to say. The symptom is more like "is not working", and that
timeout is just one of the small pieces out there why it may not be
working. It may or may not help.
But easy to test, the timeout is here, try to bump it to 10 mins:
https://github.com/google/syzkaller/blob/master/pkg/ipc/ipc.go#L672

If it's really slow, there may be more things (silently) timing out.
This syz-runtest thing is a good way to ensure that it's actually
working rather than just consuming CPU time and not erroring out
loudly :)
https://github.com/google/syzkaller/pull/1536#issuecomment-566483564

We have a bunch of hardcoded timeouts in executor code. E.g. 40ms for
a single syscall execution. And these numbers were tuned more-or-less
on non-emulated linux amd64. What we really need is a flexible
mechanism to be able to specify and tune a number of timeouts
throughout based on OS/arch/VM/etc.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller/49e636a5-d7d3-44af-8ccc-97aed4b97a86%40googlegroups.com.

Dmitry Vyukov

unread,
Dec 19, 2019, 4:13:21 AM12/19/19
to Jukka Kaartinen, syzkaller
On Thu, Dec 19, 2019 at 10:04 AM Dmitry Vyukov <dvy...@google.com> wrote:
>
> On Wed, Dec 18, 2019 at 2:25 PM <jukka.k...@unikie.com> wrote:
> >
> > Here are logs from not working version and working. (I added JK in front of some the prints) Looks like difference is that in the working version there are logs: "new input from vm-0 for syscall openat (signal=589, cover=535)" would the timeout increment have effect on this?
>
> Hard to say. The symptom is more like "is not working", and that
> timeout is just one of the small pieces out there why it may not be
> working. It may or may not help.
> But easy to test, the timeout is here, try to bump it to 10 mins:
> https://github.com/google/syzkaller/blob/master/pkg/ipc/ipc.go#L672
>
> If it's really slow, there may be more things (silently) timing out.
> This syz-runtest thing is a good way to ensure that it's actually
> working rather than just consuming CPU time and not erroring out
> loudly :)
> https://github.com/google/syzkaller/pull/1536#issuecomment-566483564
>
> We have a bunch of hardcoded timeouts in executor code. E.g. 40ms for
> a single syscall execution. And these numbers were tuned more-or-less
> on non-emulated linux amd64. What we really need is a flexible
> mechanism to be able to specify and tune a number of timeouts
> throughout based on OS/arch/VM/etc.

Filed https://github.com/google/syzkaller/issues/1552 for the timeouts
issue as it comes up periodically.

jukka.k...@unikie.com

unread,
Dec 19, 2019, 7:45:57 AM12/19/19
to syzkaller
Thanks for filing the issue!

Looks like increasing the timeout seems to solve the coverage issue. I guess there will be still be the executor hard coded timeouts that would need to be increased. Dmitry, thanks for help I think we can close this thread.


BTW.
I also tried out the syz-runtest and I got some fails. These might be kernel config issue like you pointed out in the PR https://github.com/google/syzkaller/pull/1536#issuecomment-567441542

booting VMs...
code coverage           : enabled
comparison tracing      : ioctl(KCOV_TRACE_CMP) failed: invalid argument
extra coverage          : extra coverage is not supported by the kernel
setuid sandbox          : enabled
namespace sandbox       : enabled
Android sandbox         : /sys/fs/selinux/policy does not exist
fault injection         : enabled
leak checking           : enabled
net packet injection    : enabled
net device setup        : enabled
concurrency sanitizer   : /sys/kernel/debug/kcsan does not exist
devlink PCI setup       : PCI device 0000:00:10.0 is not available
none sandbox            : 1124 calls enabled
setuid sandbox          : 1030 calls enabled
namespace sandbox       : 1115 calls enabled
 sandbox                : 1122 calls enabled
binfmt  C                             : FAIL: run 0: wrong call 7 result 8, want 2
        ### start
        ### call=0 errno=2
        ### call=1 errno=0
        ### call=2 errno=0
        ### call=3 errno=8
        ### call=4 errno=0
        ### call=5 errno=0
        ### call=6 errno=0
        ### call=7 errno=8
        ### call=8 errno=0
        ### call=9 errno=0
        ### call=10 errno=8
        ### call=11 errno=0
        ### call=12 errno=8
        
binfmt /repeat C                      : FAIL: run 0: wrong call 7 result 8, want 2
        ### start
        ### call=0 errno=2
        ### call=1 errno=0
        ### call=2 errno=0
        ### call=3 errno=8
        ### call=4 errno=0
        ### call=5 errno=0
        ### call=6 errno=0
        ### call=7 errno=8
        ### call=8 errno=0
        ### call=9 errno=0
        ### call=10 errno=8
        ### call=11 errno=0
        ### call=12 errno=8
        ### start
        ### call=0 errno=2
        ### call=1 errno=0
        ### call=2 errno=0
        ### call=3 errno=8
        ### call=4 errno=0
        ### call=5 errno=0
        ### call=6 errno=0
        ### call=7 errno=8
        ### call=8 errno=0
        ### call=9 errno=0
        ### call=10 errno=8
        ### call=11 errno=0
        ### call=12 errno=8
        ### start
        ### call=0 errno=2
        ### call=1 errno=0
        ### call=2 errno=0
        ### call=3 errno=8
        ### call=4 errno=0
        ### call=5 errno=0
        ### call=6 errno=0
        ### call=7 errno=8
        ### call=8 errno=0
        ### call=9 errno=0
        ### call=10 errno=8
        ### call=11 errno=0
        ### call=12 errno=8

...

binfmt none/thr                       : FAIL: run 0: call 3 is not executed
binfmt none/thr/cover                 : FAIL: run 0: call 3 is blocked
binfmt none/thr C                     : FAIL: should repeat 1 times, but repeated 0
        
binfmt none/thr/repeat                : FAIL: run 0: call 3 is blocked
binfmt none/thr/repeat/cover          : FAIL: run 0: call 3 is blocked
binfmt none/thr/repeat C              : FAIL: should repeat 3 times, but repeated 0
        
binfmt setuid                         : FAIL: run 0: wrong call 7 result 8, want 2
binfmt setuid/cover                   : FAIL: no output from test machine
        Warning: Permanently added '[localhost]:62919' (ECDSA) to the list of known hosts.
        2019/12/19 10:46:08 fuzzer started
        2019/12/19 10:46:09 dialing manager at 10.0.2.10:43593
        2019/12/19 10:47:04 syscalls: 1124
        2019/12/19 10:47:04 code coverage: enabled
        2019/12/19 10:47:04 comparison tracing: ioctl(KCOV_TRACE_CMP) failed: invalid argument
        2019/12/19 10:47:04 extra coverage: extra coverage is not supported by the kernel
        2019/12/19 10:47:04 setuid sandbox: enabled
        2019/12/19 10:47:04 namespace sandbox: enabled
        2019/12/19 10:47:04 Android sandbox: /sys/fs/selinux/policy does not exist
        2019/12/19 10:47:04 fault injection: enabled
        2019/12/19 10:47:04 leak checking: enabled
        2019/12/19 10:47:04 net packet injection: enabled
        2019/12/19 10:47:04 net device setup: enabled
        2019/12/19 10:47:04 concurrency sanitizer: /sys/kernel/debug/kcsan does not exist
        2019/12/19 10:47:04 devlink PCI setup: PCI device 0000:00:10.0 is not available
        
binfmt setuid C                       : FAIL: should repeat 1 times, but repeated 0
        
binfmt setuid/repeat                  : FAIL: run 0: wrong call 7 result 8, want 2



Dmitry Vyukov

unread,
Dec 19, 2019, 8:13:06 AM12/19/19
to Jukka Kaartinen, syzkaller
On Thu, Dec 19, 2019 at 1:46 PM <jukka.k...@unikie.com> wrote:
>
> Thanks for filing the issue!
>
> Looks like increasing the timeout seems to solve the coverage issue. I guess there will be still be the executor hard coded timeouts that would need to be increased. Dmitry, thanks for help I think we can close this thread.

Could you please leave a note on the issue re what exactly timeout you
increased to what value for what configuration, so that we have that
concrete data if/when we are fixing it.
> --
> You received this message because you are subscribed to the Google Groups "syzkaller" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller/0fb3006f-3657-4d7d-865a-ce847d2f8541%40googlegroups.com.

jukka.k...@unikie.com

unread,
Dec 20, 2019, 2:32:01 AM12/20/19
to syzkaller
> To unsubscribe from this group and stop receiving emails from it, send an email to syzk...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages