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

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

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?

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.