The Mach-O reader validated segment and section file offsets by checking
that they were relative to the same base, insisting that a section’s
file offset be the same distance from a segment’s file offset as the
section’s preferred load address was from the segment’s preferred load
address. Notably, these file offsets already could not be validated
against the Mach-O image’s start because in the dyld shared cache, for
all segments other than __TEXT, these offsets were relative to the dyld
shared cache’s start.
In 10.12dp1 16A201w, file offsets for sections in the __TEXT segment are
also relative to the dyld shared cache’s start, but the file offset for
the __TEXT segment itself is relative to the Mach-O image’s start. Being
relative to different positions breaks Crashpad’s sanity check of the
module data. https://openradar.appspot.com/26864860 is filed for the use
of distinct bases in what should be related file offset fields.
While it would be possible with a bit of work to identify modules within
the dyld shared cache and adjust expectations accordingly, in reality,
these file offset values were only used to verify that the Mach-O
module.
In addition, the file offsets stored within the Mach-O file for sections
are 32-bit quantities, even in 64-bit images. It is possible to create a
large image whose section offset values have overflowed, and in these
cases, the offset value verification would also fail.
For these reasons, all file offset value validation is removed from the
Mach-O image reader.
BUG=crashpad:118, crashpad:120
Change-Id: I9c4bcc5fd0aeceef3bc8a43e5a8651735852d87b
Reviewed-on: https://chromium-review.googlesource.com/353631
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Calling std::vector<>::operator[]() with an out-of-range index argument
is undefined behavior. In two cases, Crashpad used &v[0] in situations
where it was known that the address would not be used. These calls were
wrapped in conditions guarding against vector emptiness.
While s[0] is valid on an empty string, in two cases, Crashpad used
&s[0] as an argument to a system call that would be a no-op. These calls
were wrapped in similar conditions to avoid the system call.
The two uses of vector with undefined behavior were caught by the
following tests in crashpad_snapshot_test with
UndefinedBehaviorSanitizer:
[ RUN ] CrashpadInfoClientOptions.OneModule
/Users/mark/compilatorium/llvm.build/bin/../include/c++/v1/vector:1493:12:
runtime error: reference binding to null pointer of type
'crashpad::process_types::section'
[ OK ] CrashpadInfoClientOptions.OneModule (72 ms)
[ RUN ] ProcessSnapshotMinidump.Empty
/Users/mark/compilatorium/llvm.build/bin/../include/c++/v1/vector:1493:12:
runtime error: reference binding to null pointer of type
'MINIDUMP_DIRECTORY'
[ OK ] ProcessSnapshotMinidump.Empty (1 ms)
The Crashpad codebase was audited by searching for resize() calls and
analyzing how resized strings and vectors are used.
TEST=*
BUG=
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/1283243004 .
The cl_kernels bug (Apple bug 20239912) in which cl_kernels modules show
up with an __LD,__compact_unwind section inside the __TEXT segment, is
still present in Mac OS X 10.11. This results in these warnings and a
failure to load the module:
[pid:tid:yyyymmdd,hhmmss.uuuuuu:WARNING
mach_o_image_segment_reader.cc:142] section.segname incorrect in
segment __TEXT, section __LD,__compact_unwind 3/6, load command 0x19
0/6, module cl_kernels, address 0x10e964000
BUG=crashpad:42
TEST=crashpad_snapshot_test ProcessReader.*Modules
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/1276573002 .
Add MapInsertOrReplace<>() to insert a key-value pair into a map if the
key is not already present, or replace the existing value for key if the
key is present. The original value can optionally be returned to the
caller in this case.
Map insertions now use either MapInsertOrReplace<>() or
std::map<>::insert() directly.
Use MapInsertOrReplace<>() when the map should be updated to contain a
mapping from a key to a value regardless of whether the key is already
present.
Use std::map<>::insert() to insert a mapping from a key to a value
without replacing any existing mapping from a key, if present. If it is
important to know whether an existing mapping from a key was present,
use the returned std::pair<>.second. If it is important to know the
existing value, use the returned std::pair<>.first->second.
This change has a slight positive impact on performance.
TEST=crashpad_util_test MapInsert.MapInsertOrReplace and others
BUG=
R=scottmg@chromium.org
Review URL: https://codereview.chromium.org/1044273002
