If `Type::getPointerTo` is called solely to support an unnecessary
pointer-cast, remove the call entirely.
Otherwise, replace with IRB.getPtrTy().
Clean-up work towards removing method `Type::getPointerTo`.
The other 3 sanitizers (ASAN, TSAN and MSAN) all use
maybeMarkSanitizerLibraryCallNoBuiltin to make disable optimizations
which inline functions like memcmp for example. The lack of this
optimization was allowing ExpandMemCmpPass to convert a memcmp call to
inlined assembly and cause a false negative in HWASAN.
HWAddressSanitizerPass::run sanitizes functions one by one. The
sanitization of each function - which may split blocks via
insertShadowTagCheck - may result in some cached analyses are invalid.
This matters because sanitizeFunction(F', FAM) may indirectly call the
global stack safety analysis, hence we need to make sure the analyses of
F are up to date.
Bug report: https://github.com/llvm/llvm-project/issues/66934
Usually pointer tag will match tag in the shadow, so we can keep
inlining this check keeping the rest in outlined part.
It imroves performance by about 25%, but increases code size by 30%.
Existing outlining reduces performance by 30%, but saves code size by 80%.
So we still significantly reduce code size with minimal performance loss.
Reviewed By: fmayer
Differential Revision: https://reviews.llvm.org/D159172
This patch makes the variables names for callback functions more consistent. Changes no functionality.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D151605
This patch implements `__hwasan_memset_match_all`, `__hwasan_memcpy_match_all` and `__hwasan_memmove_match_all`, making hwasan-match-all-tag flag working for hwasan versions of memset, memcpy and memmove.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D149943
Currently, hwasan-match-all-tag flag is supported in inline memory access instrumentation and outline memory access instrumentation, but not supported in callback memory access instrumentation.
- For inline memory access instrumentation: a hwasan-match-all-tag check is added following the tag-mismtach check, if tag from pointer is mismatched with tag from shadow memory and tag from pointer is not equal with hwasan-match-all-tag, then a tag-mismatch will be report.
- For outline memory acess instrumentation: MatchAllTag is encoded in AccessInfo, when emit HWASAN memaccess symbols, asm-printer emits assembly instructions to check if tag from pointer is equal with hwasan-match-all-tag.
- For callback memory access instrumentation: hwasan-match-all-tag check is not implemented in `__hwasan_load`/`__hwasan_store`.
This patch implements a set of callback functions: `__hwasan_[load|store][1|2|4|8|16|n]_match_all` and `__hwasan_load[load|store][1|2|4|8|16|n]_match_all_noabort`, making hwasan-match-all-tag flag working for callback memory access instrumentation.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D149580
Tag selection for global variables is sequential, starting at a
pseduo-ish seed that's based on the hash of the file name.
Previously, it was possible for a global to be assigned a tag in the
range [1,15]. If the global's size was not a multiple of granules (i.e.
`size % 16 != 0`), then the last granule of the global would be assigned
a short granule tag as well.
If the real memory tag of the global (e.g. '04') happened to collide
with the short granule tag (e.g. '04'), then __hwasan_check would
see that the memory tag matched the short granule tag, and dutifully
assume (in this fast check) that everthing is okay.
Unfortunately, if you tried to access the [5,15]th byte, you never get
to the short granule check. This means you miss intra-granule overflows
on the last granule of a global, if said global was assigned a real
memory tag in the range [1,15].
This causes flakiness in certain global tests, if the SHA of the
filename changes between runs.
This problem also exists for heap and stack allocations as well, but
there's a concern that if we exclude the [1,15] range for heap and stack
that it's an unhappy tradeoff. On Android, this would mean that a 1/255
chance of false positive becomes 1/240. On other platforms though (that
have a less-than-8-bit tag space), this may be unacceptable. We can
think about potential fixes for that in other places, but globals are
fine to reduce the space, as really the only thing that matters is
catching sequential overflow. The false-negative scenario is much, much
more common in use-after-free and use-after-scope, which globals don't
have.
Differential Revision: https://reviews.llvm.org/D150742
This is folloup to b5595836, which missed the
Replacemen variable.
Before b5595836 the code assumed that alloca
ptrs are not tagged so tagging is implemented
as simple OR.
So this patch completes support of tagged SP
by passing untagged alloca pointers into
tagPointer.
If stack was allocated using regular allocator, it may be tagged
and it will make memToShadow calculate invalid offset.
Also when UAR tag should be the tag of the stack frame pointer.
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D149228
This is leftover from older version of HWASAN.
The current HWASAN assumes that the new stack
frames are tagged with zeroes, which make getNextTagWithCall
or StackTag ^ TagMaskByte unusable.
Reviewed By: kstoimenov, eugenis
Differential Revision: https://reviews.llvm.org/D149220
This is a mechanical prep change for scalable vector support. All it does is move the point of TypeSize to unsigned (i.e. the unsafe cast) closer to point of use.
as the bits are all distinct, these two operations have the same result,
but the bitwise operation is more explicit about what's happening.
Reviewed By: hctim
Differential Revision: https://reviews.llvm.org/D140346
now with the fixed warning and updated lit tests
---
[RISC-V][HWASAN] Add support for HWASAN code instrumentation for RISC-V
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D131575
