This CL disables CFI for 32-bit ARM processes, which is broken due to
a compiler error in the most recent version of clang.
Bug: 35157333
Test: ENABLE_CFI=true m -j40 does not enable CFI for 32-bit processes
Change-Id: I6a6e1d14c8365da1056b4cbccad11ef2f15c70b2
Mips toolchain does not have ld.gold.
ARM change is a workaround for LLVM r290384.
Bug: 33678192
Test: make ENABLE_CFI=1
Change-Id: I77a127e0b472d5da10bf45a2983527a714339cb8
This CL ensures that the LOCAL_SANITIZE=cfi is not honored unless it
is enabled globally using ENABLE_CFI='true' first. This allows CFI to
be hidden behind a flag.
Bug: 30227045
Bug: 22033465
Test: m -j40 works and device boots
Test: cfi is correctly honored only when the global flag is set.
Change-Id: If4508ba448bd4260020483f9c11ee849bb419713
Also renames the variable from SANITIZE_ARCH to SANITIZE_TARGET_ARCH,
and makes it only apply to the device.
Bug: 29498013
Test: No change to build.ninja files with m -j SANITIZE_TARGET=address
Change-Id: Ib5f6ab448f5d96d2426c983308136670f9a55b7b
linker_asan is only needed by shared exectuables, prevent adding it as a
dependency of anything else. Avoids a dependency loop from
linker_asan -> linker -> linker_asan.
Change-Id: Id7744ad8a5901468518fac80741c75e764adb559
The idea is that targets with LOCAL_SANITIZE = signed-integer-overflow
and SANITIZE_TARGET=safe-stack should get both sanitizers.
This should work just fine for SANITIZE_TARGET=address, too.
Bug: 27729263
Change-Id: Ifee350da4877008fb061bc7f6c700e7fade405bc
* changes:
Build: Add module-level product configuration of sanitization
Build: Add option to restrict sanitization by owner
Build: Add option to restrict sanitization by architecture
-Wl,-no-undefined is currently disabled for any SANITIZE_TARGET. Limit that to
the sanitizers with a runtime library (i.e. address, thread).
Re-enable the relocation packer for ASan. This has been fixed upstream a long
time ago.
Bug: 27729263
Change-Id: I566df6104de816223dc1c519d41a87629ce9c47c
Only sanitizers that intercept stuff need that. For example,
SafeStack does not, and I think UBSan too.
Bug: 27729263
Change-Id: I413cd46cc6c6914a363a3c53da7954beacd8f0d8
To allow special sanitizer settings for modules shared between
products, add product-specific module settings.
This was copied from the product-specific dexopt settings.
Bug: 29498013
Change-Id: I17a96b975bb6ac7f4ffb3d5b08e2f00b21bd97a1
(cherry picked from commit bb5454b6db)
Add Make variable SANITIZE_NEVER_BY_OWNER to selectively
sanitize modules. By default, both are being sanitized. The
value of the variable is interpreted as a space or colon
separated list of owner names.
This can be used to create builds that lower the sanitization
burden by not sanitizing parts of the platform.
Bug: 29498013
Change-Id: Ib4412657fd38ff28a5c0863eddc2acde63c88ebb
(cherry picked from commit ea38d8e95d)
Add Make variable SANITIZE_ARCH to selectively sanitize binaries.
This uses the "bitness," i.e., 32 or 64, to potentially filter
the sanitization. By default, both are being sanitized.
This can be used to create builds that lower the sanitization
burden by not sanitizing "half" of the platform.
Bug: 29498013
Change-Id: I73e6d479f08a970ba912f4f63967d32f3487125f
(cherry picked from commit 0290a416c8)
This can be used to selectively disable individual sanitizers on a
target. For example, some parts of libc should be built with
SafeStack (when requested with SANITIZE_TARGET), but never with
AddressSanitizer. Current build rules specify LOCAL_SANITIZE := never
to disable AddressSanitizer; the idea is to change that to
LOCAL_NOSANITIZE := address thread.
Bug: 27729263
Change-Id: I2b770f2ce3faf6ad6798792327e96adb86fe4a4f
We're beginning to enforce (still warning) that NDK code only links to
other NDK code. So we should never need to link them to the address
sanitizer libraries.
This breaks down a bit when platform code starts depending on NDK-built
code, where the NDK-built code should be mostly the same as if it was
built with the platform, but has an implicit LOCAL_SANITIZE := never.
Even so, this change shouldn't make that worse, as we'll still compile
fine, and anything platform code that uses asan should pull in the
shared library.
Change-Id: I81b30b9edd971468c3cb1467f809f184807b505e
* When my_global_santitize is set and requires ASAN,
link with ASAN library even when local module is not
instrumented with ASAN, unless the local module is
the ASAN library itself.
* Add -Wl,--as-needed to my_ldflags for shared libraries
so that unneeded ASAN library would not become
a dependent of the built .so file.
* Change shared file and executable file link argument order
so that -Wl flags will have effect on linked-in libraries.
* Remove unused ADDRESS_SANITIZER_CONFIG_EXTRA_SHARED_LIBRARIES.
BUG: 27614834
Change-Id: I4eda6003f1f24e498cba91c043dbe1fabe522686
RPATH was used in order for ASan executables to prefer ASan libraries
under /data. Now ASan executables use a special loader (linker_asan),
which implements this logic. RPATH is no longer needed.
Change-Id: Ic7a39b022267b80bd0ce3e95a2e822eb308a1fba
This reverts commit f7dbab16ff.
Bug: 23396112
Switch from "-fsanitize-undefined-trap-on-error" to
"-fsanitize-trap=all". The former ends up accidentally leaving
unresolved calls to __ubsan* helper functions in the object file with
clang 3.8. The latter is used when we don't include address sanitizer,
and replaces any misbehavior with a direct call to abort().
Bug: 23396112
Switch from "-fsanitize-undefined-trap-on-error" to
"-fsanitize-trap=all". The former ends up accidentally leaving
unresolved calls to __ubsan* helper functions in the object file with
clang 3.8. The latter is used when we don't include address sanitizer,
and replaces any misbehavior with a direct call to abort().
Change-Id: I8a67461b45f5f1dd9f2d179b6b64a4ca905e999f
The sanitizer chosen by the environment (either by SANITIZE_TARGET or
SANITIZE_HOST) should be chosen over the one specified by the module.
Bug: http://b/23330588
Change-Id: I835b7d76e071fc0db2f859f98dfb9d7ff76af245
TSAN is not supported on 32-bit architectures. For non-multilib cases,
make its use an error. For multilib cases, don't use it for the 32-bit
case.
Change-Id: I8e40be4002379cc2c9aa98ab8b812b337d6e077e
Another change in bionic/linker adds linker_asan/linker_asan64 that
know where to find ASan shared libraries.
Also, include linker_asan to the required packages list when building
for ASan.
Change-Id: I8ebe7c0091bbeb0c135708a891d33d9844373d37
This is a temporary change pending code cleanup.
We are already disabling detection of ODR violations. As it turns out,
an ODR between an ASan-instrumented library and a non-instrumented library
may actually crash ASan, and there is no obvious way out, and one of those
prevents us from booting a SANITIZE_TARGET image right now.
Bug: 21951850
Change-Id: I49508242ec96089a3d4d8b7e45f36323d62f2be9
These symbols are defined in the ASan runtime library, which is always
present at runtime.
Bug:21785137
Change-Id: Ib8418c66323fd4cdfdc05548048f32380cb84ee5
This also does a bit of cleanup in config_sanitizers.mk. The result is
that `LOCAL_SANITIZE := <any arbitrary ubsan group>` should function
fine for both host and target.
This is a superset of LOCAL_DETECT_INTEGER_OVERFLOWS, so remove that.
This also checks integer division by zero. It's supposed to cover
shifting undefined behaviors as well, but apparently it does not
(though `LOCAL_SANITIZE := shift` works fine).
Change-Id: I4ac99eafa6920a3f8cb82af37ce56ff0fdb95223
The same as SANITIZE_HOST, but for the target.
Also, skip all LOCAL_FORCE_STATIC_EXECUTABLE targets, as ASan does not
support static linking.
Bug: 21785137
Change-Id: Ief53ff8de1fee18f230d6c7dd31845db5bbd415c
I've migrated all users of this to the new option now, so we can drop
this.
Dropping `SANITIZE_HOST := true` will have to wait until the build
server configs have been updated.
Change-Id: I591436e197a6c6c079a6cd6a2decb702b574cd71
Add build system support for LOCAL_DETECT_INTEGER_OVERFLOWS. When enabled,
an attempt to perform an integer arithmetic operation which overflows
will result in a call to abort(). This is intended for security
sensitive code, where integer overflow operations are not expected
nor desirable.
Two classes of underflows/overflows are detected and blocked:
1) Signed integer underflow/overflow.
2) Unsigned integer underflow/overflows.
Signed integer overflows are undefined behavior, according to the
C standard. Unsigned integer overflows are defined behavior, but
still undesirable in security sensitive code.
Only clang is supported today. gcc has -ftrapv for handling signed
integer overflow, but it's widely considered broken
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35412) and we're
deliberately avoiding it's use here.
Change-Id: Ib4918dc84e37e83d4205e5035544545d91671e5f
Vaguely-Related-Bug: 11859726
The relocation packer is causing the kernel to load the executable
overlapping ASAN's shadow space.
Bug: http://b/20665974
Change-Id: Ifc5914f4fbed5f4f00ed1c795d01cf2fcb849cfe
Always link libm with asan. Hasn't been a problem before because ASAN
was only ever used when libc++ was as well, which already links libm.
Pass --no-as-needed for host modules.
These aren't needed for the target builds because the target uses the
shared RTL.
Change-Id: I5d6a3c2dd557b5231be2b7711df6438693753a88
ASan runtime library (when using dynamic linking) must be the first
dependency of the main executable to achieve correct symbol
interposition. This matches how the clang driver works.
In multilib setup, ASan-RT name depends on the target arch:
/system/lib/libclang_rt.asan-arm-android.so
/system/lib64/libclang_rt.asan-arm64-android.so
We also set RPATH to /system/lib/asan or /system/lib64/asan
to have a place for ASan-only versions of system libraries.
Change-Id: I5c0cdb89e5e08a1950eb276e406da9f31a6e52dd
This is needed for projects that have known ubsan issues that we can't
fix right away (perhaps because it's an upstream project that we're
diligent about keeping in sync with upsteam).
Also make the normal ubsan use -fno-sanitize-recover=all by default.
Change-Id: I1b0f3309792f32dbd08c18816d7306e76c8d7c30
Some of the ubsan checks expose a few pathological performance cases
in clang, and thus aren't suited to be used in SANITIZE_HOST.
This mode is also supported on the target despite not having the
target runtime libraries for ubsan by generating traps.
Change-Id: I0b0f0a08ca84d72e44e2174a66726b1c5e5cad7e
