Include check_op.h directly, instead of relying on the transitive
include from logging.h. This transitive include does not exist in
Chromium's //base.
Change-Id: I15962a9cdc26ac206032157b8d2659cf263ad695
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/4950200
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Lei Zhang <thestig@chromium.org>
Only RV64GC is supported.
Bug: fuchsia:127655
Tested: `python build/run_tests.py` on RISC-V emulator
Tested: Created minidump via self-induced crash on RISC-V emulator,
ran through Breakpad stackwalker
Change-Id: I713797cd623b0a758269048e01696cbce502ca6c
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/4581050
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
GCC 12 does not allow it in C++20 mode anymore.
Bug: chromium:819294
Change-Id: I025dda8046739fefc4ff449d4496ef496374eff5
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3929186
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
sed -i '' -E -e 's/Copyright (.+) The Crashpad Authors\. All rights reserved\.$/Copyright \1 The Crashpad Authors/' $(git grep -El 'Copyright (.+) The Crashpad Authors\. All rights reserved\.$')
Bug: chromium:1098010
Change-Id: I8d6138469ddbe3d281a5d83f64cf918ec2491611
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3878262
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
Use BUILDFLAG(IS_*) instead of defined(OS_*).
This was generated mostly mechnically by performing the following steps:
- sed -i '' -E -e 's/defined\(OS_/BUILDFLAG(IS_/g' \
-e 's%([ !])OS_([A-Z]+)%\1BUILDFLAG(IS_\2)%g' \
$(git grep -l 'OS_'
'**/*.c' '**/*.cc' '**/*.h' '**/*.m' '**/*.mm')
- sed -i '' -e 's/#ifdef BUILDFLAG(/#if BUILDFLAG(/' \
$(git grep -l '#ifdef BUILDFLAG('
'**/*.c' '**/*.cc' '**/*.h' '**/*.m' '**/*.mm')
- gsed -i -z -E -e \
's%(.*)#include "%\1#include "build/buildflag.h"\n#include "%' \
$(git grep -l 'BUILDFLAG(IS_'
'**/*.c' '**/*.cc' '**/*.h' '**/*.m' '**/*.mm')
- Spot checks to move #include "build/buildflag.h" to the correct parts
of files.
- sed -i '' -E -e \
's%^(#include "build/buildflag.h")$%#include "build/build_config.h"\n\1%' \
$(grep -L '^#include "build/build_config.h"$'
$(git grep -l 'BUILDFLAG(IS_'
'**/*.c' '**/*.cc' '**/*.h' '**/*.m' '**/*.mm'))
- Add “clang-format off” around tool usage messages.
- git cl format
- Update mini_chromium to 85ba51f98278 (intermediate step).
TESTING ONLY).
- for f in $(git grep -l '^#include "build/buildflag.h"$'
'**/*.c' '**/*.cc' '**/*.h' '**/*.m' '**/*.mm'); do \
grep -v '^#include "build/buildflag.h"$' "${f}" > /tmp/z; \
cp /tmp/z "${f}"; done
- git cl format
- Update mini_chromium to 735143774c5f (intermediate step).
- Update mini_chromium to f41420eb45fa (as checked in).
- Update mini_chromium to 6e2f204b4ae1 (as checked in).
For ease of review and inspection, each of these steps is uploaded as a
new patch set in a review series.
This includes an update of mini_chromium to 6e2f204b4ae1:
f41420eb45fa Use BUILDFLAG for OS checking
6e2f204b4ae1 Include what you use: string_util.h uses build_config.h
Bug: chromium:1234043
Change-Id: Ieef86186f094c64e59b853729737e36982f8cf69
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3400258
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
This change was partially scripted and partially done manually with vim
regex + manually placing the deleted constructors.
The script change looked for destructors in the public: section of a
class, if that existed the deleted constructors would go before the
destructor.
For manual placement I looked for any constructor in the public: section
of the corresponding class. If there wasn't one, then it would ideally
have gone as the first entry except below enums, classes and typedefs.
This may not have been perfect, but is hopefully good enough. Fingers
crossed.
#include "base/macros.h" is removed from files that don't use
ignore_result, which is the only other thing defined in base/macros.h.
Bug: chromium:1010217
Change-Id: I099526255a40b1ac1264904b4ece2f3f503c9418
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3171034
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Peter Boström <pbos@chromium.org>
Overflows before and after padding could cause the max note size check
to be evaded.
Bug: chromium:967228, chromium: 967257, chromium:967223
Change-Id: I499a273e76e78529fc59ddcb74055be6d01fa2cb
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/1631635
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
This fixes a fuzzer-only bug, and modifies the note API so that it can
no longer request infinitely sized notes.
Bug: chromium:966303
Change-Id: I97b9ca6774d3101560caddf2f9b0a8d7ecf7c2e2
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/1628675
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
This is a reland of 95e97a32eba4d505ab9591e683d2147c441eea48
Original change's description:
> Use a relative address in .note.crashpad.info
>
> The desc value in the note is now the offset of CRASHPAD_INFO_SYMBOL
> from desc.
>
> Making this note writable can trigger a linker error resulting in
> the binary embedding .note.crashpad.info to be rejected by the
> kernel during program loading.
>
> The error was observed with:
> GNU ld (GNU Binutils for Debian) 2.30
> clang version 4.0.1-10 (tags/RELEASE_401/final)
> Debian 4.17.17-1rodete2
>
> When the note is made writable, crashpad_snapshot_test contains two
> PT_LOAD segments which map to the same page.
>
> LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000
> 0x0000000000000258 0x0000000000000258 R 0x200000
> LOAD 0x0000000000000258 0x0000000000000258 0x0000000000000258
> 0x00000000002b84d8 0x00000000002b8950 RWE 0x200000
>
> Executing this binary with the execv system call triggers a segfault
> during program loading (an error can't be returned because the original
> process vm has already been discarded).
>
> I suspect (I haven't set up a debuggable kernel) the failure occurs
> while attempting to map the second load segment because its virtual
> address, 0x258, is in the same page as the first load segment.
> https://elixir.bootlin.com/linux/v4.17.17/source/fs/binfmt_elf.c#L380
>
> The linker normally produces consecutive load segments where the second
> segment is loaded 0x200000 bytes after the first, which I think is the
> maximum expected page size. Modifying the test executable to load the
> second segment at 0x1258 (4096 byte page size) allows program loading
> to succeed (but of course crashes after control is given to it).
>
> Bug: crashpad:260
> Change-Id: I2b9f1e66e98919138baef3da991a9710bd970dc4
> Reviewed-on: https://chromium-review.googlesource.com/c/1292232
> Reviewed-by: Scott Graham <scottmg@chromium.org>
> Reviewed-by: Mark Mentovai <mark@chromium.org>
> Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Bug: crashpad:260
Change-Id: I66713de84cc26c9119e0454d19c9c189263fe054
Reviewed-on: https://chromium-review.googlesource.com/c/1318066
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
This reverts commit 95e97a32eba4d505ab9591e683d2147c441eea48.
Reason for revert: arm64 lto build
Original change's description:
> Use a relative address in .note.crashpad.info
>
> The desc value in the note is now the offset of CRASHPAD_INFO_SYMBOL
> from desc.
>
> Making this note writable can trigger a linker error resulting in
> the binary embedding .note.crashpad.info to be rejected by the
> kernel during program loading.
>
> The error was observed with:
> GNU ld (GNU Binutils for Debian) 2.30
> clang version 4.0.1-10 (tags/RELEASE_401/final)
> Debian 4.17.17-1rodete2
>
> When the note is made writable, crashpad_snapshot_test contains two
> PT_LOAD segments which map to the same page.
>
> LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000
> 0x0000000000000258 0x0000000000000258 R 0x200000
> LOAD 0x0000000000000258 0x0000000000000258 0x0000000000000258
> 0x00000000002b84d8 0x00000000002b8950 RWE 0x200000
>
> Executing this binary with the execv system call triggers a segfault
> during program loading (an error can't be returned because the original
> process vm has already been discarded).
>
> I suspect (I haven't set up a debuggable kernel) the failure occurs
> while attempting to map the second load segment because its virtual
> address, 0x258, is in the same page as the first load segment.
> https://elixir.bootlin.com/linux/v4.17.17/source/fs/binfmt_elf.c#L380
>
> The linker normally produces consecutive load segments where the second
> segment is loaded 0x200000 bytes after the first, which I think is the
> maximum expected page size. Modifying the test executable to load the
> second segment at 0x1258 (4096 byte page size) allows program loading
> to succeed (but of course crashes after control is given to it).
>
> Bug: crashpad:260
> Change-Id: I2b9f1e66e98919138baef3da991a9710bd970dc4
> Reviewed-on: https://chromium-review.googlesource.com/c/1292232
> Reviewed-by: Scott Graham <scottmg@chromium.org>
> Reviewed-by: Mark Mentovai <mark@chromium.org>
> Commit-Queue: Joshua Peraza <jperaza@chromium.org>
TBR=scottmg@chromium.org,jperaza@chromium.org,mark@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: crashpad:260
Change-Id: I7a2c741e6b4c10d3e3b8be3213a8ce2cd93675f7
Reviewed-on: https://chromium-review.googlesource.com/c/1316372
Reviewed-by: Scott Graham <scottmg@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
The desc value in the note is now the offset of CRASHPAD_INFO_SYMBOL
from desc.
Making this note writable can trigger a linker error resulting in
the binary embedding .note.crashpad.info to be rejected by the
kernel during program loading.
The error was observed with:
GNU ld (GNU Binutils for Debian) 2.30
clang version 4.0.1-10 (tags/RELEASE_401/final)
Debian 4.17.17-1rodete2
When the note is made writable, crashpad_snapshot_test contains two
PT_LOAD segments which map to the same page.
LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000258 0x0000000000000258 R 0x200000
LOAD 0x0000000000000258 0x0000000000000258 0x0000000000000258
0x00000000002b84d8 0x00000000002b8950 RWE 0x200000
Executing this binary with the execv system call triggers a segfault
during program loading (an error can't be returned because the original
process vm has already been discarded).
I suspect (I haven't set up a debuggable kernel) the failure occurs
while attempting to map the second load segment because its virtual
address, 0x258, is in the same page as the first load segment.
https://elixir.bootlin.com/linux/v4.17.17/source/fs/binfmt_elf.c#L380
The linker normally produces consecutive load segments where the second
segment is loaded 0x200000 bytes after the first, which I think is the
maximum expected page size. Modifying the test executable to load the
second segment at 0x1258 (4096 byte page size) allows program loading
to succeed (but of course crashes after control is given to it).
Bug: crashpad:260
Change-Id: I2b9f1e66e98919138baef3da991a9710bd970dc4
Reviewed-on: https://chromium-review.googlesource.com/c/1292232
Reviewed-by: Scott Graham <scottmg@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Modules mapped from zipfiles will have mappings named for the zipfile
rather than the module name and an offset into that zipfile instead of
0.
Bug: crashpad:253, crashpad:254
Change-Id: I0503d13e7b80ba7bd1cc2d241633d9c68c98f1cd
Reviewed-on: https://chromium-review.googlesource.com/1232294
Reviewed-by: Mark Mentovai <mark@chromium.org>
The general strategy used by Crashpad to determine loaded modules is to
read the link_map to get the addresses of the dynamic arrays for all
loaded modules. Those addresses can then be used to query the MemoryMap
to locate the module's mappings, and in particular the base mapping
from which Crashpad can parse the entire loaded ELF file.
ELF modules are typically loaded in several mappings with varying
permissions for different segments. The previous strategy used to find
the base mapping for a module was to search backwards from the mapping
for the dynamic array until a mapping from file offset 0 was found for
the same file. This fails when the file is mapped multiple times from
file offset 0, which can happen if the first page of the file contains
a GNU_RELRO segment.
This new strategy queries the MemoryMap for ALL mappings associated
with the dynamic array's mapping, mapped from offset 0. The consumer
(process_reader_linux.cc) can then determine which mapping is the
correct base by attempting to parse a module at that address and
corroborating the PT_DYNAMIC or program header table address from the
parsed module with the values Crashpad gets from the link_map or
auxiliary vector.
Bug: crashpad:30
Change-Id: Ibfcbba512e8fccc8c65afef734ea5640b71e9f70
Reviewed-on: https://chromium-review.googlesource.com/1139396
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Don't attempt to read data if the note isn't in an allocated segment.
See investigation starting at
https://bugs.chromium.org/p/crashpad/issues/detail?id=220#c27 for
details.
Bug: crashpad:220, crashpad:30, crashpad:196
Change-Id: I60eaacb83ad00ef33bde9079d25cc23a59bdf2c8
Reviewed-on: https://chromium-review.googlesource.com/941507
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
Without the section headers for the symbol table, there's no direct way
to calculate the number of entries in the table.
DT_HASH and DT_GNU_HASH are auxiliary tables that are designed to make
symbol lookup faster. DT_HASH is the original and is theoretically
mandatory. DT_GNU_HASH is the new-and-improved, but is more complex.
In practice, however, an Android build (at least vs. API 16) has only
DT_HASH, and not DT_GNU_HASH, and a Fuchsia build has only DT_GNU_HASH
but not DT_HASH. So, both are tried.
This change does not actually use the data in these tables to improve
the speed of symbol lookup, but instead only uses them to correctly
terminate the linear search.
DT_HASH contains the total number of symbols in the symbol table fairly
directly because there is an entry for each symbol table entry in the
hash table, so the number is the same.
DT_GNU_HASH regrettably does not. Instead, it's necessary to walk the
buckets and chain structure to find the largest entry.
DT_GNU_HASH doesn't appear in any "real" documentation that I'm aware
of, other than the binutils code (at least as far as I know). Some
more-and-less-useful references:
- https://flapenguin.me/2017/04/24/elf-lookup-dt-hash/
- https://flapenguin.me/2017/05/10/elf-lookup-dt-gnu-hash/
- http://deroko.phearless.org/dt_gnu_hash.txt
- https://sourceware.org/ml/binutils/2006-10/msg00377.html
Change-Id: I7cfc4372f29efc37446f0931d22a1f790e44076f
Bug: crashpad:213, crashpad:196
Reviewed-on: https://chromium-review.googlesource.com/876879
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
(Still need to avoid fork()-dependence for the non-self tests.)
Bug: crashpad:196
Change-Id: Ib34fe33c7ec295881c1f555995072d9ff742647f
Reviewed-on: https://chromium-review.googlesource.com/876650
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
A step towards making these files usable by non-Linux systems.
Bug: crashpad:196
Change-Id: I2497fd7e3bcb5390ae1e6ae22902ab6f56b59dff
Reviewed-on: https://chromium-review.googlesource.com/685405
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Dave Bort <dbort@google.com>
A step towards making these files usable by non-Linux systems.
Bug: crashpad:196
Change-Id: I1dc4304b1376a3a5e45228cf40b23f0367d3efa8
Reviewed-on: https://chromium-review.googlesource.com/685404
Commit-Queue: Dave Bort <dbort@google.com>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
