Fix GetRandom in sanitizer_fuchsia.cpp (#110155)

The `zx_cprng_draw` system call has no limit on how much you can draw.

Co-authored-by: Marco Vanotti <mvanotti@users.noreply.github.com>

[sanitizer] Add TryMemCpy (#112668)

For posix implementation is similar to
`IsAccessibleMemoryRange`, using `pipe`.

We need this because we can't rely on non-atomic
`IsAccessibleMemoryRange` +

[sanitizer] Add TryMemCpy (#112668)

For posix implementation is similar to
`IsAccessibleMemoryRange`, using `pipe`.

We need this because we can't rely on non-atomic
`IsAccessibleMemoryRange` + `memcpy`, as the
protection or mapping may change and we may
crash.

show more ...

[NFC][sanitizer] Move `InitTlsSize` into `InitializePlatformEarly` (#108921)

[compiler-rt][Fuchsia] Propogate raw_report to UnmapOrDieVmar (#82566)

As of #77488, UnmapOrDie now accepts raw_report which allows the program
to crash without calling Report(). We should propogat

[compiler-rt][Fuchsia] Propogate raw_report to UnmapOrDieVmar (#82566)

As of #77488, UnmapOrDie now accepts raw_report which allows the program
to crash without calling Report(). We should propogate this value
through UnmapOrDieVmar and have that call ReportMunmapFailureAndDie
which uses `raw_report`.

show more ...

[sanitizer][fuchsia] Fix fuchsia buildbot failure after 64790064e82467b43c04a70b6e9873e6939be81f (#82202)

In https://github.com/llvm/llvm-project/pull/77488, a param `raw_report`
is added for funct

[sanitizer][fuchsia] Fix fuchsia buildbot failure after 64790064e82467b43c04a70b6e9873e6939be81f (#82202)

In https://github.com/llvm/llvm-project/pull/77488, a param `raw_report`
is added for function `UnmapOrDie()`.
But missing the corresponding change for fuchsia, causes the buildbot
failure, see https://lab.llvm.org/buildbot/#/builders/98/builds/33593.
This patch should fix the fuchsia buildbot failure.

show more ...

[sanitizer_common][fuchsia] Get correct vmar info

Forward fix for https://github.com/llvm/llvm-project/pull/75256

The process for MmapAlignedOrDieOnFatalError involves trimming the start
and end of

[sanitizer_common][fuchsia] Get correct vmar info

Forward fix for https://github.com/llvm/llvm-project/pull/75256

The process for MmapAlignedOrDieOnFatalError involves trimming the start
and end of a mapping to ensure it's aligned correctly. This invloves
calling zx_vmar_map again but overwriting a part of the original vmar
which involves a call to zx_object_get_info(ZX_INFO_VMAR). After
https://github.com/llvm/llvm-project/pull/75256, we unconditionally
called this on gSanitizerHeapVmar but this can lead to a
ZX_ERR_INVALID_ARGS if the prior mapping was on the root vmar.

This can be fixed by also returning the vmar we did the last mapping to
and using that for followup operations that specifically involve the
same vmar. This way we don't have to try each syscall for both vmars.

show more ...

[compiler-rt][fuchsia] Preallocate a vmar for sanitizer internals (#75256)

In an effort to reduce more mmap fragmentation, allocate a large enough
vmar where we can map sanitizer internals via DoAn

[compiler-rt][fuchsia] Preallocate a vmar for sanitizer internals (#75256)

In an effort to reduce more mmap fragmentation, allocate a large enough
vmar where we can map sanitizer internals via DoAnonymousMmap. Objects
being mapped here include asan's FakeStack, LowLevelAllocator mappings,
the primary allocator's TwoLevelMap, InternalMmapVector, StackStore, and
asan's thread internals. The vmar is large enough to hold the total size
of these objects seen in a "typical" process lifetime. If the vmar is
full, it will fallback to mapping in the root vmar.

show more ...

[compiler-rt][Fuchsia] Use map name if provided

Prior to this, any allocations coming from the SizeClassAllocator would just
have the vmo name "SizeClassAllocator". This will instead use the string

[compiler-rt][Fuchsia] Use map name if provided

Prior to this, any allocations coming from the SizeClassAllocator would just
have the vmo name "SizeClassAllocator". This will instead use the string passed
to the Map functions if provided which provide slightly more info on what the
vmo is used for. That is, is it for region data, metadata, or freearray space.

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

show more ...

[NFC] Add MprotectReadWrite

It's unused, but I need it for debuging.
Seems usefull for completeness.

Reviewed By: thurston

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

[Sanitizer][Darwin] Cleanup MaybeReexec() function and usage

While investigating another issue, I noticed that `MaybeReexec()` never
actually "re-executes via `execv()`" anymore. `DyldNeedsEnvVaria

[Sanitizer][Darwin] Cleanup MaybeReexec() function and usage

While investigating another issue, I noticed that `MaybeReexec()` never
actually "re-executes via `execv()`" anymore. `DyldNeedsEnvVariable()`
only returned true on macOS 10.10 and below.

Usually, I try to avoid "unnecessary" cleanups (it's hard to be certain
that there truly is no fallout), but I decided to do this one because:

* I initially tricked myself into thinking that `MaybeReexec()` was
relevant to my original investigation (instead of being dead code).
* The deleted code itself is quite complicated.
* Over time a few other things were mushed into `MaybeReexec()`:
initializing `MonotonicNanoTime()`, verifying interceptors are
working, and stripping the `DYLD_INSERT_LIBRARIES` env var to avoid
problems when forking.
* This platform-specific thing leaked into `sanitizer_common.h`.
* The `ReexecDisabled()` config nob relies on the "strong overrides weak
pattern", which is now problematic and can be completely removed.
* `ReexecDisabled()` actually hid another issue with interceptors not
working in unit tests. I added an explicit `verify_interceptors`
(defaults to `true`) option instead.

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

show more ...

Revert "[Sanitizer][Darwin] Cleanup MaybeReexec() function and usage"

Many tests for the `UBSan-Standalone-iossim-x86_64` fail with this.
Reverting so I can investigate.

This reverts commit 0a9667b

Revert "[Sanitizer][Darwin] Cleanup MaybeReexec() function and usage"

Many tests for the `UBSan-Standalone-iossim-x86_64` fail with this.
Reverting so I can investigate.

This reverts commit 0a9667b0f56b1b450abd02f74c6175bea54f832e.

show more ...

[Sanitizer][Darwin] Cleanup MaybeReexec() function and usage

While investigating another issue, I noticed that `MaybeReexec()` never
actually "re-executes via `execv()`" anymore. `DyldNeedsEnvVaria

[Sanitizer][Darwin] Cleanup MaybeReexec() function and usage

While investigating another issue, I noticed that `MaybeReexec()` never
actually "re-executes via `execv()`" anymore. `DyldNeedsEnvVariable()`
only returned true on macOS 10.10 and below.

Usually, I try to avoid "unnecessary" cleanups (it's hard to be certain
that there truly is no fallout), but I decided to do this one because:

* I initially tricked myself into thinking that `MaybeReexec()` was
relevant to my original investigation (instead of being dead code).
* The deleted code itself is quite complicated.
* Over time a few other things were mushed into `MaybeReexec()`:
initializing `MonotonicNanoTime()`, verifying interceptors are
working, and stripping the `DYLD_INSERT_LIBRARIES` env var to avoid
problems when forking.
* This platform-specific thing leaked into `sanitizer_common.h`.
* The `ReexecDisabled()` config nob relies on the "strong overrides weak
pattern", which is now problematic and can be completely removed.
* `ReexecDisabled()` actually hid another issue with interceptors not
working in unit tests. I added an explicit `verify_interceptors`
(defaults to `true`) option instead.

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

show more ...

[compiler-rt] Update Fuchsia sanitizer sched_yield

Fuchsia has split overloaded nanosleep(0) for yielding to its own
dedicated syscall, so valid zero deadlines would just return.

Patch By: gevalent

[compiler-rt] Update Fuchsia sanitizer sched_yield

Fuchsia has split overloaded nanosleep(0) for yielding to its own
dedicated syscall, so valid zero deadlines would just return.

Patch By: gevalentino

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

show more ...

[compiler-rt][sanitizer] Have all OOM-related error messages start with the same format

This way downstream tools that read sanitizer output can differentiate between OOM errors
reported by sanitize

[compiler-rt][sanitizer] Have all OOM-related error messages start with the same format

This way downstream tools that read sanitizer output can differentiate between OOM errors
reported by sanitizers from other sanitizer errors.

Changes:

- Introduce ErrorIsOOM for checking if a platform-specific error code from an "mmap" is an OOM err.
- Add ReportOOMError which just prepends this error message to the start of a Report call.
- Replace some Reports for OOMs with calls to ReportOOMError.
- Update necessary tests.

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

show more ...

Revert "[sanitizer] Don't run malloc hooks for stacktraces"

Msan crashes on clang-s390x-linux bot

This reverts commit d3531fc7f0053a7fe68317521ee6491da6e36733.

[sanitizer] Don't run malloc hooks for stacktraces

Usually when we generated stacktraces the process is in error state, so
running hooks may crash the process and prevent meaningfull error report.

[sanitizer] Don't run malloc hooks for stacktraces

Usually when we generated stacktraces the process is in error state, so
running hooks may crash the process and prevent meaningfull error report.

Symbolizer, unwinder and pthread are potential source of mallocs.

https://b.corp.google.com/issues/228110771

Reviewed By: kda

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

show more ...

Revert "[sanitizer] Don't run malloc hooks for stacktraces"

Breaks android and iOS bots.
https://green.lab.llvm.org/green/job/clang-san-iossim/5229/consoleFull#711521816a1ca8a51-895e-46c6-af87-ce24f

Revert "[sanitizer] Don't run malloc hooks for stacktraces"

Breaks android and iOS bots.
https://green.lab.llvm.org/green/job/clang-san-iossim/5229/consoleFull#711521816a1ca8a51-895e-46c6-af87-ce24fa4cd561
https://lab.llvm.org/buildbot/#/builders/77/builds/16456

This reverts commit 6345d7f2a829faea56ad522a7d5180043f862a5c.

show more ...

[sanitizer] Don't run malloc hooks for stacktraces

Usually when we generated stacktraces the process is in error state, so
running hooks may crash the process and prevent meaningfull error report.

[sanitizer] Don't run malloc hooks for stacktraces

Usually when we generated stacktraces the process is in error state, so
running hooks may crash the process and prevent meaningfull error report.

Symbolizer, unwinder and pthread are potential source of mallocs.

https://b.corp.google.com/issues/228110771

Reviewed By: kda

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

show more ...

sanitizer_common: Remove Fuchsia support for reading flags from files

This has never really been used in practice. Fuchsia is moving
away from the support this requires, so don't use it.

Reviewed

sanitizer_common: Remove Fuchsia support for reading flags from files

This has never really been used in practice. Fuchsia is moving
away from the support this requires, so don't use it.

Reviewed By: phosek

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

show more ...

sanitizer_common: make internal/external headers compatible

This is a follow up to 4f3f4d672254
("sanitizer_common: fix __sanitizer_get_module_and_offset_for_pc signature mismatch")
which fixes a si

sanitizer_common: make internal/external headers compatible

This is a follow up to 4f3f4d672254
("sanitizer_common: fix __sanitizer_get_module_and_offset_for_pc signature mismatch")
which fixes a similar problem for msan build.

I am getting the following error compiling a unit test for code that
uses sanitizer_common headers and googletest transitively includes
sanitizer interface headers:

In file included from third_party/gwp_sanitizers/singlestep_test.cpp:3:
In file included from sanitizer_common/sanitizer_common.h:19:
sanitizer_interface_internal.h:41:5: error: typedef redefinition with different types
('struct __sanitizer_sandbox_arguments' vs 'struct __sanitizer_sandbox_arguments')
} __sanitizer_sandbox_arguments;
common_interface_defs.h:39:3: note: previous definition is here
} __sanitizer_sandbox_arguments;

Reviewed By: melver

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

show more ...

[sanitizer] Run Stack compression in background thread

Depends on D114495.

Reviewed By: dvyukov

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

[compiler-rt] Fix incorrect variable names used

[sanitizer] Implement MprotectReadOnly and MprotectNoAccess

MprotectReadOnly for Win and Fuchsia
MprotectNoAccess for Fuchsia

sanitizer_common: remove unnecessary GetMemoryProfile arg

stats_size argument is unnecessary in GetMemoryProfile and in the callback.
It just clutters code. The callback knowns how many stats to exp

sanitizer_common: remove unnecessary GetMemoryProfile arg

stats_size argument is unnecessary in GetMemoryProfile and in the callback.
It just clutters code. The callback knowns how many stats to expect.

Depends on D112789.

Reviewed By: melver

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

show more ...

sanitizer_common: replace RWMutex/BlockingMutex with Mutex

Mutex supports reader access, OS blocking, spinning,
portable and smaller than BlockingMutex.
Overall it's supposed to be better than RWMut

sanitizer_common: replace RWMutex/BlockingMutex with Mutex

Mutex supports reader access, OS blocking, spinning,
portable and smaller than BlockingMutex.
Overall it's supposed to be better than RWMutex/BlockingMutex.
Replace RWMutex/BlockingMutex with Mutex.

Reviewed By: melver

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

show more ...