Details
-
Task
-
Status: Stalled (View Workflow)
-
Major
-
Resolution: Unresolved
-
None
-
None
Description
Redzones are poisoned memory between all allocations from memory heaps. It uses more memory but catches buffer overflow and underflow.
Actually redzones could present if requested size is not a multiply of 8, because allocations size is aligned by 8. Obviously, it's not guaranteed.
As a bonus string-like and vector-like containers could be instrumented too. See here for example https://github.com/llvm-mirror/libcxx/blob/ab883e8c3b9fb281e5fe064784951c5addd5d11c/include/vector#L846
Attachments
Issue Links
- relates to
-
MDEV-19471 Add ASAN-poisoned redzones for mem_heap_t
-
- Closed
-
Activity
| Field | Original Value | New Value |
|---|---|---|
| Description |
Redzones are poisoned memory between all allocations from memory heaps. It uses more memory but catches buffer overflow and underflow.
Actually redzones could present if requested size is not a multiply of 8, because allocations size is aligned by 8. Obviously, it's not guaranteed. As a bonus string-like and vector-like containers could be instrumented too. |
Redzones are poisoned memory between all allocations from memory heaps. It uses more memory but catches buffer overflow and underflow.
Actually redzones could present if requested size is not a multiply of 8, because allocations size is aligned by 8. Obviously, it's not guaranteed. As a bonus string-like and vector-like containers could be instrumented too. See here for example https://github.com/llvm-mirror/libcxx/blob/ab883e8c3b9fb281e5fe064784951c5addd5d11c/include/vector#L846 |
| Assignee | Eugene Kosov [ kevg ] |
marko, yes. I even have a PR for this: https://github.com/MariaDB/server/pull/954
One more patch is needed for InnoDB.
| Summary | Add ASAN-poisoned redzones for MEM_ROOT and mem_heap_t | Add ASAN-poisoned redzones for MEM_ROOT |
| Link |
This issue relates to |
| Status | Open [ 1 ] | In Progress [ 3 ] |
| Assignee | Eugene Kosov [ kevg ] | Sergei Golubchik [ serg ] |
| Status | In Progress [ 3 ] | In Review [ 10002 ] |
| Fix Version/s | 5.5 [ 15800 ] | |
| Fix Version/s | 10.1 [ 16100 ] | |
| Fix Version/s | 10.2 [ 14601 ] | |
| Fix Version/s | 10.3 [ 22126 ] | |
| Fix Version/s | 10.4 [ 22408 ] |
| Status | In Review [ 10002 ] | Stalled [ 10000 ] |
| Fix Version/s | 5.5 [ 15800 ] |
| Fix Version/s | 10.1 [ 16100 ] |
| Workflow | MariaDB v3 [ 90822 ] | MariaDB v4 [ 131706 ] |
| Fix Version/s | 10.2 [ 14601 ] |
| Fix Version/s | 10.3 [ 22126 ] |
Consider a test case:
heap_t heap;my_class_t *c = NULL;{c->use();c->cleanup();}c->use();ASAN should bark on second c->use() but in general it won't because heap memory won't freed. It's partially solved with Sql_alloc but for classes only and not for stuff like THD::make_clex_string(). And it doesn't work at all for mem_heap_t.
We may store size_t with allocation length right before allocated chunk. This will serve as a redzone too.
dealloc_root() and mem_heap_dealloc() can be added. They will read allocated size from redzone and poison freed chunk. No real memory freeing.
This is simple to add but to make it really work those functions should be added to a lot of places in code. Like manual allocation pairs malloc()/free(). But I think one goal was to not call free() on every allocated chunk. Anyway, this is a C style.
C++ style is to create (in terms of C++17) a memory resources with will actually own memory. Examples are bulk allocator, thread-safe bulk allocator, static storage + heap. And allocator is a handler (pointer) to that resource. In that case poisoning of deallocated memory will happen in allocator_t::deallocate().