Mips64ler2 support #1536
Merged
Mips64ler2 support #1536
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). 📝 Please visit https://cla.developers.google.com/ to sign. Once you've signed (or fixed any issues), please reply here with What to do if you already signed the CLAIndividual signers
Corporate signers
ℹ️ Googlers: Go here for more info. |
|
Hi @hogander-unikie, |
@googlebot I signed it! |
|
CLAs look good, thanks! ℹ️ Googlers: Go here for more info. |
Add basic stuff to enable MIPS64ELR2 target: - build - make extract - make generate - qemu execution - system call parsing from /proc/kallsyms
Couple of include paths are needed for syz-extract to work for mips64ler2.
This patch adds all autogenerated files for linux/mips64le. Files are generated by following commands: make extract bin/syz-extract -build -os=linux -arch=mips64le -sourcedir=linux make generate
hogander-unikie
force-pushed
the
mips64ler2_support
branch
2 times, most recently
from
ebcbbbf
to
1667421
Compare
Codecov Report
@@ Coverage Diff @@
## master #1536 +/- ##
==========================================
- Coverage 56.04% 56.02% -0.02%
==========================================
Files 142 142
Lines 26556 26559 +3
==========================================
- Hits 14882 14881 -1
- Misses 10957 10960 +3
- Partials 717 718 +1
Continue to review full report at Codecov.
|
|
👍 Looks good, and CI runs through. @dvyukov do see any open points for adding this architecture? |
|
I tested it on mips64el with following steps:
Patch create-image.sh scriptdiff --git a/tools/create-image.sh b/tools/create-image.sh
index 9e931e99..9b10d5e6 100755
--- a/tools/create-image.sh
+++ b/tools/create-image.sh
@@ -20,11 +20,13 @@ RELEASE=stretch
FEATURE=minimal
SEEK=2047
PERF=false
+ARCH=amd64
# Display help function
display_help() {
echo "Usage: $0 [option...] " >&2
echo
+ echo " -a, --arch Set debian architecture to create"
echo " -d, --distribution Set on which debian distribution to create"
echo " -f, --feature Check what packages to install in the image, options are minimal, full"
echo " -s, --size Image size (MB), default 2048 (2G)"
@@ -43,6 +45,10 @@ while true; do
display_help
exit 0
;;
+ -a | --arch)
+ ARCH=$2
+ shift 2
+ ;;
-d | --distribution)
RELEASE=$2
shift 2
@@ -82,7 +88,7 @@ fi
sudo rm -rf $DIR
mkdir -p $DIR
-sudo debootstrap --include=$PREINSTALL_PKGS $RELEASE $DIR
+sudo qemu-debootstrap --arch=$ARCH --include=$PREINSTALL_PKGS $RELEASE $DIR
# Set some defaults and enable promtless ssh to the machine for root.
sudo sed -i '/^root/ { s/:x:/::/ }' $DIR/etc/passwd
@@ -112,9 +118,9 @@ cat $RELEASE.id_rsa.pub | sudo tee $DIR/root/.ssh/authorized_keys
# Add perf support
if [ $PERF = "true" ]; then
cp -r $KERNEL $DIR/tmp/
- sudo chroot $DIR /bin/bash -c "apt-get update; apt-get install -y flex bison python-dev libelf-dev libunwind8-dev libaudit-dev libslang2-dev libperl-dev binutils-dev liblzma-dev libnuma-dev"
- sudo chroot $DIR /bin/bash -c "cd /tmp/linux/tools/perf/; make"
- sudo chroot $DIR /bin/bash -c "cp /tmp/linux/tools/perf/perf /usr/bin/"
+ sudo schroot $DIR /bin/bash -c "apt-get update; apt-get install -y flex bison python-dev libelf-dev libunwind8-dev libaudit-dev libslang2-dev libperl-dev binutils-dev liblzma-dev libnuma-dev"
+ sudo schroot $DIR /bin/bash -c "cd /tmp/linux/tools/perf/; make"
+ sudo schroot $DIR /bin/bash -c "cp /tmp/linux/tools/perf/perf /usr/bin/"
rm -r $DIR/tmp/linux
fi
2.1) Backport this patch from mips-next https://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git/commit/?id=3f0a2abff9aa 2.2) I used this config for kernel (based on defconfig) https://pastebin.com/cLsuhsRm
Syzkaller config |
|
Look like coverage is not working on my setup: Syzkaller LogMaybe I miss something? |
|
After every 40 executions "no output from test machine" occurs Syzkaller Log |
|
Denis Efremov <[email protected]> writes:
After every 40 executions "no output from test machine" occurs
Seems to be same for me as well. I was using more than one VM and it
looked more random with that setup...
…
Syzkaller Log
2019/12/12 12:38:35 VMs 1, executed 0, cover 0, crashes 0, repro 0
2019/12/12 12:38:45 VMs 1, executed 8, cover 0, crashes 0, repro 0
...
2019/12/12 12:43:45 VMs 1, executed 40, cover 0, crashes 0, repro 0
2019/12/12 12:43:45 vm-0: crash: no output from test machine
2019/12/12 12:43:55 VMs 0, executed 40, cover 0, crashes 1, repro 0
...
2019/12/12 12:50:05 VMs 1, executed 80, cover 0, crashes 1, repro 0
2019/12/12 12:50:06 vm-0: crash: no output from test machine
2019/12/12 12:50:15 VMs 0, executed 80, cover 0, crashes 2, repro 0
...
2019/12/12 12:56:25 VMs 1, executed 120, cover 0, crashes 2, repro 0
2019/12/12 12:56:26 vm-0: crash: no output from test machine
2019/12/12 12:56:35 VMs 0, executed 120, cover 0, crashes 3, repro 0
...
2019/12/12 13:02:45 VMs 1, executed 160, cover 0, crashes 3, repro 0
2019/12/12 13:02:46 vm-0: crash: no output from test machine
2019/12/12 13:02:55 VMs 0, executed 160, cover 0, crashes 4, repro 0
...
2019/12/12 13:08:55 VMs 1, executed 200, cover 0, crashes 4, repro 0
2019/12/12 13:08:56 vm-0: crash: no output from test machine
2019/12/12 13:09:05 VMs 0, executed 200, cover 0, crashes 5, repro 0
...
2019/12/12 13:15:15 VMs 1, executed 240, cover 0, crashes 5, repro 0
2019/12/12 13:15:17 vm-0: crash: no output from test machine
2019/12/12 13:15:25 VMs 0, executed 240, cover 0, crashes 6, repro 0
...
2019/12/12 13:21:35 VMs 1, executed 280, cover 0, crashes 6, repro 0
2019/12/12 13:21:37 vm-0: crash: no output from test machine
2019/12/12 13:21:45 VMs 0, executed 280, cover 0, crashes 7, repro 0
...
2019/12/12 13:27:55 VMs 1, executed 320, cover 0, crashes 7, repro 0
2019/12/12 13:27:58 vm-0: crash: no output from test machine
2019/12/12 13:28:05 VMs 0, executed 320, cover 0, crashes 8, repro 0
...
2019/12/12 13:34:15 VMs 1, executed 360, cover 0, crashes 8, repro 0
2019/12/12 13:34:18 vm-0: crash: no output from test machine
2019/12/12 13:34:25 VMs 0, executed 360, cover 0, crashes 9, repro 0
...
2019/12/12 13:40:35 VMs 1, executed 400, cover 0, crashes 9, repro 0
2019/12/12 13:40:39 vm-0: crash: no output from test machine
2019/12/12 13:40:45 VMs 0, executed 400, cover 0, crashes 10, repro 0
...
2019/12/12 13:46:55 VMs 1, executed 440, cover 0, crashes 10, repro 0
2019/12/12 13:47:00 vm-0: crash: no output from test machine
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
Interesting enough that with "-debug" flag syzkaller starts to show coverage: But it can't show the coverage in dashboard. Enabling CONFIG_DEBUG_INFO=y doesn't help. |
|
Denis Efremov <[email protected]> writes:
Interesting enough that with "-debug" flag syzkaller starts to show
coverage:
I'm able to reproduce this. It seems to be some issue with parallel test
processes. -Debug uses only 1 test process? If you set procs as 1 it
shows coverage...
…
$ ./bin/syz-manager -config=./default.cfg -debug
...
2019/12/12 15:24:53 fuzzer vm-0 connected
2019/12/12 15:25:10 machine check:
2019/12/12 15:25:10 syscalls : 1205/2885
2019/12/12 15:25:10 code coverage : enabled
2019/12/12 15:25:10 comparison tracing : enabled
2019/12/12 15:25:10 extra coverage : enabled
2019/12/12 15:25:10 setuid sandbox : enabled
2019/12/12 15:25:10 namespace sandbox : /proc/self/ns/user does not exist
2019/12/12 15:25:10 Android sandbox : /sys/fs/selinux/policy does not exist
2019/12/12 15:25:10 fault injection : enabled
2019/12/12 15:25:10 leak checking : CONFIG_DEBUG_KMEMLEAK is not enabled
2019/12/12 15:25:10 net packet injection : enabled
2019/12/12 15:25:10 net device setup : enabled
2019/12/12 15:25:10 concurrency sanitizer : /sys/kernel/debug/kcsan does not exist
2019/12/12 15:25:10 devlink PCI setup : PCI device 0000:00:10.0 is not available
2019/12/12 15:25:10 corpus : 127 (0 deleted)
2019/12/12 15:25:17 VMs 1, executed 0, cover 0, crashes 0, repro 0
2019/12/12 15:25:27 VMs 1, executed 0, cover 0, crashes 0, repro 0
2019/12/12 15:25:37 VMs 1, executed 1, cover 0, crashes 0, repro 0
2019/12/12 15:25:47 VMs 1, executed 52, cover 3627, crashes 0, repro 0
2019/12/12 15:25:57 VMs 1, executed 174, cover 5037, crashes 0, repro 0
2019/12/12 15:26:07 VMs 1, executed 299, cover 5842, crashes 0, repro 0
2019/12/12 15:26:17 VMs 1, executed 436, cover 5918, crashes 0, repro 0
2019/12/12 15:26:27 VMs 1, executed 436, cover 5953, crashes 0, repro 0
2019/12/12 15:26:37 VMs 1, executed 533, cover 5970, crashes 0, repro 0
2019/12/12 15:26:47 VMs 1, executed 698, cover 6885, crashes 0, repro 0
2019/12/12 15:26:57 VMs 1, executed 811, cover 7004, crashes 0, repro 0
2019/12/12 15:27:07 VMs 1, executed 951, cover 8214, crashes 0, repro 0
2019/12/12 15:27:17 VMs 1, executed 1094, cover 8252, crashes 0, repro 0
2019/12/12 15:27:27 VMs 1, executed 1210, cover 8331, crashes 0, repro 0
2019/12/12 15:27:37 VMs 1, executed 1320, cover 8358, crashes 0, repro 0
But it can't show the coverage in dashboard. Enabling CONFIG_DEBUG_INFO=y
doesn't help.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
[email protected] (Jouni Högander) writes:
Denis Efremov ***@***.***> writes:
> Interesting enough that with "-debug" flag syzkaller starts to show
> coverage:
I'm able to reproduce this. It seems to be some issue with parallel test
processes. -Debug uses only 1 test process? If you set procs as 1 it
shows coverage...
After more testing/debugging I found out that this is not just issue
with coverage. Executor seems to be exiting quietly and I'm seeing these
messages in the log:
2019/12/16 09:28:15 fuzzer detected executor failure='executor 1: not serving
', retrying #1
2019/12/16 09:28:16 fuzzer detected executor failure='executor 2: not serving
', retrying #1
2019/12/16 09:28:16 fuzzer detected executor failure='executor 3: not serving
', retrying #1
I have found out the failure/exit happen in
common_linux.h:initialize_netdevice. It seems that more number
of executors (procs) more probable it is to fail. procs = 2 can be used without
seeing this problem. 3 is also pretty stable, but 4 doesn't work. Also
disabling netdevice initialization in Syzkaller seems to be workaround
for the issue.
There are no error messages when failure/exit happens. Sometimes it
happens in if_nametoindex. Sometimes in
some other networking related c library function.
This is what I'm seeing when using strace to trace syz-executor:
recvfrom(3, {{len=60, type=NLMSG_ERROR, flags=0, seq=0, pid=1}, {error=-ENODEV, msg={{len=40, type=0x14 /* NLMSG_??? */, flags=NLM_F_REQUEST|NLM_F_ACK|0x500, seq=0, pid=0}, "\x02\x18\x00\x00\x00\x00\x00\x00\x08\x00\x02\x00\xac\x14\x14\x1a\x08\x00\x01\x00\xac\x14\x14\x1a"}}}, 1024, 0, NULL, NULL) = 60
write(2, "netlink: add addr 172.20.20.26 d"..., 57) = 57
socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 4
ioctl(4, SIOCGIFINDEX, {ifr_name="team0" <unfinished ...>) = ?
+++ killed by SIGKILL +++
>
>
> $ ./bin/syz-manager -config=./default.cfg -debug
> ...
> 2019/12/12 15:24:53 fuzzer vm-0 connected
> 2019/12/12 15:25:10 machine check:
> 2019/12/12 15:25:10 syscalls : 1205/2885
> 2019/12/12 15:25:10 code coverage : enabled
> 2019/12/12 15:25:10 comparison tracing : enabled
> 2019/12/12 15:25:10 extra coverage : enabled
> 2019/12/12 15:25:10 setuid sandbox : enabled
> 2019/12/12 15:25:10 namespace sandbox : /proc/self/ns/user does not exist
> 2019/12/12 15:25:10 Android sandbox : /sys/fs/selinux/policy does not exist
> 2019/12/12 15:25:10 fault injection : enabled
> 2019/12/12 15:25:10 leak checking : CONFIG_DEBUG_KMEMLEAK is not enabled
> 2019/12/12 15:25:10 net packet injection : enabled
> 2019/12/12 15:25:10 net device setup : enabled
> 2019/12/12 15:25:10 concurrency sanitizer : /sys/kernel/debug/kcsan does not exist
> 2019/12/12 15:25:10 devlink PCI setup : PCI device 0000:00:10.0 is not available
> 2019/12/12 15:25:10 corpus : 127 (0 deleted)
> 2019/12/12 15:25:17 VMs 1, executed 0, cover 0, crashes 0, repro 0
> 2019/12/12 15:25:27 VMs 1, executed 0, cover 0, crashes 0, repro 0
> 2019/12/12 15:25:37 VMs 1, executed 1, cover 0, crashes 0, repro 0
> 2019/12/12 15:25:47 VMs 1, executed 52, cover 3627, crashes 0, repro 0
> 2019/12/12 15:25:57 VMs 1, executed 174, cover 5037, crashes 0, repro 0
> 2019/12/12 15:26:07 VMs 1, executed 299, cover 5842, crashes 0, repro 0
> 2019/12/12 15:26:17 VMs 1, executed 436, cover 5918, crashes 0, repro 0
> 2019/12/12 15:26:27 VMs 1, executed 436, cover 5953, crashes 0, repro 0
> 2019/12/12 15:26:37 VMs 1, executed 533, cover 5970, crashes 0, repro 0
> 2019/12/12 15:26:47 VMs 1, executed 698, cover 6885, crashes 0, repro 0
> 2019/12/12 15:26:57 VMs 1, executed 811, cover 7004, crashes 0, repro 0
> 2019/12/12 15:27:07 VMs 1, executed 951, cover 8214, crashes 0, repro 0
> 2019/12/12 15:27:17 VMs 1, executed 1094, cover 8252, crashes 0, repro 0
> 2019/12/12 15:27:27 VMs 1, executed 1210, cover 8331, crashes 0, repro 0
> 2019/12/12 15:27:37 VMs 1, executed 1320, cover 8358, crashes 0, repro 0
>
> But it can't show the coverage in dashboard. Enabling CONFIG_DEBUG_INFO=y
> doesn't help.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub, or unsubscribe.
BR,
Jouni Högander
|
|
Hi. Sorry for delays, as busy with other things. This looks good to me, I am going to merge this now. The remaining issues will be easier to fix separately in smaller changes. Thanks! |
dvyukov
added a commit
that referenced
this pull request
Dec 17, 2019
This is not necessary since we build legit object file
for the target binary now. But this breaks mips with:
/linux/arch/mips/include/asm/thread_info.h:53:30: error: register name not specified for ‘__current_thread_info’
register struct thread_info *__current_thread_info __asm__("$28");
So just remove the old hack.
Follow up to #1536
|
I fixed the __current_thread_info problem with 17273b7. I tried to regenerate consts, and it worked without any problems, which is good. However, I had to revert SOL_SOCKET change. We need to figure out something for this asap. Otherwise somebody (me) will check in a non-reverted version very soon. This whole procedure is specifically automated to not require dozen of assorted fixups here and there. What |
|
So how stable it is now? |
|
This should fix the SOL_SOCKET problem (at least for now): |
|
Filed #1552 for timeouts issues as it comes up periodically. |
|
Hello,
Dmitry Vyukov <[email protected]> writes:
So how stable it is now?
Does it work with procs=1/2?
This "not serving" comes from pkg/ipc.go. There is is timeout of 1 minute for setup of a new executor. Perhaps we could bump it to 3 mins b/c it's generally only meant to detect broken configurations, but if it's just slow but works eventually, then it's fine. But if you do it, please also add a
comment re slow qemu emulation instances (you use emulation, right?).
We may have more hardcoded timeout in executor that were tuned for
native x86_64 linux. There is no systematic solution for this yet.
Increasing this timeout to 3 minutes seem to help the setup issue I was
seeing. It seems 1 minute is too tight...
Try to run: make runtest; && bin/syz-runtest -config
manager.config. This will run a set of simple programs in different
modes and show if they pass/fail. It gives good insight into if
syzkaller actually working or not in your configuration.
All of them seem to be failing:
binfmt C : FAIL: run 0: wrong call 1 result 2, want 0
### start
### call=0 errno=2
### call=1 errno=2
### call=2 errno=9
### call=3 errno=2
### call=4 errno=2
### call=5 errno=9
### call=6 errno=9
### call=7 errno=2
### call=8 errno=2
### call=9 errno=9
### call=10 errno=2
### call=11 errno=2
### call=12 errno=2
...
BR,
Jouni Högander
|
Is it really all or some? If all, then it's all broken and totally not working. But I forgot to mention that some of the tests may require particular kernel configs and/or image. We have some constraints in these tests, but they don't handle just everything. |
Full log: |
|
So it's not completely bad, half has passed (and considerable amount is not supposed to pass due to missing configs/etc): However I see: which means some startup timeout is too low. This is really concerning: it just tried to create a local file and it fails. Not sure about this: Do you have uptodate kernel? maybe there were some kernel checks added to make this work as intended. Note you can run any of these tests manually with syz-execprog as well, e..g copy sys/linux/test/file to test machine, run syz-execprog -debug file. |
After your patch with procs=[1:5] output log shows that coverage is collected. But it's impossible to view it on web dashboard: For procs=6 and more |
I'm able to create files manually in this VM.
Latest mainline git tree with KCOV fix cherry-picked from mips-next. I will try to rerun tests on mips-next. |
But maybe executor is stared in some dir, where it does not have write permissions or something. If it's not able to create files in this test, most likely it's not able to create them at all. One way or another it's a problem.
No, it should not be that old. The change was at least some months old. |
The easiest way to debug this would be to run this tool: Or perhaps just this: We have that bit here: |
On arm64 I got the same message. It was fixed when I changed the objdump, nm and addr2line to arm64 specific versions. See: https://groups.google.com/d/msg/syzkaller/mCXA3j0oJfE/tfnd42XXBgAJ |
With this patch: diff --git a/pkg/cover/report.go b/pkg/cover/report.go
index 419fd4ba..89307e8e 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("mips64el-linux-gnuabi64-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..8a3b9e46 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("mips64el-linux-gnuabi64-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..b75abfad 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("mips64el-linux-gnuabi64-addr2line", "-afi", "-e", bin)
stdin, err := cmd.StdinPipe()
if err != nil {
return nil, errThe message on dashboard changed to |
|
Could you please leave a note on the issue #1552 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. |
|
Denis Efremov <[email protected]> writes:
On arm64 I got the same message. It was fixed when I changed the objdump, nm and addr2line to arm64 specific versions. See: https://groups.google.com/d/msg/syzkaller/mCXA3j0oJfE/tfnd42XXBgAJ
With this patch:
diff --git a/pkg/cover/report.go b/pkg/cover/report.go
index 419fd4ba..89307e8e 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("mips64el-linux-gnuabi64-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..8a3b9e46 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("mips64el-linux-gnuabi64-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..b75abfad 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("mips64el-linux-gnuabi64-addr2line", "-afi", "-e", bin)
stdin, err := cmd.StdinPipe()
if err != nil {
return nil, err
The message on dashboard changed to failed to generate coverage
profile: no coverage data available, console log 2019/12/19 15:30:28
VMs 1, executed 8597, cover 16205, crashes 0, repro 0 I will try to
debug it with syz-cover as Dmitry suggested
I got same after adding symbolic links to correct version to obj
objdump, nm and addr2line.
I add one pc value to cover.raw and run syz-cover:
$ echo 0xffffffff80100450 > cover.raw && ./bin/syz-cover -arch mips64le -kernel_obj /mnt/work/linux -kernel_src /mnt/work/linux -kernel_build_src /home/hogander/work/linux cover.raw
and I get browser telling 1% coverage for init/main.c
this part seems to be working? Is it then kcov data delivery from the
target to the host? Is that data stored somewhere during running syz-manager?
BR,
Jouni Högander
|
|
You can fetch raw coverage from manager at /rawcover address. |
|
This says that mips call instructions are 4 bytes: |
|
Dmitry Vyukov <[email protected]> writes:
This says that mips call instructions are 4 bytes:
case "mips64le":
return pc - 4
Is it the case?
Yes it is. If I understand this correclty:
$ objdump -d --no-show-raw-insn /mnt/work/linux/vmlinux
...
ffffffff8010044c: nop
ffffffff80100450: jal ffffffff80232080 <__sanitizer_cov_trace_pc>
ffffffff80100454: nop
...
BR,
Jouni Högander
|
|
Dmitry Vyukov <[email protected]> writes:
This says that mips call instructions are 4 bytes:
case "mips64le":
return pc - 4
Is it the case?
Browser interface started showing coverage now with pc - 8
Added this logging:
XXX fullPC 18446744071573925572
XXX prevPC 18446744071573925564
These are mapped into following snippet in vmlinux:
ffffffff80b4eebc: jal ffffffff80232080 <__sanitizer_cov_trace_pc>
ffffffff80b4eec0: nop
ffffffff80b4eec4: move a1,s0
So there seems to be always this nop after jal and PC values contain
address of next instruction after that: pc - 8 is correct. I don't
understand why these returned addresses are this way...I will still
prepare patch...
BR,
Jouni Högander
|
|
Just include all of this as a comment for future generations :) |
This probably has to do with the fact that MIPS uses branch delay slot. |
|
Dmitry Vyukov <[email protected]> writes:
Just include all of this as a comment for future generations :)
And then if it works for you, it's fine.
There is now pull request available:
#1554
|
|
With:
Dashboard show coverage. Full patch:diff --git a/pkg/cover/report.go b/pkg/cover/report.go
index 419fd4ba..3728c1db 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("mips64el-linux-gnuabi64-objdump", "-d", "--no-show-raw-insn", obj)
stdout, err := cmd.StdoutPipe()
if err != nil {
return nil, err
@@ -436,7 +436,7 @@ func PreviousInstructionPC(arch string, pc uint64) uint64 {
case "ppc64le":
return pc - 4
case "mips64le":
- return pc - 4
+ return pc - 8
default:
panic(fmt.Sprintf("unknown arch %q", arch))
}
diff --git a/pkg/ipc/ipc.go b/pkg/ipc/ipc.go
index a238d2ba..10f62ecb 100644
--- a/pkg/ipc/ipc.go
+++ b/pkg/ipc/ipc.go
@@ -669,7 +669,7 @@ func (c *command) handshake() error {
read <- nil
}()
// Sandbox setup can take significant time.
- timeout := time.NewTimer(time.Minute)
+ timeout := time.NewTimer(5 * time.Minute)
select {
case err := <-read:
timeout.Stop()
@@ -800,8 +800,8 @@ func (c *command) exec(opts *ExecOpts, progData []byte) (output []byte, hanged b
func sanitizeTimeout(config *Config) time.Duration {
const (
- executorTimeout = 5 * time.Second
- minTimeout = executorTimeout + 2*time.Second
+ executorTimeout = 150 * time.Second
+ minTimeout = executorTimeout + 50 * time.Second
)
timeout := config.Timeout
if timeout == 0 {
diff --git a/pkg/symbolizer/nm.go b/pkg/symbolizer/nm.go
index caa24662..8a3b9e46 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("mips64el-linux-gnuabi64-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..b75abfad 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("mips64el-linux-gnuabi64-addr2line", "-afi", "-e", bin)
stdin, err := cmd.StdinPipe()
if err != nil {
return nil, errIncreased timeouts && haveged doesn't help with tests in my case. Results are the same as in my previous run. Tests: ok: 227, broken: 0, skip: 165, fail: 223 |
|
I can create manually file1 at AT_FDCWD in vm. The test fails: |
|
It should create some temp dirs and use them. Perhaps there is something wrong with the location where it creates temp dirs. You could trace that with more debug() calls. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
linux/mips64le Syzkaller port
There are problems with MIPS64LE support in GO 1.12. Build needs GO 1.13.4.
Tested on MIPS64LE R2 QEMU environment.
Some problems were faced in extracting const files:
__current_thread_info is defined as a register for MIPS. This was solved by changing the definition to to normal pointer while extracting.
Two different values for SOL_SOCKET. This was solved by: sed "s/SOL_SOCKET = 65535/SOL_SOCKET = 1/" -i sys/linux/socket_unix_mips64le.const