GWP-ASan's recoverable mode was landed upstream in
https://reviews.llvm.org/D140173.
This mode allows for a use-after-free or a buffer-overflow bug to be
detected by GWP-ASan, a crash report dumped, but then GWP-ASan (through
the preCrashReport() and postCrashReportRecoverableOnly() hooks) will
patch up the memory so that the process can continue, in spite of the
memory safety bug.
This is desirable, as it allows us to consider migrating non-system apps
from opt-in GWP-ASan to opt-out GWP-ASan. The major concern was "if we
make it opt-out, then bad apps will start crashing". If we don't crash,
problem solved :). Obviously, we'll need to do this with an amount of
process sampling to mitigate against the 70KiB memory overhead.
The biggest problem is that the debuggerd signal handler isn't the first
signal handler for apps, it's the sigchain handler inside of libart.
Clearly, the sigchain handler needs to ask us whether the crash is
GWP-ASan's fault, and if so, please patch up the allocator. Because of
linker namespace restrictions, libart can't directly ask the linker
(which is where debuggerd lies), so we provide a proxy function in libc.
Test: Build the platform, run sanitizer-status and various test apps
with recoverable gwp-asan. Assert that it doesn't crash, and we get a
debuggerd report.
Bug: 247012630
Change-Id: I86d5e27a9ca5531c8942e62647fd377c3cd36dfd
Enable linking on a system without /proc mounted by falling back to
reading the executable paths from argv[0] when /proc/exe/self can't be
found.
Bug: 254835242
Change-Id: I0735e873fa4e2f439688722c4a846fb70ff398a5
This is a no-op but will be used in upcoming scudo changes that allow to
change the buffer size at process startup time, and as such we will no
longer be able to call __scudo_get_ring_buffer_size in debuggerd.
Bug: 263287052
Change-Id: I18f166fc136ac8314d748eb80a806defcc25c9fd
When loading a dynamic library, reserved memory is successful, but fail in other steps, such as loading segments, which will generate a memory leak. Because the reserved memory is not released in time.
Bug: https://issuetracker.google.com/issues/263713888
Change-Id: I556ee02e37db5259df0b6c7178cd9a076dab9725
Signed-off-by: huangchaochao <huangchaochao@bytedance.com>
android_namespace_link_t::shared_lib_sonames_ is unorderd_set<string>.
When initializing, it's copied a few times unnecessarily.
- when add_linked_namespace is called
- when android_namespace_link_t() is called
- when push_back is called.
Now, it's moved around after the initial creation.
Bug: n/a
Test: atest --test-mapping .
Change-Id: I283954bb0c0bbf94ebd74407137f492e08fd41bd
As of https://r.android.com/2304013 classloader namespaces are no
longer called "classloader-namespace". However, this whole TODO is
stale - it was supposed to be addressed in O and it only applies to
compat code for SDK < 24, so there is no use fixing it now.
Test: N/A - comment change only
Bug: 258340826
Change-Id: Id09e262191cea236224196a4a4268331d5cf84c6
The only meaningful change from alibaba's version is jr instead of jalr.
Also fix the comment that's in all the begin.S files while we're here.
Signed-off-by: Mao Han <han_mao@linux.alibaba.com>
Signed-off-by: Xia Lifang <lifang_xia@linux.alibaba.com>
Signed-off-by: Chen Guoyin <chenguoyin.cgy@linux.alibaba.com>
Signed-off-by: Wang Chen <wangchen20@iscas.ac.cn>
Signed-off-by: Lu Xufan <luxufan@iscas.ac.cn>
Test: ran mksh
Change-Id: I2645c78bd700b8a55bde363600d7f8b87de641a1
The two namespaces are often the same, but if they aren't the old
message could be confusing and not very helpful.
#codehealth
Test: Build and boot with `LinkerLogger::flags_ = kLogDlopen` and check
logcat
Change-Id: I61a78d40f1eb5c074772e3c113a1055d3e915cb1
liblog_for_runtime_apex is a static variant of liblog which is
explicitly marked as available to the runtime APEX. Any static
dependency to liblog from inside the runtime APEX is changed from liblog
to liblog_for_runtime_apex.
Previously, to support the need for using liblog inside the runtime
APEX, the entire (i.e. both static and shared variants) liblog module
was marked as available to the runtime APEX, although in reality only
the static variant of the library was needed there. This was not only
looking dirty, but also has caused a problem like b/241259844.
To fix this, liblog is separated into two parts. (1) liblog and (2)
liblog_for_runtime_apex. (1) no longer is available to the runtime APEX
and is intended to be depended on in most cases: either from the
non-updatable platform, or from other APEXes. (2) is a static library
which is explicitly marked as available to the runtime APEX and also
visible to certain modules that are included in the runtime APEX.
Bug: 241259844
Test: m and check that liblog depends on stub library of libc
Change-Id: Ib21f6e64da0c7592341b97b95ca8485d7c29ac4d
As with libc.so, add the debug frame into the linker for arm32
to make any crashes unwindable.
Bug: 242162222
Test: Forced a crash on wembley where an unwind failed before and
Test: verified it unwinds properly with the debug frame.
Change-Id: I2b904af63f670b038d169f5a7d907637b352ab4e
Map all stacks (primary, thread, and sigaltstack) as PROT_MTE when the
binary requests it through the ELF note.
For the reference, the note is produced by the following toolchain changes:
https://reviews.llvm.org/D118948https://reviews.llvm.org/D119384https://reviews.llvm.org/D119381
Bug: b/174878242
Test: fvp_mini with ToT LLVM (more tests in a separate change)
Change-Id: I04a4e21c966e7309b47b1f549a2919958d93a872
The lambda function is converted to bool instead of being called. So,
get_transparent_hugepages_supported() returns always true.
Test: check whether /sys/kernel/mm/transparent_hugepage/enabled is
accessed via strace.
Bug: http://b/233137490
Signed-off-by: Suchang Woo <suchang.woo@samsung.com>
Change-Id: I88b0d18d8ceb2300482043391eed4ae7041866ca
The file is a manually created linker config file for the binaries in
the APEX. This is discouraged since such a manually created linker
config is error-prone and hard to maintain. Since the per-APEX
linker config file is automatically created by the linkerconfig tool as
/linkerconfig/<name>/ld.config.txt, we can safely deprecated the
fallback path.
There currently are two APEXes using these hand-crafted configs. They
can (and should) keep the configs for backwards compatibility; in case
when they run on older devices where the auto-generated configs are not
available. But for newer platforms, the files are simply ignored and no
new APEX should be using that.
Bug: 218933083
Test: m
Change-Id: I84bd8850b626a8506d53af7ebb86b158f6e6414a
This is important for enabling the error about unsupported TLS
relocations to local symbols. The fast path tends to skip this error,
because it fails during lookup_symbol(). Add a test for this error.
I didn't see a performance regression in the linker_relocation
benchmark.
Bug: http://b/226978634
Test: m bionic-unit-tests
Change-Id: Ibef9bde2973cf8c2d420ecc9e8fe2c69a5097ce2
This flag means "$ORIGIN processing required", and since we always
do that, we can claim support for it.
Change-Id: If60ef331963f6bc1e1818d7fa2ee57c1aa8fa343
For convenience, builds against musl libc currently use the
linux_glibc properties because they are almost always linux-specific
and not glibc-specific. In preparation for removing this hack,
tweak the linux_glibc properties by either moving them to host_linux,
which will apply to linux_glibc, linux_musl and linux_bionic, or
by setting appropriate musl or linux_musl properties. Properties
that must not be repeated while musl uses linux_musl and also still
uses the linux_glibc properties are moved to glibc properties, which
don't apply to musl. Whether these stay as glibc properties or get
moved back to linux_glibc later once the musl hack is removed is TBD.
Bug: 223257095
Test: m checkbuild
Test: m USE_HOST_MUSL=true host-native
Change-Id: I809bf1ba783dff02f6491d87fbdc9fa7fc0975b0
For a 32-bit userspace, `struct LinkedListEntry` takes 8 bytes for
storing the two pointers, a default block allocator size alignment of
16-bytes would waste 50% of memory. By changing the alignment to size
of a pointer, it saves >1MB memory postboot on wembley device.
Bug: http://b/206889551
Test: bionic-unit-tests
Change-Id: Ie92399c9bb3971f631396ee09bbbfd7eb17dc1a7
This change is to allocate `head_` and `tail_` outside of LinkedList
and only keep a readonly pointer there. By doing this, all updates
of the list touches memory other than the LinkedList itself, thus
preventing copy-on-write pages being allocated in child processes
when the list changes.
The other approach is to make the LinkedList a singly-linked list,
however, that approach would cause a full list traversal to add
one item to the list. And preliminary number shows there are ~60K
calls to `soinfo::add_secondary_namespace` during Android bootup
on a wembley device, where a singly-linked approach could be
hurting performance.
NOTE: the header is allocated and initialized upon first use instead
of being allocated in the constructor, the latter ends up in crash.
This is likely caused by static initialization order in the linker,
e.g. g_soinfo_list_allocator is a static object, and if this linked
list is embedded into some other static objects, there's no guarantee
the allocator will be available.
Bug: http://b/206889551
Test: bionic-unit-tests
Change-Id: Ic6f053881f85f9dc5d249bb7d7443d7a9a7f214f
Clang cannot build ifunc with LTO. This is a KI: https://bugs.llvm.org/show_bug.cgi?id=46488
Move the LTO: never down to libc itself, so that we can have LTO for the
rest of linker.
Test: m GLOBAL_THINLTO=true linker
Change-Id: I483fc3944e340638a664fb390279e211c2ae224b
This also effectively re-enables linker_wrapper, which may have been
independently fixed some time ago.
Test: mixed_droid.sh
Change-Id: I9bc7e099fe3c5da1c4da12c79128baf6f807354a
A recent change to lld [1] made it so that the __rela?_iplt_*
symbols are no longer defined for PIEs and shared libraries. Since
the linker is a PIE, this prevents it from being able to look up
its own relocations via these symbols. We don't need these symbols
to find the relocations however, as their location is available via
the dynamic table. Therefore, start using the dynamic table to find
the relocations instead of using the symbols.
Previously landed in r.android.com/1801427 and reverted in
r.android.com/1804876 due to linux-bionic breakage. This time,
search .rela.dyn as well as .rela.plt, since the linker may put the
relocations in either location (see [2]).
[1] f8cb78e99a
[2] https://reviews.llvm.org/D65651
Bug: 197420743
Change-Id: I5bef157472e9893822e3ca507ef41a15beefc6f1
This reverts commit 65bdf655c4.
Reason for revert: checking the failure of avd/avd_boot_test
Bug: 197781964
Change-Id: I70eb03b45cdfbd87ef6edb03b74ad6d1970dc08c
A recent change to lld [1] made it so that the __rela?_iplt_*
symbols are no longer defined for PIEs and shared libraries. Since
the linker is a PIE, this prevents it from being able to look up
its own relocations via these symbols. We don't need these symbols
to find the relocations however, as their location is available via
the dynamic table. Therefore, start using the dynamic table to find
the relocations instead of using the symbols.
[1] f8cb78e99a
Change-Id: I4a12ae9f5ffd06d0399e05ec3ecc4211c7be2880
In order to support demangling of rust symbols by the linker, we are
adding a small Rust component. Rust expects `memalign` to be present in
hosted environments, and it doesn't appear costly to enable it.
Bug: 178565008
Test: m, killall -11 keystore2 produced mangled names in tombstone
Change-Id: I8fc749000fa02a3b760c8cc55be3348b9964d931
Now that linker_wrapper.o does not use objcopy --prefix-symbols=__dlwrap_
it can reference the _start symbol of the original binary without
colliding with its own __dlwrap__start symbol, which means
host_bionic_inject is no longer necessary.
Test: build and run host bionic binary
Change-Id: I1752efa39fa73a092fab039771bf59c99b7b5974
The only symbol that actually needs a prefix to avoid a collision is
_start, and that can be handled with a copy of begin.S that uses a
"#define" to rename _start to __dlwrap__start. Removing the prefixed
symbols will also allow simplifying the host bionic build process by
letting it directly reference the real _start.
Test: build and run host bionic binary
Change-Id: I50be786c16fe04b7f05c14ebfb74f710c7446ed9
To take advantage of file-backed huge pages for the text segments of key
shared libraries (go/android-hugepages), the dynamic linker must load
candidate ELF files at an appropriately aligned address and mark
executable segments with MADV_HUGEPAGE.
This patches uses segments' p_align values to determine when a file is
PMD aligned (2MB alignment), and performs load operations accordingly.
Bug: 158135888
Test: Verified PMD aligned libraries are backed with huge pages on
supporting kernel versions.
Change-Id: Ia2367fd5652f663d50103e18f7695c59dc31c7b9
Introduces a cc_defaults category hugepage_aligned that passes the
requisite linker flags to produce shared object files with 2MB-aligned
sections. This enables supporting platforms to back the text segments of
these libraries with hugepages.
Bug: 158135888
Test: Built and confirmed ELF layout
Change-Id: I5c8ce35d8f8bf6647ec19d58398740bd494cc89c
This works around buggy applications that read a few bytes past the
end of their allocation, which would otherwise cause a segfault with
the concurrent Scudo change that aligns large allocations to the right.
Because the implementation of
android_set_application_target_sdk_version() lives in the linker,
we need to introduce a hook so that libc is notified when the target
SDK version changes.
Bug: 181344545
Change-Id: Id4be6645b94fad3f64ae48afd16c0154f1de448f
Otherwise if a 32bit copy of a library used by Toybox
exists on LD_LIBRARY_PATH then file(1) will fail.
Bug: 181666541
Test: Manually copied to device and verified correct behaviour
Change-Id: I7d729927b1b433ec953c266920489613fc096e03
Auto-generate NOTICE files for all the directories, and for each one
individually rather than mixing libc and libm together.
Test: N/A
Change-Id: I7e251194a8805c4ca78fcc5675c3321bcd5abf0a
With this change we can report memory errors involving secondary
allocations. Update the existing crasher tests to also test
UAF/overflow/underflow on allocations with sizes sufficient to trigger
the secondary allocator.
Bug: 135772972
Change-Id: Ic8925c1f18621a8f272e26d5630e5d11d6d34d38
These lines shouldn't actually matter, because the DSOs are using
version scripts to allow-list exported symbols.
Bug: none
Test: bionic unit tests
Change-Id: I39d3df8c4f8053624f862b3c6994e30c693e928c
During "step 1" of find_libraries, the linker finds the transitive
closure of dependencies, in BFS order. As it finds each library, it
adds the library to its primary namespace (so that, if some other
library also depends on it, find_loaded_library_by_soname can find the
library in the process of being loaded).
LD_PRELOAD libraries are automatically marked DF_1_GLOBAL, and any
DF_1_GLOBAL library is added to every linker namespace. Previously,
this secondary namespace registration happened after step 1. The result
is that across different namespaces, the order of libraries could vary.
In general, a namespace's primary members will all appear before
secondary members. This is undesirable for libsigchain.so, which we
want to have appear before any other non-preloaded library.
Instead, when an soinfo is added to its primary namespace, immediately
add it to all the other namespaces, too. This ensures that the order of
soinfo objects is the same across namespaces.
Expand the dl.exec_with_ld_config_file_with_ld_preload and
dl.exec_with_ld_config_file tests to cover the new behavior. Mark
lib1.so DF_1_GLOBAL and use a "foo" symbol to mimic the behavior of a
signal API interposed by (e.g.) libsigchain.so and a ASAN preload.
Test: bionic unit tests
Bug: http://b/143219447
Change-Id: I9fd90f6f0d14caf1aca6d414b3e9aab77deca3ff
No-one seems to understand that a crash in a random .so from call_array()
in the linker isn't a linker bug. They _seem_ to understand (or at least
claim to) when we explain that this is just the linker calling their ELF
constructors --- despite the fact that the caller of call_array() is
call_constructors().
One experiment we can try though is to inline call_array() to elide that
frame from the crash dumps. I do also wonder whether renaming
call_constructors() to call_elf_constructors() would help/hinder/make no
difference. For now I'm leaning toward "hinder" because I suspect most
people don't understand "ELF constructor" and C++ folks at least will
probably be influenced in a not wholly incorrect direction when they
hear "constructor" (whereas "ELF constructor" might mislead them back in
the direction of "strange linker magic, not my fault" again)...
(The reformatting is clang-format's decision, not mine.)
Test: treehugger
Change-Id: I65ab95ceb2e988fd053c48c66f51afba17ccfa61
For libc.so, use a special build of libunwind.a whose symbols aren't
hidden ("libunwind-exported"), because libc.so exports the _Unwind_*
APIs.
Bug: http://b/153025717
Test: bionic unit tests
Change-Id: I7435e076ec8cc4410e3e6086d3cf5d2c6011c80c
Setting the linker's soname ("ld-android.so") can allocate heap memory
now that the name uses an std::string, and it's probably a good idea to
defer doing this until after the linker has relocated itself (and after
it has called C++ constructors for global variables.)
Bug: none
Test: bionic unit tests
Test: verify that dlopen("ld-android.so", RTLD_NOLOAD) works
Change-Id: I6b9bd7552c3ae9b77e3ee9e2a98b069b8eef25ca
Once upon a time (and, indeed, to this very day if you're on LP32) the
soinfo struct used a fixed-length buffer for the soname. This caused
some issues, mainly with app developers who accidentally included a full
Windows "C:\My Computer\...\libfoo.so" style path. To avoid all this we
switched to just pointing into the ELF file itself, where the DT_SONAME
is already stored as a NUL-terminated string. And all was well for many
years.
Now though, we've seen a bunch of slow startup traces from dogfood where
`dlopen("libnativebridge.so")` in a cold start takes 125-200ms on a recent
device, despite no IO contention. Even though libnativebridge.so is only
20KiB.
Measurement showed that every library whose soname we check required
pulling in a whole page just for the (usually) very short string. Worse,
there's readahead. In one trace we saw 18 pages of libhwui.so pulled
in just for `"libhwui.so\0"`. In fact, there were 3306 pages (~13MiB)
added to the page cache during `dlopen("libnativebridge.so")`. 13MiB for
a 20KiB shared library!
This is the obvious change to use a std::string to copy the sonames
instead. This will dirty slightly more memory, but massively improve
locality.
Testing with the same pathological setup took `dlopen("libnativebridge.so")`
down from 192ms to 819us.
Bug: http://b/177102905
Test: tested with a pathologically modified kernel
Change-Id: I33837f4706adc25f93c6fa6013e8ba970911dfb9
Use a note in executables to specify
(none|sync|async) heap tagging level. To be extended with (heap x stack x
globals) in the future. A missing note disables all tagging.
Bug: b/135772972
Test: bionic-unit-tests (in a future change)
Change-Id: Iab145a922c7abe24cdce17323f9e0c1063cc1321
There are multiple build breakages with bionic when we enable ThinLTO
globally. Opt bionic out of ThinLTO for now.
#global-thinlto-opt-out
Test: TreeHugger
Bug: 169004486
Change-Id: I546a8074f9c3e0ddbd01d3b7cd730e215e3c0c49
This patch adds support to load BTI-enabled objects.
According to the ABI, BTI is recorded in the .note.gnu.property section.
The new parser evaluates the property section, if exists.
It searches for .note section with NT_GNU_PROPERTY_TYPE_0.
Once found it tries to find GNU_PROPERTY_AARCH64_FEATURE_1_AND.
The results are cached.
The main change in linker is when protection of loaded ranges gets
applied. When BTI is requested and the platform also supports it
the prot flags have to be amended with PROT_BTI for executable ranges.
Failing to add PROT_BTI flag would disable BTI protection.
Moreover, adding the new PROT flag for shared objects without BTI
compatibility would break applications.
Kernel does not add PROT_BTI to a loaded ELF which has interpreter.
Linker handles this case too.
Test: 1. Flame boots
2. Tested on FVP with BTI enabled
Change-Id: Iafdf223b74c6e75d9f17ca90500e6fe42c4c1218
As we enable arm64-based Bionic host target (linux_bionic_arm64),
linker_wrapper is added with the corresponding source.
Bug: 159685774
Test: HOST_CROSS_OS=linux_bionic HOST_CROSS_ARCH=arm64 m
Test: copy out/soong/host/linux_bionic_arm64/ to an ARM64 emulator
running Linux and execute the binaries
Change-Id: I4f367a349f7e0015318352cb7f2870fc856eab05
(Based on proposal at https://sourceware.org/glibc/wiki/ThreadPropertiesAPI)
This includes API to:
- locate static and dynamic TLS
- register thread-exit and dynamic TLS creation/destruction callbacks
Change-Id: Icd9d29a5b2f47495395645e19d3b2c96826f19c8
Update a comment in android-changes-for-ndk-developers.md about the
removed debug.ld.greylist_disabled system property.
Update language to comply with Android's inclusive language guidance
#inclusivefixit
See https://source.android.com/setup/contribute/respectful-code for reference
Bug: http://b/162536543
Test: bionic-unit-tests
Change-Id: I760ee14bce14d9d799926c43d2c14fd8ffbc6968
1. Cleanup for #inclusivefixit. (whitelisted -> allowed_libs)
2. Support the old term for backwards compatibility. (Also update test.)
3. Fix the formatting errors found by clang-format.
See https://source.android.com/setup/contribute/respectful-code
for reference.
Bug: 161896447
Test: atest linker-unit-tests linker-benchmarks
Change-Id: I19dbed27a6d874ac0049cb7b67d2cb0f75369c1b
This property provided a way to disable the greylist, for testing
whether an app targeting < 24 still works. Instead of turning off the
greylist, though, an app developer should simply target a newer API.
(If app developers really need this property for testing, they can
still use it on versions of Android between N and R, inclusive.)
Update language to comply with Android's inclusive language guidance
See https://source.android.com/setup/contribute/respectful-code for reference
#inclusivefixit
Bug: http://b/162536543
Test: bionic-unit-tests
Change-Id: Id1eb2807fbb7436dc9ed7fe47e15b7d165a26789
Add inaccessible gaps between shared libraries to make it harder for the
attackers to defeat ASLR by random probing.
To avoid excessive page table bloat, only do this when a library is
about to cross a huge page boundary, effectively allowing several
smaller libraries to be lumped together.
Bug: 158113540
Test: look at /proc/$$/maps
Change-Id: I39c0100b81f72447e8b3c6faafa561111492bf8c
This reverts commit a8cf3fef2a.
Reason for revert: memory regression due to the fragmentation of the page tables
Bug: 159810641
Bug: 158113540
Change-Id: I6212c623ff440c7f6889f0a1e82cf7a96200a411
There are some special cases - such as init process - when linker
configuration is not expected to exist. This change disables warning
message that generated linker configuration does not exist in those
cases.
Bug: 158800902
Test: Tested from cuttlefish that warning message is not generated from
init
Change-Id: Ie2fbb5210175cf1e6f2b7e638f57c3b74d395368
Improve ASLR by increasing the randomly sized gaps between shared
library mappings, and keep them mapped PROT_NONE.
Bug: 158113540
Test: look at /proc/$$/maps
Change-Id: Ie72c84047fb624fe2ac8b7744b2a2d0d255ea974
This replaces a single 2Gb readable memory region with a bunch of tiny
regions, and leaves the bulk of 2Gb mapped but unaccessible. This makes
it harder to defeat ASLR by probing for the CFI shadow region.
Sample CFI shadow mapping with this change:
7165151000-716541f000 ---p 00000000 00:00 0 [anon:cfi shadow]
716541f000-7165420000 r--p 00000000 00:00 0 [anon:cfi shadow]
7165420000-71654db000 ---p 00000000 00:00 0 [anon:cfi shadow]
71654db000-71654dc000 r--p 00000000 00:00 0 [anon:cfi shadow]
71654dc000-71654dd000 r--p 00000000 00:00 0 [anon:cfi shadow]
71654dd000-71654f0000 ---p 00000000 00:00 0 [anon:cfi shadow]
71654f0000-71654f1000 r--p 00000000 00:00 0 [anon:cfi shadow]
71654f1000-71e5151000 ---p 00000000 00:00 0 [anon:cfi shadow]
This change degrades CFI diagnostics for wild jumps and casts (i.e. when
the target of a CFI check is outside of any known library bounds). This
is acceptable, because CFI does not have much to tell about those cases
anyway. Such bugs will show up as SEGV_ACCERR crashes inside
__cfi_slowpath in libdl.so from now on.
Bug: 158113540
Test: bionic-unit-tests/cfi_test.*
Test: adb shell cat /proc/$PID/maps | grep cfi
Change-Id: I57cbd0d3f87eb1610ad99b48d98ffd497ba214b4
Merged-In: I57cbd0d3f87eb1610ad99b48d98ffd497ba214b4
In particular, add the strerror() output if mprotect() fails.
Fix the CHECK macro so that you can make assertions involving operator%
without that being confused for a printf format specifier.
Bug: https://issuetracker.google.com/158645318
Test: treehugger
Change-Id: I6817f8ca5f094c52dc2c9067bfac90385a8743f5
.whitelisted is a list of sonames seperated by ":" just like
.shared_libs and .paths properties. It makes sense to make it appendable
using += as well ass .shared_libs and .paths.
Bug: n/a
Test: atest linker-unit-tests
Change-Id: If61cc553c8080e8a58de8a3a6051c1853f7bfe5f
Change the location set in the linker
Bug: 130219528
Bug: 138994281
Test: atest CtsBionicTestCases
Test: atest CtsJniTestCases
Change-Id: I215a8e023ccc4d5ffdd7df884c809f8d12050c8f
The SYNC tagging level enables stack trace collection for allocations and
deallocations, which allows allocation and deallocation stack traces to
appear in tombstones when encountering a tag check fault in synchronous tag
checking mode.
Bug: 135772972
Change-Id: Ibda9f51b29d2c8e2c993fc74425dea7bfa23ab1e
Before this Soong added hardcoded system include paths to
bionic/libc/{include,kernel}, which won't work when Bionic libs are
packaged up as prebuilts in an SDK module snapshot.
Test: Build and boot
Test: Check in out/verbose.log.gz that a C file doesn't get any bionic
include path for linux_glibc.
Bug: 153590472
Change-Id: I13c8eb3dd7150d6e0fee001b290b53fcebebcfea
CfiFail calls find_containing_library, which searches the linker's
internal soinfo list, which could be modified by another thread.
Bug: http://b/150372650
Test: bionic-unit-tests
Change-Id: I59024a0a47913caa75702f15ec058b0a360727b5
android_get_exported_namespace searches g_exported_namespaces, which
isn't modified after process initialization, but it does the search
using a new std::string object, and the linker's malloc/free functions
aren't thread-safe. (They're protected by the same lock (g_dl_mutex) as
the rest of the linker's state.)
Bug: http://b/150372650
Test: bionic-unit-tests
Change-Id: Iafd12e5ab36ae61f0642aad59939f528d31bda16
For the bootstrap linker, insert /system/${LIB}/bootstrap in front of
/system/${LIB} in any namespace search path.
Bug: http://b/152572170
Test: bionic unit tests
Change-Id: Ia359d9f2063f4b6fff3f79b51b500ba968a18247
If ElfReader::Read fails, then it is hazardous to leave the invalid
ElfReader in the soinfo*->ElfReader table, because a future soinfo
object could happen to have the same address, then reuse the invalid
ElfReader. I'm not sure whether this can break anything, because the
linker would call ElfReader::Read on the invalid object and overwrite
its previous value.
Test: bionic unit tests
Bug: none
Change-Id: Ibabbf559443441b9caeacc34ca165feaafe5e3a7
The doc_link argument is really a URL fragment within the
android-changes-for-ndk-developers.md document, not a filename at the
root of the bionic repository.
Test: manual
Bug: none
Change-Id: I1b542e47aca132ce43ba1d50d83db1bf3c7b10c6
The search_linked_namespaces parameter to find_library_internal is
always true.
Bug: none
Test: bionic tests
Change-Id: I4b6f48afefca4f52b34ca2c9e0f4335fa895ff34
Add a few _Nonnull / _Nullable annotations. Clang may use them to issue
warnings but violating the annotation isn't undefined behavior.
Bug: none
Test: bionic tests
Change-Id: I82e442f06a2c59c69bc0008f0f686785695cdd02
This reverts commit 8dba7fefb0.
Reason for revert: This workaround is not necessary with ag/10700799
Merged-In: I2bf469bfe00f3a70e67085abfb3822db6908d522
Change-Id: If351aedfce23d60582f0c5ff965f94356d1900d9
Bug: 150860940
Update message that generated linker configuration is missing to from
into to warning again. Also do not raise this message from host
environment which is expected.
Bug: 146386369
Test: m -j passed
Change-Id: Ia5c2969d77fbc70e0406fbb449920080989a1ea8
When libbase is built for an APEX, it uses dlsym to reflectively access
liblog symbols that are added in R. This is because the APEX where
libbasse is packaged into might be running in pre-R devices where the
symbols don't exist in liblog.so.
This however causes a problem for a static executable in an APEX. Since
it is in an APEX, the dlsym is used. But libdl.so which provides dlsym
is not available to static executable. Currently, the dynamic linker is
the only executable in an APEX that all of its dependencies are
statically linked. Fixing the issue by providing fake dlsym by
statically linking to libdl.a.
Exempt-From-Owner-Approval: cherry-pick rvc-dev
Bug: 149569129
Test: m
Merged-In: I2e9e45d9876c2d6c878e541715389e6d1ef56996
(cherry picked from commit ec829ed4ea)
Change-Id: I2e9e45d9876c2d6c878e541715389e6d1ef56996
Exports GWP-ASan allocator information callbacks to libdebuggerd so that
tombstoned can get information from the GWP-ASan allocator in the case
of a crash.
Bug: 135634846
Test: atest bionic-unit-tests
Change-Id: Ie16426af55602fb2a76c4e69217773354c365843
sys.linker.use_generated_config property was introduced at the beginning
of linkerconfig development to skip this generated configuration if it
does not work properly during dev. However, linkerconfig development is
now completed and is working properly from most of devices, so this
property is no longer in use. Therefore deprecating this property as
this would not be used.
Bug: 149335054
Test: m -j passed
Test: No linking error from Cuttlefish and Crosshatch
Change-Id: I0a1b3f36b69872862196b1613718a75d482e0a92
XOM is no longer supported by the build system, so remove these
properties.
Bug: 123034666
Bug: 147300048
Test: Build succeeds.
Change-Id: I77efc98241f45b1a78b1cca5560f64eef5ef22f4
When a library is present in a namespace via the secondary_namespaces
list (i.e. the executable, LD_PRELOAD, DF_1_GLOBAL, or
android_create_namespace inheritance), then we want to search that
library's symbols, but not the symbols of its dependencies. Otherwise,
we want to search the dependencies to handle cross-NS dependency.
Bug: http://b/148569846
Test: bionic unit tests
Change-Id: If798d69de28ed5c0f1a155e4ff85c7e08934e531
LinkerConfig will start to generate linker configuration for APEX
binaries. Linker should check if this generated file exists first, and
use it if exists and otherwise use ld.config.txt under APEX etc.
Bug: 147987608
Test: m -j passed
Test: Tested with adbd and SWCodec from Cuttlefish and Crosshatch
Change-Id: I5a0c28ee1a427adface3e67c8af062e1b2ef6197
Until now we've only supported RELR with our own OS-private-use
constants. Add support for the official numbers (while maintaining
support for the historical numbers).
Add tests to ensure we continue to support both indefinitely.
We can't yet flip the build system over to using the official constants
because the old GNU binutils objcopy we still use in most cases (for the
mini-debug section) only supports the historical constants.
Bug: http://b/147452927
Test: treehugger
Change-Id: If214fce7fade4316115947e90b78ab40864b61f2
A static analyzer is complaining that num_valid_bits could be 64, and if
it were 64, then two later accesses would be out-of-bounds. is_nul_u64
can't be zero, though, because we only exit the loop when part of is_nul
is non-zero.
Bug: none
Test: manual
Change-Id: I75c3f70b600aa5478cb32fdf4ca0ae1173b69524
Previously, the linker was ignoring the symbol of the R_GENERIC_NONE
relocation, so continue ignoring it. This is a little unfortunate because
it requires adding an extra condition on the fast path for relocation
handling.
I tried benchmarking this change, and I can't tell whether it has no
effect or is a regression of up to 1%. It might be possible to refactor
this code (e.g. do the lookup anyway, but avoid reporting an error), or by
changing the linker behavior, but this simple change gets the linker
working again.
Bug: http://b/147719203
Test: verify that the broken app works again
Change-Id: I7589b65705fec522d5fbadc05136dd5489833aea
Symbol lookup is O(L) where L is the number of libraries to search (e.g.
in the global and local lookup groups). Factor out the per-DSO work into
soinfo_do_lookup_impl, and optimize for the situation where all the DSOs
are using DT_GNU_HASH (rather than SysV hashes).
To load a set of libraries, the loader first constructs an auxiliary list
of libraries (SymbolLookupList, containing SymbolLookupLib objects). The
SymbolLookupList is reused for each DSO in a load group. (-Bsymbolic is
accommodated by modifying the SymbolLookupLib at the front of the list.)
To search for a symbol, soinfo_do_lookup_impl has a small loop that first
scans a vector of GNU bloom filters looking for a possible match.
There was a slight improvement from templatizing soinfo_do_lookup_impl
and skipping the does-this-DSO-lack-GNU-hash check.
Rewrite the relocation processing loop to be faster. There are specialized
functions that handle the expected relocation types in normal relocation
sections and in PLT relocation sections.
This CL can reduce the initial link time of large programs by around
40-50% (e.g. audioserver, cameraserver, etc). On the linker relocation
benchmark (64-bit walleye), it reduces the time from 131.6ms to 71.9ms.
Bug: http://b/143577578 (incidentally fixed by this CL)
Test: bionic-unit-tests
Change-Id: If40a42fb6ff566570f7280b71d58f7fa290b9343
This supports the soong commit which causes most platform binaries to stop
statically linking against the unwinder implementation. The soong commit
message has more motivation for this change.
ARM32 uses LLVM libunwind, while all other platforms use libgcc as the
unwinder implementation. This matches the current choices of unwinders on
the various architectures, but means that apps which were directly linking
against the libc.so unwinder symbols on ARM32 are now using LLVM libunwind
instead of libgcc.
Set libc_headers sdk_version to 1 so that libunwind_llvm can depend on it,
and stop statically linking libunwind into libc_malloc_debug.
Bug: 144430859
Change-Id: I52c7f7893d93f500383aeb0b76086c3b6f1935a5
These are no longer necessary now that LLVM no longer emits references to
this symbol on Android.
Bug: 144430859
Change-Id: I6c43338f755ce5a79e2df36bd3f2006a748fab27
A later linker CL defines a function that needs to forward a printf format
and argument list to TRACE(), but there is no version of the TRACE macro
that works with a va_list. The CL also needs to check the verbosity level,
using a slow path if tracing is enabled, so define LINKER_VERBOSITY_xxx
macros.
Bug: none
Test: bionic unit tests
Change-Id: I578d36a12dc40f9a651956b4b09adc1a7c644e24
Validate the list of defined versions explicitly, during library
prelinking, rather than implicitly as part of constructing the
VersionTracker in soinfo::link_image.
Doing the validation upfront allows removing the symbol lookup failure
code paths, which only happen on a library with invalid version
information.
Helps on the walleye 64-bit linker relocation benchmark (146.2ms ->
131.6ms)
Bug: none
Test: bionic unit tests
Change-Id: Id17508aba3af2863909f0526897c4277419322b7
Previously, during a find_libraries call that loaded a library, a
library was prelinked once for each DT_NEEDED reference to the library.
This CL has a negligible effect on the linker relocation benchmark
(146.9ms -> 146.2ms).
Bug: none
Test: bionic unit tests
Change-Id: I385f312b8acf8d35aa0af9722131fe367b5edd9b
The soinfo instances of linker and vdso have been added to g_default_namespace
before init_default_namespace() is called. So init_default_namespace() don't
have to add them a second time.
Test: manual
Change-Id: I29b3da782b1e9445509f45a7698561fc3e19e9a1
Historically we've made a few mistakes where they haven't matched the
right number. And most non-Googlers are much more familiar with the
numbers, so it seems to make sense to rely more on them. Especially in
header files, which we actually expect real people to have to read from
time to time.
Test: treehugger
Change-Id: I0d4a97454ee108de1d32f21df285315c5488d886
DL_WARN message when failed to find generated linker config makes some
of the ART tests fail. Lowering log level as ART test does not have
linkerconfig generated for the test.
Bug: 146386369
Test: Cuttlefish boot succeeded without any error
Test: run_build_test_target.py art-linux-bionic-x64-zipapex passed
Change-Id: I4f876c3ac5c30d32d51346d4cd16b5205da8f1bf
New linker configuration from /linkerconfig is not suitbale for emulated
architectures. But as of now, native_bridge linkers pick it up as well
and thus fail to find the libraries for emulated architectures.
This is a (temporary) fix so native_bridge linker still picks up
configuration from old location.
Bug: 138920271
Test: native_bridge linker works
Change-Id: I0abbd3e95f9e6830385b0f19db0688e6183030b9
Current linker configuration is only enabled from fully treblelized
devices. This change will allow linker to first check generated linker
configuration even for non-treblelized devices and recovery.
Bug: 139638519
Test: Tested from cuttlefish
Change-Id: I655b1ab807cd8db5696d07fd2bdd00ce0558901d
