CCaslyn Tonelli[gwp_asan] Exclude recoverable tests on Fuchsia
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[GWP-ASan] Handle wild touches of the guarded pool. AllocMeta could be null when returned from __gwp_asan_get_metadata() for a bad access into the GuardedPagePool that was never allocated. Currently, then we dereference the null pointer, oops. Hoist the check up and print a message (only once in recoverable mode) about the bad memory access. Reviewed By: fmayer Differential Revision: https://reviews.llvm.org/D144973 | 3 年前 | |
[GWP-ASan] Fix atfork handlers being installed multiple times in tests We incorrectly install the atfork handlers multiple times in the test harness, tracked down to the default parameter used by CheckLateInitIsOK. This manifested in a hang if running the tests with --gtest_repeat={>=2} as the atfork handler ran multiple times, causing double-lock and double-unlock, which on my machine hung. Add a check-fail for this case as well to prevent this from happening again (it was difficult to track down and is an easy mistake to make). Differential Revision: https://reviews.llvm.org/D139731 | 3 年前 | |
[compiler-rt] Use portable "#!/usr/bin/env bash" shebang for tests. In build_symbolizer.sh we can safely remove the -eu argument from the shebang (which is an unportable construct), as the scripts sets **-e** and **-u** already. Differential Revision: https://reviews.llvm.org/D110039 | 4 年前 | |
[gwp_asan] Exclude recoverable tests on Fuchsia Signal handlers used by recoverable tests are unsupported on Fuchsia. Exclude the set of tests that test recoverable code paths (i.e. BacktraceGuardedPoolAllocator tests in recoverable.cpp) and always set the Recoverable testing bool to false on the Fuchsia platform. Differential Revision: https://reviews.llvm.org/D149311 | 3 年前 | |
[sanitizer] Fix for CMAKE_CXX_FLAGS update With unquoted ${CMAKE_CXX_FLAGS}, the REGEX fails when it's empty: CMake Error at lib/scudo/standalone/CMakeLists.txt:14 (string): string sub-command REGEX, mode REPLACE needs at least 6 arguments total to command. | 4 年前 | |
Reland: [GWP-ASan] Add recoverable mode. The GWP-ASan recoverable mode allows a process to continue to function after a GWP-ASan error is detected. The error will continue to be dumped, but GWP-ASan now has APIs that a signal handler (like the example optional crash handler) can call in order to allow the continuation of a process. When an error occurs with an allocation, the slot used for that allocation will be permanently disabled. This means that free() of that pointer is a no-op, and use-after-frees will succeed (writing and reading the data present in the page). For heap-buffer-overflow/underflow, the guard page is marked as accessible and buffer-overflows will succeed (writing and reading the data present in the now-accessible guard page). This does impact adjacent allocations, buffer-underflow and buffer-overflows from adjacent allocations will no longer touch an inaccessible guard page. This could be improved in future by having two guard pages between each adjacent allocation, but that's out of scope of this patch. Each allocation only ever has a single error report generated. It's whatever came first between invalid-free, double-free, use-after-free or heap-buffer-overflow, but only one. Reviewed By: eugenis, fmayer Differential Revision: https://reviews.llvm.org/D140173 | 3 年前 | |
Reland: [GWP-ASan] Add recoverable mode. The GWP-ASan recoverable mode allows a process to continue to function after a GWP-ASan error is detected. The error will continue to be dumped, but GWP-ASan now has APIs that a signal handler (like the example optional crash handler) can call in order to allow the continuation of a process. When an error occurs with an allocation, the slot used for that allocation will be permanently disabled. This means that free() of that pointer is a no-op, and use-after-frees will succeed (writing and reading the data present in the page). For heap-buffer-overflow/underflow, the guard page is marked as accessible and buffer-overflows will succeed (writing and reading the data present in the now-accessible guard page). This does impact adjacent allocations, buffer-underflow and buffer-overflows from adjacent allocations will no longer touch an inaccessible guard page. This could be improved in future by having two guard pages between each adjacent allocation, but that's out of scope of this patch. Each allocation only ever has a single error report generated. It's whatever came first between invalid-free, double-free, use-after-free or heap-buffer-overflow, but only one. Reviewed By: eugenis, fmayer Differential Revision: https://reviews.llvm.org/D140173 | 3 年前 | |
Reland: [GWP-ASan] Add recoverable mode. The GWP-ASan recoverable mode allows a process to continue to function after a GWP-ASan error is detected. The error will continue to be dumped, but GWP-ASan now has APIs that a signal handler (like the example optional crash handler) can call in order to allow the continuation of a process. When an error occurs with an allocation, the slot used for that allocation will be permanently disabled. This means that free() of that pointer is a no-op, and use-after-frees will succeed (writing and reading the data present in the page). For heap-buffer-overflow/underflow, the guard page is marked as accessible and buffer-overflows will succeed (writing and reading the data present in the now-accessible guard page). This does impact adjacent allocations, buffer-underflow and buffer-overflows from adjacent allocations will no longer touch an inaccessible guard page. This could be improved in future by having two guard pages between each adjacent allocation, but that's out of scope of this patch. Each allocation only ever has a single error report generated. It's whatever came first between invalid-free, double-free, use-after-free or heap-buffer-overflow, but only one. Reviewed By: eugenis, fmayer Differential Revision: https://reviews.llvm.org/D140173 | 3 年前 | |
Reland: [GWP-ASan] Add recoverable mode. The GWP-ASan recoverable mode allows a process to continue to function after a GWP-ASan error is detected. The error will continue to be dumped, but GWP-ASan now has APIs that a signal handler (like the example optional crash handler) can call in order to allow the continuation of a process. When an error occurs with an allocation, the slot used for that allocation will be permanently disabled. This means that free() of that pointer is a no-op, and use-after-frees will succeed (writing and reading the data present in the page). For heap-buffer-overflow/underflow, the guard page is marked as accessible and buffer-overflows will succeed (writing and reading the data present in the now-accessible guard page). This does impact adjacent allocations, buffer-underflow and buffer-overflows from adjacent allocations will no longer touch an inaccessible guard page. This could be improved in future by having two guard pages between each adjacent allocation, but that's out of scope of this patch. Each allocation only ever has a single error report generated. It's whatever came first between invalid-free, double-free, use-after-free or heap-buffer-overflow, but only one. Reviewed By: eugenis, fmayer Differential Revision: https://reviews.llvm.org/D140173 | 3 年前 | |
[GWP-ASan] Cleanup (NFC) Cleaning up some of the GWP-ASan code base: - lots of headers didn't have the correct file name - adding #ifdef guard to utilities.h - correcting an #ifdef guard based on actual file name - removing an extra ; - clang-format'ing the code (-style=llvm) Differential Revision: https://reviews.llvm.org/D89721 | 5 年前 | |
Reland: [GWP-ASan] Add recoverable mode. The GWP-ASan recoverable mode allows a process to continue to function after a GWP-ASan error is detected. The error will continue to be dumped, but GWP-ASan now has APIs that a signal handler (like the example optional crash handler) can call in order to allow the continuation of a process. When an error occurs with an allocation, the slot used for that allocation will be permanently disabled. This means that free() of that pointer is a no-op, and use-after-frees will succeed (writing and reading the data present in the page). For heap-buffer-overflow/underflow, the guard page is marked as accessible and buffer-overflows will succeed (writing and reading the data present in the now-accessible guard page). This does impact adjacent allocations, buffer-underflow and buffer-overflows from adjacent allocations will no longer touch an inaccessible guard page. This could be improved in future by having two guard pages between each adjacent allocation, but that's out of scope of this patch. Each allocation only ever has a single error report generated. It's whatever came first between invalid-free, double-free, use-after-free or heap-buffer-overflow, but only one. Reviewed By: eugenis, fmayer Differential Revision: https://reviews.llvm.org/D140173 | 3 年前 | |
Reland: [GWP-ASan] Add recoverable mode. The GWP-ASan recoverable mode allows a process to continue to function after a GWP-ASan error is detected. The error will continue to be dumped, but GWP-ASan now has APIs that a signal handler (like the example optional crash handler) can call in order to allow the continuation of a process. When an error occurs with an allocation, the slot used for that allocation will be permanently disabled. This means that free() of that pointer is a no-op, and use-after-frees will succeed (writing and reading the data present in the page). For heap-buffer-overflow/underflow, the guard page is marked as accessible and buffer-overflows will succeed (writing and reading the data present in the now-accessible guard page). This does impact adjacent allocations, buffer-underflow and buffer-overflows from adjacent allocations will no longer touch an inaccessible guard page. This could be improved in future by having two guard pages between each adjacent allocation, but that's out of scope of this patch. Each allocation only ever has a single error report generated. It's whatever came first between invalid-free, double-free, use-after-free or heap-buffer-overflow, but only one. Reviewed By: eugenis, fmayer Differential Revision: https://reviews.llvm.org/D140173 | 3 年前 | |
[GWP-ASan] IWYU & clang-format Run an IWYU pass and clang-format GWP-ASan code. Reviewed By: eugenis, mcgrathr Differential Revision: https://reviews.llvm.org/D92688 | 5 年前 | |
[GWP-ASan] Crash Handler API. Summary: Forewarning: This patch looks big in #LOC changed. I promise it's not that bad, it just moves a lot of content from one file to another. I've gone ahead and left inline comments on Phabricator for sections where this has happened. This patch: 1. Introduces the crash handler API (crash_handler_api.h). 2. Moves information required for out-of-process crash handling into an AllocatorState. This is a trivially-copied POD struct that designed to be recovered from a deceased process, and used by the crash handler to create a GWP-ASan report (along with the other trivially-copied Metadata struct). 3. Implements the crash handler API using the AllocatorState and Metadata. 4. Adds tests for the crash handler. 5. Reimplements the (now optionally linked by the supporting allocator) in-process crash handler (i.e. the segv handler) using the new crash handler API. 6. Minor updates Scudo & Scudo Standalone to fix compatibility. 7. Changed capitalisation of errors (e.g. /s/Use after free/Use After Free). Reviewers: cryptoad, eugenis, jfb Reviewed By: eugenis Subscribers: merge_guards_bot, pcc, jfb, dexonsmith, mgorny, cryptoad, #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D73557 | 6 年前 | |
Reland: [GWP-ASan] Add recoverable mode. The GWP-ASan recoverable mode allows a process to continue to function after a GWP-ASan error is detected. The error will continue to be dumped, but GWP-ASan now has APIs that a signal handler (like the example optional crash handler) can call in order to allow the continuation of a process. When an error occurs with an allocation, the slot used for that allocation will be permanently disabled. This means that free() of that pointer is a no-op, and use-after-frees will succeed (writing and reading the data present in the page). For heap-buffer-overflow/underflow, the guard page is marked as accessible and buffer-overflows will succeed (writing and reading the data present in the now-accessible guard page). This does impact adjacent allocations, buffer-underflow and buffer-overflows from adjacent allocations will no longer touch an inaccessible guard page. This could be improved in future by having two guard pages between each adjacent allocation, but that's out of scope of this patch. Each allocation only ever has a single error report generated. It's whatever came first between invalid-free, double-free, use-after-free or heap-buffer-overflow, but only one. Reviewed By: eugenis, fmayer Differential Revision: https://reviews.llvm.org/D140173 | 3 年前 | |
[GWP-ASan] Implement stack frame compression. Summary: This patch introduces stack frame compression to GWP-ASan. Each stack frame is variable-length integer encoded as the difference between frame[i] and frame[i - 1]. Furthermore, we use zig-zag encoding on the difference to ensure that negative differences are also encoded into a relatively small number of bytes. Examples of what the compression looks like can be seen in gwp_asan/tests/compression.cpp. This compression can reduce the memory consumption cost of stack traces by ~50%. Reviewers: vlad.tsyrklevich Reviewed By: vlad.tsyrklevich Subscribers: mgorny, #sanitizers, llvm-commits, eugenis, morehouse Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D66189 llvm-svn: 369048 | 6 年前 | |
[GWP-ASan] Implement stack frame compression. Summary: This patch introduces stack frame compression to GWP-ASan. Each stack frame is variable-length integer encoded as the difference between frame[i] and frame[i - 1]. Furthermore, we use zig-zag encoding on the difference to ensure that negative differences are also encoded into a relatively small number of bytes. Examples of what the compression looks like can be seen in gwp_asan/tests/compression.cpp. This compression can reduce the memory consumption cost of stack traces by ~50%. Reviewers: vlad.tsyrklevich Reviewed By: vlad.tsyrklevich Subscribers: mgorny, #sanitizers, llvm-commits, eugenis, morehouse Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D66189 llvm-svn: 369048 | 6 年前 | |
[GWP-ASan] Add aligned allocations. Adds a new allocation API to GWP-ASan that handles size+alignment restrictions. Reviewed By: cryptoad, eugenis Differential Revision: https://reviews.llvm.org/D94830 | 5 年前 |