sanitizer-coverage vs asan_blacklist

[Alexey Samsonov]

On Sat, Apr 11, 2015 at 11:33 AM, Timur Iskhodzhanov <timurrrr at google.com>
wrote:

>
>
> сб, 11 апр. 2015 г. в 20:17, Alexey Samsonov <vonosmas at gmail.com>:
>
>> I think that using blacklist to disable instrumentation because of
>> sandbox is a pretty gross hack, and
>> the wrong thing to do. I think the better "solution" would be to move
>> sandbox-related code to a different
>> source files, and compile them with -fno-sanitize=all. Then you can also
>> compile them with -fsanitize-coverage=0,
>> and the problem would be solved.
>>
>
> I don't agree this is a better solution.
> Changing the file/code structure of a project to please a deficiency of
> every tool we want to use doesn't scale in general.
>

Fair enough, but I'd argue we should have added
__attribute__((no_sanitize_address)) to these functions instead of
blacklisting them.
I'm OK with implementing similar attribute for coverage.

>
> For example, Chromium's sandbox/ code depends on base/ and we do blacklist
> some code from base/.  Some of that code is located in a header file...
> I doubt sufficiently changing the file structure would be welcome.
> I'm not a GYP expert, so the thought of passing an extra compiler flag for
> select TUs scares me as well.
>
>
>> On Fri, Apr 10, 2015 at 12:16 PM, Timur Iskhodzhanov <timurrrr at google.com
>> > wrote:
>>
>>> (After looking at the code)
>>> Is it fine to just return from SanitizerCoverageModule::runOnFunction if
>>> a given function doesn't have one of the Sanitize{Address,Thread,Memory}
>>> attributes for the "current" sanitizer set?
>>>
>>
>> No. Coverage is also supposed to work with DFSan, and with UBSan (the
>> latter doesn't add any attributes to LLVM functions).
>>
>
> Alright, can we support that exclusion just for ASan for the time being?
>
>
>> Logic could be like that:
>>> – instrument all the code if we're only doing coverage [w/o
>>> asan,msan,tsan]
>>> – instrument all the non-blacklisted code, use the same
>>> instrument/no-instrument attribute as the "main" sanitizer being used
>>>
>>> WDYT?
>>>
>>> пт, 10 апр. 2015 г. в 21:32, Timur Iskhodzhanov <timurrrr at google.com>:
>>>
>>> ... especially since the blacklist option is called -fsanitize-blacklist.
>>>> Just looking at its name, I'd had assumed it affected
>>>> -fsanitize-coverage too.
>>>>
>>>
>> I'd try to abstain from using blacklist for coverage instrumentation. If
>> we would still definitely have to add it for
>> some reason (see above for suggestion regarding sandbox issue in Chrome),
>> we can use categories:
>>
>> src:*/dont/use/coverage.cc=coverage
>> fun:DontUseCoverage=coverage
>>
>>
>>>
>>>> пт, 10 апр. 2015 г. в 21:08, Timur Iskhodzhanov <timurrrr at google.com>:
>>>>
>>>> Kostya, Alexey,
>>>>>
>>>>> I'm currently working on sanitizer coverage on Windows for Chromium.
>>>>> As described in http://crbug.com/459166 , we currently blacklist some
>>>>> sandbox code from ASan instrumentation, otherwise shadow memory is accessed
>>>>> before the RTL is even loaded.
>>>>> As it turns out, we should also disable coverage instrumentation for
>>>>> that code, otherwise the guard variables are checked before the RTL is
>>>>> loaded.
>>>>>
>>>>> That being said, the ASan blacklist should probably be used in the
>>>>> coverage instrumentation module pass.  Or it should have a separate
>>>>> blacklist...
>>>>>
>>>>> What do you think?
>>>>> ––
>>>>> Timur
>>>>>
>>>>
>>
>>
>> --
>> Alexey Samsonov
>> vonosmas at gmail.com
>>
>


-- 
Alexey Samsonov
vonosmas at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150411/9088a40c/attachment.html>