A proposed set of changes:
https://android-review.googlesource.com/q/topic:"no-dup-hwasans"
will cause the HWASAN runtime to be moved from /system/lib64 to
/system/lib64/bootstrap. This causes a problem in the case where libc is built
with HWASAN but init is not built with HWASAN. In this case, libc.so will have
a DT_NEEDED dependency on the HWASAN runtime but init will not. Currently,
init and other bootstrap executables arrange to load bootstrap libraries by
setting rpath, but rpath only has an effect on libraries directly depended
on by the main executable, not libraries indirectly depended on by it. This
means that the loading of the HWASAN runtime will fail.
Instead of relying on rpath to find the bootstrap libraries, modify the
bootstrap linker so that it searches the bootstrap library directory after
searching the rpath.
Change-Id: I297be32e04ecd316ee12b8e694588e1249e2bb89
Given that we have both linker and linker64, I didn't really want to have
to have ldd and ldd64, so this change just adds the --list option to the
linkers and a shell script wrapper "ldd" that calls the appropriate
linker behind the scenes.
Test: adb shell linker --list `which app_process32`
Test: adb shell linker64 --list `which date`
Test: adb shell ldd `which app_process32`
Test: adb shell ldd `which date`
Change-Id: I33494bda1cc3cafee54e091f97c0f2ae52d1f74b
ANDROID_DLEXT_WRITE_RELRO was inadvertently writing out the RELRO
section of all libraries loaded during a given dlopen() call instead of
only the main library; since the other libraries are loaded at
unpredictable addresses this additional data is rarely useful.
Fix this to only happen when the
ANDROID_DLEXT_RESERVED_ADDRESS_RECURSIVE flag is being used.
Bug: 128623590
Test: DlExtRelroSharingTest.CheckRelroSizes
Change-Id: I05e8651d06ce2de77b8c85fe2b6238f9c09691ad
ANDROID_DLEXT_WRITE_RELRO was causing the GNU RELRO sections of
libraries to become corrupted if more than one library was being loaded
at once (i.e. if the root library has DT_NEEDED entries for libraries
that weren't already loaded). The file offset was not being correctly
propagated between calls, so after writing out the (correct) RELRO data
to the file, it was mapping the data at file offset 0 for all libraries,
which corrupted the data for all but one of the libraries.
Fix this by passing file_offset as a pointer the same way that
phdr_table_map_gnu_relro does.
Bug: 128623590
Test: tbd
Change-Id: I196cd336bd5a67454e89fd85487356b1c7856871
In order to enable no-vendor-variant VNDK, we need a way to restrict a
namespace to only a list of whitelisted libraries. We add a new
"whitelisted" property for this. If the property is not set, all
libraries in the search paths are available in a namespace. If the
property is set, only the libraries named are available.
Bug: 119423884
Test: Boot with no-vendor-variant VNDK enabled using the new property.
Change-Id: Id808c1733c8e2c2c3462b04c72461f9698403571
- Show which executable is being linked, which linker config file is
being read, and which section in it is being used with, enabled on
$LD_DEBUG>=1.
- Show more info to follow the dlopen() process, enabled with "dlopen"
in the debug.ld.xxx property.
Test: Flash, boot, and look at logcat after "adb shell setprop debug.ld.all dlopen"
Bug: 120430775
Change-Id: I5441c8ced26ec0e2f04620c3d2a1ae860b792154
The tlsdesc_resolver_dynamic function is only defined on arm64, but the
code was taking its address on all targets. (Apparently the optimizer was
removing the entire deferred_tlsdesc_relocs loop?)
Bug: none
Test: bionic unit tests
Test: add -O0 to cc_defaults in linker/Android.bp, device boots
Change-Id: I899c78018cbe82aeaca7856c9f7b04300c1d3196
It's possible and sometimes beneficial for a library to have disjoint mappings
and for other libraries to be mapped into the gap between the mappings using
ANDROID_DLEXT_RESERVED_ADDRESS. See for example the proposal for partitioning
in lld [1].
Because the find_containing_library and do_dl_unwind_find_exidx functions use
a simple bounds check to figure out whether a pointer belongs to a library
they will, given a pointer into a library mapped into the gap of a library
with disjoint mappings, return a pointer to the soinfo for the outer library
instead of the inner one, because the outer library will appear before the
inner one in the solist.
From a user perspective this means that we won't be able to unwind the inner
library's frames on 32-bit ARM with libgcc, dladdr() will return information
for the outer library given a pointer to the inner one and dlopen() et al will
use the linker namespace of the outer library when called from the inner one
(although they will usually be the same).
To make this work correctly, make it so that once find_containing_library
sees a match for the bounds check, it examines the library's PT_LOADs to
make sure that there is a mapping for the given address. This is similar
to how libgcc and libunwind_llvm already handle finding the PT_GNU_EH_FRAME
on non-ARM32 platforms [2,3]. do_dl_unwind_find_exidx is reimplemented in
terms of find_containing_library.
[1] http://lists.llvm.org/pipermail/llvm-dev/2019-February/130583.html
[2] e739ac0e25/libunwind/src/AddressSpace.hpp (L523)
[3] https://android.googlesource.com/toolchain/gcc/+/master/gcc-4.9/libgcc/unwind-dw2-fde-dip.c#294
Test: /data/nativetest{,64}/bionic-unit-tests/bionic-unit-tests on walleye-userdebug
Change-Id: I368fe6ad3c470b3dff80f7d9b04253566d63a7d2
Introduce a new flag ANDROID_DLEXT_RESERVED_ADDRESS_RECURSIVE which
instructs the linker to use the reserved address space to load all of
the newly-loaded libraries required by a dlopen() call instead of only
the main library. They will be loaded consecutively into that region if
they fit. The RELRO sections of all the loaded libraries will also be
considered for reading/writing shared RELRO data.
This will allow the WebView implementation to potentially consist of
more than one .so file while still benefiting from the RELRO sharing
optimisation, which would otherwise only apply to the "root" .so file.
Test: bionic-unit-tests (existing and newly added)
Bug: 110790153
Change-Id: I61da775c29fd5017d9a1e2b6b3757c3d20a355b3
The change is a workaround of app compat issue until the app fixes the
issue.
Likely, the app does not only dlopen(), but open() the libicuuc.so
with the absolute path.
Note that platform uses the stub libandroidicu.so, not libicuuc directly.
This CL topic moves (not duplicates) libandroidicu from /system to
/apex. Even though /system/lib/libicuuc.so is kept in the default
namespace, but no one should be using it.
Some debug info after this CL:
$ adb shell cat /proc/<zygote pid>/maps | grep libicuuc
$ adb shell cat /proc/<app pid>/maps | grep libicuuc
Only /apex/com.android.runtime/lib64/libicuuc.so is found, not the
/system.
Bug: 124218500
Test: The app can be launched successfully
Test: CtsJniTestCases
Change-Id: I67a50f0ad934be567a63d4038215546c9b4e5f7e
Some of the greylist libraries can be in directories other than
/system/lib. For example, libnativehelper.so is moved from the directory
to /apex/com.android.runtime/lib.
Previous behavior for greylist libraries is to find the lib under
/system/lib while "within" the current namespace which is usually the
classloader-namespace. Since the libs no longer exist there, linker
fails to load it and no further attempt is made.
This change fixes the problem by loading the greylist libs "from" the
default namespace. Since there is a link from the default namespace to
the namespace where the moved libraries are intended to be loaded (e.g.,
the 'runtime' namespace for libnativehelper.so), the call is successful.
Bug: 124201397
Test: bionic-unit-tests
Change-Id: I11d15993d18896bdf663c408f9e40d8a607c9b80
This reverts commit 1906e77665
and fixes dlopen(nullptr)
It's enabled for the following .so libraries
libicuuc.so
libicui18n.so
This CL does not move the .so files into a APEX.
Thus, no visible effect before moving .so files.
Bug: 121248172
Test: dlfcn#dlopen_from_nullptr
Test: Perform the following test after moving libicuuc to /apex
dlopen("/system/lib64/libicuuc.so") for targetSdkVersion < Q
Change-Id: Ia310ea566485fe00ca28e2203f4bffbd92243638
It's enabled for the following .so libraries
libicuuc.so
libicui18n.so
This CL does not move the .so files into a APEX.
Thus, no visible effect before moving .so files.
Bug: 121248172
Test: Perform the following test after moving libicuuc to /apex
dlopen("/system/lib64/libicuuc.so") for targetSdkVersion < Q
Change-Id: Ic00d281d59de924c01582c48d2a946e3f5f33a09
This is the second attempt to purge linker block allocators. Unlike the
previously reverted change which purge allocators whenever all objects
are freed, we only purge right before control leaves the linker. This
limits the performance impact to one munmap() call per dlopen(), in
most cases.
Bug: 112073665
Test: Boot and check memory usage with 'showmap'.
Test: Run camear cold start performance test.
Change-Id: I02c7c44935f768e065fbe7ff0389a84bd44713f0
Each TLSDESC relocation relocates a 2-word descriptor in the GOT that
contains:
- the address of a TLS resolver function
- an argument to pass (indirectly) to the resolver function
(Specifically, the address of the 2-word descriptor is passed to the
resolver.)
The loader resolves R_GENERIC_TLSDESC relocations using one of three
resolver functions that it defines:
- tlsdesc_resolver_static
- tlsdesc_resolver_dynamic
- tlsdesc_resolver_unresolved_weak
The resolver functions are written in assembly because they have a
restrictive calling convention. They're only allowed to modify x0 and
(apparently) the condition codes.
For a relocation to memory in static TLS (i.e. the executable or an solib
loaded initially), the loader uses a simple resolver function,
tlsdesc_resolver_static, that returns the static offset it receives from
the loader.
For relocations to dynamic TLS memory (i.e. memory in a dlopen'ed solib),
the loader uses tlsdesc_resolver_dynamic, which allocates TLS memory on
demand. It inlines the fast path of __tls_get_addr, then falls back to
__tls_get_addr when it needs to allocate memory. The loader handles these
dynamic TLS relocations in two passes:
- In the first pass, it allocates a table of TlsDynamicResolverArg
objects, one per dynamic TLSDESC relocation.
- In the second pass, once the table is finalized, it writes the
addresses of the TlsDynamicResolverArg objects into the TLSDESC
relocations.
tlsdesc_resolver_unresolved_weak returns a negated thread pointer so that
taking the address of an unresolved weak TLS symbols produces NULL.
The loader handles R_GENERIC_TLSDESC in a target-independent way, but
only for arm64, because Bionic has only implemented the resolver functions
for arm64.
Bug: http://b/78026329
Test: bionic unit tests
Test: check that backtrace works inside a resolver function and inside
__tls_get_addr called from a resolver
(gdbclient.py, b __tls_get_addr, bt)
Merged-In: I752e59ff986292449892c449dad2546e6f0ff7b6
Change-Id: I752e59ff986292449892c449dad2546e6f0ff7b6
Generalize the omitted symbol and missing-TLS-segment behaviors to all TLS
relocations.
R_GENERIC_TLS_DTPMOD is a module ID, which starts at 1 for the executable.
R_GENERIC_TLS_DTPREL is an offset from the start of a module to a specific
TLS symbol.
binutils currently disagrees with Bionic about the values of
R_AARCH64_TLS_DTPMOD64 and R_AARCH64_TLS_DTPREL64, so disable
DTPMOD/DTPREL for now on arm64.
Bug: http://b/78026329
Test: bionic unit tests (Tests for dynamic TLS will be added later)
Change-Id: I05c28d6a1036bdd6127f605036679b7475689445
These dynamic table entries are used for lazy relocation of TLSDESC
relocations. Bionic relocates everything eagerly and can ignore these
entries.
Bug: http://b/78026329
Test: bionic unit tests
Test: manual
Change-Id: I788c4a95041fae66de2fbeab3babe0205631999c
The field was pointing into an element of an std::vector, but the address
of a vector element is invalidated when the vector is resized.
This bug was caught by the new elftls.shared_ie and
elftls_dl.dlopen_shared_var_ie tests.
Bug: http://b/78026329
Test: bionic unit tests
Change-Id: I7232f6d703a9e339fe8966a95b7a68bae2c9c420
* changes:
Handle R_GENERIC_TLS_TPREL relocations
Avoid a dlopen abort on an invalid TLS alignment
Initialize static TLS memory using module list
Record TLS modules and layout static TLS memory
StaticTlsLayout: add exe/tcb and solib layout
This relocation is used for static TLS's initial-exec (IE) accesses.
A TLS symbol's value is its offset from the start of the ELF module's
TLS segment. It doesn't make sense to add the load_bias to this value,
so skip the call to soinfo::resolve_symbol_address.
Allow TLS relocations to refer to an unresolved weak symbol. In that case,
sym will be non-zero, but lsi will be nullptr. The dynamic linker resolves
the TPREL relocation to 0, making &missing_weak_symbol equal the thread
pointer.
Recognize Gold-style relocations to STB_LOCAL TLS symbols/sections and
issue an error.
Remove the "case R_AARCH64_TLS_TPREL64", because the R_GENERIC_TLS_TPREL
case handles it.
Remove the no-op R_AARCH64_TLSDESC handler. It's better to issue an error.
dlopen_library_with_ELF_TLS now fails with a consistent error about an
unimplemented dynamic TLS relocation.
Bug: http://b/78026329
Test: bionic unit tests (elftls tests are added in a later CL)
Change-Id: Ia08e1b5c8098117e12143d3b4ebb4dfaa5ca46ec
If the alignment of a TLS segment in a shared object is invalid, return
an error through dlerror() rather than aborting the process.
Bug: http://b/78026329
Test: bionic unit tests
Change-Id: I60e589ddd8ca897f485d55af089f08bd3ff5b1fa
It can happen e.g. if android_dlopen_ext is called with an absolute path to
a file that is not accessible in the current namespace. The first
load_library call in find_library_internal will then open the file and
assign its fd to the task and return false. Then linked namespaces are
searched, and load_library gets called again and opens the same file and
overwrites the fd in the task without closing it first. (In one of the later
calls the namespace config might very well allow the file to be loaded and
the android_dlopen_ext call eventually returns successfully, and the process
continues with the leaked fd.)
The code could perhaps be changed to avoid opening the file repeatedly in
these cases, but the LoadTask class should arguably keep its state clean
anyway.
Bug: 113373927
Test: Flash and boot device with (and without) http://r.android.com/812674,
which moves libart.so to the runtime namespace and thus makes it load
/system/framework/*/boot*.oat files across the namespace boundary from
runtime to default.
Change-Id: Iae91b7c743c5f3f973506153ba52898ae72e6fee
- Insert /apex/com.android.runtime/lib(64) before /system/lib(64)
in the default library search paths (`kDefaultLdPaths`,
`kAsanDefaultLdPaths`).
- Insert apex/com.android.runtime/bin before /system/bin in the
default shell search path (`_PATH_DEFPATH`).
Test: Device boot test with Android Runtime APEX.
Test: Device boot test without Android Runtime APEX.
Bug: 113373927
Change-Id: I9ae6bfe6939f63e7d76e7b3c9b21d8b698bd8fda
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
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
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
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
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
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
init is now built as a dynamic executable, so the dynamic linker has to
be able to run in the init process. However, since init is launched so
early, even /dev/* and /proc/* file systems are not mounted and thus
some APIs that rely on the paths do not work. The dynamic linker now
goes alternative path when it is running in the init process.
For example, /proc/self/exe is not read for the init since we always now
the path of the init (/init). Also, arc4random* APIs are not used since
the APIs rely on /dev/urandom. Linker now does not randomize library
loading order and addresses when running in the init process.
Bug: 80454183
Test: `adb reboot recovery; adb devices` shows the device ID
Change-Id: I29b6d70e4df5f7f690876126d5fe81258c1d3115
The tls_nodelete state should apply to load_group not
isolated soinfo. This actually also means that multiple
soinfos may have tls_counter on their dso_handles.
This change replaces TLS_NODELETE flag with secondary counter.
Note that access to the secondary counter (located inside soinfo)
is pretty expensive because it requires soinfo lookup by dso_handle
whereas dso_handle counter is much faster. This is why it is updated
only when dso_handle counter starts or hits 0.
Bug: http://b/80278285
Test: bionic-unit-tests --gtest_filter=dl*
Change-Id: I535583f6714e45fa2a7eaf7bb3126da20ee7cba9
