sanitizer-coverage vs asan_blacklist

Alexey Samsonov vonosmas at gmail.com
Sat Apr 11 10:17:32 PDT 2015


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.

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).


> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150411/3027dd39/attachment.html>


More information about the llvm-commits mailing list