When -asan-max-inline-poisoning-size=0, all shadow memory access should be
outlined (through asan calls). This was not occuring when partial poisoning
was required on the right side of a variable's redzone. This diff contains
the changes necessary to implement and utilize asan_set_shadow_01() through
asan_set_shadow_07(). The change is necessary for the full abstraction of
the asan implementation and will enable experimentation with alternate strategies.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
the patch is technically correct
however ___asan_set_shadow_* where introduced to workaround some backed issues to handle huge functions. ___asan_set_shadow_01 can't be repeated, so likely outlining will cost more then inlining
Which arch is your target? On ARM HWASAN is better tool to detect same kind of bugs.
compiler-rt/test/asan/TestCases/set_shadow_test.c | ||
---|---|---|
16–22 | if we want to optimize, these can't have anything other than 1 as size | |
38 | remove new line |
compiler-rt/test/asan/TestCases/set_shadow_test.c | ||
---|---|---|
16–22 | Good value @vitalybuka. Thank you. I put asserts on the implementation side (compiler-rt/lib/asan/asan_poisoning.cpp) where I expect never to get anything but single byte partial poisoning calls but I will firm that up where the optimizer can see it. |
compiler-rt/test/asan/TestCases/set_shadow_test.c | ||
---|---|---|
16–22 | Rather than having a mix of one and two parameter functions right now, I'm leaning toward possibly adding both one and two parameter versions of all of the __asan_set_shadow_xx() calls, and using the one parameter calls (implied single byte) when I know I can. Would you be ok with deferring any action on this for now @vitalybuka? |
LGTM
Note: For existing code, with default ClMaxInlinePoisoningSize = 64, probability to hit any on new callbacks close to zero.
llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp | ||
---|---|---|
2898 | It has to stay because it's a fallback if there isn't a function to call. While it's true that for -asan-mapping-scale=3, we have all the possibilities covered, we don't at higher scales. For example, we needed 0x08..0x0F for -asan-mapping-scale=4, 0x08..0x1F for -asan-mapping-scale=5, etc. up to 0x08..0xFF for -asan-mapping-scale=8. (Not sure that any of this works at scales higher than 8 tbh.) Frankly, I think that passing the constant to a generic routine would be as good in practice, reduce the number of one-off functions and work for -asan-mapping-scale up to 8. @vitalybuka and @kubamracek , what do you think? My sense is to make a __asan_set_shadow1(address, value) and kill two birds with one stone. |
if we want to optimize, these can't have anything other than 1 as size