Re: About KTSAN with Syzkaller

[Andrey Konovalov]

On Sun, Apr 29, 2018 at 4:02 AM, Xiaorui Pan <xia...@iu.edu> wrote:
> Hi Andrey,

Hi Xiaorui,

>
>
> I hope this email finds you well.
>
> I'm a phd student at Indiana University Bloomington, and am currently
> focusing on kernel data race bugs. In the long run, I want to build an end
> to end kernel data race fuzzer. So
> I have been very excited since I saw KTSAN being mentioned in several
> Syzkaller related talks. I'm wondering whether KTSAN can directly work with
> Syzkaller. In the current KTSAN wiki
> (https://github.com/google/ktsan/wiki), I can only find example of working
> with trinity, but no example of Syzkaller.

syzkaller and KTSAN are separate things, one is a fuzzer that stresses
the kernel and the other is a detector that finds data races. I
haven't tried running them together (since KTSAN development had been
put on hold before syzkaller was released), but I would imagine that
should be possible (although KTSAN is based on an old kernel that
doesn't have kcov support).

I would suggest trying to run it with trinity first. AFAIR even with
trinity we were getting more KTSAN reports than we were able to
process (see the reason below), so using syzkaller doesn't make much
sense at this point.

>
> Also, do you have any near future plan to make KTSAN upstream ?

No near plans.

> If not,
> could you outline the challenges and possible procedures of how to do this
> ?

The biggest issue we faced is that the kernel currently has lots of
benign data races that satisfy the formal definition of a data race
(and therefore are discovered and reported by the tool), but don't
lead to anything bad in practice. I think dealing with this is the
main obstacle.

Other than that you would need to rebase KTSAN onto the latest kernel
(since it's based on 4.2) and probably somehow deal with the fact that
it requires 32 GB of RAM to work.

Thanks!