Use adb to read kernel log instead of ttyUSB

[chengh...@gmail.com]

Hi everyone,

I planed to run syzkaller on an android phone using adb for testing kernel drivers (ioctls).

As this discussion thread Cross Compile syzkaller ARM suggests, I will need a ttyUSB* to read kernel log of the target phone.

However, I don't have this kind of JTAG device. 

I wonder if it is possible to just read kernel log via adb, for example, adb shell 'cat /dev/kmsg' and make syzkaller fully functioned.

I am not familiar with golang.

Please kindly let me know if I am wrong about the following.

According to my understanding of codes, the console operation is defined vm/adb/console.go and vm/adb/adb.go

During syzkaller inits, a console device must be found in findConsole function (adb.go).

For each time of test program execution, the console device is opened, read output into merger, and then close (console.go).

It looks like the above operations could be totally replaced with adb operation.

During init, findConsole check if device is ready via adb shell.

For each time of test program execution, run 'adb shell cat /dev/kmsg', read the output, and kill the adb client as close.

Maybe you guys have better ideas to solve my problem. 

Please let me know.

Thanks,

Han

[$rik@nth]

Hi,

I would suggest you to check this patch

https://github.com/google/syzkaller/commit/a074da17a4055352fea94afbd5a15c53d0946653

--
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.

--

Thanks & Regards,
M.Srikanth Kumar.

[chengh...@gmail.com]

Hi, 

I checked that patch and I read the discussion between you and Dmitry.

That patch doesn't solve my problem because I don't have any ttyUSB.

Therefore, I think maybe it is a good feature if we could fuzz the regular android phone without any JTAG devices, since most of developers in my company just use an engineer-build phone, not a development board.

Han

[$rik@nth]

It doesn't require a jtag. Serial USB is fine for you to give a try.

[Dmitry Vyukov]

Hello Han,

Please read this thread, it is about the same thing:
https://groups.google.com/forum/#!searchin/syzkaller/adb$20console$20|sort:relevance/syzkaller/jCDmlTU5Jbg/bW7oQ3ETDwAJ
If the proposed patch (in the second message there) will work for you.
Then we can think about how to integrate it into syzkaller.

[chengh...@gmail.com]

Hi Dmitry, 

I will try this patch tomorrow and let you guys know the result.

Thanks,

Han

[chengh...@gmail.com]

Hi Dmitry, 

I confirm that the patch works.

In my company, we have lots of test phones that could be used to perform fuzz testing. 

But the number of debug boards is much less than the phones.

It would be really great if we are able to run syzkaller without any special hardware.

Thanks for your help. 

Han

[Dmitry Vyukov]

Committed support for 'adb shell dmesg -w':
https://github.com/google/syzkaller/commit/c81cc207a69c4efeb8ca07090ef1427a13324a0b
Please test if it works for you.

[xfran...@gmail.com]

Hi Dmitry,

I am testing a android phone with syzkaller, use adb shell to get kernel log. 

And I do found lots of 'lost connection', as you said in the above commit.

Can you tell the exact reason why the 'adb shell' way is not reliable? And how can I impove it?

Thank you.

[Dmitry Vyukov]

On Mon, Feb 20, 2017 at 10:32 AM, <xfran...@gmail.com> wrote:
> Hi Dmitry,
> I am testing a android phone with syzkaller, use adb shell to get kernel
> log.
> And I do found lots of 'lost connection', as you said in the above commit.
>
> Can you tell the exact reason why the 'adb shell' way is not reliable? And
> how can I impove it?

After printing a panic message to console, kernel shut down all cpus
and stalls/reboots machine.
To get the panic message to syzkaller we need: (1) schedule tail
process, let it read the panic message and write it to stdout, (2)
schedule adb server process, let it read the output and send it to
network, (3) actually push data from kernel networking state. The
chances are that all that won't have time to happen before machine is
stalled/rebooted.

I don't know how to make it more reliable. If you find a way, I am
happy to accept patches.

You could replay the crash logs manually with syz-execprog, but
probably you won't see the crash message as well. But at least if you
see that the machine reboots, you know that you found a bug.

[xfran...@gmail.com]

So the "adb shell" is reliable if device is not rebooted or stalled?

This is my scenario:

In manager.go's runInstance function, after call "vm.MonitorExecution", I add a function call "inst.after_Run", to check if the device is rebooted.If rebooted, save the 'last_kmsg'.

Typically, after a whole night running, I can get dozens of 'lost connection' (and may be some other type crashes). But very few of this 'lost connection' is actually a reboot.

So, the other non-reboot 'lost connection' is not the result of using 'adb shell'?

And how to analyze the 'lost connection' log? 

I can see lots of syz-executor crash in same log, it's normal, right?

Thank you.

[Dmitry Vyukov]

On Tue, Feb 21, 2017 at 6:54 AM, <xfran...@gmail.com> wrote:
> So the "adb shell" is reliable if device is not rebooted or stalled?
>
> This is my scenario:
> In manager.go's runInstance function, after call "vm.MonitorExecution", I
> add a function call "inst.after_Run", to check if the device is rebooted.If
> rebooted, save the 'last_kmsg'.
> Typically, after a whole night running, I can get dozens of 'lost
> connection' (and may be some other type crashes). But very few of this 'lost
> connection' is actually a reboot.
>
> So, the other non-reboot 'lost connection' is not the result of using 'adb
> shell'?
> And how to analyze the 'lost connection' log?
> I can see lots of syz-executor crash in same log, it's normal, right?

No, it's generally not normal.
Can you show the most frequent ones? There can be something to fix in syzkaller.
If they happen not too often and they don't actually lead to reboots,
then you can ignore them.