This is an archive of the discontinued LLVM Phabricator instance.

[RFC] Introduce support for multiple sanitizer blacklists (Clang side).
Needs ReviewPublic

Authored by pcc on Jul 16 2014, 2:32 PM.

Details

Reviewers
samsonov
Summary

This adds support for multiple -fsanitize-blacklist flags, which cause
clang to load blacklists from each of the specified paths. This could be
useful for sanitizers such as DFSan where we may have multiple ABI lists,
each covering a specific library, which describes the ABI of that library.

This changes the semantics of the -fsanitize-blacklist flag, so I wanted to
make sure that we were comfortable with that. Now, the flag is additive, so a
-fsanitize-blacklist flag on the command line loads the specified blacklist
as well as the one in the resource directory. The -fno-sanitize-blacklist
flag works as before in that it prevents the blacklist in the resource
directory from being loaded, but it can also be used in combination with
-fsanitize-blacklist to load only user-specified blacklists.

Tests to come. I've removed the one test which fails as a result of the
changed semantics.

Diff Detail

Event Timeline

pcc updated this revision to Diff 11538.Jul 16 2014, 2:32 PM
pcc retitled this revision from to [RFC] Introduce support for multiple sanitizer blacklists (Clang side)..
pcc updated this object.
pcc edited the test plan for this revision. (Show Details)
pcc added a reviewer: samsonov.
pcc added a subscriber: Unknown Object (MLST).
samsonov added inline comments.Jul 16 2014, 4:16 PM
include/clang/Driver/SanitizerArgs.h
12

You may include clang/Basic/LLVM.h and use plain StringRef instead of llvm::StringRef.

lib/CodeGen/BackendUtil.cpp
592

See my comment in LLVM part - this file doesn't look like the right place for this function.

lib/Driver/SanitizerArgs.cpp
128

nit: remove {} for if- and else- clauses for consistency.

pcc updated this revision to Diff 11554.Jul 16 2014, 8:31 PM

Address comments.

include/clang/Driver/SanitizerArgs.h
12

Done.

lib/CodeGen/BackendUtil.cpp
592

I was imagining that we could add things like support for ad hoc entries here if we needed it.

lib/Driver/SanitizerArgs.cpp
128

Done.

samsonov added inline comments.Jul 17 2014, 6:36 PM
lib/CodeGen/BackendUtil.cpp
592

Can you provide an example for "ad hoc" entries which can't be explained by special case list format? It's somewhat unfortunate that you need to modify special case list twice - in Clang CodeGen and before passing it to the backend.

pcc added inline comments.Aug 5 2014, 7:01 PM
lib/CodeGen/BackendUtil.cpp
592

I was referring to the case where you might have an entry on the command line or dynamically loaded from an object file; see my comments in D4546.

I think we can avoid the double construction issue by modifying SanitizerBlacklist to only create a SpecialCaseList if the user has enabled a sanitizer that uses it.

pcc updated this revision to Diff 12252.Aug 6 2014, 2:15 PM

Add tests and address reviewer comments.

samsonov edited edge metadata.Aug 7 2014, 4:35 PM

Support for adding special case list entries in commandline seems an overkill to me. Now, if you presumably need logic to dynamically construct special case list from object files, I don't see why Clang's codegen will be a good place for it. It won't even use this list, only pass it to the DFSan backend...

lib/Driver/SanitizerArgs.cpp
118

Hm. So now -fno-sanitize-blacklist only disables the default blacklist, but not blacklists specified in -fsanitize-blacklist= arguments? This looks weird. I'd suggest the following semantics:

  • default blacklist in resource directory is implicitly enabled.
  • -fsanitize-blacklist= specifes one more blacklist to use
  • -fno-sanitize-blacklist - discards all blacklists previously defined in the command line, and the default blacklist.

That is,

BLSet.insert(DefaultBlacklist);
foreach (arg)
  if arg is -fsanitize-blacklist=, insert the blacklist into BLSet
  else if arg is -fno-sanitize-blacklist, clear BLSet.
pcc added a comment.Aug 7 2014, 6:45 PM

Support for adding special case list entries in commandline seems an overkill to me. Now, if you presumably need logic to dynamically construct special case list from object files, I don't see why Clang's codegen will be a good place for it. It won't even use this list, only pass it to the DFSan backend...

I don't think I actually need support for entries on the command line. Forget I brought it up.

I can probably live with having dfsan take two lists of strings, one for the ABI list files and the other for the object files. The thing is that I wanted the ABI list to be collected into an object before being used to create the pass. That way, it would probably be easier to do error handling and such from Clang or whatever is building the ABI list. The existing SpecialCaseList object seemed like a reasonable place to do it, but maybe it would be better to use DFSanABIList for that purpose and make it a public class.

I was imagining that the code that extracts the list from the object files would live in DataFlowSanitizer.cpp and be called from clang.

lib/Driver/SanitizerArgs.cpp
118

Sounds good. I initially wanted to have a -fno-default-sanitize-blacklist flag but I imagined that would be even more confusing if we needed to keep -fno-sanitize-blacklist.

I see. As I mentioned in offline discussion, you'd probably need smth. like LLVMObject library to dynamically extract the symbols you need from the shared objects, and it would we weird to have Clang CodeGen depend on it.