CFI attempts to verify that the dynamic type of a function object
matches the static type of the function pointer used to call it.
https://clang.llvm.org/docs/ControlFlowIntegrity.html#indirect-function-call-checking
However, the analyzer does not have enough information to check
cross-dso calls. In these instances, CFI crashes upon calling the
function with an error like:
pthread_create_linux.cc:60:16: runtime error:
control flow integrity check for type
'int (unsigned long *, const pthread_attr_t *, void *(*)(void *), void *)'
failed during indirect function call
(/lib/x86_64-linux-gnu/libpthread.so.0+0x9200):
note: (unknown) defined here pthread_create_linux.cc:60:16:
note: check failed in crashpad_handler,
destination function located in /lib/x86_64-linux-gnu/libpthread.so.0
Change-Id: Ib29dabfe714f2ee9cc06a5d17e6899ff81a06df4
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2339332
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
On Android, the compat library built compat/android/sys/mman.cc, which
provides a fallback for mmap, and compat/linux/sys/mman.cc, which
provides a fallback for memfd_create. This can result in two object
files colliding in the library, which is flagged as a “gn analyze”
error:
> ERROR at //crashpad/compat/BUILD.gn:62:5: Duplicate object file
> static_library(target_name) {
> ^----------------------------
> The target //crashpad/compat:compat
> generates two object files with the same name:
> obj/crashpad/compat/compat/mman.o
>
> It could be you accidentally have a file listed twice in the
> sources. Or, depending on how your toolchain maps sources to
> object files, two source files with the same name in different
> directories could map to the same object file.
>
> In the latter case, either rename one of the files or move one of
> the sources to a separate source_set to avoid them both being in
> the same target.
The files are renamed to avoid this collision. The associated headers
cannot be renamed because they need to shadow the SDK’s copies. There is
no “gn analyze” conflict reported for headers with the same name.
Change-Id: Ia49ef5ff8375673395597e96555f72f7c69e3564
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2285965
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
A uint8_t won't be bit-extended, zero-ing all the upper bits of value.
Change-Id: Iae41eeb4a014de5ed47ad599081959250a7bbe9c
Reviewed-on: https://chromium-review.googlesource.com/c/1405691
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
`dlsym` on Android KitKat (4.4.*) raises SIGFPE when searching for
non-existent symbols. This wrapper installs a signal handler prior to
calling `dlsym`.
Bug: crashpad:30
Change-Id: Iee94672d3c11b1fad1b01526eea7df688c0356cb
Reviewed-on: https://chromium-review.googlesource.com/835411
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Although API 21 introduced support for 64-bit off_t in many system calls
or their wrappers, <stdio.h> support for 64-bit off_t is absent until
API 24.
This is a partial revert of 5969d6b1eb22, because with this more
targeted fix applying only to gtest, the rest of Crashpad will work with
a 64-bit off_t even at API levels lacking NDK support by going through
the mmap() shim in compat.
This includes a mini_chromium update to 96e32dd499a4.
85cbec19ffc0 fuchsia: Make EINTR macros no-ops
fbf410cd4d40 fuchsia: Use koid instead of getpid() for process field in
logging
96e32dd499a4 Revert "android: Don’t use _FILE_OFFSET_BITS=64 until API
21"
Bug: crashpad:211
Change-Id: I34c3c8b42eb315605e6775962b44c3c4573b7462
Reviewed-on: https://chromium-review.googlesource.com/811204
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
This updates build/gyp_crashpad_android.py to define the
android_api_level GYP variable whenver unified headers are in use.
Previously, it was only set when compiling with GCC and using unified
headers. This pairs with https://crrev.com/c/804574 to allow proper
detection of when _FILE_OFFSET_BITS=64 would be inappropriate.
Since there’s no longer any possibility of using a 64-bit off_t with API
< 21, this also drops the compatibility wrapper for mmap() that allowed
this configuration to work. Too bad, I liked this, but it’s pointless to
carry now.
The development documentation is also updated to refer to NDK r16.
mini_chromium is updated to 88e056258a01450b07414642fa5fb98493c1f6ce.
f609089390cd fuchsia: Add ZX_LOG, et al. to mini_chromium
0a8c5de30c67 fuchsia: Fix RandBytes() ZX_CHECK message string
88e056258a01 android: Don’t use _FILE_OFFSET_BITS=64 until API 21
Change-Id: I932116e0c01bcddd5719f9091a070d504eae600f
Reviewed-on: https://chromium-review.googlesource.com/804555
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Chrome (and therefore mini_chromium) has always built with
_FILE_OFFSET_BITS=64, which is intended to enable a 64-bit off_t even
for 32-bit programs. However, support was never present in Android with
NDK traditional headers.
The new NDK unified headers do recognize _FILE_OFFSET_BITS=64 and enable
a 64-bit off_t, along with corresponding functions and system call
wrappers. However, no mmap() wrapper supporting a 64-bit off_t for
32-bit programs was available prior to API 21 (Android 5.0 “Lollipop”),
so when targeting older API levels, NDK headers do not proivde an mmap()
declaration. This avoids silently truncating 64-bit off_t values to 32
bits. NDK r15b did make such an mmap() wrapper available
(https://android.googlesource.com/platform/bionic/+/785b249df024), and
it did silently truncate, but this was removed for r15c
(https://android.googlesource.com/platform/bionic/+/00fedf587917).
How should this work if _FILE_OFFSET_BITS is set to 64 and recent
unified headers are in use?
The strategy employed here is to provide an mmap() declaration in
compat, with a 64-bit off_t. That mmap() will call to Bionic’s mmap64()
wrapper if available (it’s available since Android 5.0 “Lollipop”). If
unavailable, it implements the same logic that mmap64() does directly,
which predominantly involves calling the __mmap2() system call. Bionic
has always provided wrappers for __mmap2().
Additional reading:
https://android.googlesource.com/platform/bionic/+/0bfcbaf4d069/docs/32-bit-abi.md#is-32_bit-1https://github.com/android-ndk/ndk/issues/442
Bug: crashpad:30
Change-Id: I98c10e2eda773cb6f3d9eb8db9b8bfde43c885e7
Reviewed-on: https://chromium-review.googlesource.com/705674
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
ProcessReader is responsible for collecting information needed to build
a snapshot of the target process, independent of the Snapshot
interface. This CL includes implementation and tests for collecting
thread information, but does not yet collect module information.
Bug: crashpad:30
Change-Id: I911f155c953129a5fa8c031e923c0de2bd740ce0
Reviewed-on: https://chromium-review.googlesource.com/488162
Reviewed-by: Mark Mentovai <mark@chromium.org>
