From: Kostya Serebryany Date: Wed, 14 Mar 2018 01:55:49 +0000 (+0000) Subject: [hwasan] update docs X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=e5f2c8657c646d5ddf8ccebcd26d7e6cb7c07715;p=clang [hwasan] update docs git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@327471 91177308-0d34-0410-b5e6-96231b3b80d8 --- diff --git a/docs/HardwareAssistedAddressSanitizerDesign.rst b/docs/HardwareAssistedAddressSanitizerDesign.rst index 71a9df1017..06e5a435e9 100644 --- a/docs/HardwareAssistedAddressSanitizerDesign.rst +++ b/docs/HardwareAssistedAddressSanitizerDesign.rst @@ -7,8 +7,6 @@ This page is a design document for a tool similar to :doc:`AddressSanitizer`, but based on partial hardware assistance. -The document is a draft, suggestions are welcome. - Introduction ============ @@ -30,15 +28,16 @@ accuracy guarantees. Algorithm ========= -* Every heap/stack/global memory object is forcibly aligned by `N` bytes - (`N` is e.g. 16 or 64). We call `N` the **granularity** of tagging. -* For every such object a random `K`-bit tag `T` is chosen (`K` is e.g. 4 or 8) +* Every heap/stack/global memory object is forcibly aligned by `TG` bytes + (`TG` is e.g. 16 or 64). We call `TG` the **tagging granularity**. +* For every such object a random `TS`-bit tag `T` is chosen (`TS`, or tag size, is e.g. 4 or 8) * The pointer to the object is tagged with `T`. -* The memory for the object is also tagged with `T` - (using a `N=>1` shadow memory) +* The memory for the object is also tagged with `T` (using a `TG=>1` shadow memory) * Every load and store is instrumented to read the memory tag and compare it with the pointer tag, exception is raised on tag mismatch. +For a more detailed discussion of this approach see https://arxiv.org/pdf/1802.09517.pdf + Instrumentation =============== @@ -59,8 +58,8 @@ verifies the tags. Currently, the following sequence is used: c: 3f 01 08 6b cmp w9, w8 // compare tags 10: 61 00 00 54 b.ne #12 // jump on mismatch 14: 00 00 40 b9 ldr w0, [x0] // original load - 18: c0 03 5f d6 ret - 1c: 40 20 40 d4 hlt #0x102 // halt + 18: c0 03 5f d6 ret + 1c: 40 20 21 d4 brk #0x902 // trap Alternatively, memory accesses are prefixed with a function call. @@ -69,14 +68,14 @@ Heap ---- Tagging the heap memory/pointers is done by `malloc`. -This can be based on any malloc that forces all objects to be N-aligned. +This can be based on any malloc that forces all objects to be TG-aligned. `free` tags the memory with a different tag. Stack ----- Stack frames are instrumented by aligning all non-promotable allocas -by `N` and tagging stack memory in function prologue and epilogue. +by `TG` and tagging stack memory in function prologue and epilogue. Tags for different allocas in one function are **not** generated independently; doing that in a function with `M` allocas would require @@ -131,15 +130,25 @@ HWASAN: https://www.kernel.org/doc/Documentation/arm64/tagged-pointers.txt). * **Does not require redzones to detect buffer overflows**, but the buffer overflow detection is probabilistic, with roughly - `(2**K-1)/(2**K)` probability of catching a bug. + `(2**TS-1)/(2**TS)` probability of catching a bug. * **Does not require quarantine to detect heap-use-after-free, or stack-use-after-return**. The detection is similarly probabilistic. The memory overhead of HWASAN is expected to be much smaller than that of AddressSanitizer: -`1/N` extra memory for the shadow -and some overhead due to `N`-aligning all objects. +`1/TG` extra memory for the shadow +and some overhead due to `TG`-aligning all objects. + +Supported architectures +======================= +HWASAN relies on `Address Tagging`_ which is only available on AArch64. +For other 64-bit architectures it is possible to remove the address tags +before every load and store by compiler instrumentation, but this variant +will have limited deployability since not all of the code is +typically instrumented. + +The HWASAN's approach is not applicable to 32-bit architectures. Related Work