syzkaller installation issues

[Alexander Popov]

Hello,

I would like to contribute to syzkaller. I've installed it and got 3 issues. I'm new to
this project and not sure about my fixes. Could I have a feedback before making pull requests?

The first issue is about create-image.sh.
It adds the string "V0:23:respawn:/sbin/getty 115200 hvc0" to inittab, but a fresh
debian-wheezy doesn't have a hvc0 device. So getty fails to start and respawns over and
over again. Does it work in your setup?

The second issue is about create-image.sh too. It tries to enable eth0 network interface,
but there is no eth0 in a fresh debian-wheezy, since biosdevname renames interfaces. The
simplest fix is disabling biosdevname by adding "net.ifnames=0 biosdevname=0" to the
kernel command line. Would you like it?

The third issue is about CONFIG_KCOV.
My kernel config is based on the default config of Linux Mint 18. It has
CONFIG_RANDOMIZE_BASE and CONFIG_RANDOMIZE_MEMORY enabled. So applying addr2line to the
output of the program from Documentation/kcov.txt doesn't give any sane result. Does
CONFIG_KCOV conflict with KASLR?

Best regards,
Alexander

[Dmitry Vyukov]

On Mon, Nov 21, 2016 at 8:26 PM, Alexander Popov <alex....@linux.com> wrote:
> Hello,
>
> I would like to contribute to syzkaller. I've installed it and got 3 issues. I'm new to
> this project and not sure about my fixes. Could I have a feedback before making pull requests?

Hi!

Sure

> The first issue is about create-image.sh.
> It adds the string "V0:23:respawn:/sbin/getty 115200 hvc0" to inittab, but a fresh
> debian-wheezy doesn't have a hvc0 device. So getty fails to start and respawns over and
> over again. Does it work in your setup?

I saw messages about init restarting something and then disabling
because it restarts too frequently. But I had no idea what it is. Yes,
I guess we need to remove it.

> The second issue is about create-image.sh too. It tries to enable eth0 network interface,
> but there is no eth0 in a fresh debian-wheezy, since biosdevname renames interfaces. The
> simplest fix is disabling biosdevname by adding "net.ifnames=0 biosdevname=0" to the
> kernel command line. Would you like it?

If enabling fails, but everything works, should we just remove that
enabling of eth0?
I need to note that I just don't fully understand what happens here.

> The third issue is about CONFIG_KCOV.
> My kernel config is based on the default config of Linux Mint 18. It has
> CONFIG_RANDOMIZE_BASE and CONFIG_RANDOMIZE_MEMORY enabled. So applying addr2line to the
> output of the program from Documentation/kcov.txt doesn't give any sane result. Does
> CONFIG_KCOV conflict with KASLR?

