Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
The reason it was done this way was that what looks like a short granule might not be one - sometimes a low tag value is simply a low tag value, and the last byte of the granule is user memory that can match by chance.
On the other hand, the chance of that happening is very low and perhaps this is a good tradeoff for better report quality.
compiler-rt/test/hwasan/TestCases/heap-buffer-overflow-into.c | ||
---|---|---|
16 | why offset 10 and not 5? |
compiler-rt/test/hwasan/TestCases/heap-buffer-overflow-into.c | ||
---|---|---|
16 | The first 5 bytes, [5, 10) are the valid access, and the invalid one is [10, 26). |
isn't the chance of this lower than a normal tag matching by accident (also producing an incorrect report)? The chance of this should be (16 / 256) * (1 / 256).
compiler-rt/test/hwasan/TestCases/heap-buffer-overflow-into.c | ||
---|---|---|
16 | Sorry, my mistake, replied too fast. Will look tomorrow. |
isn't the chance of this lower than a normal tag matching by accident (also producing an incorrect report)? The chance of this should be (16 / 256) * (1 / 256).
Right, we can find an unrelated alloc/dealloc stack trace because of an accidental tag match. That happens.
compiler-rt/test/hwasan/TestCases/heap-buffer-overflow-into.c | ||
---|---|---|
16 | Fixed. Sorry about that, added second test as well. |
compiler-rt/lib/hwasan/hwasan_report.cpp | ||
---|---|---|
710 | Is this really different from ShadowToMem(tag_ptr) ? But if I read __hwasan_test_shadow correctly, (untagged_addr + offset) must be granule-aligned already. |
compiler-rt/lib/hwasan/hwasan_report.cpp | ||
---|---|---|
710 |
I wrote it this way so it's easy to see I am separating the low from the high bits from this and the line below.
Done.
There is the edge case where offset == 0, then untagged_addr + offset is not necessarily aligned. |
compiler-rt/lib/hwasan/hwasan_report.cpp | ||
---|---|---|
716 | This line assumes that the first bad access has to be 1 byte past the end. What if ex. the short granule is 5 byte in size, and the access is for offsets [10, 12) ? |
Please add a test where the bad access starts after the end of the allocation.
LGTM with that and the other comments.
compiler-rt/lib/hwasan/hwasan_report.cpp | ||
---|---|---|
709 | call it "granule_ptr" or something like that. | |
713 | "this is the offset of the leftmost accessed byte within the bad granule" or something more literate. I.e. it's not the bad address, it's the start of the accessed ranged clamped to the granule bounds. | |
718 | "if the access starts after the end of the short granule, then the first bad byte is the first byte of the access; otherwise it is the first byte past the end of the short granule" or something like that in your own words. This is not really obvious from the code. | |
compiler-rt/test/hwasan/TestCases/heap-buffer-overflow-into.c | ||
23 | I was really confused why the size is 10 until I realized that in "%t 5 2>&1" 2 is the file descriptor and not the argument. Please make all arguments explicit in the command lines and remove the argc checks (or rather turn them into asserts). |
Probably caused by this patch https://lab.llvm.org/buildbot/#/builders/77/builds/7379
(untested) maybe broke the x64 LAM under QEMU bot: https://lab.llvm.org/buildbot/#/builders/169/builds/1199/steps/25/logs/stdio
call it "granule_ptr" or something like that.