Add Safe-Linking to Single-Linked-Lists (SLL) #1
Comments
|
Resolved my build issue, and sent it as pull request #19 . |
copybara-service bot
pushed a commit
that referenced
this issue
Sep 5, 2023
Asan says:
==2416==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7ffd820085c0 at pc 0x7f763ef6555a bp 0x7f7577efc770 sp 0x7f7577efc768
READ of size 4 at 0x7ffd820085c0 thread T17
#0 0x7f763ef65559 in operator() testing/heap_profiling_test.cc:75:40
#1 0x7f763ef65559 in __invoke<(lambda at testing/heap_profiling_test.cc:74:22) &, int> invoke.h:340:25
...
Address 0x7ffd820085c0 is located in stack of thread T0 at offset 384 in frame
#0 0x7f763ef64f1f in tcmalloc::(anonymous namespace)::HeapProfilingTest_GetHeapProfileWhileAllocAndDealloc_Test::TestBody() testing/heap_profiling_test.cc:57
This frame has 6 object(s):
[64, 192) 'harness' (line 61)
[224, 256) 'manager' (line 60)
[288, 320) 'ref.tmp' (line 64)
[352, 364) 'start' (line 66)
[384, 388) 't' (line 69) <== Memory access at offset 384 is inside this variable
[400, 432) 'ref.tmp11' (line 74)
PiperOrigin-RevId: 562765497
Change-Id: I5188c93725981b03683bdb0c550a87982a663127
copybara-service bot
pushed a commit
that referenced
this issue
Jun 10, 2024
…om Filter The Guarded Page Allocator (aka. GWP-ASan), currently implements a relatively complex policy to filter allocations based on previously covered stack traces. The current implementation of StackTraceFilter is a fixed-size cache, where the hash of a stack trace is used to look up the entry count since the last eviction; evictions occur if different stack trace hashes map to the same cache entry, but otherwise explicit removals are not possible. The properties of this policy are difficult to reason about, and it is unclear if some of these requirements are met: 1. Prevent the pool from filling up with the same frequent or long-lived allocations: Due to the unpredictability of evictions on stack trace entry collisions, there is no guarantee that the pool will not fill up with allocations of the same source. This problem is most likely to manifest on large long-running services. 2. Ensure that GWP-ASan keeps sampling allocations (depends on #1): Since the cache has no explicit removals, once the StackTraceFilter contains all allocation stack traces possible for a program, the current policy will simply stop sampling altogether (see the "max per stack" case of the old policy). The current policy crucially relies on evictions to take place to keep sampling. This problem is most likely to manifest on small programs, such as tests. While the above are necessary properties to keep GWP-ASan working, the policy was introduced primarily to achieve this requirement: 3. Achieve diverse set of covered allocations: The current solution overfits towards rare allocations, although it is unclear to what extent due to the unpredictability of when evictions may occur. We argue that achieving requirement #3 is satisfied when both #1 and #2 are satisfied: one of GWP-ASan's main design principles is that with increasing total allocations sampled (across a fleet of machines), allocation coverage increases sufficiently to detect previously undetected bugs. In general, we know that coverage (esp. at the level available to us here) is a bad metric [1] to predict if we covered enough: we are looking for an unknown population of bugs, and recent coverage of an allocation of a given source does not provide any strong indicators that subsequent sampling of an allocation of the same source finds fewer bugs. [1] "Coverage is not strongly correlated with test suite effectiveness", https://dl.acm.org/doi/10.1145/2568225.2568271 This change simplifies the allocation filtering logic to achieve #1 and #2 with more predictable runtime properties: A. StackTraceFilter is changed to implement a thread-safe Counting Bloom Filter. A major benefit is that it allows to (a) choose parameters to achieve desirable false positive probabilities, and (b) allow for removals (by decrementing). The parameters for GuardedPageAllocator are chosen to give us relatively low false positive probabilities (10-20%) even in cases with a very diverse set of allocations in the GPA pool. See code comments for details. On top of that, DecayingStackTraceFilter adds ring-buffer based decaying of the Bloom Filter, which allows to further filter recent allocations, but will allow GWP-ASan to keep allocating if it only sees the same allocations over and over (they always eventually decay). On deallocation, an entry is now removed from the filter, which will help satisfy requirement #2: after deallocation and decaying of all same-source allocations, subsequent allocations of the same source are allowed to happen again. B. GuardedPageAllocator will filter an allocation that is currently or recently covered (i.e. currently in the pool or not yet decayed) with a probability that increases proportionally with pool utilization. Once the pool reaches more than 50% utilization, all currently or recently covered allocations will always be filtered on repeated allocation attempts. This will help satisfy requirements #1. Overall, the new implementation is simpler and easier to reason about. The implementation is based on what is implemented in Linux's KFENCE: https://lore.kernel.org/all/20210923104803.2620285-4-elver@google.com/ PiperOrigin-RevId: 641968555 Change-Id: Ie73bf5b06ce65fb42667e28c69f09daca0ea395e
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I found this repository by following this link from gperftools, and now I don't really know what to do with my pull request that was sent to gperftools what I thought it is the public implementation of TCMalloc.
tl;dr - Safe-Linking is a security feature that I added on top of the Single-Linked-Lists (SLL). It is similar to the existing
maskPtr()functionality that was added to Chrome's TCMalloc implementation by Chrome's security team in 2012. Safe-Linking (as a concept) is now in the process of also being merged into GLIBC's ptmalloc implementation, and also uClibc's dlmalloc implementation.I was hoping that this security enhancement feature could be integrated in TCMalloc to help prevent attacks, as is detailed fully in the my white-paper that could be found on the original pull request. The benchmarking results for all of the different heap implementations are very encouraging, and according to gperftool's benchmarking they are 0.02% for the average test and 1.5% for the worst test case.
This feature was already implemented for gperftools and sent as a pull request, including the CLA and everything. Could you check if you could integrate it into your implementation as well? I didn't send a new pull request as the changes to my original pull request seem minor and I am having trouble to setup your dev environment on my computer...
The text was updated successfully, but these errors were encountered: