[
https://issues.apache.org/jira/browse/DISPATCH-2039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiri Daněk updated DISPATCH-2039:
---------------------------------
Description:
>From https://github.com/google/sanitizers/wiki/AddressSanitizerManualPoisoning
bq. A user may poison/unpoison a region of memory manually. Use this feature
with caution. In many cases good old malloc+free is a better way to find heap
bugs than using custom allocators with manual poisoning.
As far as I can tell, it is nowadays not possible to turn off the pool
allocation and use malloc/free, because the pool mechanism also implements the
weak pointers and ref counters. That means giving hints to ASAN is the only way
to discover memory bugs of the type (if what Chuck speculated is true) of
DISPATCH-2032.
bq. If you have a custom allocation arena, the typical workflow would be to
poison the entire arena first, and then unpoison allocated chunks of memory
leaving poisoned redzones between them. The allocated chunks should start with
8-aligned addresses.
Alternatively, the current memory debugging machinery for the pool could take
care of it on its own... but using ASAN seems sensible to me.
http://blog.hostilefork.com/poison-memory-without-asan/
h3. Nice to have extra features (which won't be implemented at first)
* redzones, there should be chunks of poison on either end of a returned
memory, to detect invalid accesses out of bounds; this means deliberate waste
of memory (I am thinking 3x increase, to make implementation easy)
* quarantine, returned chunks should be kept in the pool for some time before
they are returned as new allocations, to catch use-after-free; this policy goes
against performance considerations
h3. Open issues
Is it necessary to lock around the poison macros? I did not understand the
thread safety note in API comment fully.
h3. One thought
Actually, setting a limit on free_list length == 0 would effectively disable
pool and turn the calls into simple wrappers over malloc/free. It would be
enough to make this configurable at build time. Then asan should work just fine
without poison.
was:
>From https://github.com/google/sanitizers/wiki/AddressSanitizerManualPoisoning
bq. A user may poison/unpoison a region of memory manually. Use this feature
with caution. In many cases good old malloc+free is a better way to find heap
bugs than using custom allocators with manual poisoning.
As far as I can tell, it is nowadays not possible to turn off the pool
allocation and use malloc/free, because the pool mechanism also implements the
weak pointers and ref counters. That means giving hints to ASAN is the only way
to discover memory bugs of the type (if what Chuck speculated is true) of
DISPATCH-2032.
bq. If you have a custom allocation arena, the typical workflow would be to
poison the entire arena first, and then unpoison allocated chunks of memory
leaving poisoned redzones between them. The allocated chunks should start with
8-aligned addresses.
Alternatively, the current memory debugging machinery for the pool could take
care of it on its own... but using ASAN seems sensible to me.
http://blog.hostilefork.com/poison-memory-without-asan/
h3. Nice to have extra features (which won't be implemented at first)
* redzones, there should be chunks of poison on either end of a returned
memory, to detect invalid accesses out of bounds; this means deliberate waste
of memory (I am thinking 3x increase, to make implementation easy)
* quarantine, returned chunks should be kept in the pool for some time before
they are returned as new allocations, to catch use-after-free; this policy goes
against performance considerations
h3. Open issues
Is it necessary to lock around the poison macros? I did not understand the
thread safety note in API comment fully.
> Memory pool should be manually poisoned so that ASAN works with it
> ------------------------------------------------------------------
>
> Key: DISPATCH-2039
> URL: https://issues.apache.org/jira/browse/DISPATCH-2039
> Project: Qpid Dispatch
> Issue Type: Wish
> Affects Versions: 1.15.0
> Reporter: Jiri Daněk
> Priority: Minor
>
> From https://github.com/google/sanitizers/wiki/AddressSanitizerManualPoisoning
> bq. A user may poison/unpoison a region of memory manually. Use this feature
> with caution. In many cases good old malloc+free is a better way to find heap
> bugs than using custom allocators with manual poisoning.
> As far as I can tell, it is nowadays not possible to turn off the pool
> allocation and use malloc/free, because the pool mechanism also implements
> the weak pointers and ref counters. That means giving hints to ASAN is the
> only way to discover memory bugs of the type (if what Chuck speculated is
> true) of DISPATCH-2032.
> bq. If you have a custom allocation arena, the typical workflow would be to
> poison the entire arena first, and then unpoison allocated chunks of memory
> leaving poisoned redzones between them. The allocated chunks should start
> with 8-aligned addresses.
> Alternatively, the current memory debugging machinery for the pool could take
> care of it on its own... but using ASAN seems sensible to me.
> http://blog.hostilefork.com/poison-memory-without-asan/
> h3. Nice to have extra features (which won't be implemented at first)
> * redzones, there should be chunks of poison on either end of a returned
> memory, to detect invalid accesses out of bounds; this means deliberate waste
> of memory (I am thinking 3x increase, to make implementation easy)
> * quarantine, returned chunks should be kept in the pool for some time before
> they are returned as new allocations, to catch use-after-free; this policy
> goes against performance considerations
> h3. Open issues
> Is it necessary to lock around the poison macros? I did not understand the
> thread safety note in API comment fully.
> h3. One thought
> Actually, setting a limit on free_list length == 0 would effectively disable
> pool and turn the calls into simple wrappers over malloc/free. It would be
> enough to make this configurable at build time. Then asan should work just
> fine without poison.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
