Posix standards says sem_wait is interruptible by the delivery
of a signal. To keep compatiblity with old apps, only fix that
in newer sdk versions.
Bug: 26743454
Change-Id: I924cbb436658e3e0f397c922d866ece99b8241a3
The major components of the rewrite:
- Completely remove the qemu shared library code. Nobody was using it
and it appears to have broken at some point.
- Adds the ability to enable/disable different options independently.
- Adds a new option that can enable the backtrace on alloc/free when
a process gets a specific signal.
- Adds a new way to enable malloc debug. If a special property is
set, and the process has an environment variable set, then debug
malloc will be enabled. This allows something that might be
a derivative of app_process to be started with an environment variable
being enabled.
- get_malloc_leak_info() used to return one element for each pointer that
had the exact same backtrace. The new version returns information for
every one of the pointers with same backtrace. It turns out ddms already
automatically coalesces these, so the old method simply hid the fact
that there where multiple pointers with the same amount of backtrace.
- Moved all of the malloc debug specific code into the library.
Nothing related to the malloc debug data structures remains in libc.
- Removed the calls to the debug malloc cleanup routine. Instead, I
added an atexit call with the debug malloc cleanup routine. This gets
around most problems related to the timing of doing the cleanup.
The new properties and environment variables:
libc.debug.malloc.options
Set by option name (such as "backtrace"). Setting this to a bad value
will cause a usage statement to be printed to the log.
libc.debug.malloc.program
Same as before. If this is set, then only the program named will
be launched with malloc debug enabled. This is not a complete match,
but if any part of the property is in the program name, malloc debug is
enabled.
libc.debug.malloc.env_enabled
If set, then malloc debug is only enabled if the running process has the
environment variable LIBC_DEBUG_MALLOC_ENABLE set.
Bug: 19145921
Change-Id: I7b0e58cc85cc6d4118173fe1f8627a391b64c0d7
This is just a subset of the recently-implemented getifaddrs(3), though if
we want to handle interfaces (such as "rmnet_*") that don't have an address,
we need to either expose ifaddrs_storage and keep track of which interfaces
we've already seen (which is pretty messy), or refactor the netlink code so
we can reuse it and just extract the information we need for if_nameindex(3).
This patch goes the latter route.
Also clean up if_nametoindex(3) and if_indextoname(3).
Change-Id: I5ffc5df0bab62286cdda2e7af06f032c767119a8
Also fix a bug where we were mutating the address/broadcast address
of an existing entry rather than the new entry, and use 'const' to
ensure we don't make that mistake again.
Change-Id: I31c127a5d21879b52c85cd0f7ed2e66554a21e39
Exactly which functions get a stack protector is up to the compiler, so
let's separate the code that sets up the environment stack protection
requires and explicitly build it with -fno-stack-protector.
Bug: http://b/26276517
Change-Id: I8719e23ead1f1e81715c32c1335da868f68369b5
Currently, reads of ro.* properties are treated differently than
writes of ro.* properties. When writing an ro.* property, we ignore
the "ro." portion of the property, and base the security decision
on the label of the remaining portion.
See e7a9e52740/init/property_service.cpp
line 120-126
For example, for writing, the label associated with
"ro.build.fingerprint" comes from the /property_contexts file
entry:
# ro.build.fingerprint is either set in /system/build.prop, or is
# set at runtime by system_server.
build.fingerprint u:object_r:fingerprint_prop:s0
However, we fail to follow this same special case when sorting
properties into files. Instead, ro.build.fingerprint is assigned
u:object_r:default_prop:s0 instead of u:object_r:fingerprint_prop:s0
Ignore the "ro." portion when sorting properties into files.
This will make reads and writes of properties use the same label.
Bug: 21852512
Change-Id: Ie88ffc6b78b31fc8ddf370ae27c218546fb25a83
This reverts commit 76814a8250.
This differs from the original in fixing the GCC -Werror build:
bionic/libc/bionic/ifaddrs.cpp: In function 'void __handle_netlink_response(ifaddrs**, nlmsghdr*)':
bionic/libc/bionic/ifaddrs.cpp:113:62: error: use of old-style cast [-Werror=old-style-cast]
ifinfomsg* ifi = reinterpret_cast<ifinfomsg*>(NLMSG_DATA(hdr));
This appears to be a GCC bug; the GCC command-line correctly uses -isystem,
and manually adding #pragma GCC system_header doesn't help. So just turn the
warning off for GCC for now. We won't need to worry about building with GCC
soon anyway.
Bug: http://b/26238832
Change-Id: I01615bd335edf11baf487b1c83a9157cd780f4a1
Time to dust off the old libcore implementation from gingerbread and add it
to bionic. Unlike the original, this actually looks at both RTM_NEWLINK and
RTM_NEWADDR.
Bug: http://b/26238832
Change-Id: I7bb4b432deb766065b66b9c9ff36ed68249aba82
It actually means "crash immediately". Well, it's an error. And callers are
much more likely to realize their mistake if we crash immediately rather
than return EINVAL. Historically, glibc has crashed and bionic -- before
the recent changes -- returned EINVAL, so this is a behavior change.
Change-Id: I0c2373a6703b20b8a97aacc1e66368a5885e8c51
This change removes endpwent, dlmalloc_inspect_all, dlmalloc_trim
from lp64 libc.so. It also removed necessety of having brillo
version scripts for lp64 platforms.
Bug: http://b/26164862
Change-Id: I4e9b38907bb1dc410f0eb6d2f5d5944fe713da51
Treat subsequent calls to __system_properties_init() as a
reinitialization of system properties and revoke access to prop files
that have been previously mapped but that the process's current context
does not have access to. Additionally reset the no_access_ flag in
case permissions have loosened and previously unaccessible files can now
be accessed.
This is meant to work around an issue that setcon() does not revoke
mmap() mappings, so we must manually revoke them after a successful
setcon() call.
Bug 26114086
Change-Id: I4d690abb6817283ca64ac26ea4c1dad398a98fbc
Currently, if the debug.atrace.tags.enableflags property is not found,
it is set to a safe value such that a pointer to this property can be
stored for later access. This may result in selinux denials because not
all processes write permissions for this property or permission to
connect to the property write socket at all.
Change I6d953c0c281fd72ad3eba8a479fd258023579b5b writes this property to
a safe value upon boot, which greatly decreases the cases in which this
property will not be accessible and removes the need to write it here.
This commit removes this write.
Bug 26115803
Change-Id: Ief72c5f731d3a1231b5080eb531fa0a491a8b1d1
We need to ensure %gs:20 is set up early enough for -fstack-protector-strong
on x86, and that __set_tls doesn't get stack protector checks because it's a
prerequisite for them. x86 devices/emulators won't boot without this.
Bug: http://b/26073874
Change-Id: Icf0d34294648cc0c8cb406a3617befe0d45c525a
POSIX defined bcopy to handle overlapping memory akin to memmove and
bionic appears to have always done so.
Change-Id: I2599113411e3532913270ba1c1b49e35cbc5f106
This reverts commit c8bae05f3f.
We were breaking init (ueventd) because we initialize system properties
before we initialize stdio. The new system property implementation uses
stdio to read from /property_contexts, so we end up touching stdio data
structures before they've been initialized.
This second attempt takes things further by removing the stdio initialization
function altogether. The data structures for stdin/stdout/stderr can be
statically initialized as data, and -- since we already had to give the
atexit implementation a backdoor for stdio -- we can just admit that we
need to clean up stdio, and that we always do so last.
This patch also removes the 17 statically pre-allocated file structures,
so the first fopen will now allocate a block of 10 (the usual overflow
behavior). I did this just to make my life simpler, but it's not actually
necessary to remove it if we want it back.
Change-Id: I936b2eb5e88e4ebaf5516121872b71fc88e5609c
This reverts commit 4371961e00.
This broke booting; ueventd crashes with a null pointer dereference
somewhere in __sfp (but the kernel doesn't unwind, so I don't know
what was calling __sfp).
Change-Id: I65375fdfdf1d339a06558b4057b580cacd6324e2
Primarily a debug feature that can be switched at runtime to permit
developer to have the option of high-resolution Android logs with
either CLOCK_REALTIME (default) or CLOCK_MONOTONIC to correlate with
other system activities like kernel logs or systrace.
Bug: 23668800
Change-Id: Ib29024899540f51a72cad5dde25517a7134d68f7
If a __system_property* function is called before
__system_properties_init() then the app will will abort. This commit
returns either an error code or a safe return value instead.
Bug 26027140
Change-Id: I95ffd143e9563658ab67a397991e84fb4c46ab77
Several parts in pthread_internal_t should be initialized
to zero, like tls, key_data and thread_local_dtors. So
just clear the whole pthread_internal_t is more convenient.
Bug: 25990348
Change-Id: Ibb6d1200ea5e6e1afbc77971f179197e8239f6ea
The purpose of this change is to add read access control to the property
space.
In the current design, a process either has access to the single
/dev/__properties__ file and therefore all properties that it contains
or it has access to no properties. This change separates properties
into multiple property files based on their selabel, which allows
creation of sepolicies that allow read access of only specific sets of
properties to specific domains.
Bug 21852512
Change-Id: Ice265db79201ca811c6b6cf6d851703f53224f03
Previously we call __sinit() lazily. But it is likely to cause data
races like in https://android-review.googlesource.com/#/c/183237/. So
we prefer to call __sinit() explicitly at libc initialization.
Bug: 25392375
Change-Id: I181ea7a4b2e4c7350b45f2e6c86886ea023e80b8
Currently we use __thread variable to store thread_local_dtors,
which makes tsan test fork_atexit.cc hang. The problem is as below:
The main thread creates a worker thread, the worker thread calls
pthread_exit() -> __cxa_thread_finalize() -> __emutls_get_address()
-> pthread_once(emutls_init) -> emutls_init().
Then the main thread calls fork(), the child process cals
exit() -> __cxa_thread_finalize() -> __emutls_get_address()
-> pthread_once(emutls_init).
So the child process is waiting for pthread_once(emutls_init)
to finish which will never occur.
It might be the test's fault because POSIX standard says if a
multi-threaded process calls fork(), the new process may only
execute async-signal-safe operations until exec functions are
called. And exit() is not async-signal-safe. But we can make
bionic more reliable by not using __thread in
__cxa_thread_finalize().
Bug: 25392375
Change-Id: Ife403dd7379dad8ddf1859c348c1c0adea07afb3
It is reported by tsan that funlockfile() can unlock an unlocked mutex.
It happens when printf() is called before fopen() or other stdio stuff.
As FLOCKFILE(fp) is called before __sinit(), _stdio_handles_locking is false,
and _FLOCK(fp) will not be locked. But then cantwrite(fp) in __vfprintf()
calls__sinit(), which makes _stdio_handles_locking become true, and
FUNLOCKFILE(fp) unlocks _FLOCK(fp).
Change _stdio_handles_locking into _caller_handles_locking,
so __sinit() won't change its value. Add test due to my previous fault.
Bug: 25392375
Change-Id: I483e3c3cdb28da65e62f1fd9615bf58c5403b4dd
Currently is_private_anonymous is calculated as true if _either_
MAP_PRIVATE or MAP_ANONYMOUS is set, which is a mistake.
According to Documentation/vm/ksm.txt, "KSM only merges anonymous
(private) pages, never pagecache (file) pages". MAP_PRIVATE can
still be set on file cache pages so in order to not redundantly
set MADV_MERGEABLE on pages that are not fitted for it, both
MAP_PRIVATE and MAP_ANONYMOUS should be set.
Along with this fix, add an extra check that the mapped page is
not a stack page before setting MADV_MERGEABLE for it. Stack pages
change too quickly and always end up in KSM 'page_volatile' list.
Change-Id: If4954142852f17cc61f02985ea1cb625a7f3dec6
If tsan is used, the following callchain can happen:
__libc_preinit() -> __libc_init_globals() ->
__libc_init_vdso() -> strcmp() -> __tsan_init()
-> sysconf(_SC_PAGE_SIZE) -> getauxval().
But __libc_auxv is initialized in __libc_init_common(),
after __libc_init_globals(). One simple way to fix
this is to initialize __libc_auxv at __libc_init_globals().
Bug: 25392375
Change-Id: I3893b1f567d5f3b7a8c881c0c1b8234b06b7751b
This removes another way to obtain objects larger than PTRDIFF_MAX. The
only known remaining hole is now jemalloc's merging of virtual memory
spans.
Technically this could be wrapped in an __LP64__ ifndef since it can't
occur on 64-bit due to the 1:1 split. It doesn't really matter either
way.
Change-Id: Iab2af242b775bc98a59421994d87aca0433215bd
In order to run tsan unit tests, we need to support pthread spin APIs.
Bug: 18623621
Bug: 25392375
Change-Id: Icbb4a74e72e467824b3715982a01600031868e29
If calling pthread_mutex_trylock from pthread_mutex_destroy, tsan
warns about an attempt to destroy a locked mutex.
Bug: 25392375
Change-Id: I5feee20e7a0d0915adad24da874ec1ccce241381
The current comment implies that we only strip sensitive
environment variables on executing a setuid program. This is
true but incomplete. The AT_SECURE flag is set whenever a
security transition occurs, such as executing a setuid program,
SELinux security transition, executing a file with file capabilities,
etc...
Fixup the comments.
Change-Id: I30a73992adfde14d6e5f642b3a1ead2ee56726be
The mremap definition was incorrect (unsigned long instead of int) and
it was missing the optional new_address parameter.
Change-Id: Ib9d0675aaa098c21617cedc9b2b8cf267be3aec4
_signal was static in 64 bit, and hidden on 32 bit. There is no
reason to have this distinction, so make it hidden in all cases.
Change-Id: I09d5d93ac8cab4fe14dc7bdfeb25aa46a3b7413d
These don't work, aren't thread-safe, aren't in POSIX (or our header
files), and are only used by one app (whose developers I've contacted).
But the presence of these symbols causes configure to be confused, which
is a pain for Brillo.
Bug: http://b/24812426
Change-Id: I7fa6ef82864d5563929d9b8a7f8fcacb30b26d45
It removes calling to pthread_mutex_lock() at the beginning of new
thread, which helps to support thread sanitizer.
Change-Id: Ia3601c476de7976a9177b792bd74bb200cee0e13
Rewrite inet_addr and inet_network in terms of inet_aton, and reimplement
that to include all the missing error checks.
Bug: http://b/24754503
Change-Id: I5dfa971c87201968985a0894df419f0fbf54768a
Read /proc/stat to count online cpus is not correct for all android
kernels. Change to reading /sys/devices/system/cpu/online instead.
Bug: 24376925
Change-Id: I3785a6c7aa15a467022a9a261b457194d688fb38
Bug: 24492248
Shifting sign bits left is considered undefined behavior, so we need to
switch these uses to unsigned equivalents. The time_t-related code is
updated relative to upstream sources.
Change-Id: I226e5a929a10f5c57dfcb90c748fdac34eb377c2
Until we implement full support for passwd/group files, add a simple
way to use the new OEM UID/GID range (5000-5999).
oem_XXX -> 5000 + XXX iff 0 <= XXX < 1000.
Bug: 23225475
Change-Id: If48b88135d5df538313414f747d6c4c63bf0a103
Reuse the top bits of _JB_SIGFLAG field previously used to store a
boolean to store a cookie that's validated by [sig]longjmp to make it
harder to use as a ROP gadget. Additionally, encrypt saved registers
with the cookie so that an attacker can't modify a register's value to
a specific value without knowing the cookie.
Bug: http://b/23942752
Change-Id: Id0eb8d06916e89d5d776bfcaa9458f8826717ba3
For previous way to get the stack using the [stack] string from
/proc/self/task/<pid>/maps is not enough. On x86/x86_64, if an
alternative signal stack is used while a task switch happens,
the [stack] indicator may no longer be correct.
Instead, stack_start from /proc/self/stat which is always inside
the main stack, is used to find the main stack in /proc/self/maps.
Change-Id: Ieb010e71518b57560d541cd3b3563e5aa9660750
Signed-off-by: Nitzan Mor-sarid <nitzan.mor-sarid@intel.com>
Signed-off-by: Mingwei Shi <mingwei.shi@intel.com>
Allocations larger than PTRDIFF_MAX can be successfully created on
32-bit with a 3:1 split, or in 32-bit processes running on 64-bit.
Allowing these allocations to succeed is dangerous, as it introduces
overflows for `end - start` and isn't compatible with APIs (mis)using
ssize_t to report either the size or an error. POSIX is guilty of this,
as are many other Android APIs. LLVM even considers the `ptr + size`
case to be undefined, as all pointer arithmetic compiles down to signed
operations and overflow is treated as undefined for standard C pointer
arithmetic (GNU C `void *` arithmetic works differently).
This also prevents dlmalloc from allocating > PTRDIFF_MAX as it doesn't
merge mappings like jemalloc. A similar check will need to be added in
jemalloc's code path for huge allocations.
The musl libc implementation also performs this sanity check.
Change-Id: I5f849543f94a39719f5d27b00cef3079bb5933e9
The debug malloc code unconditionally closes stdin/stdout/stderr,
which means that other atexit functions cannot use them. Only
close these if there is a debug malloc final function to call.
This doesn't appear to be a problem on most normal applications or the
atexit_exit bionic unit test would be failing. However, if you
enable stat dumping in jemalloc, nothing prints. Most likely trying
to add an atexit function from within libc is causing that atexit
to run after the debug malloc atexit function.
Change-Id: I963720d4ccaaa511e44af07a7461f17eb3f84e8e
