Re: Failing NetBSD execs and new Instance for KuBSAN

[Dmitry Vyukov]

On Thu, Jul 18, 2019 at 8:03 AM Siddharth Muralee
<siddhart...@gmail.com> wrote:
>
> Hey Dmitry,
> I saw that the execs are failing for NetBSD. Is the due to the prefix computation code?
>
> Also, we were thinking if it would be possible to have a separate instance with KuBSan instead of KASAN. We still haven't figured out how to make them work together. And it would probably be a while before someone takes a look at what's going wrong.

+syzkaller mailing list

Yes, it seems like something related to coverage reports, the
syz-manager started objdump and waits for it to exit, but it did not
command it to exit:

root 15892 0.5 0.0 112000 67348 ? Sl Jul17 4:44 \_
syzkaller/current/bin/syz-manager -config
/syzkaller/managers/netbsd/current/manager.cfg
root 28018 0.0 0.0 50404 36996 ? S Jul17 0:00
\_ objdump -d --no-show-raw-insn
/syzkaller/managers/netbsd/current/obj/netbsd.gdb

Here is goroutine traceback of syz-manager:
https://gist.githubusercontent.com/dvyukov/b92e5dbf68d873458fa52474af3c85aa/raw/ceae5c6ee91d2a8567578e8a9be148e2b887e3eb/gistfile1.txt

[Dmitry Vyukov]

From the trace, objdump hanged due to stdout pipe overflow due to
panic in archCallInsn.
I've fixed the hang here:
https://github.com/google/syzkaller/commit/f53c0235fad462c4a1608b9ddfad4aeba7b26d72
But not the original panic in archCallInsn yet.

[Dmitry Vyukov]

I think this was the root cause:
https://github.com/google/syzkaller/commit/7bb222f7bcce6f16c2e110f4c3270e009aaf55e7
I've killed all objdump's on all instances and now restarting everything.

[Dmitry Vyukov]

On Thu, Jul 18, 2019 at 8:03 AM Siddharth Muralee
<siddhart...@gmail.com> wrote:
>
> Hey Dmitry,
> I saw that the execs are failing for NetBSD. Is the due to the prefix computation code?
>
> Also, we were thinking if it would be possible to have a separate instance with KuBSan instead of KASAN. We still haven't figured out how to make them work together. And it would probably be a while before someone takes a look at what's going wrong.

Setting up an instance is not a problem. However, if an instance does
not have KASAN, then it's highly likely what you will see is tons of
assorted crashes (KUBSAN and all other bug types) due to silent
undetected memory corruptions. Running automated continuous stress
testing without KASAN is problematic for this reason. So it would be
much more preferable to have them enabled together.
How fundamental is the problem? KUBSAN should be pretty simple and
non-conflicting with everything else (provided we don't
cross-instrument KUBSAN<->KASAN<->KCOV runtimes).

[Siddharth Muralee]

Oops, Sorry.

Should probably work now.

--

Regards, 

  Siddharth M
  Final Year B.Tech (CSE) Student,
  Amrita School of Engineering, Kollam

  Blog 

---------------------------------------

“Most people get ahead during the time that others waste."

[Kamil Rytarowski]

Kernel UBSan can still detect certain memory corruptions such as access
out of array bounds (and ASan can miss them in certain scenarios).

We will add Kernel MSan too and it will most likely conflict with Kernel
ASan, so we need to live without Kernel ASan in certain fuzzing
combinations.

The problem is that ASan+UBSan crash in some hard to spot location and
nobody had enough spare time to track it. For the time being we want to
make use of this sanitizer and being aware about memory corruptions that
can occur unnoticed.

We have cleaned all known UBSan warnings and we will make all UBSan
reports fatal for the fuzzer.

[Dmitry Vyukov]

Yes, we also use KMSAN without KASAN for linux, but it becomes a bit tricky.

Then as you wish, this won't be _my_ problem :)

Siddharth, please update
https://github.com/google/syzkaller/blob/master/pkg/build/netbsd.go to
use provided config rather than a hardcoded one similar to
https://github.com/google/syzkaller/blob/master/pkg/build/openbsd.go
And 2 configs: one for KASAN and one for KUBSAN.

[Dmitry Vyukov]

Enjoy:
https://storage.googleapis.com/syzkaller/cover/ci2-netbsd.html

Though, the coverage is small, it always crashes with some tun error,
seems to be related to the new network packet injection.

[Kamil Rytarowski]

Great work! Thank you.

> Though, the coverage is small, it always crashes with some tun error,
> seems to be related to the new network packet injection.
>

Do you mean?

https://syzkaller.appspot.com/bug?id=8893b85275e0919be2ddeabb3ea1c62d62a1361f

[Dmitry Vyukov]

That one happened only once, it couldn't cause any havoc.

I mean this one:
https://syzkaller.appspot.com/bug?id=f53c6b4870dcdbc12871ccf79e1c5b1e1757fd26

[Siddharth Muralee]

I noticed a few such errors happening due to the tun-id being out of range. I will try to figure out how to make the tun-id in the range itself. 

It actually leads to a check in the executor failing.

--
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/CACT4Y%2BY55r5PEHpaAmWiWXLXPfHBGLNknjZGSGuL8h3gus%2BZ9A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Kamil Rytarowski]

On 18.07.2019 17:27, Siddharth Muralee wrote:
> I noticed a few such errors happening due to the tun-id being out of
> range. I will try to figure out how to make the tun-id in the range itself. 
>

To be precise we use tap(4) and we support 0...4 device ids out of the
box. for more we shall be prepared with an image for fuzzing with
MAKEDEV that creates as many nodes as we need.

Creating additional devices (like up to 64 or 128) is better than
reducing the algorithm to 5 device nodes.

[Dmitry Vyukov]

Increasing number of devices should fit well somewhere in
pkg/build/netbsd.go, right?
We should increase it to MaxPids:
https://github.com/google/syzkaller/blob/master/prog/types.go#L277

[Kamil Rytarowski]

In the same place where we call './MAKEDEV kcov'.