This caused false positives because the existing logic was not taking into account that pointers could have a tag in them.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D144305
Looks like builders were failing for the sized variants of operator
delete. These are hidden behind the __cpp_sized_deallocation macro
which can be defined with -fsized-deallocation.
The implementations of those functions require the rounding target to be
power-of-two. It's better to add a debugging check to avoid misuse.
Besides, add a general verion of those three to accommadate non
power-of-two cases.
Also change the name to roundUp/roundDown/isAligned
Reviewed By: cferris, cryptoad
Differential Revision: https://reviews.llvm.org/D142658
Ideally, we want to assert that all the operations on
Cache/QuarantineCache always have the `Mutex` acquired. However,
the current architecture of accessing TSD is not easy to cooperate
with the thread-safety analysis because of pointer aliasing. In
alternative, we add the getters for accessing TSD member and attach
proper thread-safety annotations on them.
Reviewed By: cferris
Differential Revision: https://reviews.llvm.org/D142151
allocation ring buffer is allowed to be zero. Update the logic in the
test so that on the platform that disables it won't fail this case.
Reviewed By: fmayer
Differential Revision: https://reviews.llvm.org/D144055
This CL adds the proper thread-safety annotations for most of the
functions and variables. However, given the restriction of the current
architecture, in some cases, we may not be able to use the annotations
easily. The followings are two exceptions,
1. enable()/disable(): Many structures in scudo are enabled/disabled by
acquiring the lock in each instance. This makes those structure act
like a `lock`. We can't mark those functions with ACQUIRE()/RELEASE()
because that makes the entire allocator become another `lock`. In the
end, that implies we need to *acquire* the `allocator` before each
malloc et al. request. Therefore, adding a variable to tell the
status of those structures may be a better way to cooperate with
thread-safety annotation.
2. TSD/TSD shared/TSD exclusive: These three have simiar restrictions as
mentioned above. In addition, they don't always need to be released
if it's a thread local instance. However, thread-safety analysis
doesn't support conditional branch. Which means we can't mark the
proper annotations around the uses of TSDs. We may consider to make
it consistent and which makes the code structure simpler.
This CL is supposed to introduce the annotations with the least code
refactoring. So only trivial thread safety issues will be addressed
here. For example, lacking of acquiring certain lock before accessing
certain variables will have the ScopedLock inserted. Other than that,
they are supposed to be done in the later changes.
Reviewed By: cferris
Differential Revision: https://reviews.llvm.org/D140706
Scudo is expected to call __scudo_allocate_hook on allocations, and
__scudo_deallocate_hook on deallocations, but it's behavior is not
clear on reallocations. Currently, non-trivial reallocations call
__scudo_allocate_hook but never __scudo_deallocate_hook. We should
prefer either calling both, none, or a dedicated
hook (__scudo_reallocate_hook, for instance).
This patch implements the former, and adds a unit test to enforce
those expectations.
Reviewed By: Chia-hungDuan
Differential Revision: https://reviews.llvm.org/D141407
Because of lock contention, we temporarily disabled the printing of
regions' status when it's exhausted. Given that it's useful when the
Region OOM happens, this CL brings it back without lock contention.
Differential Revision: https://reviews.llvm.org/D141955
We didn't acquire the mutex while accessing those lock protected data,
this CL fixes it and now we don't need to disable the allocator while
reading its states.
Differential Revision: https://reviews.llvm.org/D142149
I found a few Python files not using Python 3 syntax in the tree
when trying to apply reformatting to them. This was converted with
2to3 and the changes seemed sane.
Reviewed By: MaskRay, browneee
Differential Revision: https://reviews.llvm.org/D143701
The fix only affects Darwin, but to write the test I had to modify
the MemoryMappingLayout class which is used by all OSes,
to allow for mocking of image header (this change should be NFC). Hence no [Darwin] in the subject
so I can get more eyes on it.
While looking for a memory gap to put the shadow area into, the sanitizer code
scans through the loaded images, and for each image it scans through its
loader command to determine the occupied memory ranges.
While doing so, if the 'segment load' (kLCSegment) loader comand is encountered, the command scanning function
returns success (true), but does not decrement the command list iterator counter.
The result is that the function is called again and again, with the iterator counter
now being too high. The command scanner keeps updating the loader command pointer,
by using the command size field.
If the loop counter is too high, the command pointer
lands into unintended area ( beyond
+sizeof(mac_header64)+header->sizeofcmds ),
and result depends on the random content found there.
The random content interpreted as loader command might contain a large integer value in the
cmdsize field - this value is added to the current loader command pointer,
which might now point to an inaccessible memory address. It can occasionally result
in a crash if it happens to run beyond the mapped memory segment.
Note that when the area after the loader command list
contains zeros or small integers only, the loop will end normally and the problem
will go unnoticed. So it happened until now since having a some big value
after the header area, falling into command size field is a pretty rare situation.
The fix makes sure that the iterator counter gets updated when the segment load (kLCSegment)
loader command is found too, and in the same code location so the updates will always go together.
Undo the changes in the sanitizer_procmaps_mac.cpp to see the test failing.
rdar://101161047
rdar://102819707
Differential Revision: https://reviews.llvm.org/D142164
After D143438 there is no point in this check as the size will never 0. Also this keeps it consistent with ASAN where there is not size check in LsanMetadata::allocated.
Reviewed By: MaskRay, vitalybuka
Differential Revision: https://reviews.llvm.org/D143442
The fix only affects Darwin, but to write the test I had to modify
the MemoryMappingLayout class which is used by all OSes,
to allow for mocking of image header (this change should be NFC). Hence no [Darwin] in the subject
so I can get more eyes on it.
While looking for a memory gap to put the shadow area into, the sanitizer code
scans through the loaded images, and for each image it scans through its
loader command to determine the occupied memory ranges.
While doing so, if the 'segment load' (kLCSegment) loader comand is encountered, the command scanning function
returns success (true), but does not decrement the command list iterator counter.
The result is that the function is called again and again, with the iterator counter
now being too high. The command scanner keeps updating the loader command pointer,
by using the command size field.
If the loop counter is too high, the command pointer
lands into unintended area ( beyond <header addr>+sizeof(mac_header64)+header->sizeofcmds ),
and result depends on the random content found there.
The random content interpreted as loader command might contain a large integer value in the
cmdsize field - this value is added to the current loader command pointer,
which might now point to an inaccessible memory address. It can occasionally result
in a crash if it happens to run beyond the mapped memory segment.
Note that when the area after the loader command list
contains zeros or small integers only, the loop will end normally and the problem
will go unnoticed. So it happened until now since having a some big value
after the header area, falling into command size field is a pretty rare situation.
The fix makes sure that the iterator counter gets updated when the segment load (kLCSegment)
loader command is found too, and in the same code location so the updates will always go together.
Undo the changes in the sanitizer_procmaps_mac.cpp to see the test failing.
rdar://101161047
rdar://102819707
Differential Revision: https://reviews.llvm.org/D142164
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
It's better and easier for us to just have threads contend against each
other in the tests if it's more than the maximum supported number of
hardware threads available.
Specifically, the recoverable test fails on Android because the
GTEST_SKIP in a called function, and it only properly works from the
TEST_* harness function. Android tests run on cuttlefish, which can be a
single core with two hyperthreads.
Reviewed By: fmayer
Differential Revision: https://reviews.llvm.org/D143221
For HWASAN this would be the tagged address. It is the same pointer when pointer tagging is not used. Coincidently this also fixes some test which rely on comparing pointers.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D143121
They were being initialized anyway, I believe, but the logic was a bit
convoluted for the Clang warnings to detect so we were getting "variable 'EBX'
may be uninitialized when used here" later on.
Older GNU assemblers generate R_X86_64_PC32 relocation against
defined non-weak global branch targets with default visibility. A
linker may issue an error when building a shared library. Add a local
alias, .Linterceptor_sigsetjmp, to __interceptor_sigsetjmp to avoid
R_X86_64_PC32 relocation for "jmp __interceptor_sigsetjmp" with older
GNU assemblers.
Fixes: https://github.com/llvm/llvm-project/issues/60426
Differential Revision: https://reviews.llvm.org/D142995
This reverts commit 45368c75582f0bded1f06d5c82c1f2ee023fb186.
There were some unexpected failures in aarch64 and arm buildbots, I will
have to investigate why these suddenly fell over.
Since bfloat16 and float16 support is not available for i386-freebsd,
the `truncdfbf2.c` and `truncsfbf2.c` builtin sources should be skipped
when targeting that platform, and `COMPILER_RT_HAS_FLOAT16` should not
be defined.
However, the CMake configuration stage runs its tests with the default
target, which normally is amd64-freebsd, so it will detect both bfloat16
and float16 support.
Move adding of the `COMPILER_RT_HAS_FLOAT16` define to the `foreach()`
loop where all the supported architectures are handled, and do not
enable it when targeting i386-freebsd.
Also remove the bfloat16 sources from the `i386_SOURCES` list, when
targeting i386-freebsd.
Differential Revision: https://reviews.llvm.org/D136044
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
In LLVM the MachOPlatform class is modified to identify unwind info sections
and the address ranges of the functions these sections cover. These address
ranges are then communicated to the ORC runtime by attaching them to the
register-object-platform-sections allocation action.
In the ORC runtime the unwind-info section addresses are recorded and used to
support lookup of unwind info via the new `findDynamicUnwindSections` function.
At bootstrap time the ORC runtime checks for the presence of new
unwind-info-lookup-registration functions in libunwind (see
https://reviews.llvm.org/D142176), and if available uses them to register the
`findDynamicUnwindSections` function with libunwind to enable callback-based
lookup. If the new unwind-info-lookup-registration functions are not available
then the ORC runtime falls back to using the existing libunwind registration
APIs.
The callback-based scheme is intended to address three shortcomings in the
current registration scheme for JIT'd unwind info on Darwin: (1) Lack of
compact-unwind support, (2) inability to describe the subarchitecture of JIT'd
frames, and (3) lack of efficient address-based lookup data structures in
libunwind.
For more details see the proposed libunwind changes in
https://reviews.llvm.org/D142176.
