Syzkaller with Android emulator (x86_64) failures

[Nickleman]

Hi,

I have previously worked on setting up Syzkaller with arm64 Android emulator (comes with AOSP) which worked.

To make use of KVM for efficiency (host is Ubuntu x86_64 machine), I'm trying to set-up with x86_64 targets instead.

I have managed to build the syzkaller and dmesg (to support -w option). But when I run syzkaller with Android emulated device (Android 7.1.2 userdebug), I get the following error:

/system/bin/sh: /data/syz-fuzzer: no such file or directory

I've checked that the file is indeed loaded onto the emulated device. SELinux is also in permissive mode. So I'm not sure why it is not running. Executing syz-fuzzer manually gives the same error.

Any idea what could be wrong?

[Dmitry Vyukov]

Such error is frequently caused by missing dynamic libraries. Check ldd syz-fuzzer output.

How do you build it? make should produce static binaries which are not subject to this error.

FWIW we are testing android x86_64 kernel with debian image and plain qemu, no android emulator, no NDK, etc. That stuff only causes problems.

[Nickleman]

Seems you are spot on. Here's the output of #file syz-fuzzer:

bin/linux_amd64/syz-fuzzer:   ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, stripped

The interpreter should be something like "bin/linker64"

My build commands were:

#export NDK=~/projects/aosp/prebuilts/ndk/current

#make TARGETOS=android TARGETARCH=amd64 CC=~/tools/android-toolchain-x86_64-24/bin/x86_64-linux-android-gcc

I tried specifying LD and AS environmental values as well but that didn't change anything.

[Dmitry Vyukov]

On Tue, Dec 19, 2017 at 10:18 AM, Nickleman <nclm...@gmail.com> wrote:
> Seems you are spot on. Here's the output of #file syz-fuzzer:
>
> bin/linux_amd64/syz-fuzzer: ELF 64-bit LSB executable, x86-64, version 1
> (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2,
> stripped
>
>
> The interpreter should be something like "bin/linker64"
>
> My build commands were:
>
> #export NDK=~/projects/aosp/prebuilts/ndk/current
>
> #make TARGETOS=android TARGETARCH=amd64
> CC=~/tools/android-toolchain-x86_64-24/bin/x86_64-linux-android-gcc

Try to build with TARGETOS=linux, without specifying NDK/CC. This
works for arm64 android devices.
If that works, another reason to wipe TARGETOS=android.

> --
> 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.
> For more options, visit https://groups.google.com/d/optout.

[Nickleman]

Tried as you suggested. Cleared NDK and CC. And used TARGETOS=linux

However, the same error is still seen. I don't see anything changed.

[Dmitry Vyukov]

Are you sure it's a problem with dynamic linker and not with dynamic libraries?

Try:

CGO_ENABLED=0 make fuzzer TARGETOS=linux

After this ldd should say "not a dynamic executable" and then both
linker and libraries should be irrelevant.

[Nickleman]

Yes it seems to work now.

bin/linux_amd64/syz-fuzzer:

not a dynamic executable

I ran it and the error is no longer seen.

Thanks!

What does CGO_ENABLED do?

[Dmitry Vyukov]

On Tue, Dec 19, 2017 at 11:21 AM, Nickleman <nclm...@gmail.com> wrote:
> Yes it seems to work now.
>
> bin/linux_amd64/syz-fuzzer:
>
> not a dynamic executable
>
>
> I ran it and the error is no longer seen.
> Thanks!
>
> What does CGO_ENABLED do?

CGO is Go's FFI for C code.

Go binaries are static by default. However, if CGO is used, then Go
binaries become dynamic (C code generally requires libc).
There is a single standard library package that uses CGO -- net, CGO
is used to get access to system DNS resolver. However, there is an
alternative, pure Go resolver implementation, which is usually enough,
but does not handle some weird corner cases that glibc's resolver can
handle. syzkaller does not need any of these weird corner cases and
does not use CGO itself, so we can just turn it off and then Go
binaries become static (read, reliably work on any linux
kernel/image).

I've mailed https://github.com/google/syzkaller/pull/485