crashpad/handler/win/fastfail_test_program.cc

152 lines
4.6 KiB
C++
Raw Normal View History

// Copyright 2022 The Crashpad Authors
Add WER runtime exception helper module for Windows This adds a runtime exception helper (& test module) for Windows and plumbing to allow the module to be registered by the crashpad client, and to trigger the crashpad handler. Embedders can build their own module to control which exceptions are passed to the handler. See: go/chrome-windows-runtime-exception-helper for motivation. When registered (which is the responsibility of the embedding application), the helper is loaded by WerFault.exe when Windows Error Reporting receives crashes that are not caught by crashpad's normal handlers - for instance a control-flow violation when a module is compiled with /guard:cf. Registration: The embedder must arrange for the full path to the helper to be added in the appropriate Windows Error Reporting\ RuntimeExceptionHelperModules registry key. Once an embedder's crashpad client is connected to a crashpad handler (e.g. through SetIpcPipeName()) the embedder calls RegisterWerModule. Internally, this registration includes handles used to trigger the crashpad handler, an area reserved to hold an exception and context, and structures needed by the crashpad handler. Following a crash: WerFault.exe handles the crash then validates and loads the helper module. WER hands the helper module a handle to the crashing target process and copies of the exception and context for the faulting thread. The helper then copies out the client's registration data and duplicates handles to the crashpad handler, then fills back the various structures in the paused client that the crashpad handler will need. The helper then signals the crashpad handler, which collects a dump then notifies the helper that it is done. Support: WerRegisterExceptionHelperModule has been availble since at least Windows 7 but WerFault would not pass on the exceptions that crashpad could not already handle. This changed in Windows 10 20H1 (19041), which supports HKCU and HKLM registrations, and passes in more types of crashes. It is harmless to register the module for earlier versions of Windows as it simply won't be loaded by WerFault.exe. Tests: snapshot/win/end_to_end_test.py has been refactored slightly to group crash generation and output validation in main() by breaking up RunTests into smaller functions. As the module works by being loaded in WerFault.exe it is tested in end_to_end_test.py. Bug: crashpad:133, 866033, 865632 Change-Id: Id668bd15a510a24c79753e1bb03e9456f41a9780 Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3677284 Reviewed-by: Joshua Peraza <jperaza@chromium.org> Commit-Queue: Alex Gough <ajgo@chromium.org>
2022-07-06 13:53:12 -07:00
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
// http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.
#include <string.h>
#include "base/check.h"
Add WER runtime exception helper module for Windows This adds a runtime exception helper (& test module) for Windows and plumbing to allow the module to be registered by the crashpad client, and to trigger the crashpad handler. Embedders can build their own module to control which exceptions are passed to the handler. See: go/chrome-windows-runtime-exception-helper for motivation. When registered (which is the responsibility of the embedding application), the helper is loaded by WerFault.exe when Windows Error Reporting receives crashes that are not caught by crashpad's normal handlers - for instance a control-flow violation when a module is compiled with /guard:cf. Registration: The embedder must arrange for the full path to the helper to be added in the appropriate Windows Error Reporting\ RuntimeExceptionHelperModules registry key. Once an embedder's crashpad client is connected to a crashpad handler (e.g. through SetIpcPipeName()) the embedder calls RegisterWerModule. Internally, this registration includes handles used to trigger the crashpad handler, an area reserved to hold an exception and context, and structures needed by the crashpad handler. Following a crash: WerFault.exe handles the crash then validates and loads the helper module. WER hands the helper module a handle to the crashing target process and copies of the exception and context for the faulting thread. The helper then copies out the client's registration data and duplicates handles to the crashpad handler, then fills back the various structures in the paused client that the crashpad handler will need. The helper then signals the crashpad handler, which collects a dump then notifies the helper that it is done. Support: WerRegisterExceptionHelperModule has been availble since at least Windows 7 but WerFault would not pass on the exceptions that crashpad could not already handle. This changed in Windows 10 20H1 (19041), which supports HKCU and HKLM registrations, and passes in more types of crashes. It is harmless to register the module for earlier versions of Windows as it simply won't be loaded by WerFault.exe. Tests: snapshot/win/end_to_end_test.py has been refactored slightly to group crash generation and output validation in main() by breaking up RunTests into smaller functions. As the module works by being loaded in WerFault.exe it is tested in end_to_end_test.py. Bug: crashpad:133, 866033, 865632 Change-Id: Id668bd15a510a24c79753e1bb03e9456f41a9780 Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3677284 Reviewed-by: Joshua Peraza <jperaza@chromium.org> Commit-Queue: Alex Gough <ajgo@chromium.org>
2022-07-06 13:53:12 -07:00
#include "base/files/file_path.h"
#include "base/logging.h"
#include "client/crashpad_client.h"
#include "util/misc/paths.h"
#include <Windows.h>
// We set up a program that crashes with a CFG exception so must be built and
// linked with /guard:cf. We register the crashpad runtime exception helper
// module to intercept and trigger the crashpad handler. Note that Windows only
// loads the module in WerFault after the crash for Windows 10 >= 20h1 (19041).
namespace crashpad {
namespace {
// This function should not be on our stack as CFG prevents the modified
// icall from happening.
int CallRffeManyTimes() {
RaiseFailFastException(nullptr, nullptr, 0);
RaiseFailFastException(nullptr, nullptr, 0);
RaiseFailFastException(nullptr, nullptr, 0);
RaiseFailFastException(nullptr, nullptr, 0);
return 1;
}
using FuncType = decltype(&CallRffeManyTimes);
void IndirectCall(FuncType* func) {
// This code always generates CFG guards.
(*func)();
}
void CfgCrash() {
// Call into the middle of the Crashy function.
FuncType func = reinterpret_cast<FuncType>(
(reinterpret_cast<uintptr_t>(CallRffeManyTimes)) + 16);
__try {
// Generates a STATUS_STACK_BUFFER_OVERRUN exception if CFG triggers.
IndirectCall(&func);
} __except (EXCEPTION_EXECUTE_HANDLER) {
// CFG fast fail should never be caught.
CHECK(false);
}
// Should only reach here if CFG is disabled.
abort();
}
void FastFailCrash() {
__fastfail(77);
}
int CrashyMain(int argc, wchar_t* argv[]) {
static CrashpadClient* client = new crashpad::CrashpadClient();
std::wstring type;
if (argc == 3) {
type = argv[2];
// We call this from end_to_end_test.py.
if (!client->SetHandlerIPCPipe(argv[1])) {
LOG(ERROR) << "SetHandler";
return EXIT_FAILURE;
}
} else if (argc == 4) {
type = argv[3];
// This is helpful for debugging.
if (!client->StartHandler(base::FilePath(argv[1]),
base::FilePath(argv[2]),
base::FilePath(),
std::string(),
std::map<std::string, std::string>(),
std::vector<std::string>(),
false,
true)) {
LOG(ERROR) << "StartHandler";
return EXIT_FAILURE;
}
// Got to have a handler & registration.
if (!client->WaitForHandlerStart(10000)) {
LOG(ERROR) << "Handler failed to start";
return EXIT_FAILURE;
}
} else {
fprintf(stderr, "Usage: %ls <server_pipe_name> [cf|ff]\n", argv[0]);
fprintf(
stderr, " %ls <handler_path> <database_path> [cf|ff]\n", argv[0]);
return EXIT_FAILURE;
}
base::FilePath exe_path;
if (!Paths::Executable(&exe_path)) {
LOG(ERROR) << "Failed getting path";
return EXIT_FAILURE;
}
// Find the module.
auto mod_path = exe_path.DirName().Append(L"crashpad_wer.dll");
// Make sure it is registered in the registry.
DWORD dwOne = 1;
LSTATUS reg_res =
RegSetKeyValueW(HKEY_CURRENT_USER,
L"Software\\Microsoft\\Windows\\Windows Error Reporting\\"
L"RuntimeExceptionHelperModules",
mod_path.value().c_str(),
REG_DWORD,
&dwOne,
sizeof(DWORD));
if (reg_res != ERROR_SUCCESS) {
LOG(ERROR) << "RegSetKeyValueW";
return EXIT_FAILURE;
}
if (!client->RegisterWerModule(mod_path.value())) {
LOG(ERROR) << "WerRegisterRuntimeExceptionModule";
return EXIT_FAILURE;
}
// Some versions of python call SetErrorMode() which extends to children, and
// prevents the WerFault infrastructure from running.
SetErrorMode(SEM_FAILCRITICALERRORS | SEM_NOOPENFILEERRORBOX);
Add WER runtime exception helper module for Windows This adds a runtime exception helper (& test module) for Windows and plumbing to allow the module to be registered by the crashpad client, and to trigger the crashpad handler. Embedders can build their own module to control which exceptions are passed to the handler. See: go/chrome-windows-runtime-exception-helper for motivation. When registered (which is the responsibility of the embedding application), the helper is loaded by WerFault.exe when Windows Error Reporting receives crashes that are not caught by crashpad's normal handlers - for instance a control-flow violation when a module is compiled with /guard:cf. Registration: The embedder must arrange for the full path to the helper to be added in the appropriate Windows Error Reporting\ RuntimeExceptionHelperModules registry key. Once an embedder's crashpad client is connected to a crashpad handler (e.g. through SetIpcPipeName()) the embedder calls RegisterWerModule. Internally, this registration includes handles used to trigger the crashpad handler, an area reserved to hold an exception and context, and structures needed by the crashpad handler. Following a crash: WerFault.exe handles the crash then validates and loads the helper module. WER hands the helper module a handle to the crashing target process and copies of the exception and context for the faulting thread. The helper then copies out the client's registration data and duplicates handles to the crashpad handler, then fills back the various structures in the paused client that the crashpad handler will need. The helper then signals the crashpad handler, which collects a dump then notifies the helper that it is done. Support: WerRegisterExceptionHelperModule has been availble since at least Windows 7 but WerFault would not pass on the exceptions that crashpad could not already handle. This changed in Windows 10 20H1 (19041), which supports HKCU and HKLM registrations, and passes in more types of crashes. It is harmless to register the module for earlier versions of Windows as it simply won't be loaded by WerFault.exe. Tests: snapshot/win/end_to_end_test.py has been refactored slightly to group crash generation and output validation in main() by breaking up RunTests into smaller functions. As the module works by being loaded in WerFault.exe it is tested in end_to_end_test.py. Bug: crashpad:133, 866033, 865632 Change-Id: Id668bd15a510a24c79753e1bb03e9456f41a9780 Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3677284 Reviewed-by: Joshua Peraza <jperaza@chromium.org> Commit-Queue: Alex Gough <ajgo@chromium.org>
2022-07-06 13:53:12 -07:00
if (type == L"cf")
CfgCrash();
if (type == L"ff")
FastFailCrash();
LOG(ERROR) << "Invalid type or exception failed.";
return EXIT_FAILURE;
}
} // namespace
} // namespace crashpad
int wmain(int argc, wchar_t* argv[]) {
return crashpad::CrashyMain(argc, argv);
}