Re: [stos, again] Re: CVS commit: src/sys/arch/amd64

[Kamil Rytarowski <kamil%netbsd.org@localhost>]

On 04.06.2020 23:41, Andrew Doran wrote:
> On Thu, Jun 04, 2020 at 02:35:17AM +0200, Kamil Rytarowski wrote:
> 
>> On 04.06.2020 00:42, Andrew Doran wrote:
>>> On Wed, Jun 03, 2020 at 02:03:22AM +0200, Kamil Rytarowski wrote:
>>>
>>>> On 03.06.2020 01:49, Andrew Doran wrote:
>>>>> On the assembly thing recall that recently you expressed a desire to remove
>>>>> all of the amd64 assembly string functions from libc because of sanitizers -
>>>>> I invested my time to do up a little demo to try and show you why that's not
>>>>> a good idea:
>>>>>
>>>>> 	http://mail-index.netbsd.org/port-amd64/2020/04/19/msg003226.html
>>>>
>>>> Please note that interceptors for string functions are not just some
>>>> extra burden, but also very useful approach to feedback a fuzzer through
>>>> additional coverage.
>>>>
>>>> At least libFuzzer and honggfuzz wrap many kinds of string functions and
>>>> use it for fuzzing. We should add a special mode in KCOV to feedback
>>>> userland (syzkaller) with traces from string functions.
>>>>
>>>> https://github.com/google/honggfuzz/blob/bbb476eec95ad927d6d7d3d367d2b3e38eed3569/libhfuzz/memorycmp.c#L24
>>>
>>> No argument from me there at all.  I think that's a great idea and was
>>> looking at the interceptors in TSAN recently to see how they work.
>>>
>>> Andrew
>>>
>>
>> My note was not about switching away from ASM functions for certain
>> functions, but rather giving an option to disable them under a sanitizer
>> and adding an interceptor that can be useful for feedbacking a fuzzer.
>> It's still not clear whether we will create such interface in KCOV as it
>> has to be coordinated with Google+Linux as we would like to have a
>> compatible interface for syzkaller.
>>
>> TSAN - do you mean the userland ones?
> 
> Right, the userland one.
>  

Great.

We used to pass around 95% of upstream LLVM TSan tests. The remaining
ones were hard and I had no time to look into them.

>> BTW. There is a work-in-progress MKSANITIZER support for TSan, but it
>> used to create unkillable processes (kernel bug). Basically when using a
>> TSanitized userland applications, you will quickly end up with such
>> processes (from AFAIR calling ls(1) and other simple applications are
>> enough).
>>
>> If you are interested, I can share a reproducer.
> 
> Yes please.  Is the setup difficult?  I plan to look at some of the
> remaining issues noted on syzbot over the next while too.
> 

 ./build.sh -j8 -N0 -U -u -V MAKECONF=/dev/null -V MKCOMPAT=no -V
MKDEBUGLIB=yes -V MKDEBUG=yes -V MKSANITIZER=yes -V USE_SANITIZER=thread
-V MKLLVM=yes -V MKGCC=no -V HAVE_LLVM=yes -O /public/netbsd.fuzzer
distribution

Null mount /dev /dev/pts /tmp and chroot into it.

Try to run some basic applications and see creation unkillable
processes. Unless that was fixed by an accident/indirectly, you will
quickly reproduce it.

> Cheers,
> Andrew
>