Some projects are still built with our host GCC 4.8, which doesn't
support -fstack-protector-strong. The combo .mk files are used by
GCC and clang, so it's not safe to turn on -fstack-protector-strong
there. Instead, do it in the clang-specific .mk for now.
We can clean this up when elfutils (the last code built for the host
with GCC that I'm aware of) is built by clang. We'll be able to
remove the host GCC prebuilts too!
Change-Id: I314b9eab071c132a8e2cb8cc779a75ae8abb12e2
This results in nearly all functions with the possibility of stack
corruption getting stack canaries, because it applies to any function
taking a reference to the frame or with a local array rather than just
the functions with arrays larger than 8 bytes. It was developed for use
in Chrome (and Chrome OS) and has also been adopted by various other
distributions (Arch, Fedora, Ubuntu, etc).
The code size increase ranges from ~1.5% to ~2.5%, compared to ~0.3% to
~0.7% with the more conservative switch. The increase in the performance
loss is usually minimal. The overall size increase once everything other
than C and C++ code is taken into account is minimal, and it greatly
improves the mitigation of stack buffer overflow vulnerabilities.
https://lwn.net/Articles/584225/
Change-Id: I3ce7a73c5cf36eba5c74df37367f3d3475b0a4ed
This results in nearly all functions with the possibility of stack
corruption getting stack canaries, because it applies to any function
taking a reference to the frame or with a local array rather than just
the functions with arrays larger than 8 bytes. It was developed for use
in Chrome (and Chrome OS) and has also been adopted by various other
distributions (Arch, Fedora, Ubuntu, etc).
The code size increase ranges from ~1.5% to ~2.5%, compared to ~0.3% to
~0.7% with the more conservative switch. The increase in the performance
loss is usually minimal. The overall size increase once everything other
than C and C++ code is taken into account is minimal, and it greatly
improves the mitigation of stack buffer overflow vulnerabilities.
https://lwn.net/Articles/584225/
Change-Id: I55a9fdbf5777ccdeed9f2e9a23c73bb94ad7b646
This results in nearly all functions with the possibility of stack
corruption getting stack canaries, because it applies to any function
taking a reference to the frame or with a local array rather than just
the functions with arrays larger than 8 bytes. It was developed for use
in Chrome (and Chrome OS) and has also been adopted by various other
distributions (Arch, Fedora, Ubuntu, etc).
The code size increase ranges from ~1.5% to ~2.5%, compared to ~0.3% to
~0.7% with the more conservative switch. The increase in the performance
loss is usually minimal. The overall size increase once everything other
than C and C++ code is taken into account is minimal, and it greatly
improves the mitigation of stack buffer overflow vulnerabilities.
https://lwn.net/Articles/584225/
Change-Id: I97a2187cebac64e3b9f22b691d4676b6da083ebd
This was previously working because for some reason prebuilts/ndk had
a tangled mess of hand assembled symlinks that pointed lib -> lib64
for the multilib architectures.
Change-Id: I294d67f58f2008b1a53790cf676f5223df449cbc
This makes the signapk tool use Conscrypt (where possible) instead of
the platform-default JCA providers and the Bouncy Castle JCA provider.
This speeds up (by 10-30%) APK and OTA update signing because
Conscrypt's crypto primitives are backed by BoringSSL.
Previously, the signapk tool consisted only of the signapk.jar.
Because Conscrypt is backed by native code, signapk now consists of
signapk.jar and crypto_openjdk_jni shared library. This requires that
users of the tool be updated to provide a suitable -Djava.library.path
argument to the Java runtime. This change updates all known users of
the tool inside the Android source tree to do so.
Bug: 26097626
Change-Id: I8411b37d7f771ed99269751a3007dff103083552
This commit fixes the avc denied issues in the emulators:
- goldfish_setup is granted for network access
- netd dontaudit for sys_module
- qemu_prop is granted domain for get_prop
Critical issue was that SELinux denied reading the lcd_density property
by SurfaceFlinger via qemu_prop and this commit fixes it.
Change-Id: I633d96f4d2ee6659f18482a53e21f816abde2a5f
Signed-off-by: Miroslav Tisma <miroslav.tisma@imgtec.com>
When USE_CLANG_PLATFORM_BUILD is not set, default will be clang/llvm.
USE_CLANG_PLATFORM_BUILD=false can be used to select gcc as default.
BUG: 23163853
BUG: 26102335
Change-Id: I00604c2aef4849e8c3505b2c4002eb1c46cd1fd1
libext2_uuid_host was renamed to libext2_uuid-host to match the
"-host" suffix used in most libraries.
Bug: 24619596
TEST=make dist
Change-Id: Ic5faccb4d5fdbbf3d3bba6f4a35cf99d4961bb54
Without this if a Java libraryw with LOCAL_NO_STANDARD_LIBRARIES doesn't
have core-libart in its LOCAL_JAVA_LIBRARIES, it would use core-libart
as bootclasspath but without having dependency on it.
Change-Id: I611a5a5df2bf0ad59e0be50ed1ad1afe8b843e90
(cherry-pick from commit c6a301756c)
This results in nearly all functions with the possibility of stack
corruption getting stack canaries, because it applies to any function
taking a reference to the frame or with a local array rather than just
the functions with arrays larger than 8 bytes. It was developed for use
in Chrome (and Chrome OS) and has also been adopted by various other
distributions (Arch, Fedora, Ubuntu, etc).
The code size increase ranges from ~1.5% to ~2.5%, compared to ~0.3% to
~0.7% with the more conservative switch. The increase in the performance
loss is usually minimal. The overall size increase once everything other
than C and C++ code is taken into account is minimal, and it greatly
improves the mitigation of stack buffer overflow vulnerabilities.
https://lwn.net/Articles/584225/
Change-Id: Ie83d381e09d94deb34c5ff142a101ba3d14cf3ba
