PR_GET_DUMPABLE is used by an application to indicate whether or
not core dumps / PTRACE_ATTACH should work.
Security sensitive applications often set PR_SET_DUMPABLE to 0 to
disable core dumps, to avoid leaking sensitive memory to persistent
storage. Similarly, they also set PR_SET_DUMPABLE to zero to prevent
PTRACE_ATTACH from working, again to avoid leaking the contents
of sensitive memory.
Honor PR_GET_DUMPABLE when connecting to debuggerd. If an application
has said it doesn't want its memory dumped, then we shouldn't
ask debuggerd to dump memory on its behalf.
FORTIFY_SOURCE tests: Modify the fortify_source tests to set
PR_SET_DUMPABLE=0. This reduces the total runtime of
/data/nativetest/bionic-unit-tests/bionic-unit-tests32 from approx
53 seconds to 25 seconds. There's no need to connect to debuggerd
when running these tests.
Bug: 16513137
Change-Id: Idc7857b089f3545758f4d9b436b783d580fb653f
There's no need: __linker_init only takes one argument.
Also remove the arm __CTOR_LIST__; we use .init_array and .fini_array instead
of .ctor and .dtor anyway, and I don't think we've ever supported the latter.
Change-Id: Ifc91a5a90c6aa39d674bf0509a7af2e1ff0beddd
Also fix a few formatting issues in copyright headers that were confusing
the script (though obviously it would be better if the script were smarter).
Change-Id: I7f561bef4f84fdcbd84f375ee226bd65db0e507b
/system/bin/tf_daemon on Nakasi has been updated so it's
a PIE executable. We can now drop non-PIE support.
This reverts commit d81b3b275d.
Bug: 15086752
Bug: 15732002
Bug: 14566672
Change-Id: I832c4de01a8fa050754ea64da317d1639990265e
On Nakasi builds, /system/bin/tf_daemon is a pre-compiled
vendor supplied binary. When support for non-PIE executables
was removed, that daemon failed to start, which induced
a number of bugs.
* keystore is broken
* CTS runs will hang after a certain period of time
Temporarily reenable non-PIE support for 32-bit platforms
until Nakasi is fixed.
This rolls back the following commits:
Cleanup: updated comments
* 6275f20834
Cleanup: remove AARCH/ARM_COPY relocation support
* b906e13c55
And restricts the following patch to 64 bit only:
Remove support for non-PIE executables
* 2aebf5429b
Bug: 14566672
Bug: 15086752
Bug: 15732002
Change-Id: Ia2501aa14bd30feb4a6ce66bdb7c9f066dba0b5f
While introducing RTLD_NOLOAD in b648a8a5 a change in how soinfo structs are
connected was also introduced. When calling dlopen the library that is loaded
is added as a child to the soinfo from which the caller comes - i.e. building a
dependency graph.
Unfortunately this shows issues upon unloading, such as blowing the stack if
there are loops in the graph.
This change reverts that part of b648a8a5, keeping everything as a child of the
root soinfo.
Change-Id: I604ee9210613b19f693a568158e69707620a95db
Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
* Removed unnecessary NULL check in dlsym
* Fixed dlsym_failure test to account for
correct RTLD_DEFAULT value
* Added temporary check for legacy RTLD_DEFAULT
value for non-yet-recompiled binaries
Bug: 15146875
Change-Id: I089fa673762629f5724b6e4fbca019d9cfc39905
bionic RTLD_NEXT was changed from 0xffffffff to -1L, which breaks
existing binaries compiled. Temporarily look either until we can
get recompiled binaries.
Bug: 15113039
Change-Id: I1568fa0e4a832c5e6df21da74a33b22bde7f16f6
Linker is now able to resolve symlinked libraries correctly.
soinfo is extended to save the graph of dependencies during
load/unload. Dependencies are used only in CallConstructor.
Bug: 9741592
Change-Id: Id9c48a74c46aa89bcdf3d54ec2f8ba3d398130b1
Freeing block mprotects on the page which it turn
may lead to application crash if linker subsequently
tries to modify another block on the page.
Bug: 14895266
Change-Id: I8ff7f5df467d7be184242de652032b3c84e24b76
Don't support the dynamic linker loading ET_EXEC executables. Only
support ET_DYN executables.
Bug: 14566672
Change-Id: Ia1f2bfffe7ea867c1cd62e67d7fd637c60c0728d
If the file has no relro segment, the generated relro file will have
length 0, which caused mmap to fail. If the relro file has nonzero size,
but is too short (e.g. because it's for the wrong version of the
library), the linker would segfault while comparing the data. Fix both
these issues: don't try to map a zero length file, and don't try to
compare data that would be beyond the end of the file.
Improve test to explicitly generate two versions of the library: one
with -z relro, and one with -z norelro, so we can test both cases; also
explicitly test the case where the relro file has length 0.
Bug: 14299541
Change-Id: Id8b95585edda90e8bb5de452a35b70ed2d224934
