[compiler-rt] Remove support and workarounds for Android 4 and older (#124056)

[compiler-rt] fseek interception update. (#122795)

fseek api is POSIX.

to also address #122163

[sanitizer_common] Handle ptrace on Linux/sparc64 (#109310)

When ASan testing is enabled on SPARC as per PR #107405, the
```
AddressSanitizer-sparc-linux :: TestCases/Linux/ptrace.cpp
```
`FAI

[sanitizer_common] Handle ptrace on Linux/sparc64 (#109310)

When ASan testing is enabled on SPARC as per PR #107405, the
```
AddressSanitizer-sparc-linux :: TestCases/Linux/ptrace.cpp
```
`FAIL`s on Linux/sparc64. This happens because the `ptrace` interceptor
has no support for that target at all.

This patch adds the missing parts and accounts for a couple of issues
specific to this target:
- In some cases, SPARC just needs to be included in the list of
supported targets.
- Besides, the types used by the `PTRACE_GETREGS` and `PTRACE_GETFPREGS`
requests need to be filled in.
- `ptrace` has a weird quirk on this target: for a couple of requests,
the meaning of the `data` and `addr` args is reversed. All of the
`Linux/ptrace.cpp` test and the interceptor, pre-syscall and
post-syscall hooks need to account for that swap in their checks.

Tested on `sparc64-unknown-linux-gnu` and `x86_64-pc-linux-gnu`.

show more ...

Reapply [compiler-rt] prctl interception update, SECCOMP_MODE_FILTER … (#109834)

…support. #107722

Revert "[compiler-rt] prctl interception update, SECCOMP_MODE_FILTER support. (#107722)"

This reverts commit b75174d05aa033a382d4c088e96e068a774f46da.
Does not build on Android, see comments on
http

Revert "[compiler-rt] prctl interception update, SECCOMP_MODE_FILTER support. (#107722)"

This reverts commit b75174d05aa033a382d4c088e96e068a774f46da.
Does not build on Android, see comments on
https://github.com/llvm/llvm-project/pull/107722

show more ...

[compiler-rt] prctl interception update, SECCOMP_MODE_FILTER support. (#107722)

[sanitizer] Remove crypt and crypt_r interceptors

From Florian Weimer's D144073

> On GNU/Linux (glibc), the crypt and crypt_r functions are not part of the main shared object (libc.so.6), but libcr

[sanitizer] Remove crypt and crypt_r interceptors

From Florian Weimer's D144073

> On GNU/Linux (glibc), the crypt and crypt_r functions are not part of the main shared object (libc.so.6), but libcrypt (with multiple possible sonames). The sanitizer libraries do not depend on libcrypt, so it can happen that during sanitizer library initialization, no real implementation will be found because the crypt, crypt_r functions are not present in the process image (yet). If its interceptors are called nevertheless, this results in a call through a null pointer when the sanitizer library attempts to forward the call to the real implementation.
>
> Many distributions have already switched to libxcrypt, a library that is separate from glibc and that can be build with sanitizers directly (avoiding the need for interceptors). This patch disables building the interceptor for glibc targets.

Let's remove crypt and crypt_r interceptors (D68431) to fix issues with
newer glibc.

For older glibc, msan will not know that an uninstrumented crypt_r call
initializes `data`, so there is a risk for false positives. However, with some
codebase survey, I think crypt_r uses are very few and the call sites typically
have a `memset(&data, 0, sizeof(data));` anyway.

Fix https://github.com/google/sanitizers/issues/1365
Related: https://bugzilla.redhat.com/show_bug.cgi?id=2169432

Reviewed By: #sanitizers, fweimer, thesamesam, vitalybuka

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

show more ...

[sanitizer] Support v2 and v3 capabilities

capget() and capset() may read or write more than one cap_user_data_t,
depending on the version field of cap_user_header_t. Currently the
code assumes it's

[sanitizer] Support v2 and v3 capabilities

capget() and capset() may read or write more than one cap_user_data_t,
depending on the version field of cap_user_header_t. Currently the
code assumes it's just one, so MSan complains if an application uses
version 2 or 3, where two cap_user_data_ts are used.

Parse the header in order to determine the number of cap_user_data_ts.
Also add a test.

Reviewed By: vitalybuka

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

show more ...

[sanitizer] Undef _TIME_BITS along with _FILE_OFFSET_BITS on Linux

On 32-bit glibc>=2.34 systems using 64bit time_t build fails because
_FILE_OFFSET_BITS is undefined here but _TIME_BITS is still se

[sanitizer] Undef _TIME_BITS along with _FILE_OFFSET_BITS on Linux

On 32-bit glibc>=2.34 systems using 64bit time_t build fails because
_FILE_OFFSET_BITS is undefined here but _TIME_BITS is still set to 64

Fixes

```
/usr/include/features-time64.h:26:5: error: "_TIME_BITS=64 is allowed
only with _FILE_OFFSET_BITS=64"
| # error "_TIME_BITS=64 is allowed only with _FILE_OFFSET_BITS=64"
| ^
| 1 error generated.
```

Reviewed By: thesamesam, MaskRay

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

show more ...

tsan: Consider SI_TIMER signals always asynchronous

POSIX timer can be configured to send any kind of signal, however, it
fundamentally does not make sense to consider a timer a synchronous
signal.

tsan: Consider SI_TIMER signals always asynchronous

POSIX timer can be configured to send any kind of signal, however, it
fundamentally does not make sense to consider a timer a synchronous
signal. Teach TSan that timers are never synchronous.

The tricky bit here is correctly defining compiler-rt's siginfo
replacement, which is a rather complex struct. Extend it in a limited
way that is mostly cross-platform compatible and add offset tests in
sanitizer_platform_limits_posix.cpp.

Reviewed By: dvyukov

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

show more ...

[sanitizer] Don't intercept LFS64 symbols on musl

LFS64 symbols in musl are for glibc-ABI-compat and not intended for linking
(correct usage will not create LFS64 references). The next release 1.2.4

[sanitizer] Don't intercept LFS64 symbols on musl

LFS64 symbols in musl are for glibc-ABI-compat and not intended for linking
(correct usage will not create LFS64 references). The next release 1.2.4 will
disallow linking against LFS64 symbols[1].

For sanitizers, let's just remove LFS64 interceptors. In case of erroneous LFS64
references, asan/tsan will detect fewer problems and msan may have false
positives.

[1]: https://git.musl-libc.org/cgit/musl/commit/?id=246f1c811448f37a44b41cd8df8d0ef9736d95f4

Reviewed By: thesamesam

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

show more ...

[sanitizer] Add ptrace interceptor support for LoongArch

Add ptrace interceptor support for LoongArch, `ptrace.cpp` has been
tested and passed.

Reviewed By: SixWeining

Differential Revision: https

[sanitizer] Add ptrace interceptor support for LoongArch

Add ptrace interceptor support for LoongArch, `ptrace.cpp` has been
tested and passed.

Reviewed By: SixWeining

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

show more ...

[sanitizer] Use consistent checks for XDR

sanitizer_platform_limits_posix.h defines `__sanitizer_XDR ` if `SANITIZER_LINUX && !SANITIZER_ANDROID`, but sanitizer_platform_limits_posix.cpp tries to ch

[sanitizer] Use consistent checks for XDR

sanitizer_platform_limits_posix.h defines `__sanitizer_XDR ` if `SANITIZER_LINUX && !SANITIZER_ANDROID`, but sanitizer_platform_limits_posix.cpp tries to check it if `HAVE_RPC_XDR_H`. This coincidentally works because macOS has a broken <rpc/xdr.h> which causes `HAVE_RPC_XDR_H` to be 0, but if <rpc/xdr.h> is fixed then clang fails to compile on macOS. Restore the platform checks so that <rpc/xdr.h> can be fixed on macOS.

Reviewed By: vitalybuka

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

show more ...

[sanitizer] Port sanitizer_common to LoongArch

Initial libsanitizer support for LoongArch. It survived all GCC UBSan tests.

Major changes:

1. LoongArch port of Linux kernel only supports `statx` f

[sanitizer] Port sanitizer_common to LoongArch

Initial libsanitizer support for LoongArch. It survived all GCC UBSan tests.

Major changes:

1. LoongArch port of Linux kernel only supports `statx` for `stat` and its families. So we need to add `statx_to_stat` and use it for `stat`-like libcalls. The logic is "borrowed" from Glibc.
2. `sanitizer_syscall_linux_loongarch64.inc` is mostly duplicated from RISC-V port, as the syscall interface is almost same.

Reviewed By: SixWeining, MaskRay, XiaodongLoong, vitalybuka

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

show more ...

[sanitizer] Remove #include <linux/fs.h> to resolve fsconfig_command/mount_attr conflict with glibc 2.36

It is generally not a good idea to mix usage of glibc headers and Linux UAPI
headers (https:/

[sanitizer] Remove #include <linux/fs.h> to resolve fsconfig_command/mount_attr conflict with glibc 2.36

It is generally not a good idea to mix usage of glibc headers and Linux UAPI
headers (https://sourceware.org/glibc/wiki/Synchronizing_Headers). In glibc
since 7eae6a91e9b1670330c9f15730082c91c0b1d570 (milestone: 2.36), sys/mount.h
defines `fsconfig_command` which conflicts with linux/mount.h:

.../usr/include/linux/mount.h:95:6: error: redeclaration of ‘enum fsconfig_command’

Remove #include <linux/fs.h> which pulls in linux/mount.h. Expand its 4 macros manually.
Android sys/mount.h doesn't define BLKBSZGET and it still needs linux/fs.h.
In the long term we should move Linux specific definitions to sanitizer_platform_limits_linux.cpp
but this commit is easy to cherry pick into older compiler-rt releases.

Fix https://github.com/llvm/llvm-project/issues/56421

Reviewed By: #sanitizers, vitalybuka, zatrazz

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

show more ...

Revert "[sanitizer] Remove #include <linux/fs.h> to resolve fsconfig_command/mount_attr conflict with glibc 2.36"

This reverts commit b379129c4beb3f26223288627a1291739f33af02.

Breaks Android build.

Revert "[sanitizer] Remove #include <linux/fs.h> to resolve fsconfig_command/mount_attr conflict with glibc 2.36"

This reverts commit b379129c4beb3f26223288627a1291739f33af02.

Breaks Android build. Android sys/mount.h doesn't define macros like BLKBSZGET.

show more ...

[sanitizer] Remove #include <linux/fs.h> to resolve fsconfig_command/mount_attr conflict with glibc 2.36

It is generally not a good idea to mix usage of glibc headers and Linux UAPI
headers (https:/

[sanitizer] Remove #include <linux/fs.h> to resolve fsconfig_command/mount_attr conflict with glibc 2.36

It is generally not a good idea to mix usage of glibc headers and Linux UAPI
headers (https://sourceware.org/glibc/wiki/Synchronizing_Headers). In glibc
since 7eae6a91e9b1670330c9f15730082c91c0b1d570 (milestone: 2.36), sys/mount.h
defines `fsconfig_command` which conflicts with linux/mount.h:

.../usr/include/linux/mount.h:95:6: error: redeclaration of ‘enum fsconfig_command’

Remove #include <linux/fs.h> which pulls in linux/mount.h. Expand its 4 macros manually.

Fix https://github.com/llvm/llvm-project/issues/56421

Reviewed By: #sanitizers, vitalybuka, zatrazz

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

show more ...

[Sanitizers] Cleanup handling of stat64/statfs64

This is a follow up to <LLVM reviews>/D127343, which was reverted due to test failures.

There are differences in handling of stat64/statfs64 calls b

[Sanitizers] Cleanup handling of stat64/statfs64

This is a follow up to <LLVM reviews>/D127343, which was reverted due to test failures.

There are differences in handling of stat64/statfs64 calls by sanitizers between Linux and macOS. Versions of macOS starting with 10.6 drop the stat64/statfs64 APIs completely, relying on the linker to redirect stat/statfs to the appropriate 64 bit versions. Emitting variables needed by sanitizers is thus controlled by convoluted sets of conditions, involving Linux, IOS, macOS and Android, sprinkled around files.

This change clarifies it a bit, allowing to specify presence/absence of stat64/statfs64 for each platform, in a single location.

Please note that I wasn't able to test this change on platforms other than macOS and Linux Fedora 34. The previous attempt has caused test failures but couldn't figure out the context. I have a vague suspicion that they were Android and perhaps Fuchsia builds - and some build involving ppc64le, I don't have hardware handy to attempt a test there. Tried to tighten the conditions this time to clearly separate macOS from Linux, so Linux builds should behave same (sanitizerwise) as before the change. Will add people who reported the tests failing before as reviewers, so they can provide context should the change cause the test failures again.

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

show more ...

Revert "[Sanitizers] Cleanup handling of stat64/statfs64"

This reverts commit 6d890a0fb8b1962cf7b58e9e16ff4545f1f2b84f.

[Sanitizers] Cleanup handling of stat64/statfs64

There are differences in handling of stat64/statfs64 calls by sanitizers between Linux and macOS. Versions of macOS starting with 10.6 drop the stat6

[Sanitizers] Cleanup handling of stat64/statfs64

There are differences in handling of stat64/statfs64 calls by sanitizers between Linux and macOS. Versions of macOS starting with 10.6 drop the stat64/statfs64 APIs completely, relying on the linker to redirect stat/statfs to the appropriate 64 bit versions. Emitting variables needed by sanitizers is thus controlled by convoluted sets of conditions, involving Linux, IOS, macOS and Android, sprinkled around files.

This change adresses it, allowing to specify presence/absence of stat64/statfs64 for each platform, in a single location. Also, it adresses the Android case which handles stat64, but not statfs64.

Adding Vitaly as a reviewer since he seems to be actively working on sanitizers, perhaps can comment on the Android bit

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

show more ...

sanitizers: Do not include crypt.h if SANITIZER_INTERCEPT_CRYPT_R is undef

sanitizer_intercept_overriders.h might override SANITIZER_INTERCEPT_CRYPT_R to
be undefined. There's no need to require cry

sanitizers: Do not include crypt.h if SANITIZER_INTERCEPT_CRYPT_R is undef

sanitizer_intercept_overriders.h might override SANITIZER_INTERCEPT_CRYPT_R to
be undefined. There's no need to require crypt.h in that case.

(The motivation is that crypt() moved from glibc into its own package at some
point, which makes intercepting it and building with a single sysroot that
supports both pre-bullseye and post-bullseye a bit hairy.)

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

show more ...

[Sanitizers][Darwin] Replace SANITIZER_MAC with SANITIZER_APPLE in source files

This is a follow up to [Sanitizers][Darwin] Rename Apple macro SANITIZER_MAC -> SANITIZER_APPLE (D125816)

Performed a

[Sanitizers][Darwin] Replace SANITIZER_MAC with SANITIZER_APPLE in source files

This is a follow up to [Sanitizers][Darwin] Rename Apple macro SANITIZER_MAC -> SANITIZER_APPLE (D125816)

Performed a global search/replace as in title against LLVM sources

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

show more ...

sanitizer_common: Define FP_XSTATE_MAGIC1 for old glibc

D116208 (commit 1298273e8206a8fc2) added FP_XSTATE_MAGIC1.
However, when building with glibc < 2.16 for backward-dependency
compatibility, it

sanitizer_common: Define FP_XSTATE_MAGIC1 for old glibc

D116208 (commit 1298273e8206a8fc2) added FP_XSTATE_MAGIC1.
However, when building with glibc < 2.16 for backward-dependency
compatibility, it is not defined - and the build breaks.

Note: The define comes from Linux's asm/sigcontext.h but the
file uses signal.h which includes glibc's bits/sigcontext.h - which
is synced from the kernel's file but lags behind.

Solution: For backward compatility with ancient systems, define
FP_XSTATE_MAGIC1 if undefined.

//For the old systems, we were building with Linux kernel 3.19 but to support really old glibc systems, we build with a sysroot of glibc 2.12. While our kernel (and the users' kernels) have FP_XSTATE_MAGIC1, glibc 2.12 is too old. – With this patch, building the sanitizer libs works again. This showed up for us today as GCC mainline/13 has now synced the sanitizer libs.//

Reviewed By: #sanitizers, vitalybuka

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

show more ...

[MSAN] extend ioctl interceptor to support BLKSSZGET

Reviewed By: eugenis

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

[msan] Guard FP_XSTATE_MAGIC1 usage with SANITIZER_GLIBC

Fix build for Linux musl.

Reviewed By: #sanitizers, dvyukov

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