crashpad/util/win/safe_terminate_process_test.cc

188 lines
6.9 KiB
C++
Raw Normal View History

// Copyright 2017 The Crashpad Authors
win: Wrap TerminateProcess() to accept cdecl patches on x86 TerminateProcess(), like most of the Windows API, is declared WINAPI, which is __stdcall on 32-bit x86. That means that the callee, TerminateProcess() itself, is responsible for cleaning up parameters on the stack on return. In https://crashpad.chromium.org/bug/179, crashes in ExceptionHandlerServer::OnNonCrashDumpEvent() were observed in ways that make it evident that TerminateProcess() has been patched with a __cdecl routine. The crucial difference between __stdcall and __cdecl is that the caller is responsible for stack parameter cleanup in __cdecl. The mismatch means that nobody cleans parameters from the stack, and the stack pointer has an unexpected value, which in the case of the Crashpad handler crash, results in TerminateProcess()’s second argument erroneously being used as the lock address in the call to ReleaseSRWLockExclusive() or LeaveCriticalSection(). As a workaround, on 32-bit x86, call through SafeTerminateProcess(), a custom assembly routine that’s compatible with either __stdcall or __cdecl implementations of TerminateProcess() by not trusting the value of the stack pointer on return from that function. Instead, the stack pointer is restored directly from the frame pointer. Bug: crashpad:179 Test: crashpad_util_test SafeTerminateProcess.*, others Change-Id: If9508f4eb7631020ea69ddbbe4a22eb335cdb325 Reviewed-on: https://chromium-review.googlesource.com/481180 Reviewed-by: Scott Graham <scottmg@chromium.org>
2017-04-19 13:22:08 -04: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 "util/win/safe_terminate_process.h"
#include <string.h>
#include <iterator>
win: Wrap TerminateProcess() to accept cdecl patches on x86 TerminateProcess(), like most of the Windows API, is declared WINAPI, which is __stdcall on 32-bit x86. That means that the callee, TerminateProcess() itself, is responsible for cleaning up parameters on the stack on return. In https://crashpad.chromium.org/bug/179, crashes in ExceptionHandlerServer::OnNonCrashDumpEvent() were observed in ways that make it evident that TerminateProcess() has been patched with a __cdecl routine. The crucial difference between __stdcall and __cdecl is that the caller is responsible for stack parameter cleanup in __cdecl. The mismatch means that nobody cleans parameters from the stack, and the stack pointer has an unexpected value, which in the case of the Crashpad handler crash, results in TerminateProcess()’s second argument erroneously being used as the lock address in the call to ReleaseSRWLockExclusive() or LeaveCriticalSection(). As a workaround, on 32-bit x86, call through SafeTerminateProcess(), a custom assembly routine that’s compatible with either __stdcall or __cdecl implementations of TerminateProcess() by not trusting the value of the stack pointer on return from that function. Instead, the stack pointer is restored directly from the frame pointer. Bug: crashpad:179 Test: crashpad_util_test SafeTerminateProcess.*, others Change-Id: If9508f4eb7631020ea69ddbbe4a22eb335cdb325 Reviewed-on: https://chromium-review.googlesource.com/481180 Reviewed-by: Scott Graham <scottmg@chromium.org>
2017-04-19 13:22:08 -04:00
#include <memory>
#include <string>
win: Wrap TerminateProcess() to accept cdecl patches on x86 TerminateProcess(), like most of the Windows API, is declared WINAPI, which is __stdcall on 32-bit x86. That means that the callee, TerminateProcess() itself, is responsible for cleaning up parameters on the stack on return. In https://crashpad.chromium.org/bug/179, crashes in ExceptionHandlerServer::OnNonCrashDumpEvent() were observed in ways that make it evident that TerminateProcess() has been patched with a __cdecl routine. The crucial difference between __stdcall and __cdecl is that the caller is responsible for stack parameter cleanup in __cdecl. The mismatch means that nobody cleans parameters from the stack, and the stack pointer has an unexpected value, which in the case of the Crashpad handler crash, results in TerminateProcess()’s second argument erroneously being used as the lock address in the call to ReleaseSRWLockExclusive() or LeaveCriticalSection(). As a workaround, on 32-bit x86, call through SafeTerminateProcess(), a custom assembly routine that’s compatible with either __stdcall or __cdecl implementations of TerminateProcess() by not trusting the value of the stack pointer on return from that function. Instead, the stack pointer is restored directly from the frame pointer. Bug: crashpad:179 Test: crashpad_util_test SafeTerminateProcess.*, others Change-Id: If9508f4eb7631020ea69ddbbe4a22eb335cdb325 Reviewed-on: https://chromium-review.googlesource.com/481180 Reviewed-by: Scott Graham <scottmg@chromium.org>
2017-04-19 13:22:08 -04:00
#include "base/check.h"
win: Wrap TerminateProcess() to accept cdecl patches on x86 TerminateProcess(), like most of the Windows API, is declared WINAPI, which is __stdcall on 32-bit x86. That means that the callee, TerminateProcess() itself, is responsible for cleaning up parameters on the stack on return. In https://crashpad.chromium.org/bug/179, crashes in ExceptionHandlerServer::OnNonCrashDumpEvent() were observed in ways that make it evident that TerminateProcess() has been patched with a __cdecl routine. The crucial difference between __stdcall and __cdecl is that the caller is responsible for stack parameter cleanup in __cdecl. The mismatch means that nobody cleans parameters from the stack, and the stack pointer has an unexpected value, which in the case of the Crashpad handler crash, results in TerminateProcess()’s second argument erroneously being used as the lock address in the call to ReleaseSRWLockExclusive() or LeaveCriticalSection(). As a workaround, on 32-bit x86, call through SafeTerminateProcess(), a custom assembly routine that’s compatible with either __stdcall or __cdecl implementations of TerminateProcess() by not trusting the value of the stack pointer on return from that function. Instead, the stack pointer is restored directly from the frame pointer. Bug: crashpad:179 Test: crashpad_util_test SafeTerminateProcess.*, others Change-Id: If9508f4eb7631020ea69ddbbe4a22eb335cdb325 Reviewed-on: https://chromium-review.googlesource.com/481180 Reviewed-by: Scott Graham <scottmg@chromium.org>
2017-04-19 13:22:08 -04:00
#include "base/files/file_path.h"
#include "build/build_config.h"
#include "gtest/gtest.h"
#include "test/errors.h"
#include "test/test_paths.h"
#include "test/win/child_launcher.h"
#include "util/win/scoped_handle.h"
namespace crashpad {
namespace test {
namespace {
// Patches executable code, saving a copy of the original code so that it can be
// restored on destruction.
class ScopedExecutablePatch {
public:
ScopedExecutablePatch(void* target, const void* source, size_t size)
: original_(new uint8_t[size]), target_(target), size_(size) {
memcpy(original_.get(), target_, size_);
ScopedVirtualProtectRWX protect_rwx(target_, size_);
memcpy(target_, source, size_);
}
ScopedExecutablePatch(const ScopedExecutablePatch&) = delete;
ScopedExecutablePatch& operator=(const ScopedExecutablePatch&) = delete;
win: Wrap TerminateProcess() to accept cdecl patches on x86 TerminateProcess(), like most of the Windows API, is declared WINAPI, which is __stdcall on 32-bit x86. That means that the callee, TerminateProcess() itself, is responsible for cleaning up parameters on the stack on return. In https://crashpad.chromium.org/bug/179, crashes in ExceptionHandlerServer::OnNonCrashDumpEvent() were observed in ways that make it evident that TerminateProcess() has been patched with a __cdecl routine. The crucial difference between __stdcall and __cdecl is that the caller is responsible for stack parameter cleanup in __cdecl. The mismatch means that nobody cleans parameters from the stack, and the stack pointer has an unexpected value, which in the case of the Crashpad handler crash, results in TerminateProcess()’s second argument erroneously being used as the lock address in the call to ReleaseSRWLockExclusive() or LeaveCriticalSection(). As a workaround, on 32-bit x86, call through SafeTerminateProcess(), a custom assembly routine that’s compatible with either __stdcall or __cdecl implementations of TerminateProcess() by not trusting the value of the stack pointer on return from that function. Instead, the stack pointer is restored directly from the frame pointer. Bug: crashpad:179 Test: crashpad_util_test SafeTerminateProcess.*, others Change-Id: If9508f4eb7631020ea69ddbbe4a22eb335cdb325 Reviewed-on: https://chromium-review.googlesource.com/481180 Reviewed-by: Scott Graham <scottmg@chromium.org>
2017-04-19 13:22:08 -04:00
~ScopedExecutablePatch() {
ScopedVirtualProtectRWX protect_rwx(target_, size_);
memcpy(target_, original_.get(), size_);
}
private:
// Sets the protection on (address, size) to PAGE_EXECUTE_READWRITE by calling
// VirtualProtect(), and restores the original protection on destruction. Note
// that the region may span multiple pages, but the first pages original
// protection will be applied to the entire region on destruction. This
// shouldnt be a problem in practice for patching a function for this tests
// purposes.
class ScopedVirtualProtectRWX {
public:
// If either the constructor or destructor fails, PCHECK() to terminate
// immediately, because the process will be in a weird and untrustworthy
Update gtest to e3f0319d89f4cbf32993de595d984183b1a9fc57 I’m most interested in picking up 1b3eb6ef3462, “Explicitly define copy constructors used in googletest tests.” This also reorganizes files and rewrites text to refer to this project as Google Test and googletest (and Google Mock and googlemock), as it prefers to be known. Some filenames are left at gtest_* following the precedent set by gtest itself. For example, #include "gtest/gtest.h" is still used, so #include "test/gtest_death.h" is retained too. gtest_all_test OutputFileHelpersTest.GetCurrentExecutableName hard-codes the expected executable name as gtest_all_test among other options that do not include googletest_all_test, so test executables retain their names as well. fb19f57880f6 Add GTEST_BRIEF option 3549237957a1 Ensure that gtest/gmock pkgconfig requirements specify version 189299e957bb Merge branch 'master' into quiet-flag 5504ded3ab5c Fix a typo in .travis.yml 6ed4e7168f54 Replace the last instance of `throw()` with `noexcept`. NFC 879fd9b45299 Remove duplicate codes existed in get-nprocessors.sh 644f3a992c28 gtest-unittest-api_test - fix warning in clang build 0b6d567619fe Remove redundant .c_str() be3ac45cf673 fix signed/unsigned comparison issue (on OpenBSD) b51a49e0cb82 Merge pull request #2773 from Quuxplusone:replace-noexcept c2032090f373 Merge pull request #2772 from Quuxplusone:travis 4fe5ac53337e Merge pull request #2756 from Conan-Kudo:fix-pkgconfig-reqs 373d72b6986f Googletest export 4c8e6a9fe1c8 Merge pull request #2810 from ptahmose:master 71d5df6c6b67 Merge pull request #2802 from e-i-n-s:fix_clang_warning dcc92d0ab6c4 Merge pull request #2805 from pepsiman:patch-1 4f002f1e236c VariadicMatcher needs a non-defaulted move constructor for compile-time performance 9d580ea80592 Enable protobuf printing for open-source proto messages 766ac2e1a413 Remove all uses of GTEST_DISALLOW_{MOVE_,}ASSIGN_ 11b3cec177b1 Fix a -Wdeprecated warning 01c0ff5e2373 Fix a -Wdeprecated warning c7d8ec72cc4b Fix a -Wdeprecated warning 1b066f4edfd5 Add -Wdeprecated to the build configuration 4bab55dc54b4 Removed a typo in README.md a67701056425 Googletest export fb5d9b66c5b0 Googletest export 1b3eb6ef3462 Googletest export b0e53e2d64db Merge pull request #2797 from Jyun-Neng:master d7ca9af0049e Googletest export 955552518b4e Googletest export ef25d27d4604 Merge pull request #2815 from Quuxplusone:simple 129329787429 Googletest export b99b421d8d68 Merge pull request #2818 from inazarenko:master 472cd8fd8b1c Merge pull request #2818 from inazarenko:master 3cfb4117f7e5 Googletest export 0eea2e9fc634 Googletest export a9f6c1ed1401 Googletest export 1a9c3e441407 Merge pull request #2830 from keshavgbpecdelhi:patch-1 e589a3371705 Merge pull request #2751 from calumr:quiet-flag Change-Id: Id788a27aa884ef68a21bae6c178cd456f5f6f2b0 Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2186009 Reviewed-by: Joshua Peraza <jperaza@chromium.org> Commit-Queue: Mark Mentovai <mark@chromium.org>
2020-05-06 20:39:19 -04:00
// state, and Google Test error handling isnt worthwhile at that point.
win: Wrap TerminateProcess() to accept cdecl patches on x86 TerminateProcess(), like most of the Windows API, is declared WINAPI, which is __stdcall on 32-bit x86. That means that the callee, TerminateProcess() itself, is responsible for cleaning up parameters on the stack on return. In https://crashpad.chromium.org/bug/179, crashes in ExceptionHandlerServer::OnNonCrashDumpEvent() were observed in ways that make it evident that TerminateProcess() has been patched with a __cdecl routine. The crucial difference between __stdcall and __cdecl is that the caller is responsible for stack parameter cleanup in __cdecl. The mismatch means that nobody cleans parameters from the stack, and the stack pointer has an unexpected value, which in the case of the Crashpad handler crash, results in TerminateProcess()’s second argument erroneously being used as the lock address in the call to ReleaseSRWLockExclusive() or LeaveCriticalSection(). As a workaround, on 32-bit x86, call through SafeTerminateProcess(), a custom assembly routine that’s compatible with either __stdcall or __cdecl implementations of TerminateProcess() by not trusting the value of the stack pointer on return from that function. Instead, the stack pointer is restored directly from the frame pointer. Bug: crashpad:179 Test: crashpad_util_test SafeTerminateProcess.*, others Change-Id: If9508f4eb7631020ea69ddbbe4a22eb335cdb325 Reviewed-on: https://chromium-review.googlesource.com/481180 Reviewed-by: Scott Graham <scottmg@chromium.org>
2017-04-19 13:22:08 -04:00
ScopedVirtualProtectRWX(void* address, size_t size)
: address_(address), size_(size) {
PCHECK(VirtualProtect(
address_, size_, PAGE_EXECUTE_READWRITE, &old_protect_))
<< "VirtualProtect";
}
ScopedVirtualProtectRWX(const ScopedVirtualProtectRWX&) = delete;
ScopedVirtualProtectRWX& operator=(const ScopedVirtualProtectRWX&) = delete;
win: Wrap TerminateProcess() to accept cdecl patches on x86 TerminateProcess(), like most of the Windows API, is declared WINAPI, which is __stdcall on 32-bit x86. That means that the callee, TerminateProcess() itself, is responsible for cleaning up parameters on the stack on return. In https://crashpad.chromium.org/bug/179, crashes in ExceptionHandlerServer::OnNonCrashDumpEvent() were observed in ways that make it evident that TerminateProcess() has been patched with a __cdecl routine. The crucial difference between __stdcall and __cdecl is that the caller is responsible for stack parameter cleanup in __cdecl. The mismatch means that nobody cleans parameters from the stack, and the stack pointer has an unexpected value, which in the case of the Crashpad handler crash, results in TerminateProcess()’s second argument erroneously being used as the lock address in the call to ReleaseSRWLockExclusive() or LeaveCriticalSection(). As a workaround, on 32-bit x86, call through SafeTerminateProcess(), a custom assembly routine that’s compatible with either __stdcall or __cdecl implementations of TerminateProcess() by not trusting the value of the stack pointer on return from that function. Instead, the stack pointer is restored directly from the frame pointer. Bug: crashpad:179 Test: crashpad_util_test SafeTerminateProcess.*, others Change-Id: If9508f4eb7631020ea69ddbbe4a22eb335cdb325 Reviewed-on: https://chromium-review.googlesource.com/481180 Reviewed-by: Scott Graham <scottmg@chromium.org>
2017-04-19 13:22:08 -04:00
~ScopedVirtualProtectRWX() {
DWORD last_protect_;
PCHECK(VirtualProtect(address_, size_, old_protect_, &last_protect_))
<< "VirtualProtect";
}
private:
void* address_;
size_t size_;
DWORD old_protect_;
};
std::unique_ptr<uint8_t[]> original_;
void* target_;
size_t size_;
};
// SafeTerminateProcess is calling convention specific only for x86.
#if defined(ARCH_CPU_X86_FAMILY)
win: Wrap TerminateProcess() to accept cdecl patches on x86 TerminateProcess(), like most of the Windows API, is declared WINAPI, which is __stdcall on 32-bit x86. That means that the callee, TerminateProcess() itself, is responsible for cleaning up parameters on the stack on return. In https://crashpad.chromium.org/bug/179, crashes in ExceptionHandlerServer::OnNonCrashDumpEvent() were observed in ways that make it evident that TerminateProcess() has been patched with a __cdecl routine. The crucial difference between __stdcall and __cdecl is that the caller is responsible for stack parameter cleanup in __cdecl. The mismatch means that nobody cleans parameters from the stack, and the stack pointer has an unexpected value, which in the case of the Crashpad handler crash, results in TerminateProcess()’s second argument erroneously being used as the lock address in the call to ReleaseSRWLockExclusive() or LeaveCriticalSection(). As a workaround, on 32-bit x86, call through SafeTerminateProcess(), a custom assembly routine that’s compatible with either __stdcall or __cdecl implementations of TerminateProcess() by not trusting the value of the stack pointer on return from that function. Instead, the stack pointer is restored directly from the frame pointer. Bug: crashpad:179 Test: crashpad_util_test SafeTerminateProcess.*, others Change-Id: If9508f4eb7631020ea69ddbbe4a22eb335cdb325 Reviewed-on: https://chromium-review.googlesource.com/481180 Reviewed-by: Scott Graham <scottmg@chromium.org>
2017-04-19 13:22:08 -04:00
TEST(SafeTerminateProcess, PatchBadly) {
// This is a test of SafeTerminateProcess(), but it doesnt actually terminate
// anything. Instead, it works with a process handle for the current process
// that doesnt have PROCESS_TERMINATE access. The whole point of this test is
// to patch the real TerminateProcess() badly with a cdecl implementation to
// ensure that SafeTerminateProcess() can recover from such gross misconduct.
// The actual termination isnt relevant to this test.
//
// Notably, dont duplicate the process handle with PROCESS_TERMINATE access
// or with the DUPLICATE_SAME_ACCESS option. The SafeTerminateProcess() calls
// that follow operate on a duplicate of the current process process handle,
// and theyre supposed to fail, not terminate this process.
HANDLE process;
ASSERT_TRUE(DuplicateHandle(GetCurrentProcess(),
GetCurrentProcess(),
GetCurrentProcess(),
&process,
PROCESS_QUERY_INFORMATION,
false,
0))
<< ErrorMessage("DuplicateHandle");
ScopedKernelHANDLE process_owner(process);
// Make sure that TerminateProcess() works as a baseline.
SetLastError(ERROR_SUCCESS);
EXPECT_FALSE(TerminateProcess(process, 0));
EXPECT_EQ(GetLastError(), static_cast<DWORD>(ERROR_ACCESS_DENIED));
win: Wrap TerminateProcess() to accept cdecl patches on x86 TerminateProcess(), like most of the Windows API, is declared WINAPI, which is __stdcall on 32-bit x86. That means that the callee, TerminateProcess() itself, is responsible for cleaning up parameters on the stack on return. In https://crashpad.chromium.org/bug/179, crashes in ExceptionHandlerServer::OnNonCrashDumpEvent() were observed in ways that make it evident that TerminateProcess() has been patched with a __cdecl routine. The crucial difference between __stdcall and __cdecl is that the caller is responsible for stack parameter cleanup in __cdecl. The mismatch means that nobody cleans parameters from the stack, and the stack pointer has an unexpected value, which in the case of the Crashpad handler crash, results in TerminateProcess()’s second argument erroneously being used as the lock address in the call to ReleaseSRWLockExclusive() or LeaveCriticalSection(). As a workaround, on 32-bit x86, call through SafeTerminateProcess(), a custom assembly routine that’s compatible with either __stdcall or __cdecl implementations of TerminateProcess() by not trusting the value of the stack pointer on return from that function. Instead, the stack pointer is restored directly from the frame pointer. Bug: crashpad:179 Test: crashpad_util_test SafeTerminateProcess.*, others Change-Id: If9508f4eb7631020ea69ddbbe4a22eb335cdb325 Reviewed-on: https://chromium-review.googlesource.com/481180 Reviewed-by: Scott Graham <scottmg@chromium.org>
2017-04-19 13:22:08 -04:00
// Make sure that SafeTerminateProcess() works, calling through to
// TerminateProcess() properly.
SetLastError(ERROR_SUCCESS);
EXPECT_FALSE(SafeTerminateProcess(process, 0));
EXPECT_EQ(GetLastError(), static_cast<DWORD>(ERROR_ACCESS_DENIED));
win: Wrap TerminateProcess() to accept cdecl patches on x86 TerminateProcess(), like most of the Windows API, is declared WINAPI, which is __stdcall on 32-bit x86. That means that the callee, TerminateProcess() itself, is responsible for cleaning up parameters on the stack on return. In https://crashpad.chromium.org/bug/179, crashes in ExceptionHandlerServer::OnNonCrashDumpEvent() were observed in ways that make it evident that TerminateProcess() has been patched with a __cdecl routine. The crucial difference between __stdcall and __cdecl is that the caller is responsible for stack parameter cleanup in __cdecl. The mismatch means that nobody cleans parameters from the stack, and the stack pointer has an unexpected value, which in the case of the Crashpad handler crash, results in TerminateProcess()’s second argument erroneously being used as the lock address in the call to ReleaseSRWLockExclusive() or LeaveCriticalSection(). As a workaround, on 32-bit x86, call through SafeTerminateProcess(), a custom assembly routine that’s compatible with either __stdcall or __cdecl implementations of TerminateProcess() by not trusting the value of the stack pointer on return from that function. Instead, the stack pointer is restored directly from the frame pointer. Bug: crashpad:179 Test: crashpad_util_test SafeTerminateProcess.*, others Change-Id: If9508f4eb7631020ea69ddbbe4a22eb335cdb325 Reviewed-on: https://chromium-review.googlesource.com/481180 Reviewed-by: Scott Graham <scottmg@chromium.org>
2017-04-19 13:22:08 -04:00
{
// Patch TerminateProcess() badly. This turns it into a no-op that returns 0
// without cleaning up arguments from the stack, as a stdcall function is
// expected to do.
//
// This simulates the unexpected cdecl-patched TerminateProcess() as seen at
// https://crashpad.chromium.org/bug/179. In reality, this only affects
// 32-bit x86, as theres no calling convention confusion on x86_64. It
// doesnt hurt to run this test in the 64-bit environment, though.
static constexpr uint8_t patch[] = {
win: Wrap TerminateProcess() to accept cdecl patches on x86 TerminateProcess(), like most of the Windows API, is declared WINAPI, which is __stdcall on 32-bit x86. That means that the callee, TerminateProcess() itself, is responsible for cleaning up parameters on the stack on return. In https://crashpad.chromium.org/bug/179, crashes in ExceptionHandlerServer::OnNonCrashDumpEvent() were observed in ways that make it evident that TerminateProcess() has been patched with a __cdecl routine. The crucial difference between __stdcall and __cdecl is that the caller is responsible for stack parameter cleanup in __cdecl. The mismatch means that nobody cleans parameters from the stack, and the stack pointer has an unexpected value, which in the case of the Crashpad handler crash, results in TerminateProcess()’s second argument erroneously being used as the lock address in the call to ReleaseSRWLockExclusive() or LeaveCriticalSection(). As a workaround, on 32-bit x86, call through SafeTerminateProcess(), a custom assembly routine that’s compatible with either __stdcall or __cdecl implementations of TerminateProcess() by not trusting the value of the stack pointer on return from that function. Instead, the stack pointer is restored directly from the frame pointer. Bug: crashpad:179 Test: crashpad_util_test SafeTerminateProcess.*, others Change-Id: If9508f4eb7631020ea69ddbbe4a22eb335cdb325 Reviewed-on: https://chromium-review.googlesource.com/481180 Reviewed-by: Scott Graham <scottmg@chromium.org>
2017-04-19 13:22:08 -04:00
#if defined(ARCH_CPU_X86)
0x31, 0xc0, // xor eax, eax
#elif defined(ARCH_CPU_X86_64)
0x48, 0x31, 0xc0, // xor rax, rax
#else
#error Port
#endif
0xc3, // ret
};
void* target = reinterpret_cast<void*>(TerminateProcess);
ScopedExecutablePatch executable_patch(target, patch, std::size(patch));
win: Wrap TerminateProcess() to accept cdecl patches on x86 TerminateProcess(), like most of the Windows API, is declared WINAPI, which is __stdcall on 32-bit x86. That means that the callee, TerminateProcess() itself, is responsible for cleaning up parameters on the stack on return. In https://crashpad.chromium.org/bug/179, crashes in ExceptionHandlerServer::OnNonCrashDumpEvent() were observed in ways that make it evident that TerminateProcess() has been patched with a __cdecl routine. The crucial difference between __stdcall and __cdecl is that the caller is responsible for stack parameter cleanup in __cdecl. The mismatch means that nobody cleans parameters from the stack, and the stack pointer has an unexpected value, which in the case of the Crashpad handler crash, results in TerminateProcess()’s second argument erroneously being used as the lock address in the call to ReleaseSRWLockExclusive() or LeaveCriticalSection(). As a workaround, on 32-bit x86, call through SafeTerminateProcess(), a custom assembly routine that’s compatible with either __stdcall or __cdecl implementations of TerminateProcess() by not trusting the value of the stack pointer on return from that function. Instead, the stack pointer is restored directly from the frame pointer. Bug: crashpad:179 Test: crashpad_util_test SafeTerminateProcess.*, others Change-Id: If9508f4eb7631020ea69ddbbe4a22eb335cdb325 Reviewed-on: https://chromium-review.googlesource.com/481180 Reviewed-by: Scott Graham <scottmg@chromium.org>
2017-04-19 13:22:08 -04:00
// Make sure that SafeTerminateProcess() can be called. Since its been
// patched with a no-op stub, GetLastError() shouldnt be modified.
SetLastError(ERROR_SUCCESS);
EXPECT_FALSE(SafeTerminateProcess(process, 0));
EXPECT_EQ(GetLastError(), static_cast<DWORD>(ERROR_SUCCESS));
win: Wrap TerminateProcess() to accept cdecl patches on x86 TerminateProcess(), like most of the Windows API, is declared WINAPI, which is __stdcall on 32-bit x86. That means that the callee, TerminateProcess() itself, is responsible for cleaning up parameters on the stack on return. In https://crashpad.chromium.org/bug/179, crashes in ExceptionHandlerServer::OnNonCrashDumpEvent() were observed in ways that make it evident that TerminateProcess() has been patched with a __cdecl routine. The crucial difference between __stdcall and __cdecl is that the caller is responsible for stack parameter cleanup in __cdecl. The mismatch means that nobody cleans parameters from the stack, and the stack pointer has an unexpected value, which in the case of the Crashpad handler crash, results in TerminateProcess()’s second argument erroneously being used as the lock address in the call to ReleaseSRWLockExclusive() or LeaveCriticalSection(). As a workaround, on 32-bit x86, call through SafeTerminateProcess(), a custom assembly routine that’s compatible with either __stdcall or __cdecl implementations of TerminateProcess() by not trusting the value of the stack pointer on return from that function. Instead, the stack pointer is restored directly from the frame pointer. Bug: crashpad:179 Test: crashpad_util_test SafeTerminateProcess.*, others Change-Id: If9508f4eb7631020ea69ddbbe4a22eb335cdb325 Reviewed-on: https://chromium-review.googlesource.com/481180 Reviewed-by: Scott Graham <scottmg@chromium.org>
2017-04-19 13:22:08 -04:00
}
// Now that the real TerminateProcess() has been restored, verify that it
// still works properly.
SetLastError(ERROR_SUCCESS);
EXPECT_FALSE(SafeTerminateProcess(process, 0));
EXPECT_EQ(GetLastError(), static_cast<DWORD>(ERROR_ACCESS_DENIED));
win: Wrap TerminateProcess() to accept cdecl patches on x86 TerminateProcess(), like most of the Windows API, is declared WINAPI, which is __stdcall on 32-bit x86. That means that the callee, TerminateProcess() itself, is responsible for cleaning up parameters on the stack on return. In https://crashpad.chromium.org/bug/179, crashes in ExceptionHandlerServer::OnNonCrashDumpEvent() were observed in ways that make it evident that TerminateProcess() has been patched with a __cdecl routine. The crucial difference between __stdcall and __cdecl is that the caller is responsible for stack parameter cleanup in __cdecl. The mismatch means that nobody cleans parameters from the stack, and the stack pointer has an unexpected value, which in the case of the Crashpad handler crash, results in TerminateProcess()’s second argument erroneously being used as the lock address in the call to ReleaseSRWLockExclusive() or LeaveCriticalSection(). As a workaround, on 32-bit x86, call through SafeTerminateProcess(), a custom assembly routine that’s compatible with either __stdcall or __cdecl implementations of TerminateProcess() by not trusting the value of the stack pointer on return from that function. Instead, the stack pointer is restored directly from the frame pointer. Bug: crashpad:179 Test: crashpad_util_test SafeTerminateProcess.*, others Change-Id: If9508f4eb7631020ea69ddbbe4a22eb335cdb325 Reviewed-on: https://chromium-review.googlesource.com/481180 Reviewed-by: Scott Graham <scottmg@chromium.org>
2017-04-19 13:22:08 -04:00
}
#endif // ARCH_CPU_X86_FAMILY
win: Wrap TerminateProcess() to accept cdecl patches on x86 TerminateProcess(), like most of the Windows API, is declared WINAPI, which is __stdcall on 32-bit x86. That means that the callee, TerminateProcess() itself, is responsible for cleaning up parameters on the stack on return. In https://crashpad.chromium.org/bug/179, crashes in ExceptionHandlerServer::OnNonCrashDumpEvent() were observed in ways that make it evident that TerminateProcess() has been patched with a __cdecl routine. The crucial difference between __stdcall and __cdecl is that the caller is responsible for stack parameter cleanup in __cdecl. The mismatch means that nobody cleans parameters from the stack, and the stack pointer has an unexpected value, which in the case of the Crashpad handler crash, results in TerminateProcess()’s second argument erroneously being used as the lock address in the call to ReleaseSRWLockExclusive() or LeaveCriticalSection(). As a workaround, on 32-bit x86, call through SafeTerminateProcess(), a custom assembly routine that’s compatible with either __stdcall or __cdecl implementations of TerminateProcess() by not trusting the value of the stack pointer on return from that function. Instead, the stack pointer is restored directly from the frame pointer. Bug: crashpad:179 Test: crashpad_util_test SafeTerminateProcess.*, others Change-Id: If9508f4eb7631020ea69ddbbe4a22eb335cdb325 Reviewed-on: https://chromium-review.googlesource.com/481180 Reviewed-by: Scott Graham <scottmg@chromium.org>
2017-04-19 13:22:08 -04:00
TEST(SafeTerminateProcess, TerminateChild) {
base::FilePath child_executable =
TestPaths::BuildArtifact(L"util",
L"safe_terminate_process_test_child",
TestPaths::FileType::kExecutable);
ChildLauncher child(child_executable, L"");
win: Wrap TerminateProcess() to accept cdecl patches on x86 TerminateProcess(), like most of the Windows API, is declared WINAPI, which is __stdcall on 32-bit x86. That means that the callee, TerminateProcess() itself, is responsible for cleaning up parameters on the stack on return. In https://crashpad.chromium.org/bug/179, crashes in ExceptionHandlerServer::OnNonCrashDumpEvent() were observed in ways that make it evident that TerminateProcess() has been patched with a __cdecl routine. The crucial difference between __stdcall and __cdecl is that the caller is responsible for stack parameter cleanup in __cdecl. The mismatch means that nobody cleans parameters from the stack, and the stack pointer has an unexpected value, which in the case of the Crashpad handler crash, results in TerminateProcess()’s second argument erroneously being used as the lock address in the call to ReleaseSRWLockExclusive() or LeaveCriticalSection(). As a workaround, on 32-bit x86, call through SafeTerminateProcess(), a custom assembly routine that’s compatible with either __stdcall or __cdecl implementations of TerminateProcess() by not trusting the value of the stack pointer on return from that function. Instead, the stack pointer is restored directly from the frame pointer. Bug: crashpad:179 Test: crashpad_util_test SafeTerminateProcess.*, others Change-Id: If9508f4eb7631020ea69ddbbe4a22eb335cdb325 Reviewed-on: https://chromium-review.googlesource.com/481180 Reviewed-by: Scott Graham <scottmg@chromium.org>
2017-04-19 13:22:08 -04:00
ASSERT_NO_FATAL_FAILURE(child.Start());
constexpr DWORD kExitCode = 0x51ee9d1e; // Sort of like “sleep and die.”
ASSERT_TRUE(SafeTerminateProcess(child.process_handle(), kExitCode))
<< ErrorMessage("TerminateProcess");
EXPECT_EQ(child.WaitForExit(), kExitCode);
}
} // namespace
} // namespace test
} // namespace crashpad