[Bug sanitizer/59454] blacklisting sanitized functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59454 --- Comment #6 from Jakub Jelinek --- (In reply to Yuri Gribov from comment #5) > (In reply to Martin Liška from comment #4) > > I'm pasting here Jakub's opinion which I agree with: > > > > ``` > > I'm strongly against the blacklist, that is not the way things are done in > > GCC, you have corresponding attribute to mark functions you don't want to > > instrument, people can macroize that with > > __typeof (symbol) symbol __attribute__((__no_sanitize_address__)); > > But in any case, you mark it in the code rather than adding externally > > some symbol list. > > Well, blacklists simplify integration of Asan to large codebases (e.g. full > Linux distro) where you often don't have the luxury of modifying the source > code. I believe was the main reason why they were added to Clang's sanitizer. > > Just to double check, what are the technical arguments against using > blacklists? The problem is that strings can't uniquely identify all functions. Either the strings are mangled names, but then you can only use that to identify the exported functions (and even then, for say comdat functions you can only affect all of them or none), stuff like functions in anonymous namespaces, methods in local types and the like are not accessible this way. Or you use non-mangled names and then it is even fuzzier on what you identify. I know there is #pragma weak supported for compatibility with something that also uses similar kind of symbol matching, but IMNSHO it is equally misdesigned thing.
[Bug sanitizer/59454] blacklisting sanitized functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59454 --- Comment #5 from Yuri Gribov --- (In reply to Martin Liška from comment #4) > I'm pasting here Jakub's opinion which I agree with: > > ``` > I'm strongly against the blacklist, that is not the way things are done in > GCC, you have corresponding attribute to mark functions you don't want to > instrument, people can macroize that with > __typeof (symbol) symbol __attribute__((__no_sanitize_address__)); > But in any case, you mark it in the code rather than adding externally > some symbol list. Well, blacklists simplify integration of Asan to large codebases (e.g. full Linux distro) where you often don't have the luxury of modifying the source code. I believe was the main reason why they were added to Clang's sanitizer. Just to double check, what are the technical arguments against using blacklists?
[Bug sanitizer/59454] blacklisting sanitized functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59454 Martin Liška changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #4 from Martin Liška --- I'm pasting here Jakub's opinion which I agree with: ``` I'm strongly against the blacklist, that is not the way things are done in GCC, you have corresponding attribute to mark functions you don't want to instrument, people can macroize that with __typeof (symbol) symbol __attribute__((__no_sanitize_address__)); But in any case, you mark it in the code rather than adding externally some symbol list. For others, perhaps, the question is what options to use for them, because -asan-* options are clearly unacceptable. Perhaps best might be --param asan-instrument-reads=0 and similar. Note I'd prefer not to implement ABI changing options, like making red zone size, or shadow shift or shadow base etc. variable, it is enough that libasan, etc. doesn't have a stable ABI in between major GCC versions, we don't want to people have issues with library X compiled with GCC 4.9 with one asan ABI and another with a different one. ``` Thus I'm closing that as wontfix.
[Bug sanitizer/59454] blacklisting sanitized functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59454 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-06-13 CC||marxin at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1
[Bug sanitizer/59454] blacklisting sanitized functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59454 Yury Gribov y.gribov at samsung dot com changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #3 from Yury Gribov y.gribov at samsung dot com --- Added Tobias.
[Bug sanitizer/59454] blacklisting sanitized functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59454 --- Comment #2 from Yuri Gribov tetra2005 at gmail dot com --- Proper link to Fortran attr bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41209
[Bug sanitizer/59454] blacklisting sanitized functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59454 Yuri Gribov tetra2005 at gmail dot com changed: What|Removed |Added CC||tetra2005 at gmail dot com --- Comment #1 from Yuri Gribov tetra2005 at gmail dot com --- I guess what you really need is equivalent of __attribute__((no_address_safety_analysis)) in Fortran land. People have been talking about supporting attributes in GNU Fortran for ages (see #41209) but it never got anywhere.
