Instead of passing the address of a KernelArgumentBlock to libc.so for
initialization, use __loader_shared_globals() to initialize globals.
Most of the work happened in the previous CLs. This CL switches a few
KernelArgumentBlock::getauxval calls to [__bionic_]getauxval and stops
routing the KernelArgumentBlock address through the libc init functions.
Bug: none
Test: bionic unit tests
Change-Id: I96c7b02c21d55c454558b7a5a9243c682782f2dd
Merged-In: I96c7b02c21d55c454558b7a5a9243c682782f2dd
(cherry picked from commit 746ad15912)
Split __libc_init_main_thread into __libc_init_main_thread_early and
__libc_init_main_thread_late. The early function is called very early in
the startup of the dynamic linker and static executables. It initializes
the global auxv pointer and enough TLS memory to do system calls, access
errno, and run -fstack-protector code (but with a zero cookie because the
code for generating a cookie is complex).
After the linker is relocated, __libc_init_main_thread_late finishes
thread initialization.
Bug: none
Test: bionic unit tests
Change-Id: I6fcd8d7587a380f8bd649c817b40a3a6cc1d2ee0
Merged-In: I6fcd8d7587a380f8bd649c817b40a3a6cc1d2ee0
(cherry picked from commit 39bc44bb0e)
It was discovered that we were building some objects inconsistently due
to an optimization in cc_library to only build objects once and use them
for both the static and shared libraries. But static libraries didn't
get system_shared_libs set automatically, and we didn't notice that we
would have built the objects differently.
So static libraries now get the default system_shared_libs, we allow
adjusting that for static vs shared in a cc_library, and we disable the
optimization if the linked libraries are configured differently between
static and shared in a single cc_library.
This triggers dependency cycles for static libraries that libc/libdl
use, so fix those cycles here.
Test: treehugger
Change-Id: I3cf7fda161a05ec32e0c1e871999720d12a4d38e
* changes:
Use shared globals to init __progname + environ
Move the abort message to libc_shared_globals
Expose libc_shared_globals to libc.so with symbol
Initialize the __progname and environ global variables using
libc_shared_globals rather than KernelArgumentBlock.
Also: suppose the linker is invoked on an executable:
linker prog [args...]
The first argument passed to main() and constructor functions is "prog"
rather than "linker". For consistency, this CL changes the BSD
__progname global from "linker" to "prog".
Bug: none
Test: bionic unit tests
Change-Id: I376d76953c9436706dbc53911ef6585c1acc1c31
__libc_shared_globals() is available in dynamic modules as soon as
relocation has finished (i.e. after ifuncs run). Before ifuncs have run,
the android_set_abort_message() function already doesn't work because it
calls public APIs via the PLT. (If this matters, we can use a static
bool variable to enable android_set_abort_message after libc
initialization).
__libc_shared_globals() is hidden, so it's available in the linker
immediately (i.e. before relocation). TLS memory (e.g. errno) currently
isn't accessible until after relocation, but a later patch fixes that.
Bug: none
Test: bionic unit tests
Change-Id: Ied4433758ed2da9ee404c6158e319cf502d05a53
Previously, the address of the global variable was communicated from the
dynamic linker to libc.so using a field of KernelArgumentBlock, which is
communicated using the TLS_SLOT_BIONIC_PREINIT slot.
As long as this function isn't called during relocations (i.e. while
executing an ifunc), it always return a non-NULL value. If it's called
before its PLT entry is relocated, I expect a crash.
I removed the __libc_init_shared_globals function. It's currently empty,
and I don't think there's one point in libc's initialization where
shared globals should be initialized.
Bug: http://b/25751302
Test: bionic unit tests
Change-Id: I614d25e7ef5e0d2ccc40d5c821dee10f1ec61c2e
Free pages count should be incremented by 1 when a new page is
allocated. Without this fix, free pages count underflows and the
allocator ends up freeing a free page whenever the last object in that
page is freed. In other words, it doesn't hold onto a free page as
expected and thus we may see more mmap/munmap calls.
Test: Set breakpoint at the end of __linker_init and check
free_pages_cnt values are either 0 or 1.
Change-Id: I259a3a27329aab6835c21b4aa7ddda89dac9655b
These modules have issues running with execute-only memory. Disable it
in them until we can resolve the issues.
Bug: 77958880
Test: No more XOM-related crashes in these binaries
Change-Id: Ie6c957731155566c2bbe7dbb7a91b9583d9aff93
__sanitize_environment_variables is only called when getauxval(AT_SECURE)
is true.
Instead of scanning __libc_auxv, reuse getauxval. If the entry is missing,
getauxval will set errno to ENOENT.
Reduce the number of times that __libc_sysinfo and __libc_auxv are
initialized. (Previously, __libc_sysinfo was initialized 3 times for the
linker's copy). The two variables are initialized in these places:
- __libc_init_main_thread for libc.a (including the linker copy)
- __libc_preinit_impl for libc.so
- __linker_init: the linker's copy of __libc_sysinfo is still initialized
twice, because __libc_init_main_thread runs after relocation. A later
CL consolidates the linker's two initializations.
Bug: none
Test: bionic unit tests
Change-Id: I196f4c9011b0d803ee85c07afb415fcb146f4d65
When /foo/bar/baz is added to the search paths and if getattr (stat())
is not allowed on one of its parent paths, i.e., /foo and /foo/baz, the
path was thought as non-existent and wasn't added to the search paths of
the namespace.
Fixing the bug by adding the path if the path (though not the parents)
does exist.
Bug: 119656753
Test: m apex.test; m; device boots.
Change-Id: I21bca1fee9aa20688ce9b72192d3173821ad91a3
Change three things regarding the work around to the fact that init is
special:
1) Only first stage init is special, so we change the check to include
accessing /proc/self/exe, which if is available, means that we're
not first stage init and do not need any work arounds.
2) Fix the fact that /init may be a symlink and may need readlink()
3) Suppress errors from realpath_fd() since these are expected to fail
due to /proc not being mounted.
Bug: 80395578
Test: sailfish boots without the audit generated from calling stat()
on /init and without the errors from realpath_fd()
Change-Id: I266f1486b142cb9a41ec791eba74122bdf38cf12
This reverts commit 73de62e461.
Reason for revert: bug was fixed upstream and included into AOSP lld
Bug: 78115263
Test: make checkbuild
Change-Id: Ib9e4af1efdcdb547c7bd65cce4ce48d7f09ed217
When executing an executable in an APEX (i.e., /apex/<name>/bin),
ld.config.txt file is read from the same APEX, not from /system/etc.
Bug: 115787633
Test: m apex.test; adb push ...apex.test.apex /data/apex; adb reboot
Test: adb root; adb shell /apex/com.android.example.apex/bin/dex2oat
is runnable.
Change-Id: I6400251f99d24f2379dbaf655ecd84da02490617
Use <android-base/macros.h> instead where possible, and move the bionic
macros out of the way of the libbase ones. Yes, there are folks who manage
to end up with both included at once (thanks OpenGL!), and cleaning that
up doesn't seem nearly as practical as just making this change.
Bug: N/A
Test: builds
Change-Id: I23fc544f39d5addf81dc61471771a5438778895b
We don't have a host bionic version of
libclang_rt.asan-x86_64-android.so, so I'm using the android version,
which can't load liblog.so, since it's missing DT_RUNPATH that would
normally load liblog.so from a relative path to the .so.
Bug: 118058804
Test: run ASAN host_bionic
Change-Id: I58badcd5ed35bd1c7b786b4f1e2367a1011ff08d
This is use by Host Bionic to bootstrap into an embedded copy of the
linker by tweaking the AT_* values before calling in to the linker entry.
Similarly to 9729f35922, get the base
address from AT_PHDR, so that we're not relying on the relative offset
before relocation, which doesn't work with lld (at least with the
standard flags).
To find the offset to the linker code, we can still use an absolute
symbol created by extract_linker (which is currently hardcoded to 0x1000).
Instead of relying on something similar for the linker entry point,
we're now just reading the entry point from the linker's ELF header.
Then we get the address to the real _start function using
host_bionic_inject, which injects the value into a global variable after
the link step is finished. It also uses that opportunity to verify that
the linker is embedded as we expect it to be.
Bug: 31559095
Test: build with host bionic
Change-Id: I9d81ea77c51c079de06905da1ebe421fead1dc3b
The executable can be inside a zip file using the same syntax used for
shared objects: path.zip!/libentry.so.
The linker currently requires an absolute path. This restriction could be
loosened, but it didn't seem important? If it allowed non-absolute paths,
we'd need to decide how to handle:
- foo/bar (relative to CWD?)
- foo (search PATH / LD_LIBRARY_PATH, or also relative to CWD?)
- foo.zip!/bar (normalize_path() requires an absolute path)
The linker adjusts the argc/argv passed to main() and to constructor
functions to hide the initial linker argument, but doesn't adjust the auxv
vector or files like /proc/self/{exe,cmdline,auxv,stat}. Those files will
report that the kernel loaded the linker as an executable.
I think the linker_logger.cpp change guarding against (g_argv == NULL)
isn't actually necessary, but it seemed like a good idea given that I'm
delaying initialization of g_argv until after C++ constructors have run.
Bug: http://b/112050209
Test: bionic unit tests
Change-Id: I846faf98b16fd34218946f6167e8b451897debe5
Currently it normalizes the path to a string with a single uninitialized
byte. It should instead normalize it to "/".
Bug: none
Test: /data/nativetest/linker-unit-tests/linker-unit-tests32
Test: /data/nativetest64/linker-unit-tests/linker-unit-tests64
Change-Id: I06e0f7598d16acfa21875dad53efbc293cfeb44d
The argument to CloseArchive has type ZipArchiveHandle, but we're
passing it a ZipArchiveHandle*. The compiler doesn't detect the type
mismatch because ZipArchiveHandle is a typedef for void*.
Remove a duplicate close() call:
The fourth argument to OpenArchiveFd is "bool assume_ownership = true".
Even if the function fails, ownership of the fd is still transferred to
a ZipArchive object that's deleted when this code calls CloseArchive.
AFAIK, this code path is rarely or never hit.
Bug: none
Test: manual (eventually, 'linker64 /system!/foo')
Change-Id: I95d79809b6e118fb3c39c7b98b8055c8e324db1a
Originally a BSD extension, now in glibc too. We've used it internally
for a while.
(cherry-pick of e4b13f7e3ca68edfcc5faedc5e7d4e13c4e8edb9.)
Bug: http://b/112163459
Test: ran tests
Change-Id: I813c3a62b13ddb91ba41e32a5a853d09207ea6bc
Merged-In: I813c3a62b13ddb91ba41e32a5a853d09207ea6bc
Move source files to filegroup and extract c/ldflags and
version-script to linker_defaults.
Bug: http://b/71494052
Test: make
Change-Id: Ic82885e1c006f91a8446978fabd214f87cd20510
We've copied & pasted these to too many places. And if we're going to
have another go at upstreaming these, that's probably yet another reason
to have the *values* in just one place. (Even if upstream wants different
names, we'll likely keep the legacy names around for a while for source
compatibility.)
Bug: http://b/111903542
Test: ran tests
Change-Id: I8ccc557453d69530e5b74f865cbe0b458c84e3ba
* Initialize the exe's l_ld correctly, and initialize its l_addr field
earlier.
* Copy the phdr/phnum fields from the linker's temporary soinfo to its
final soinfo. This change ensures that dl_iterate_phdr shows the phdr
table for the linker.
* Change init_linker_info_for_gdb a little: use an soinfo's fields to
init the soinfo::link_map_head field, then reuse the new
init_link_map_head function to handle the linker and the executable.
Test: manual
Test: bionic-unit-tests
Bug: https://issuetracker.google.com/112627083
Bug: http://b/110967431
Change-Id: I40fad2c4d48f409347aaa1ccb98d96db89da1dfe
gdbserver assumes that the first entry is the exe, so it must come
first.
Fixes debugging of executables with gdb.
Bug: https://issuetracker.google.com/112627083
Bug: http://b/110967431
Test: gdbclient.py -r toybox
Change-Id: I7b30398d679c3f8b92d8d02572f9073ae0fce798
* Allow sanitization of libc (excluding existing global sanitizers)
and disallow sanitization of linker. The latter has not been
necessary before because HWASan is the first sanitizer to support
static binaries (with the exception of CFI, which is not used
globally).
* Static binary startup: initialize HWASan shadow very early so that
almost entire libc can be sanitized. The rest of initialization is
done in a global constructor; until that is done sanitized code can
run but can't report errors (will simply crash with SIGTRAP).
* Switch malloc_common from je_* to __sanitizer_*.
* Call hwasan functions when entering and leaving threads. We can not
intercept pthread_create when libc depends on libclang_rt.hwasan.
An alternative to this would be a callback interface like requested
here:
https://sourceware.org/glibc/wiki/ThreadPropertiesAPI
All of the above is behind a compile-time check
__has_feature(hwaddress_sanitizer). This means that HWASan actually
requires libc to be instrumented, and would not work otherwise. It's
an implementation choice that greatly reduces complexity of the tool.
Instrumented libc also guarantees that hwasan is present and
initialized in every process, which allows piecemeal sanitization
(i.e. library w/o main executable, or even individual static
libraries), unlike ASan.
Change-Id: If44c46b79b15049d1745ba46ec910ae4f355d19c
This code path is/was a workaround for poorly-behaved apps. AFAIK it isn't
needed anymore.
The (needed != nullptr) condition should have been (needed == nullptr), so
rather than unload a library, it tends to do nothing instead. If it can't
find the library, it would segfault.
Bug: http://b/112154263
Test: /data/nativetest/bionic-unit-tests/bionic-unit-tests
Test: /data/nativetest/linker-unit-tests/linker-unit-tests32
Test: apply patch to pi-dev, verify that apps from b/72143978 still work
Change-Id: Ic598cb3dcead9f88005764a9b8746ed6b35f5f38
arm32: Add a relocation for TLS descriptors (e.g. gcc's
-mtls-dialect=gnu2).
arm64: Add all the dynamic TLS relocations.
Two of the relocations here are obsolete:
- ARM documents R_ARM_SWI24 as an obsolete static relocation without
saying what it did. It's been replaced by R_ARM_TLS_DESC, a dynamic
relocation. We could probably remove it, but I left it because arm32
is old, and I see the macro in other libc's. It's probably analogous
to R_ARM_THM_SWI8, which is also an obsolete relocation reserved for
a future dynamic relocation.
- I couldn't find any ARM documentation at all for
R_AARCH64_TLS_DTPREL32. It seems to have been part of three
relocations:
- R_AARCH64_TLS_DTPREL32 1031
- R_AARCH64_TLS_DTPMOD32 1032
- R_AARCH64_TLS_TPREL32 1033
Bug: b/78026329
Test: run bionic unit tests
Change-Id: I5e7432f6e3e906152dc489be5e812fd8defcbafd
When the linker is invoked directly, rather than as an interpreter for a
real program, the AT_BASE value is 0. To find the linker's base address,
the linker currently relies on the static linker populating the target of
a RELA relocation with an offset rather than leaving it zero. (With lld,
it will require a special flag, --apply-dynamic-relocs.)
Instead, do something more straightforward: the linker already finds the
executable's base address using its PHDR table, so do the same thing when
the linker is run by itself.
Bug: http://b/72789859
Test: boots, run linker/linker64 by itself
Change-Id: I4da5c346ca164ea6f4fbc011f8c3db4e6a829456