CONFIG_KCOV per se works with KASLR... for some definition of "works".
It works in the sense that it just gives user real PCs with or without
KASLR. It's just that's it's more difficult to make some sense of out
of PCs with KASLR.
So far our strategy was simply to disable KASLR when we are building a
kernel for fuzzing. I don't see any serious downsides of this
approach. But it's definitely something to note in documentation
(added a note to
https://github.com/google/syzkaller/wiki/Kernel-configs).
Generally it would be nice to make syzkaller work with KASLR, but I
would not consider it a high priority (unless there is something I am
missing). Note the problem is not just with addr2line, syz-manager
compares coverage from different VMs, so it is faked into thinking
they all are covering new code, while in reality they are covering the
same code with different randomization offsets. Maybe we should just
make __sanitizer_cov_trace_pc subtract the base.
There is also a more serious issue with dynamically loaded modules --
we somehow need to "normalize" their PCs, so we that syz-manager can
compare coverage in modules loaded at different addresses.


Thanks

[Alexander Popov]

Hello, Dmitry,

Thanks for your reply. I didn't receive it to my mailbox, but, fortunately, I saw it at
the mailing list webpage. Should I subscribe somehow to communicate via the mailing list?

On 21.11.2016 23:53, Dmitry Vyukov wrote:
> On Mon, Nov 21, 2016 at 8:26 PM, Alexander Popov <alex....@linux.com> wrote:
>> The first issue is about create-image.sh. It adds the string
>> "V0:23:respawn:/sbin/getty 115200 hvc0" to inittab, but a fresh debian-wheezy doesn't
>> have a hvc0 device. So getty fails to start and respawns over and over again. Does it
>> work in your setup?
>
> I saw messages about init restarting something and then disabling because it restarts
> too frequently. But I had no idea what it is. Yes, I guess we need to remove it.

Ok, I'll do it.

>> The second issue is about create-image.sh too. It tries to enable eth0 network
>> interface, but there is no eth0 in a fresh debian-wheezy, since biosdevname renames
>> interfaces. The simplest fix is disabling biosdevname by adding "net.ifnames=0
>> biosdevname=0" to the kernel command line. Would you like it?
>
> If enabling fails, but everything works, should we just remove that enabling of eth0? I
> need to note that I just don't fully understand what happens here.

No, currently the network on a fresh wheezy doesn't work. We can't access the VM via ssh
and hence syzkaller can't work. The reason is simple: we set up eth0 network interface,
but it doesn't exist in the VM (biosdevname has renamed it to something else like "eno3").

Disabling biosdevname service fixes the network. I'll propose a patch.

>> The third issue is about CONFIG_KCOV. My kernel config is based on the default config
>> of Linux Mint 18. It has CONFIG_RANDOMIZE_BASE and CONFIG_RANDOMIZE_MEMORY enabled.
>> So applying addr2line to the output of the program from Documentation/kcov.txt
>> doesn't give any sane result. Does CONFIG_KCOV conflict with KASLR?
>
> CONFIG_KCOV per se works with KASLR... for some definition of "works". It works in the
> sense that it just gives user real PCs with or without KASLR. It's just that's it's
> more difficult to make some sense of out of PCs with KASLR. So far our strategy was
> simply to disable KASLR when we are building a kernel for fuzzing. I don't see any
> serious downsides of this approach. But it's definitely something to note in
> documentation (added a note to
> https://github.com/google/syzkaller/wiki/Kernel-configs).

Ok, thanks for the details.

> Generally it would be nice to
> make syzkaller work with KASLR, but I would not consider it a high priority (unless
> there is something I am missing). Note the problem is not just with addr2line,
> syz-manager compares coverage from different VMs, so it is faked into thinking they all
> are covering new code, while in reality they are covering the same code with different
> randomization offsets. Maybe we should just make __sanitizer_cov_trace_pc subtract the
> base.

Thanks, Dmitry, I'll try to do that in my spare time.

> There is also a more serious issue with dynamically loaded modules -- we somehow
> need to "normalize" their PCs, so we that syz-manager can compare coverage in modules
> loaded at different addresses.

That seems more difficult and interesting. I'll try to dig into that. Thanks.

Best regards,
Alexander

[Dmitry Vyukov]

On Wed, Nov 23, 2016 at 11:38 PM, Alexander Popov <alex....@linux.com> wrote:
> Hello, Dmitry,
>
> Thanks for your reply. I didn't receive it to my mailbox, but, fortunately, I saw it at
> the mailing list webpage. Should I subscribe somehow to communicate via the mailing list?

You can subscribe to the list (requires gmail account I think). Or
maybe you can find an option on web to subscribe to a particular
thread. For now, I am just keeping you in CC.

> On 21.11.2016 23:53, Dmitry Vyukov wrote:
>> On Mon, Nov 21, 2016 at 8:26 PM, Alexander Popov <alex....@linux.com> wrote:
>>> The first issue is about create-image.sh. It adds the string
>>> "V0:23:respawn:/sbin/getty 115200 hvc0" to inittab, but a fresh debian-wheezy doesn't
>>> have a hvc0 device. So getty fails to start and respawns over and over again. Does it
>>> work in your setup?
>>
>> I saw messages about init restarting something and then disabling because it restarts
>> too frequently. But I had no idea what it is. Yes, I guess we need to remove it.
>
> Ok, I'll do it.
>
>>> The second issue is about create-image.sh too. It tries to enable eth0 network
>>> interface, but there is no eth0 in a fresh debian-wheezy, since biosdevname renames
>>> interfaces. The simplest fix is disabling biosdevname by adding "net.ifnames=0
>>> biosdevname=0" to the kernel command line. Would you like it?
>>
>> If enabling fails, but everything works, should we just remove that enabling of eth0? I
>> need to note that I just don't fully understand what happens here.
>
> No, currently the network on a fresh wheezy doesn't work. We can't access the VM via ssh
> and hence syzkaller can't work. The reason is simple: we set up eth0 network interface,
> but it doesn't exist in the VM (biosdevname has renamed it to something else like "eno3").
>
> Disabling biosdevname service fixes the network. I'll propose a patch.

Network works for me. Wonder what's different between our setups. I
created wheezy userspace few months ago, so it's not the latest one.
Is it a recent change? Or maybe you enable some additional kernel
configs?
Anyway, if you can propose a patch that fixes if for you and does not
break it for me, it sounds good to me.