This change fixes a problem in sanitizerMutator where a module is linked
with of non-sanitized variant of a lib at build-time, but is linked with
the sanitized variant of the lib at run-time.
This happened because, for each sanitizer type, every shared libs are
split into non-sanitized and sanitized variants, and then either of the
variants are suppressed from Make so that it isn't installed to the
device.
This change fixes the problem by NOT splitting for shared libs; only the
sanitized variant is created if needed. Header libs, static libs and
shared libs for a few sanitizer types (asan/fuzzer) are however split
into two. This is because the static and headers libs become part of the
depending module, and asan/fuzzer require that the depending module and
the dependant module should be compiled for the same sanitizer.
Bug: 138103882
Bug: 138426065
Test: m com.android.runtime.debug
Check that libziparchive exists under both
/system/apex/com.android.runtime/[lib|lib64]
Change-Id: Ia447785c485c0d049e19477b32bc638bfe6f1608
Bug: 131771163
LTO is currently broken when building with SANITIZE_TARGET=fuzzer. The
compiler bug is currently being addressed upstream (see linked bug), but
we have applied a local workaround in the build system to disable LTO
when building using the fuzzer config.
There is a bug here however. In the sanitizer mutator we explicitly
remove -flto and add -fno-lto. The sanitizer mutator runs after the LTO
mutator, so (in general) this works just fine. The problem exists when a
target specifies an explicit 'lto: { ... }' flag in their Android.bp. In
this case, the sanitizer mutator disables LTO, then the flags are parsed
from the Android.bp, re-enabling LTO.
This patch fixes this issue. If the sanitizer mutator has added the
-fsanitize=fuzzer-no-link flags, then the LTO mutator won't add the LTO
flags after this fact.
Test: Build a target with SANITIZE_TARGET=fuzzer (or a cc_fuzz target),
where there is an explitiy 'lto: { ... }' and watch it now succeed in
building.
Change-Id: I6643909417f666539c23469816926b806e204b06
We already link the shared prebuilt from the toolchain. This is
redundant and the wrong version.
Test: make checkbuild
Bug: http://b/74067984
Change-Id: I4b5d23514158eebfb4eea2aa6761e076131c3224
ASan globals instrumentation apparently broke the build in the pass.
This is now a customer feature to get this up and running, let's see if
it works.
Bug: 137312732
Test: Build the platform, deploy and run an asan-ified test (maybe
resolv_integration_test?).
Change-Id: Ic4ee0db617c290d8a3fec52db4b90bc4772696b8
sanitizerRuntimeDepsMutator only modifies the currently visited
module, it can visit modules in parallel.
Also, stop recursing into modules that are not static dependencies,
and stop recursing if the module already has all modifications that
the mutator could make.
Test: m checkbuild
Change-Id: I95a57f763a91940f1854ba3c587a2f70e8baba97
Sanitizer coverage is currently broken with the experimental pass
manager. See b/133876586 for more information. The patch is currently
being worked on upstream (https://reviews.llvm.org/D62888), but is not
ready yet. Hence, we disable it here (similar to the LTO bug).
Bug: 133876586
Test: Build anything with SANITIZE_TARGET='fuzzer', verify that it has
'sancov' symbols.
Change-Id: I4302a8cf05300015aaff137f40b61d5685dc3fea
Current Android toolchain does not support hwasan with new pm.
Bug: 135298400
Test: manual, inspect the binaries for calls to __hwasan_init
Change-Id: I126c59e6ecabc3a1699e1bf34c546568b6e8a21f
- Updates the fuzzer builds to use SANITIZE_TARGET='fuzzer' instead of
'coverage'.
- Removed an old dependency that made fuzzer builds without ASan
an error.
- Fixed up the build flags to allow fuzzers to be built. Previously, the
coverage flags were manually provided. As the toolchain has moved on,
these flags are no longer compatible with libFuzzer, and so I've updated
them to use the correct, compatible flags.
- Added a dependency mutator for fuzzer coverage.
Bug: 121042685
Test: With all patches in the bug merged, build a fuzzer using
'SANITIZE_TARGET=fuzzer mmma <your_fuzzer>'.
Change-Id: Ib6246980f77bc4babe587b1e88038aa12228fa83
Merged-In: Ib6246980f77bc4babe587b1e88038aa12228fa83
- Updates the fuzzer builds to use SANITIZE_TARGET='fuzzer' instead of
'coverage'.
- Removed an old dependency that made fuzzer builds without ASan
an error.
- Fixed up the build flags to allow fuzzers to be built. Previously, the
coverage flags were manually provided. As the toolchain has moved on,
these flags are no longer compatible with libFuzzer, and so I've updated
them to use the correct, compatible flags.
- Added a dependency mutator for fuzzer coverage.
Bug: 121042685
Test: With all patches in the bug merged, build a fuzzer using
'SANITIZE_TARGET=fuzzer mmma <your_fuzzer>'.
This is the qt-dev-plus-aosp cherrypick of aosp/954925. See the AOSP
commit for further information.
Change-Id: Ib6246980f77bc4babe587b1e88038aa12228fa83
HWASan has a feature to fill malloc() memory with non-zero pattern.
This has found a bug or two in the past, but it also keep causing hard
to debug issues. The main problem is lack of diagnostics - use of
pattern-initialized memory is not an immediate crash. More often than
not it manifests as a subtle change in system behavior.
Having MemorySanitizer on Android would be nice...
This change does not affect any shipping configuration, but improves
stability of testing-only SANITIZE_TARGET=hwaddress build.
Bug: 132803232
Bug: 132652537
Bug: 131438232
Bug: 132810685
Test: SANITIZE_TARGET=hwasan on crosshatch successfully boots in ~100%
attempt (up from ~99% currently).
Change-Id: I7dcbcdf1b8a5b8556e32690327b32f04879e5db1
Running any executable built with asan and libc_scudo results in crashes.
Bug: 131810078
Test: Built the media processes with the sanitizer enabled verifying
Test: that the libc_scudo.so shared library is not listed in the
Test: mediaextractor and the mediaswcodec binaries.
Test: Build the media processes without the sanitizer enabled verifying
Test: that the libc_scudo.so shared library is listed in the
Test: mediaextractor and the mediaswcodec binaries.
Change-Id: Ie55a0414088787ec11d85fffcb04592ed4f23c57
Disable a debugging feature in hwasan that seems to be causing flaky selinux
denials in the boot test:
05-02 12:11:11.360 1663 1663 I auditd : type=1400 audit(0.0:8): avc: denied { read } for comm="iptables-wrappe" path="/proc/1015/statm" dev="proc" ino=30968 scontext=u:r:netutils_wrapper:s0 tcontext=u:r:netmgrd:s0 tclass=file permissive=0
I could not reproduce this locally, but this feature has no users and
I've verified that things keep working without it.
This does not affect any shipped product.
Bug: 131438232
Bug: 112438058
Bug: 131845076
Test: crosshatch_hwasan boot test
Change-Id: I08d46d19151e6d5221cdd56fd6864dae224fae25
Now that the toolchain and bionic both support ifuncs in
static executables, we can turn this on. Reduces size of
walleye_hwasan-userdebug system.img by 11MB.
Change-Id: I2f19b22518153328eee3fdca79d0c851cc513c3a
The properties are no longer required as an APEX module is mutated with
required sanitizers which are gathered by scanning the sanitizers that
are enabled for its direct dependencies.
Bug: 124128094
Test: m on marlin
The extractor libs are found under /system/apex/com.android.media
Merged-In: I55961d400dcbac067a5c0dcecb90e399d4991a70
Change-Id: I55961d400dcbac067a5c0dcecb90e399d4991a70
(cherry picked from commit abda0eb76b)
Add an opaque OnceKey type and use it for all calls to Once in
build/soong. A future patch will convert the arguments to
Once* to OnceKey once users outside build/soong have been updated.
Test: onceper_test.go
Change-Id: Ifcb338e6e603e804e507203c9508d30ffb2df966
This adds an option in Soong to turn off Scudo globally.
Bug: 123228023
Test: enable Scudo for tombstoned, lunch marlin_svelte-eng && m -j, and
make sure that Scudo is not linked in
out/target/product/marlin/system/bin/tombstoned
Test: enable Scudo for tombstoned, lunch marlin-userdebug && m -j, and
make sure that Scudo is linked in
out/target/product/marlin/system/bin/tombstoned
Change-Id: I0b0992446953fc4074bde94507b66f92764c8143
Merged-In: I0b0992446953fc4074bde94507b66f92764c8143
This change the asan version of
https://android-review.googlesource.com/c/platform/build/soong/+/879237
Bug: 123725034
Test: forrest run on asan_cf_x86_pasan
Test: SANITIZE_TARGET=address m init_second_stage
inspect /system/bin/init with readelf
DT_INTERP is set to /system/bin/bootstrap/linker_asan
Change-Id: I0fabe08cc63126aadec18ca8e9f2973c33411a4f
-hwasan-with-ifunc=0 matches the default value of the flag, and there
are no plans to change that.
Test: SANITIZE_TARGET=hwaddress keeps working
Change-Id: Ie46ffa6ae3c42a9677c3a9a3b5cdc6fb62c2c2f0
Fixing the problem that IsSanitizerEnabled always returns false due to
the different sanitizer names from config.SanitizerDevice() and
sanitizerType.String().
Bug: 123708856
Test: SANITIZE_TARGET=hwaddress m com.android.runtime.release
$ ls -al out/soong/.intermediates/art/build/apex/com.android.runtime.release/android_common_hwasan_com.android.runtime.release/image.apex/lib | wc -l
34
$ ls -al out/soong/.intermediates/art/build/apex/com.android.runtime.release/android_common_hwasan_com.android.runtime.release/image.apex/lib64 | wc -l
35
$ ls -al out/target/product/blueline/apex/com.android.runtime.release/lib | wc -l
34
$ ls -al out/target/product/blueline/apex/com.android.runtime.release/lib64 | wc -l
35
Test: inspect out/soong/build.ninja
- Variant of com.android.runtime.release is "android_common_hwasan_com.android.runtime.release"
- Dependencies of com.android.runtime.release are hwasan variants: e.g.,
out/soong/.intermediates/bionic/libc/libc/android_arm64_armv8-2a_kryo385_core_shared_hwasan_com.android.runtime.release/libc.so
Test: ls out/soong/.intermediates/art/build/apex/com.android.runtime.release/android_common_hwasan_com.android.runtime.release/image.apex/lib64/*.so | xargs readelf -d | grep libclang_rt.hwasan | wc -l
29
Change-Id: Idbb1f68a3ea6bdd02351d6f6048c3eedb9cf32d2
This change fixes a bug that sanitizer runtime libs for non-core variant
(e.g. recovery, vendor, etc.) are not installed. It happened because the
dependency to the sanitizer runtime lib was without 'image' variant,
which in most case caused only the core variant - which is the first in
the image variants - of the lib to be installed.
Fixing the issue by correctly selecting image variant depending on the
location of the lib having dependency to the runtime lib.
Bug: 123525879
Test: SANITIZE_TARGET=hwaddress m out/target/product/blueline/boot.img
Test: SANITIZE_TARGET=address m out/target/product/blueline/boot.img
libclang_rt.*.so is under
out/target/product/blueline/root/recovery/system/lib64
Change-Id: Iea7d718d4971e36521f0a3f712a454de944cd7ac
This fixes a problem that APEX is unconditionally mutated for all
sanitizer types. This can make an APEX to include sanitized version
of a lib even when SANITIZE_TARGET is not set. It can happen when lib X
is directly depended on by an APEX (e.g. via native_shared_libs) and X
has a sanitized variant due to the dependency from another library Y
which is force sanitized (via 'sanitize' property). In that case,
regardless of lib Y is in the APEX or not, the APEX chooses the
sanitized variant of lib X since the dependency from APEX to the lib is
created with AddFarVariationDependency.
Fixing this problem by mutating the APEX for a sanitizer type only when
the device is requested to be sanitized.
Bug: 122717287
Test: add libnetd_client to com.android.runtime APEX.
Inspect build.ninja to verify that libnetd_client.so in the runtime APEX
is not a sanitized one.
Change-Id: I918bc8407137d74c5456142b3a29de13df68c0b3
Introduce a new tag earlySharedDepTag which is added in front of the
ordinary sharedDep dependencies. Dependency to the ASAN runtime lib is
added with the new tag.
Bug: 120894259
Bug: 121038155
Test: m; SANITIZE_TARGET=address m
Use readelf -d to see if the runtime lib is in the first DT_NEEDED one.
Change-Id: I90de6ab95df734a99995532d826564b13fe05316
Bug: http://b/123254047
This reverts commit 84757ea7ea.
Reason for revert: veridex asan failure is fixed.
Change-Id: Id03180b8d3d1dc1386fd7e4f800d64dc8578139c
This CL adds configs for the arm64 and x64 fuchsia
device targets, sets up the necessary linker flags,
and disables some functionality that is not currently
supported on Fuchsia.
Bug: 119831161
Test: Compile walleye, internal validation against
fuchsia_arm64-eng and fuchsia_x86_64-eng.
Change-Id: I2881b99d2e3a1995e2d8c00a2d86ee101a972c94
This change first introduces the interface "Sanitizeable" that
module types other than cc.Module can use to be handled by the sanitizer
mutator. APEX module, by implementing the interface, gets sanitizer
variants.
In doing so, sanitizer.go is refactored so that modules have explicit
dependencies to the runtime sanitizer libraries. This allows the runtime
library to be packaged into the APEX when required. This also completes
the dependency graph; updating the prebuilt sanitizer runtime will
trigger rebuilding of modules using the runtime.
Bug: 120894259
Bug: 121038155
Test: SANITIZE_TARGET=hwaddress m apex.test
Test: TARGET_FLATTEN_APEX=true SANITIZE_TARGET=address m
Change-Id: Ia91576ff48cda3c996350308b75bf83fcf7c23d7
Add a no_recover option that allows specifying which sanitizers in
diagnostics modes shouldn't recover. This can help debugging as we test
enabling sanitizers in new libraries since it'll cause tombstones to be
generated along with the diagnostics information.
Bug: 80195448
Bug: 110791537
Test: Compiled test module with this flag, checked compiler command.
Test: Test module crashed, tombstone contained diagnostics information.
Change-Id: Ie938923ef95716c2d49d6cd719ee223ad62755c6
Current implementation does not play nice with -gc-sections.
Bug: 120673911
Test: make SANITIZE_TARGET=hwaddress recovery-persist
Change-Id: I36cd37fb41c0c26c7e747e2c1dd5fadf7a31f4e7
* Add -fno-sanitize=implicit-integer-sign-change when
there is any integer related sanitizer, and this check
is not explicitly specified.
Android core does not boot with this new sanitizer yet.
* Filter out -fno-sanitize=implicit-integer-sign-change
from tooling flags.
Bug: 119329758
Bug: 119557795
Test: make checkbuild, boot, go/clang-r346389-testing
Change-Id: I709de569cb73d070fc4958e2b4387f4041bc5438
Make sanitized targets in recovery depend on ".recovery" flavor of
sanitizer runtime library. This forces installation of the runtime
library in recovery image as long as at least one target depends on it.
Test: hwasan build can boot into recovery
Bug: 112438058
Bug: 119582521
Change-Id: I1b7f9fa4ff5f29acb03c27074512ea24467a3d37
Shadow call stack (SCS) is a security mitigation that uses a
separate stack (the SCS) for return addresses.
The effect of setting sanitize.scs on a shared library is to build
the library and all of its static library dependencies with SCS. This
is similar to CFI and the other sanitizers.
Bug: 112907825
Bug: 119557795
Change-Id: I82fb2b38b10eac911c4d2d120b74fea4af0622ad
