CFI modules can't link against non-CFI static libraries, and vice versa.
So without capturing both CFI and non-CFI static libraries, vendor
modules won't be able to use CFI, which will be a critical security
hole.
This captures both CFI and non-CFI variants of all static libraries for
vendor snapshot, except for those whose cfi are explicitly disabled.
For example, suppose that "libfoo" is defined as follows.
cc_library_static {
name: "libfoo",
vendor_available: true,
}
As it doesn't have cfi disabled, two libraries "libfoo.a" and
"libfoo.cfi.a" will be captured. When installed, vendor snapshot module
for "libfoo" will look like:
vendor_snapshot_static {
name: "libfoo",
src: "libfoo.a",
cfi: {
src: "libfoo.cfi.a",
},
}
The build system will recognize the "cfi" property, and will create both
CFI and non-CFI variant, allowing any modules to link against "libfoo"
safely, no matter whether CFI is enabled or not.
Two clarification:
1) The reason why we don't create separate modules is that DepsMutator
runs before sanitize mutators. CFI and non-CFI variant of a library
should exist in a single module.
2) We can't capture CFI variant if the source module explicitly disables
cfi variant by specifying the following.
sanitize: {
cfi: false,
}
In this case, only non-CFI variant will be created for the vendor
snapshot module.
Bug: 65377115
Test: m dist vendor-snapshot && install && build against snapshot
Change-Id: Idbf3e3205d581800d6093c8d6cf6152374129ba4
Dependencies of makefile modules are being redirected according to
SOONG_CFI_STATIC_LIBRARIES and SOONG_HWASAN_STATIC_LIBRARIES. But the
variables are shared among all variants (e.g. core, vendor, product,
arch), which can cause build error.
This splits the Makefile variables into several lists, one list per each
arch and each image variant, to correctly make the redirection.
Bug: 162476652
Test: build and inspect ninja
Change-Id: Icc753382f1c53de8468cc85243a6954e1986297a
All uses of this property have been migrated to 'blocklist' instead.
Update language to comply with Android’s inclusive language guidance
See https://source.android.com/setup/contribute/respectful-code for
reference
Bug: 161896447
Bug: 162245450
Test: TH
Change-Id: I4b83b41ad5a4b2caf1166b1acece9537f545aaad
dependencyTag uses a set of predefined tags to identify different types
of dependencies. There are already multiple bits of metadata stored
in the dependency tag (Library, Shared, ReexportFlags), and supporting
them all requires a combinatorial explosion of predefined tags and
causes issues when using equality comparisons if a new bit of metadata
is added.
Add a new libraryDependencyTag type that will contain the metadata
bits, and replace the quality comparisons with checks on the metadata
bits.
There are 5 TODOs where modifying the checks identified problems with
the existing checks. These were left in place to produce identical
build output and will be fixed separately.
Bug: 162437057
Test: no change to build.ninja or {Android,make_vars,late}-${TARGET_PRODUCT}.mk
Change-Id: I72d4207dcf381c07c92e00e5a03968ebb5ed8d30
Bug: 162024969
Test: Successfully builds targets for both host and device
"writeonly" flag in SANITIZE_(HOST|TARGET) enables it with "address"
and "hwaddress"
Change-Id: Ia89d43230deef15a67dee09ed015fea14f0717ff
This will eventually replace the Blacklist property.
Update language to comply with Android’s inclusive language guidance
See https://source.android.com/setup/contribute/respectful-code for
reference
Bug: 161896447
Bug: 162245450
Test: build topic
Change-Id: I3c2609c791c27b8ba3bcb55f79304b78bce1f518
There're two ways to enable hwasan:
- global setting: TARGET_SANITIZE=hwaddress
- individual setting: sanitize: { hwaddress: true }
This change covers both cases by looking up if com.android.runtime is
hwaddress santized or not.
Bug: 156678661
Test: m (soong test added)
Change-Id: I67c382c3e76a06f4b27f221eebd153c698647227
This was causing build breaks when different devices moved to Android.bp
at different times.
Bug: 150878976
Test: build *_hwasan targets
Change-Id: I68912bb6a5696809c318d1ec816a1bcfbe2df245
Merged-In: I68912bb6a5696809c318d1ec816a1bcfbe2df245
(cherry picked from commit 7b6af23db6)
Also remove a deprecated flag -fsanitize-hwaddress-abi=platform.
Switching to the new pass manager reduces size of the "lib64" directory
by almost 6%.
Bug: 135298400
Test: objdump -d path/to/symbols/system/lib64/*.so | grep __hwasan_check_
Test: adb shell sanitizer-status
Change-Id: I327ee982e20c02b3b2126d93189048d9f4bfb301
Host binaries by default use the UBSan runtime whether or not
diagnostics are requested in the module definition. The rest of the code
assumes the runtime is only needed when diag properties are set.
This makes sure to add the runtime to the dependency graph of host
binaries that are UBSanitized.
Bug: 150336284
Test: ./art/tools/dist_linux_bionic.sh com.android.art.host
Test: runtime appropriately identified as a dependency of libziparchive
Change-Id: I2704aaba4abc7f4e6d96747917c77b5147fd1d56
Only disable CFI on incompatible variants rather than the base module.
Bug: 142157676
Test: Manual llvm-cfi-verify checks
Change-Id: I999e1dbcccc1ffb102b2fe01c47f1bda4df5e601
Use AndroidMkEntries so the next patch can use ExtraFooters, which
doesn't exist in AndroidMkData.
Test: manually diff out/soong/Android.aosp_x86_64.mk
Change-Id: Ia3006b6747813693cf7e2b536030b21f3109f538
Linux host prebuilts for UBSan runtime are available now, so we can
enable these. There's a bit more work to be done for Windows/Darwin
support, so that's left to another CL.
Bug: 148289941
Test: Build host binary with integer overflow sanitization enabled.
Test: ./art/test/testrunner/run_build_test_target.py art-linux-bionic-x64
Change-Id: Ie98979116fa3bb8accb23d1788adcc28330a9530
This implements four modules (static/shared/header libraries, and
binaries) for vendor snapshot. These modules will override source
modules if BOARD_VNDK_VERSION != current.
Bug: 65377115
Test: 1) VNDK_SNAPSHOT_BUILD_ARTIFACTS=true m dist vndk vendor-snapshot
Test: 2) install snapshot under source tree
Test: 3) set BOARD_VNDK_VERSION and boot cuttlefish
Change-Id: I24ddb4c3aa6abeab60bbfd31bcbd8753e2592dc5
Vendor snapshot can be captured with "m dist vendor-snapshot". With
vendor snapshot and vndk snapshot, older version of /vendor and newer
version of /system will be able to be built together by setting
BOARD_VNDK_VERSION to past vendor's version.
Only vendor modules under AOSP are to be captured. In detail, modules
under following directories are ignored:
- device/
- vendor/
- hardware/, except for interfaces/, libhardware/, libhardware_legacy/,
and ril/
Test modules (cc_test, etc.) and sanitized modules are also ignored.
Bug: 65377115
Test: m dist vendor-snapshot
Change-Id: If7a2f6de7f36deee936930c0ccf7c47c4a0cebf6
Build fuzzer-sanitized libraries with an $ORIGIN DT_RUNPATH. Android's linker
uses DT_RUNPATH, not DT_RPATH. When we deploy cc_fuzz targets and their
libraries to /data/fuzz/<arch>/lib, any transient shared library gets the
DT_RUNPATH from the shared library above it, and not the executable, meaning
that the lookup falls back to the system. Adding the $ORIGIN to the DT_RUNPATH
here means that transient shared libraries can be found colocated with their
parents.
This may have some interesting consequences if:
1. Your fuzz target depends on a shared library which has `sanitize.fuzzer:
false` (as the DT_RUNPATH won't have `$ORIGIN`, and so you may get missing
libraries).
2. A `SANITIZE_TARGET=fuzzer` platform has a shared object in two
different directories (like system vs. ndk) and is depending on the linker
implementation details to resolve this in some manner.
I don't believe either of these instances should reasonably happen in
practise.
Fixes: 145973404
Fixes: 145988908
Test: m example_fuzzer
Change-Id: I94cbf628fc1ce15c43283d72bdabd9817de1fef8
This is a workaround to improve hwasan reports involving stack
variables.
Bug: 112437883
Test: SANITIZE_TARGET=hwaddress, build and boot
Change-Id: I21ea2fdd2d1f04e2bb9b9847785c00a951030c74
Prepare for making the image mutator available to all modules and
moving it between the os and arch mutators by moving it into the
android package and using an interface implemented by the module
types to control it.
Bug: 142286466
Test: No unexpected changes to out/soong/build.ninja
Change-Id: I0dcc9c7b5ec80edffade340c367f6ae4da34151b
Native compiler flags are currently applied in approximately:
global cflags
local cflags
local include dirs
global include dirs
global conlyflags
local conlyflags
global cppflags
local cppflags
This means that a flag that is enabled in the global cppflags
cannot be disabled in the local cflags, and an Android.bp author
must know to disable it in the local cppflags. A better order
would be:
global cflags
global conlyflags
global cppflags
local cflags
local conlyflags
local cppflags
local include dirs
global include dirs
We are mixing both the global and local cflags into a single
variable, and similar for conlyflags and cppflags, which
prevents reordering them. This CL prepares to reorder them
by splitting the global and local cflags into separate variables.
Bug: 143713277
Test: m native
Change-Id: Ic55a8c3516c331dc5f2af9d00e59ceca9d3e6c15
This is a follow-up CL of I9a24f6975bd4b226a94f61a13d43857dcdce6b88
Generated files are passed to make via MakeVars:
- SOONG_LLNDK_LIBRARIES_FILE
- SOONG_VNDKCORE_LIBRARIES_FILE
- SOONG_VNDKSP_LIBRARIES_FILE
- SOONG_VNDKPRIVATE_LIBRARIES_FILE
- SOONG_VNDKCOREVARIANT_LIBRARIES_FILE
- SOONG_VNDK_LIBRARIES_FILE
Previously filenames were "guessed" from module names. Now VndkMutator
stores filenames as well and generate those files with them.
Bug: 142963962
Bug: 141450808
Test: m && device boots && TH
Change-Id: I0c248b707188f904df60ead50059fefe90bfd17f
Adds the ability for rust modules to be compiled as C libraries, and
allows cc modules to depend on these rust-generated modules. This also
means that soong-rust should not have any dependencies on soong-cc aside
from what's required for testing.
There's a couple small fixes included as well:
- A bug in libNameFromFilePath that caused issues when library's had
"lib" in their name.
- VariantName is removed from rust library MutatedProperties since this
was unused.
Bug: 140726209
Test: Soong tests pass.
Test: Example cc_binary can include a rust shared library as a dep.
Test: m crosvm.experimental
Change-Id: Ia7deed1345d2423001089014cc65ce7934123da4
Adds an interface, CcLinkableInterface, for cc linkable dependencies
which come from other toolchains such as Rust.
Bug: 140726209
Test: Soong tests pass, rust modules still compile.
Change-Id: I7378a46fad94fd0b735746aaf4e265fd2c2c04d8
libdl.a has a no-op dlopen, which breaks static libraries that need a real
dlopen. Instead of automatically linking libdl.a into static executables,
make it optional.
Until recently, the libunwind_llvm.a unwinder, used on arm32, needed the
no-op dladdr, but it's now built using -D_LIBUNWIND_USE_DLADDR=0.
The HWASan run-time uses dlsym and dladdr, so add a libdl dependency for
HWASan-built static binaries. We could also remove the dependency from
libclang_rt.hwasan_static-*.a, but this is also easy to do.
Bug: http://b/141485154
Test: bionic unit tests, device boots, verify that static and dynamic
executables can throw/catch an exception
Test: verify that a static executable using dlopen doesn't link (unless it
adds an explicit dependency on libdl)
Change-Id: Ic52c3f336b671b4ed335e99c94a64dfe8614b618
The arch variants are hardcoded in every module type. Refactor
them out into a Target.Variations() method in preparation for
splitting the arch mutator into two, which will require using
different variations.
Test: m checkbuild
Change-Id: I28ef7cd5168095ac888fe77f04e27f9ad81978c0
Fuzz targets currently have dependencies on multiple libclang_rt runtime
libraries when building with ASan/HWAsan on device. This is an error.
This happens as Soong adds the dependency on the ASan/HWASan shared
runtime library. These libraries should provide the required UBSan
components. The clang driver was previously being passed
-fsanitize=fuzzer-no-link at link time, and as it doesn't know about the
already-established dependency on ASan/HWASan, it mistakenly thinks that
there is not runtime providing the UBSan components.
This patch fixes that problem by not adding -fsanitize=fuzzer-no-link to
the link-time flags.
This revealed a underlying issue in the upstream runtime compilation.
Android uses emulated TLS, which changes the symbol names from
<my_symbol_name> to __emutls_v._<my_symbol_name>. In particular, this
fails to account for the '__sancov_lowest_stack' symbol, as it no longer
matches the linker script rule for '__sancov*', and the symbol is no
longer exported in the shared library variant of ASan/HWASan.
This patch works around the discovered issue, which is being tracked in
the linked bug. It disables stack depth instrumentation, and we no
longer depend on this symbol. This means we get a missing sanitizer
coverage feature when fuzzing, but shouldn't be too detrimental.
Bug: 142430592
Test: SANITIZE_TARGET=hwaddress m example_fuzzer && \
readelf -d example_fuzzer # ensure only ONE libclang_rt dep (in this
case, hwasan)
Change-Id: Iea6df55d592a801732511c9b690134367429d62a
Without this change, we can end up failing to sanitize parts of libraries
that are compiled as cc_objects, such as bcm_object.o in boringssl. This
is normally harmless (except that the sanitizer would fail to detect bugs
in unsanitized code), however boringssl in particular needs to be compiled
with HWASAN enabled in all translation units in order to avoid link errors
with newer toolchains that support HWASAN global instrumentation.
Change-Id: Ib8bd325f76b7852cab435bff79d6945768298a5c
Disables FORTIFY for fuzz target builds. We generally build with a
sanitizer and want the sanitizer to handle the bugs and provide us with
a nice stack trace.
Bug: 140187921
Test: m example_fuzzer && $ANDROID_HOST_OUT/fuzz/example_fuzzer (note
that you get a proper ASan report instead of a fortify crash)
Change-Id: I15a117b26c401a03785fb44c0f796588f366bc55
This reverts commit cba311bcfc.
The build is actually still broken with ASAN globals instrumentation.
We accidentally suppressed ASAN by turning on the new pass manager and
the build breakage was not discovered.
Bug: 137312732
Bug: 139747256
Change-Id: I8110e1413468c4d760a59a8de816a72c9852a7c8
ASAN build has some weird issues with the new pass manager, keep using
the legacy pass manager for now.
Test: presubmit
Bug: 139747256
Change-Id: I345afbf6bc4043f274a4e7545a895b59c65641b0
Pirama Arumuga Nainar