History log of /llvm-project/compiler-rt/lib/gwp_asan/guarded_pool_allocator.cpp (Results 1 – 25 of 36)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 11e12bd8 25-Jun-2024 Mitch Phillips <31459023+hctim@users.noreply.github.com>

[NFC] [GWP-ASan] Rename Check() to check() (#96605)

Change this function to be LLVM-style in name.


Revision tags: llvmorg-18.1.8
# 7adb7aa4 13-Jun-2024 Mitch Phillips <31459023+hctim@users.noreply.github.com>

[GWP-ASan] Various test fixes. (#94938)

When running some tests with --gtest_repeat=100 --gtest_shuffle, I
encountered some problems because the allocator wasn't torn down
completely, and the sing

[GWP-ASan] Various test fixes. (#94938)

When running some tests with --gtest_repeat=100 --gtest_shuffle, I
encountered some problems because the allocator wasn't torn down
completely, and the singleton pointer ended up pointing to a
use-after-scope'd object.

This patch has a couple of fixes and niceties:
1. Removing the once-init stuff from tests, now that it's implicitly
done in GuardedPoolAllocator::installAtFork() anyway.
2. Calling uninitTestOnly() in the late_init test.
3. Resetting the HasReportedBadPoolAccess when the signal handlers are
installed (allowing for --gtest_repeat w/ recoverable mode).
4. Adding a check and resetting the singleton pointer in
uninitTestOnly().

show more ...


Revision tags: llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init
# 35b5499d 13-Jan-2023 Mitch Phillips <31459023+hctim@users.noreply.github.com>

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

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

show more ...


# 7cc12cb6 12-Jan-2023 Mitch Phillips <31459023+hctim@users.noreply.github.com>

Revert "[GWP-ASan] Add recoverable mode."

This reverts commit 90a9beb7cc9755791caa23dfc4e36bc544e98ed3.

Reason: Broke an internal build.


Revision tags: llvmorg-15.0.7
# 90a9beb7 11-Jan-2023 Mitch Phillips <31459023+hctim@users.noreply.github.com>

[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

[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

show more ...


Revision tags: llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, working, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1
# 04f59133 27-Sep-2021 Kostya Kortchinsky <kostyak@google.com>

[gwp-asan] Initialize AllocatorVersionMagic at runtime

GWP-ASan's `AllocatorState` was recently extended with a
`AllocatorVersionMagic` structure required so that GWP-ASan bug reports
can be underst

[gwp-asan] Initialize AllocatorVersionMagic at runtime

GWP-ASan's `AllocatorState` was recently extended with a
`AllocatorVersionMagic` structure required so that GWP-ASan bug reports
can be understood by tools at different versions.

On Fuchsia, this in included in the `scudo::Allocator` structure, and
by having non-zero initializers, this effectively moved the static
allocator structure from the `.bss` segment to the `.data` segment, thus
increasing (significantly) the size of the libc.

This CL proposes to initialize the structure with its magic numbers at
runtime, allowing for the allocator to go back into the `.bss` segment.

I will work on adding a test on the Scudo side to ensure that this type
of changes get detected early on. Additional work is also needed to
reduce the footprint of the (large) memory-tagging related structures
that are currently part of the allocator.

Differential Revision: https://reviews.llvm.org/D110575

show more ...


Revision tags: llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init
# d458f379 08-Jul-2021 Mitch Phillips <31459023+hctim@users.noreply.github.com>

[GWP-ASan] Change unreachable -> trap to work around DCE bug.

trapOnAddress is designed to SEGV on a specific address. Unfortunately,
with an IR change, __builtin_unreachable() ends up doing DCE on

[GWP-ASan] Change unreachable -> trap to work around DCE bug.

trapOnAddress is designed to SEGV on a specific address. Unfortunately,
with an IR change, __builtin_unreachable() ends up doing DCE on things
that have side effects, like the load that causes the trap.

Change to __builtin_trap() to avoid the optimisation.

Root cause is still an LLVM bug, and tracked in
https://bugs.llvm.org/show_bug.cgi?id=47480.

Reviewed By: eugenis

Differential Revision: https://reviews.llvm.org/D105654

show more ...


Revision tags: llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1, llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2
# 3d8823b8 08-Feb-2021 Mitch Phillips <31459023+hctim@users.noreply.github.com>

[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/D

[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

show more ...


Revision tags: llvmorg-11.1.0, llvmorg-11.1.0-rc3
# 0dcf3324 02-Feb-2021 Mitch Phillips <31459023+hctim@users.noreply.github.com>

Revert "[GWP-ASan] Add aligned allocations."

This reverts commit 9dc06762470cb5a6cde8de5833cb75262e1bacb0.

Should not have been committed, was a bad rebase. Review still
continuing on D94830.


# 30973f6f 02-Feb-2021 Mitch Phillips <31459023+hctim@users.noreply.github.com>

[GWP-ASan] Add locking around unwinder for atfork protection.

Unwinders (like libc's backtrace()) can call their own locks (like the
libdl lock). We need to let the unwinder release the locks before

[GWP-ASan] Add locking around unwinder for atfork protection.

Unwinders (like libc's backtrace()) can call their own locks (like the
libdl lock). We need to let the unwinder release the locks before
forking. Wrap a new lock around the unwinder for atfork protection.

Reviewed By: eugenis

Differential Revision: https://reviews.llvm.org/D95889

show more ...


Revision tags: llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2
# 9dc06762 14-Jan-2021 Mitch Phillips <31459023+hctim@users.noreply.github.com>

[GWP-ASan] Add aligned allocations.

Adds a new allocation API to GWP-ASan that handles size+alignment
restrictions.

Differential Revision: https://reviews.llvm.org/D94830


Revision tags: llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2
# 61a038f8 10-Dec-2020 Mitch Phillips <31459023+hctim@users.noreply.github.com>

[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


# c904c32b 01-Dec-2020 Kostya Kortchinsky <kostyak@google.com>

[GWP-ASan] Fix flaky test on Fuchsia

The LateInit test might be reusing some already initialized thread
specific data if run within the main thread. This means that there
is a chance that the curren

[GWP-ASan] Fix flaky test on Fuchsia

The LateInit test might be reusing some already initialized thread
specific data if run within the main thread. This means that there
is a chance that the current value will not be enough for the 100
iterations, hence the test flaking.

Fix this by making the test run in its own thread.

Differential Revision: https://reviews.llvm.org/D92415

show more ...


Revision tags: llvmorg-11.0.1-rc1
# 90678f65 26-Oct-2020 Kostya Kortchinsky <kostyak@google.com>

[GWP-ASan] Abstract the thread local variables access

In a similar fashion to D87420 for Scudo, this CL introduces a way to
get thread local variables via a platform-specific reserved TLS slot,
sinc

[GWP-ASan] Abstract the thread local variables access

In a similar fashion to D87420 for Scudo, this CL introduces a way to
get thread local variables via a platform-specific reserved TLS slot,
since Fuchsia doesn't support ELF TLS from the libc itself.

If needing to use this, a platform will have to define
`GWP_ASAN_HAS_PLATFORM_TLS_SLOT` and provide `gwp_asan_platform_tls_slot.h`
which will define a `uint64_t *getPlatformGwpAsanTlsSlot()` function
that will return the TLS word of storage.

I snuck in a couple of cleanup items as well, moving some static
functions to anonymous namespace for consistency.

Differential Revision: https://reviews.llvm.org/D90195

show more ...


# 612e02ee 22-Oct-2020 Kostya Kortchinsky <kostyak@google.com>

[GWP-ASan] Refactor memory mapping functions

In preparation for Fuchsia support, this CL refactors the memory
mapping functions.

The new functions are as follows:
- for Freeslots and Metadata:
`v

[GWP-ASan] Refactor memory mapping functions

In preparation for Fuchsia support, this CL refactors the memory
mapping functions.

The new functions are as follows:
- for Freeslots and Metadata:
`void *map(size_t Size, const char *Name) const;`
`void unmap(void *Ptr, size_t Size) const;`
- for the Pool:
`void *reservePool(size_t Size);`
`void commitPool(void *Ptr, size_t Size) const;`
`void decommitPool(void *Ptr, size_t Size) const;`
`void unreservePool();`
Note that those don't need a `Name` parameter as those are fixed per
function. `{reserve,unreserve}Pool` are not `const` because they will
modify platform specific class member on Fuchsia.

I added a plethora of `assert()` as the initial code was not enforcing
page alignment for sizes and addresses, which caused problem in the
initial Fuchsia draft. All sizes should now be properly rounded up to
a page.

Differential Revision: https://reviews.llvm.org/D89993

show more ...


# 3580a450 22-Oct-2020 Kostya Kortchinsky <kostyak@google.com>

[GWP-ASan] Move random-related code in the allocator (redo)

This is a redo of D89908, which triggered some `-Werror=conversion`
errors with GCC due to assignments to the 31-bit variable.

This CL ad

[GWP-ASan] Move random-related code in the allocator (redo)

This is a redo of D89908, which triggered some `-Werror=conversion`
errors with GCC due to assignments to the 31-bit variable.

This CL adds to the original one a 31-bit mask variable that is used
at every assignment to silence the warning.

Differential Revision: https://reviews.llvm.org/D89984

show more ...


# 04e42f62 22-Oct-2020 Nikita Popov <nikita.ppv@gmail.com>

Revert "[GWP-ASan] Move random-related code in the allocator"

This reverts commit 9903b0586cfb76ef2401c342501e61e1bd3daa0f.

Causes build failures (on GCC 10.2) with the following error:

In file in

Revert "[GWP-ASan] Move random-related code in the allocator"

This reverts commit 9903b0586cfb76ef2401c342501e61e1bd3daa0f.

Causes build failures (on GCC 10.2) with the following error:

In file included from /home/nikic/llvm-project/compiler-rt/lib/scudo/standalone/combined.h:29,
from /home/nikic/llvm-project/compiler-rt/lib/scudo/standalone/allocator_config.h:12,
from /home/nikic/llvm-project/compiler-rt/lib/scudo/standalone/wrappers_cpp.cpp:14:
/home/nikic/llvm-project/compiler-rt/lib/scudo/standalone/../../gwp_asan/guarded_pool_allocator.h: In member function ‘bool gwp_asan::GuardedPoolAllocator::shouldSample()’:
/home/nikic/llvm-project/compiler-rt/lib/scudo/standalone/../../gwp_asan/guarded_pool_allocator.h:82:69: error: conversion from ‘uint32_t’ {aka ‘unsigned int’} to ‘unsigned int:31’ may change value [-Werror=conversion]
82 | (getRandomUnsigned32() % (AdjustedSampleRatePlusOne - 1)) + 1;
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~

show more ...


# 9903b058 21-Oct-2020 Kostya Kortchinsky <kostyak@google.com>

[GWP-ASan] Move random-related code in the allocator

We need to have all thread specific data packed into a single `uintptr_t`
for the upcoming Fuchsia support. We can move the `RandomState` into th

[GWP-ASan] Move random-related code in the allocator

We need to have all thread specific data packed into a single `uintptr_t`
for the upcoming Fuchsia support. We can move the `RandomState` into the
`ThreadLocalPackedVariables`, reducing the size of `NextSampleCounter`
to 31 bits (or we could reduce `RandomState` to 31 bits).

We move `getRandomUnsigned32` into the platform agnostic part of the
class, and `initPRNG` in the platform specific part.

`ScopedBoolean` is replaced by actual assignments since non-const
references to bitfields are prohibited.

`random.{h,cpp}` are removed.

Differential Revision: https://reviews.llvm.org/D89908

show more ...


Revision tags: llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3, llvmorg-11.0.0-rc2, llvmorg-11.0.0-rc1, llvmorg-12-init, llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3, llvmorg-10.0.1-rc2, llvmorg-10.0.1-rc1, llvmorg-10.0.0, llvmorg-10.0.0-rc6, llvmorg-10.0.0-rc5, llvmorg-10.0.0-rc4, llvmorg-10.0.0-rc3, llvmorg-10.0.0-rc2
# 5f2a74c8 12-Feb-2020 Mitch Phillips <31459023+hctim@users.noreply.github.com>

[GWP-ASan] Update alignment on Android.

Summary:
Android has different alignment requirements. You can read more about
them here
(https://cs.android.com/android/platform/superproject/+/master:bionic

[GWP-ASan] Update alignment on Android.

Summary:
Android has different alignment requirements. You can read more about
them here
(https://cs.android.com/android/platform/superproject/+/master:bionic/tests/malloc_test.cpp;l=808),
but the general gist is that for malloc(x <= 8), we do malloc(8), and
for everything else, we do 16-byte alignment.

Reviewers: eugenis, morehouse, cferris

Reviewed By: eugenis, morehouse

Subscribers: #sanitizers, llvm-commits, pcc

Tags: #sanitizers, #llvm

Differential Revision: https://reviews.llvm.org/D74364

show more ...


# 25de3f98 06-Feb-2020 Mitch Phillips <31459023+hctim@users.noreply.github.com>

[GWP-ASan] Fix PRNG to use IE TLS.

Summary:
GWP-ASan's PRNG didn't use Initial-Exec TLS. Fix that to ensure that we don't
have infinite recursion, and also that we don't allocate a DTV on Android wh

[GWP-ASan] Fix PRNG to use IE TLS.

Summary:
GWP-ASan's PRNG didn't use Initial-Exec TLS. Fix that to ensure that we don't
have infinite recursion, and also that we don't allocate a DTV on Android when
GWP-ASan is touched.

Test coverage ensuring that the sample counter is UINT32_MAX for an
uninitialised GWP-ASan is provided by gwp_asan/tests/late_init.cpp.

Reviewers: pcc, cferris

Reviewed By: pcc

Subscribers: #sanitizers, llvm-commits, rprichard, eugenis

Tags: #sanitizers, #llvm

Differential Revision: https://reviews.llvm.org/D74135

show more ...


# 0bfc4890 06-Feb-2020 Mitch Phillips <31459023+hctim@users.noreply.github.com>

[GWP-ASan] Fix unused variables from crash handler + clang-format

Summary: NFC - See title

Reviewers: eugenis

Reviewed By: eugenis

Subscribers: merge_guards_bot, #sanitizers, llvm-commits

Tags:

[GWP-ASan] Fix unused variables from crash handler + clang-format

Summary: NFC - See title

Reviewers: eugenis

Reviewed By: eugenis

Subscribers: merge_guards_bot, #sanitizers, llvm-commits

Tags: #sanitizers, #llvm

Differential Revision: https://reviews.llvm.org/D74100

show more ...


# a6258684 05-Feb-2020 Mitch Phillips <31459023+hctim@users.noreply.github.com>

[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 le

[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

show more ...


# 0d6fccb4 03-Feb-2020 Mitch Phillips <31459023+hctim@users.noreply.github.com>

[GWP-ASan] Allow late initialisation if single-threaded.

Summary:
This patch allows for late initialisation of the GWP-ASan allocator. Previously, if late initialisation occurred, the sample counter

[GWP-ASan] Allow late initialisation if single-threaded.

Summary:
This patch allows for late initialisation of the GWP-ASan allocator. Previously, if late initialisation occurred, the sample counter was never updated, meaning we would end up having to wait for 2^32 allocations before getting a sampled allocation.

Now, we initialise the sampling mechanism in init() as well. We require init() to be called single-threaded, so this isn't a problem.

Reviewers: eugenis

Reviewed By: eugenis

Subscribers: merge_guards_bot, mgorny, #sanitizers, llvm-commits, cferris

Tags: #sanitizers, #llvm

Differential Revision: https://reviews.llvm.org/D73896

show more ...


Revision tags: llvmorg-10.0.0-rc1
# 46044a69 24-Jan-2020 Evgenii Stepanov <eugenis@google.com>

[gwp-asan] Implement malloc_iterate.

Summary:
This is an Android-specific interface for iterating over all live
allocations in a memory range.

Reviewers: hctim, cferris

Subscribers: mgorny, mgrang

[gwp-asan] Implement malloc_iterate.

Summary:
This is an Android-specific interface for iterating over all live
allocations in a memory range.

Reviewers: hctim, cferris

Subscribers: mgorny, mgrang, #sanitizers, llvm-commits

Tags: #sanitizers, #llvm

Differential Revision: https://reviews.llvm.org/D73305

show more ...


# e1440f59 24-Jan-2020 Mitch Phillips <31459023+hctim@users.noreply.github.com>

[GWP-ASan] Add names to anonymous mappings.

Summary:
Adds names to anonymous GWP-ASan mappings. This helps Android with debugging
via. /proc/maps, as GWP-ASan-allocated mappings are now easily ident

[GWP-ASan] Add names to anonymous mappings.

Summary:
Adds names to anonymous GWP-ASan mappings. This helps Android with debugging
via. /proc/maps, as GWP-ASan-allocated mappings are now easily identifyable.

Reviewers: eugenis, cferris

Reviewed By: eugenis

Subscribers: merge_guards_bot, #sanitizers, llvm-commits, cryptoad, pcc

Tags: #sanitizers, #llvm

Differential Revision: https://reviews.llvm.org/D73373

show more ...


12