Compare commits

..

7 Commits

2 changed files with 53 additions and 28 deletions
+24 -11
View File
@@ -84,8 +84,22 @@ int main()
"## Overview\n" "## Overview\n"
"\n" "\n"
"ASAN provides a way to manually markup ranges of bytes to\n" "ASAN provides a way to manually markup ranges of bytes to\n"
"prohibit or permit reads to those addresses. There's a short\n" "prohibit or permit reads to those addresses. In\n"
"foot-note in Google's " "`<sanitizer/asan_interface.h>` there's a vague brief mention to\n"
"alignment requirements for the poison API:\n"
"\n"
"```cpp\n"
"/// ... This function is not guaranteed to poison the entire region -\n"
"/// it could poison only a subregion of <c>[addr, addr+size)</c> due to ASan\n"
"/// alignment restrictions.\n"
"void __asan_poison_memory_region(void const volatile *addr, size_t size);\n"
"\n"
"/// ... This function could unpoison a super-region of <c>[addr, addr+size)</c> due\n"
"/// to ASan alignment restrictions.\n"
"void __asan_unpoison_memory_region(void const volatile *addr, size_t size);\n"
"```\n"
"\n"
"There's another small foot-note in Google's "
"[AddressSanitizerManualPoisoning](https://github.com/google/" "[AddressSanitizerManualPoisoning](https://github.com/google/"
"sanitizers/wiki/AddressSanitizerManualPoisoning)\n" "sanitizers/wiki/AddressSanitizerManualPoisoning)\n"
"documentation that states:\n" "documentation that states:\n"
@@ -97,25 +111,24 @@ int main()
"chunks should start with 8-aligned addresses.\n" "chunks should start with 8-aligned addresses.\n"
"```\n" "```\n"
"\n" "\n"
"This repository runs some simple tests to clarify the behaviour of\n" "So then this repository runs some simple tests to clarify the behaviour\n"
"the API on un/aligned addresses at various sizes without having\n" "of the API on un/aligned addresses at various sizes without having\n"
"to dig into source code or read the [ASAN paper](https://static." "to dig into source code or read the [ASAN paper](https://static."
"googleusercontent.com/media/research.google.com/en/pubs/archive/" "googleusercontent.com/media/research.google.com/en/pubs/archive/"
"37752.pdf).\n" "37752.pdf).\n"
"\n" "\n"
"We use a stack-allocated 16 byte array and test un/poisoning\n" "We use a stack-allocated 16 byte array and test un/poisoning\n"
"various ranges of bytes from different alignments to clarify the\n" "various ranges of bytes from different alignments to clarify the\n"
"poisoning behaviour of the API.\n" "poisoning behaviour of the API. This reveals that calling the API\n"
"\n" "haphazardly, unaligned or straddling boundaries can lead to gaps in\n"
"This reveals that calling the API haphazardly, unaligned or\n" "poisoned memory and hide potential leaks (as also demonstrated in\n"
"straddling boundaries can lead to gaps in poisoned memory and hide\n" "[Manual ASAN poisoning and alignment]"
"potential leaks (as also demonstrated in [Manual ASAN poisoning and\n" "(https://github.com/mcgov/asan_alignment_example)).\n"
"alignment](https://github.com/mcgov/asan_alignment_example)).\n"
"\n" "\n"
"## References\n" "## References\n"
"\n" "\n"
"- [Manual ASAN poisoning and alignment](https://github.com/mcgov/asan_alignment_example) example by `mcgov`\n" "- [Manual ASAN poisoning and alignment](https://github.com/mcgov/asan_alignment_example) example by `mcgov`\n"
"- [Address Sanitizer: A Fast Address Sanity Checker](https://static.googleusercontent.com/media/research.google.com/en/pubs/archive/37752.pdf)\n" "- [Address Sanitizer: A Fast Address Sanity Checker](https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/37752.pdf)\n"
"- [sanitizer/asan_interface.h](https://github.com/llvm-mirror/compiler-rt/blob/master/include/sanitizer/asan_interface.h)\n" "- [sanitizer/asan_interface.h](https://github.com/llvm-mirror/compiler-rt/blob/master/include/sanitizer/asan_interface.h)\n"
"\n" "\n"
"## Raw Test Results\n" "## Raw Test Results\n"
+29 -17
View File
@@ -25,8 +25,22 @@ marked-up memory that may lead to undetected read/writes.
## Overview ## Overview
ASAN provides a way to manually markup ranges of bytes to ASAN provides a way to manually markup ranges of bytes to
prohibit or permit reads to those addresses. There's a short prohibit or permit reads to those addresses. In
foot-note in Google's [AddressSanitizerManualPoisoning](https://github.com/google/sanitizers/wiki/AddressSanitizerManualPoisoning) `<sanitizer/asan_interface.h>` there's a vague brief mention to
alignment requirements for the poison API:
```cpp
/// ... This function is not guaranteed to poison the entire region -
/// it could poison only a subregion of <c>[addr, addr+size)</c> due to ASan
/// alignment restrictions.
void __asan_poison_memory_region(void const volatile *addr, size_t size);
/// ... This function could unpoison a super-region of <c>[addr, addr+size)</c> due
/// to ASan alignment restrictions.
void __asan_unpoison_memory_region(void const volatile *addr, size_t size);
```
There's another small foot-note in Google's [AddressSanitizerManualPoisoning](https://github.com/google/sanitizers/wiki/AddressSanitizerManualPoisoning)
documentation that states: documentation that states:
``` ```
@@ -36,32 +50,30 @@ of memory leaving poisoned redzones between them. The allocated
chunks should start with 8-aligned addresses. chunks should start with 8-aligned addresses.
``` ```
This repository runs some simple tests to clarify the behaviour of So then this repository runs some simple tests to clarify the behaviour
the API on un/aligned addresses at various sizes without having of the API on un/aligned addresses at various sizes without having
to dig into source code or read the [ASAN paper](https://static.googleusercontent.com/media/research.google.com/en/pubs/archive/37752.pdf). to dig into source code or read the [ASAN paper](https://static.googleusercontent.com/media/research.google.com/en/pubs/archive/37752.pdf).
We use a stack-allocated 16 byte array and test un/poisoning We use a stack-allocated 16 byte array and test un/poisoning
various ranges of bytes from different alignments to clarify the various ranges of bytes from different alignments to clarify the
poisoning behaviour of the API. poisoning behaviour of the API. This reveals that calling the API
haphazardly, unaligned or straddling boundaries can lead to gaps in
This reveals that calling the API haphazardly, unaligned or poisoned memory and hide potential leaks (as also demonstrated in
straddling boundaries can lead to gaps in poisoned memory and hide [Manual ASAN poisoning and alignment](https://github.com/mcgov/asan_alignment_example)).
potential leaks (as also demonstrated in [Manual ASAN poisoning and
alignment](https://github.com/mcgov/asan_alignment_example) example
by `mcgov`.
## References ## References
- [Manual ASAN poisoning and alignment](https://github.com/mcgov/asan_alignment_example) example by `mcgov` - [Manual ASAN poisoning and alignment](https://github.com/mcgov/asan_alignment_example) example by `mcgov`
- [Address Sanitizer: A Fast Address Sanity Checker](https://static.googleusercontent.com/media/research.google.com/en/pubs/archive/37752.pdf) - [Address Sanitizer: A Fast Address Sanity Checker](https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/37752.pdf)
- [sanitizer/asan_interface.h](https://github.com/llvm-mirror/compiler-rt/blob/master/include/sanitizer/asan_interface.h) - [sanitizer/asan_interface.h](https://github.com/llvm-mirror/compiler-rt/blob/master/include/sanitizer/asan_interface.h)
## Raw Test Results ## Raw Test Results
Here we demonstrate that ASAN poison-ing will only poison the
byte region if the region meets an 8 byte boundary. It will only Here we poison a sliding window of 7 bytes to demonstrate that ASAN
poison bytes upto the 8 byte boundary, any bytes that straddle poisoning will only poison the byte region if the region meets an 8
the boundary that do not hit the next 8 byte boundary are not byte aligned address. It will only poison bytes up to the boundary,
poison-ed. any bytes that straddle the boundary that do not hit the next 8 byte
boundary are not poisoned.
``` ```
Byte Array 00 01 02 03 04 05 06 07 | 08 09 10 11 12 13 14 15 Byte Array 00 01 02 03 04 05 06 07 | 08 09 10 11 12 13 14 15