Summary:
This is the first mostly working version of the Sanitizer port to 32-bit Solaris/x86.
It is currently based on Solaris 11.4 Beta.
This part was initially developed inside libsanitizer in the GCC tree and should apply to
both. Subsequent parts will address changes to clang, the compiler-rt build system
and testsuite.
I'm not yet sure what the right patch granularity is: if it's profitable to split the patch
up, I'd like to get guidance on how to do so.
Most of the changes are probably straightforward with a few exceptions:
* The Solaris syscall interface isn't stable, undocumented and can change within an
OS release. The stable interface is the libc interface, which I'm using here, if possible
using the internal _-prefixed names.
* While the patch primarily target 32-bit x86, I've left a few sparc changes in. They
cannot currently be used with clang due to a backend limitation, but have worked
fine inside the gcc tree.
* Some functions (e.g. largefile versions of functions like open64) only exist in 32-bit
Solaris, so I've introduced a separate SANITIZER_SOLARIS32 to check for that.
The patch (with the subsequent ones to be submitted shortly) was tested
on i386-pc-solaris2.11. Only a few failures remain, some of them analyzed, some
still TBD:
AddressSanitizer-i386-sunos :: TestCases/Posix/concurrent_overflow.cc
AddressSanitizer-i386-sunos :: TestCases/init-order-atexit.cc
AddressSanitizer-i386-sunos :: TestCases/log-path_test.cc
AddressSanitizer-i386-sunos :: TestCases/malloc-no-intercept.c
AddressSanitizer-i386-sunos-dynamic :: TestCases/Posix/concurrent_overflow.cc
AddressSanitizer-i386-sunos-dynamic :: TestCases/Posix/start-deactivated.cc
AddressSanitizer-i386-sunos-dynamic :: TestCases/default_options.cc
AddressSanitizer-i386-sunos-dynamic :: TestCases/init-order-atexit.cc
AddressSanitizer-i386-sunos-dynamic :: TestCases/log-path_test.cc
AddressSanitizer-i386-sunos-dynamic :: TestCases/malloc-no-intercept.c
SanitizerCommon-Unit :: ./Sanitizer-i386-Test/MemoryMappingLayout.DumpListOfModules
SanitizerCommon-Unit :: ./Sanitizer-i386-Test/SanitizerCommon.PthreadDestructorIterations
Maybe this is good enough the get the ball rolling.
Reviewers: kcc, alekseyshl
Reviewed By: alekseyshl
Subscribers: srhines, jyknight, kubamracek, krytarowski, fedor.sergeev, llvm-commits, #sanitizers
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D40898
llvm-svn: 320740
This saves ~2 MB of dirty memory footprint. Can be a big deal on mobile devices especially when running multiple processes with ASan.
Differential Revision: https://reviews.llvm.org/D40627
llvm-svn: 320660
In more recent Linux kernels with 47 bit VMAs the layout of virtual memory
for powerpc64 changed causing the address sanitizer to not work properly. This
patch adds support for 47 bit VMA kernels for powerpc64 and fixes up test
cases.
https://reviews.llvm.org/D40908
There is an associated patch for trunk.
Tested on several 4.x and 3.x kernel releases.
llvm-svn: 320110
Following patch adds support of all memory origins in
CheckForInvalidPointerPair function. For small difference of pointers,
it's directly done in shadow memory (the limit was set to 2048B).
Then we search for origin of first pointer and verify that the second
one has the same origin. If so, we verify that it points either to a same
variable (in case of stack memory or a global variable), or to a same
heap segment.
Committing on behanf of marxin and jakubjelinek.
Reviewers: alekseyshl, kcc
Subscribers: llvm-commits
Differential revision: https://reviews.llvm.org/D40600
llvm-svn: 319668
ASan requires that the min alignment be at least the shadow
granularity, so add an init function to do that.
Differential Revision: https://reviews.llvm.org/D39473
llvm-svn: 318717
Summary:
This change reverts r318575 and changes FindDynamicShadowStart() to
keep the memory range it found mapped PROT_NONE to make sure it is
not reused. We also skip MemoryRangeIsAvailable() check, because it
is (a) unnecessary, and (b) would fail anyway.
Reviewers: pcc, vitalybuka, kcc
Subscribers: srhines, kubamracek, mgorny, llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D40203
llvm-svn: 318666
Revert the following commits:
r318369 [asan] Fallback to non-ifunc dynamic shadow on android<22.
r318235 [asan] Prevent rematerialization of &__asan_shadow.
r317948 [sanitizer] Remove unnecessary attribute hidden.
r317943 [asan] Use dynamic shadow on 32-bit Android.
MemoryRangeIsAvailable() reads /proc/$PID/maps into an mmap-ed buffer
that may overlap with the address range that we plan to use for the
dynamic shadow mapping. This is causing random startup crashes.
llvm-svn: 318575
Rather than assertion failing, we can fall back to the
non-optimized version which works for any shadow scale.
Differential Revision: https://reviews.llvm.org/D39474
llvm-svn: 318460
The requirement is that shadow memory must be aligned to page
boundaries (4k in this case). Use a closed form equation that always
satisfies this requirement.
Differential Revision: https://reviews.llvm.org/D39471
llvm-svn: 318421
Allow user to override shadow scale in compiler_rt by passing
-DCOMPILER_RT_ASAN_SHADOW_SCALE=n to CMake. Propagate the override
shadow scale value via a compiler define to compiler-rt and asan
tests. Tests will use the define to partially disable unsupported
tests. Set "-mllvm -asan-mapping-scale=<n>" for compiler_rt tests.
Differential Revision: https://reviews.llvm.org/D39469
llvm-svn: 318038
Summary:
The following kernel change has moved ET_DYN base to 0x4000000 on arm32:
https://marc.info/?l=linux-kernel&m=149825162606848&w=2
Switch to dynamic shadow base to avoid such conflicts in the future.
Reserve shadow memory in an ifunc resolver, but don't use it in the instrumentation
until PR35221 is fixed. This will eventually let use save one load per function.
Reviewers: kcc
Subscribers: aemerson, srhines, kubamracek, kristof.beyls, hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D39393
llvm-svn: 317943
When building LLVM on x86_64-pc-linux-gnu (Fedora 25) with the bundled gcc 6.4.1
which uses gld 2.26.1-1.fc25, the dynamic/Asan-i386-calls-Dynamic-Test and
dynamic/Asan-i386-inline-Dynamic-Test tests failed to link with
/usr/bin/ld: /var/scratch/gcc/llvm/dist/lib/clang/6.0.0/lib/linux/libclang_rt.asan-i386.so: fork: invalid version 21 (max 0)
/var/scratch/gcc/llvm/dist/lib/clang/6.0.0/lib/linux/libclang_rt.asan-i386.so: error adding symbols: Bad value
I tried building with a self-compiled gcc 7.1.0 using gld 2.28, but the error remained.
It seems the error has been hit before (cf. https://reviews.llvm.org/rL314085), but
no real explanation has been found.
However, the problem goes away when linking the i386 libclang_rt.asan with a version
script just like every other variant is. Not using the version script in this single case
dates back to the initial introduction of the version script in r236551, but this change
was just checked in without any explanation AFAICT.
Since I've not found any other workaround and no reason for not always using the
version script, I propose to do so.
Tested on x86_64-pc-linux-gnu.
Patch by Rainer Orth.
Differential Revision: https://reviews.llvm.org/D39795
llvm-svn: 317738
ASan allocator stores the requested alignment for new and new[] calls
and on delete and delete[] verifies that alignments do match.
The representable alignments are: default alignment, 8, 16, 32, 64, 128,
256 and 512 bytes. Alignments > 512 are stored as 512, hence two
different alignments > 512 will pass the check (possibly masking the bug),
but limited memory requirements deemed to be a resonable tradeoff for
relaxed conditions.
The feature is controlled by new_delete_type_mismatch flag, the same one
protecting new/delete matching size check.
Differential revision: https://reviews.llvm.org/D38574
Issue: https://github.com/google/sanitizers/issues/799
llvm-svn: 316595
Summary:
They might not be mapped on some platforms such as Win64. In
particular, this happens if the user address is null. There will not be
any shadow memory 5*16 bytes before the user address. This happens on
Win64 in the error_report_callback.cc test case. It's not clear why this
isn't a problem on Linux as well.
Fixes PR35058
Reviewers: vitalybuka
Subscribers: kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D39260
llvm-svn: 316589
Summary:
Similar to NetBSD, in FreeBSD, the first returned entry when callbacks
are done via dl_iterate_phdr will return the main program. Ignore that
entry when checking that the dynamic ASan lib is loaded first.
Reviewers: eugenis, krytarowski, emaste, joerg
Reviewed By: eugenis, krytarowski
Subscribers: kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D39253
llvm-svn: 316487
Summary:
Purging allocator quarantine and returning memory to OS might be desired
between fuzzer iterations since, most likely, the quarantine is not
going to catch bugs in the code under fuzz, but reducing RSS might
significantly prolong the fuzzing session.
Reviewers: cryptoad
Subscribers: kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D39153
llvm-svn: 316347
Remove the redundant dependency on 'gtest' target from the dynamic tests
in non-MSVC environment. The tests reuse compiled objects
from ASAN_INST_TEST_OBJECTS, and therefore they have been built against
gtest already.
This both fixes the spurious dependency on 'gtest' target that breaks
stand-alone builds, and brings the dynamic tests more in line with
regular tests which do not pass this dependency
to add_compiler_rt_test() through generate_compiler_rt_tests().
Differential Revision: https://reviews.llvm.org/D38840
llvm-svn: 315620
Summary:
This change moves cxx-abi library in asan/ubsan/dd link command line
ahead of other libraries, such as pthread/rt/dl/c/gcc. Given that
cxx-abi may be the full libstdc++/libc++, it makes sense for it to be
ahead of libc and libgcc, at least.
The real motivation is Android, where in the arm32 NDK toolchain
libstdc++.a is actually a linker script that tries to sneak LLVM's
libunwind ahead of libgcc's. Wrong library order breaks unwinding.
Reviewers: srhines, danalbert
Subscribers: aemerson, kubamracek, mgorny, kristof.beyls, llvm-commits
Differential Revision: https://reviews.llvm.org/D38520
llvm-svn: 314948
dlclose itself might touch it, so better return it to the state it was
before. I don't know how to create a test for this as it would require
chaning dlclose itself.
llvm-svn: 314415
compunit's .data section. This vector is not poisoned. Because of this the
first symbol of the following section has no left red zone. As a result, ASan
cannot detect underflow for such symbols.
Poison ASan allocated metadata, it should not be accessible to user code.
This fix does not eliminate the problem with missing left red zones but it
reduces the set of vulnerable symbols from first symbols in each input data
section to first symbols in the output section of the binary.
Differential Revision: https://reviews.llvm.org/D38056
llvm-svn: 314365
Don't overwrite exit code in LSan when running on top of ASan in recovery mode
to avoid breakage of users code due to found leaks.
Patch by Slava Barinov.
Differential Revision: https://reviews.llvm.org/D38026
llvm-svn: 313966
This is used only to make fast = true in GetStackTraceWithPcBpAndContext
on SANITIZER_FREEBSD and SANITIZER_NETBSD and can be done explicitly.
llvm-svn: 313517
Kamil Rytarowski