I was observing segfaults at executable exit in the rtsan instrumented
unit tests. Bisecting the offending test led to observing that this test
is not using our safe test fixture for anything involving a file
descriptor. Changing to use the fixture eliminated the segfault on exit.
When `ptrauth_calls` is present but `ptrauth_init_fini` is not, compiler
emits raw unsigned pointers in `.init_array`/`.fini_array` sections.
Previously, `__do_init`/`__do_fini` pointers, which are explicitly added
to the sections, were implicitly signed (due to the presense of
`ptrauth_calls`), while all the other pointers in the sections were
implicitly added by the compiler and thus non-signed.. As a result, the
sections contained a mix of unsigned function pointers and function
pointers signed with default signing schema.
This patch introduces use of inline assembly for this particular case,
so we can manually specify that we do not want to sign the pointers.
Note that we cannot use `__builtin_ptrauth_strip` for this purpose since
its result is not a constant expression.
The current code always unmaps a secondary allocation when MTE is
enabled. Fix this to match the comment, namely only unmap if MTE was
enabled and is no longer enabled after acquiring the lock.
In addition, allow quaratine to work in the secondary even if MTE is not
enabled.
Introduce the test from
https://github.com/llvm/llvm-project/issues/146120
For future readers of this PR, if this test causes a segfault please
comment out the line indicated by the comment (or revert this entire
commit).
My plan is to commit this, see if any test runners fail, then submit the
fix in a follow on.
I cannot repro this bug on my machine so I need some confirmation of the
bug being fixed as it is submitted.
Supplement to PR #144073
Previously, _msan_check_mem_is_initialized.cpp_ initialized a 32-byte
stack array, but checked the shadow for the offset range [12, 42),
exceeding the stack array size.
MSan does not guarantee that the shadow corresponding to the overflow
part is 0, so it is undefined to require the overflow part to be
unpoisoned.
glibc 2.42 made all usage of termios ioctl constants strictly internal
Therefore, we remove all usage for those removed constants.
This should only apply for Linux.
Fix#149103
Reference:
3d3572f590
@fweimer-rh @tstellar
ASan had a gap in coverage for wqthreads blocks submitted by
dispatch_apply
This adds interceptor for dispatch_apply and dispatch_apply_f and adds a
test that a failure in a dispatch apply block contains thread and stack
info.
rdar://139660648
`tid_t` is also defined in the AIX header `/usr/include/sys/types.h`
which is included by system `pthread.h`. The use of `tid_t` by AIX is
conforming according to
[POSIX](https://pubs.opengroup.org/onlinepubs/9799919799/functions/V2_chap02.html):
> Implementations may add symbols to the headers shown in the following
table [ ... ]
Do some refactoring to allocation/deallocation interceptors. Expose
explicit per-alloc_type functions and stop accepting explicit AllocType.
This ensures we do not accidentally mix.
NOTE: This change rejects attempts to call `operator new(<some_size>,
static_cast<std::align_val_t>(0))`.
For https://github.com/llvm/llvm-project/issues/144435
Signed-off-by: Justin King <jcking@google.com>
The script incorrectly checked ${LLVM_BUILD}/build.ninja to determine if
cached libcxx is available, while it should be checking the actual
libcxx build directory at ${LIBCXX_BUILD}/build.ninja.
Ran into the issue on Alpine when building with TSAN that
`__sanitizer_msghdr` and the `msghdr` provided by musl did not match.
This caused lots of tsan reports and an eventual termination of the
application by the oom during a `sendmsg`.
The sizes of the struct stat on MIPS64 differ in musl vs glibc.
See https://godbolt.org/z/qf9bcq8Y8 for the proof. Prior to this change,
compilation for MIPS64 musl would fail.
Signed-off-by: Jens Reidel <adrian@travitia.xyz>
287b24e1899eb6ce62eb9daef5a24faae5e66c1e moved the
`GetGlobalAddressInformation` call earlier, but this broke a chromium
test, so make this workaround for AIX only.
This updates the aligned version for version 26.
Note: This change is for correctness only and has no functional impact
currently. `get_macos_aligned_version` is currently only consumed when
substituting flags based on min version.
rdar://152851947
The original version of ResidentMemorySize could be a little flaky.
Replace the test with a version that verifies exactly how much of the
map is resident.
This reverts commit 0c0aa56cdcf1fe3970a5f3875db412530512fc07.
This time with the following fixes for buildbot failures:
- Add underscore prefixes to symbol names on Apple platforms.
- Modify the test so that it skips the crash tests on platforms where
they are not expected to pass:
- Platforms that implement FEAT_PAuth but not FEAT_FPAC (e.g.
Apple M1, Cortex-A78C)
- Platforms where DA key is disabled (e.g. older Linux kernels,
Linux kernels with PAC disabled, likely Windows)
Original commit message follows:
The emulated PAC runtime functions emulate the ARMv8.3a pointer
authentication instructions and are intended for use in heterogeneous
testing environments. For more information, see the associated RFC:
https://discourse.llvm.org/t/rfc-emulated-pac/85557
Reviewers: mstorsjo, pawosm-arm, atrosinenko
Reviewed By: atrosinenko
Pull Request: https://github.com/llvm/llvm-project/pull/148094
The previous test simply tried to double free the pointer in the
EXPECT_DEATH macro. Unfortunately, the gtest infrastructure can allocate
a pointer that happens to be the previously freed pointer. Thus the free
doesn't fail since the spawned process does not attempt to free all of
the pointers allocated in the original test.
NOTE: Scudo should be checked to make sure that the TSD is not always
returning pointers in the same order they are freed. Although this
appears to be a problem with a program that only does a small number of
allocations.
As well as followup "builtins: Speculative MSVC fix."
This reverts commits 5b1db59fb87b4146f827d17396f54ef30ae0dc40 and
f1c4df5b7bb79efb3e9be7fa5f8176506499d0a6.
Needs fixes for failing tests which will take time to implement.
Despite being defined in the system headers, these commands are not in
fact part of the FreeBSD system call interface. They exist solely for
the Linuxulator, i.e. running Linux binaries on FreeBSD, and any attempt
to use them from a FreeBSD binary will return EINVAL. The fact we needed
to define _KERNEL (which, as the name implies, means we are compiling
the kernel) to even get the definition of shminfo should have been a
strong indicator that IPC_INFO at least was not a userspace interface.
To prepare for other platforms, such as 64-bit AIX, that have a non-zero
mmap beginning address.
---------
Co-authored-by: David Justo <david.justo.1996@gmail.com>
Adds support to RTSan for `free_sized` and `free_aligned_sized` from
C23.
Other sanitizers will be handled with their own separate PRs.
For https://github.com/llvm/llvm-project/issues/144435
Signed-off-by: Justin King <jcking@google.com>
This allows us to change the number of blocks stored according to the
size of BatchClass.
Also change the name `TransferBatch` to `Batch` given that it's never
the unit of transferring blocks.
* Fix splitting of arguments such as `LSAN_OPTIONS=suppressions=lsan.supp`
* Prevent environment variables set in parent process being overwritten
* Replace hard-coded `env` with `%env` to allow overriding depending on target
* Replace deprecated `pipes` usage with `shlex`
* Run formatter over `iossim_env.py`
**Related to:** https://github.com/llvm/llvm-project/issues/117925
**Follow up to:** https://github.com/llvm/llvm-project/pull/117929
**Context:**
As noted in the linked issue, some ASan configuration flags are not
honored on Windows when set through the `__asan_default_options` user
function. The reason for this is that `__asan_default_options` is not
available by the time `AsanInitInternal` executes, which is responsible
for applying the ASan flags.
To fix this properly, we'll probably need a deep re-design of ASan
initialization so that it is consistent across OS'es.
In the meantime, this PR offers a practical workaround.
**This PR:** refactors part of `AsanInitInternal` so that **idempotent**
flag-applying steps are extracted into a new function `ApplyOptions`.
This function is **also** invoked in the "weak function callback" on
Windows (which gets called when `__asan_default_options` is available)
so that, if any flags were set through the user-function, they are
safely applied _then_.
Today, `ApplyOptions` contains only a subset of flags. My hope is that
`ApplyOptions` will over time, through incremental refactorings
`AsanInitInternal` so that **all** flags are eventually honored.
Other minor changes:
* The introduction of a `ApplyAllocatorOptions` helper method, needed to
implement `ApplyOptions` for allocator options without re-initializing
the entire allocator. Reinitializing the entire allocator is expensive,
as it may do a whole pass over all the marked memory. To my knowledge,
this isn't needed for the options captured in `ApplyAllocatorOptions`.
* Rename `ProcessFlags` to `ValidateFlags`, which seems like a more
accurate name to what that function does, and prevents confusion when
compared to the new `ApplyOptions` function.
#144648 was reverted because it failed the new sanitizer test
`munmap_clear_shadow.c` in IOS's CI.
That issue could be fixed by disabling the test on some platforms, due
to the incompatibility of the test on these platforms.
In detail, we should disable the test in FreeBSD, Apple, NetBSD,
Solaris, and Haiku, where `ReleaseMemoryPagesToOS` executes
`madvise(beg, end, MADV_FREE)`, which tags the relevant pages as 'FREE'
and does not release them immediately.
