win: Add implementation of ProcessInfo

util/win/process_info.cc

+// Copyright 2015 The Crashpad Authors. All rights reserved.
+//
+// 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/process_info.h"
+
+namespace crashpad {
+
+namespace {
+
+std::wstring ReadUnicodeString(HANDLE process, const UNICODE_STRING& us) {

[Mark Mentovai, 2015/03/05 17:32:22]

In returning, this should have a way to distinguish between an error in
ReadProcessMemory() and a successful read of an empty string.

[scottmg, 2015/03/05 20:31:06]

Done.

+  std::wstring str;
+  if (us.Length > 0) {
+    str.resize(us.Length / sizeof(wchar_t));

[Mark Mentovai, 2015/03/05 17:32:22]

DCHECK_EQ(us.Length % sizeof(wchar_t), 0)

[scottmg, 2015/03/05 20:31:06]

Done.

+    SIZE_T bytes_read;
+    if (!ReadProcessMemory(

[Mark Mentovai, 2015/03/05 17:32:22]

If I’m reading this correctly, for cross-bitted operation, a 32-bit process
can’t ReadProcessMemory() from a 64-bit process because us.Buffer is a native
(32-bit) pointer. A 64-bit process would be able to ReadProcessMemory() from a
32-bit process, though. Does that sound right?

[scottmg, 2015/03/05 20:31:06]

I haven't tested it yet, but yes, I believe that's correct. In theory it would
probably be possible to escape out of WOW64 and call the x64 ReadProcessMemory
from the x86-on-wow64 process. Hopefully for our purposes we can simply provide
only an x64 binary that handles reading from both 32 and 64. (Which reminds me I
should change the default gyp configuration here.)

+            process, us.Buffer, &str[0], us.Length, &bytes_read) ||
+        bytes_read != us.Length) {
+      PLOG(ERROR) << "ReadProcessMemory UNICODE_STRING";

[Mark Mentovai, 2015/03/05 17:32:22]

#include "base/logging.h". Also, PLOG is incorrect if this line was reached
because bytes_read != us.Length. Same on line 42.

[scottmg, 2015/03/05 20:31:06]

Done.

+      return std::wstring();
+    }
+  }
+  return str;
+}
+
+template <class T> bool ReadStruct(HANDLE process, void* at, T* into) {

[Mark Mentovai, 2015/03/05 17:32:22]

const void* at, but

Using pointer types to refer to things in a different process’ address space is
hairy, because it’s easy to mistake it for a pointer to the local address space
and accidentally dereference it. [u]intptr_t would be one step better, if
there’s no existing typedef specifically for this purpose.

[scottmg, 2015/03/05 20:31:06]

Switched to uintptr_t. ReadProcessMemory just uses const void* for remote
address spaces (and yes! I did have one of these incorrect until I tested
reading from not-self-process). It makes the callsites a bit uglier as they're
all void* in PEB structures, but we'll need our own definitions of those later.

+  SIZE_T bytes_read;
+  if (!ReadProcessMemory(process, at, into, sizeof(T), &bytes_read) ||
+      bytes_read != sizeof(T)) {
+    // We don't have a name for the type we're reading, so include the signature
+    // to get the type of T.
+    PLOG(ERROR) << "ReadProcessMemory: " << __FUNCSIG__;
+    return false;
+  }
+  return true;
+}
+
+// This is similar to PEB_LDR_DATA in winternl.h, but includes the
+// InInitializationOrderModuleList field.
+struct FULL_PEB_LDR_DATA {

[Mark Mentovai, 2015/03/05 17:32:22]

Since you don’t need Length or Initialized, you can make this struct extend the
SDK’s PEB_LDR_DATA. And if you did need Length or Initialized, you could use a
union.

[scottmg, 2015/03/05 20:31:06]

Done.

+  ULONG Length;
+  BOOLEAN Initialized;
+  PVOID Reserved;
+  LIST_ENTRY InLoadOrderModuleList;

[Mark Mentovai, 2015/03/05 17:32:22]

What’s the difference between load order and initialization order?

[scottmg, 2015/03/05 20:31:07]

Load and Memory order seem to always be the same (perhaps they differed on older
OS's with truly-shared DLLs?). Initialization order differs in that it's
bottom-up, rather than top-down. If we load A, and A imports B, then, the load
and memory order would be [A, B], whereas the initialization order would be [B,
A] because the initializers of B need to run before A's.

+  LIST_ENTRY InMemoryOrderModuleList;
+  LIST_ENTRY InInitializationOrderModuleList;
+};
+
+}  // namespace
+
+ProcessInfo::ProcessInfo()
+    : process_basic_information_(),
+      command_line_(),
+      is64bit_(false),
+      iswow64_(FALSE) {
+}
+
+ProcessInfo::~ProcessInfo() {
+}
+
+bool ProcessInfo::Initialize(HANDLE process) {
+  INITIALIZATION_STATE_SET_INITIALIZING(initialized_);
+
+  decltype(NtQueryInformationProcess)* nt_query_information_process =

[Mark Mentovai, 2015/03/05 17:32:22]

I like to wrap these kinds of things in their own functions, and ideally store
the function pointer in a static (because it’s not going to change during the
process’ lifetime). Then you could just call it naturally, either relying on
namespacing to get your version of the function, or giving it a slightly altered
name like CP_NtQueryInformationProcess(). Same for IsWow64Process().

[scottmg, 2015/03/05 20:31:06]

Done.

+      reinterpret_cast<decltype(NtQueryInformationProcess)*>(GetProcAddress(
+          LoadLibrary(L"ntdll.dll"), "NtQueryInformationProcess"));
+  if (!nt_query_information_process) {
+    PLOG(ERROR) << "GetProcAddress NtQueryInformationProcess failed";
+    return false;
+  }
+
+  ULONG bytes_returned;
+  NTSTATUS status =
+      nt_query_information_process(process,
+                                   ProcessBasicInformation,
+                                   &process_basic_information_,
+                                   sizeof(process_basic_information_),
+                                   &bytes_returned);
+  if (status < 0 || bytes_returned != sizeof(process_basic_information_)) {
+    LOG(ERROR) << "NtQueryInformationProcess";

[Mark Mentovai, 2015/03/05 17:32:22]

If status < 0, the value of status might be a good thing to include in the
message, like how we use PLOG for things that set something that GetLastError()
would return.

[scottmg, 2015/03/05 20:31:07]

Done.

+    return false;
+  }
+
+  // Try to read the process environment block.
+  PEB peb;
+  if (!ReadStruct(process, process_basic_information_.PebBaseAddress, &peb))

[Mark Mentovai, 2015/03/05 17:32:22]

This looks like the first point where cross-bitted operation might fail. If
we’re not ready to do cross-bitted yet (and if we won’t ever be able to do
32-reads-64), we should detect those cases early and fail fast. As things are,
the PEB structure is word size-dependent, and 64-reads-32 will begin
interpreting things incorrectly from this point on without something like
process_types.

[scottmg, 2015/03/05 20:31:06]

Right, good point.

For now I've moved the 32/64 check above here to early out when we don't match.
As follow up I'll switch our default build to x64, then start testing
x64-reading-x86. I think process_types makes sense at the cost of redefining
these SDK structures, but we've already had to make our local versions of them
for other reasons anyway.

+    return false;
+
+  RTL_USER_PROCESS_PARAMETERS process_parameters;
+  if (!ReadStruct(process, peb.ProcessParameters, &process_parameters))
+    return false;
+
+  command_line_ =
+      ReadUnicodeString(process, process_parameters.CommandLine);
+  if (command_line_.empty())
+    return false;
+
+  FULL_PEB_LDR_DATA peb_ldr_data;
+  if (!ReadStruct(process, peb.Ldr, &peb_ldr_data))
+    return false;
+
+  // Walk the PEB LDR structure (doubly-linked list) to get the list of loaded
+  // modules. We awkwardly use the Reserved fields of LDR_DATA_TABLE_ENTRY to
+  // get the modules in InitializationOrder rather than MemoryOrder.
+  LIST_ENTRY* cur = peb_ldr_data.InInitializationOrderModuleList.Flink;
+  LIST_ENTRY* last = peb_ldr_data.InInitializationOrderModuleList.Blink;
+  for (;;) {

[Mark Mentovai, 2015/03/05 17:32:21]

You could hoist some stuff into the for construct to make the loop’s behavior a
little more obvious up here:

  for (LIST_ENTRY* cur = …;
       cur != last;
       cur = …->Flink)

or even use the comma operator to initialize last in there too.

[scottmg, 2015/03/05 20:31:06]

Some hoisted. Unfortunately, it's a "back" pointer, not an "end", so the
termination needs to be at the end of the loop, not the top.

+    // |cur| is the pointer to the LIST_ENTRY embedded in the
+    // LDR_DATA_TABLE_ENTRY, in the target process's address space. So we need
+    // to read from the target, and also offset back to the beginning of the
+    // structure.
+    LDR_DATA_TABLE_ENTRY ldr_data_table_entry;
+    if (!ReadStruct(process,

[Mark Mentovai, 2015/03/05 17:32:22]

Your CL description had me geared up for a truly heinous hack. This isn’t that
bad. The offset is a little weird, but you’ve gotta do what you’ve gotta do, and
that’s about all. Whew!

[scottmg, 2015/03/05 20:31:07]

All in the eye of the beholder, I suppose. :)

+                    reinterpret_cast<char*>(cur) -
+                        offsetof(LDR_DATA_TABLE_ENTRY, Reserved2),

[Mark Mentovai, 2015/03/05 17:32:22]

I see.

Presumably, LDR_DATA_TABLE_ENTRY really starts off like this:

{
  LIST_ENTRY InLoadOrderLinks;  // PVOID Reserved1[2]
  LIST_ENTRY InMemoryOrderLinks;
  LIST_ENTRY InInitializationOrderLinks;  // PVOID Reserved2[2]
  // …
}

and that’s why you’re using Reserved2.

If that’s so, I think this code would be more self-explanatory if you declared
your own FULL_LDR_DATA_TABLE_ENTRY structure to give proper access to
InInitializationOrderLinks by name, similar to how you use FULL_PEB_LDR_DATA to
give access to InInitializationOrderModuleList.

This would also make it more natural to access the Flink to advance to the next
iteration, no funky cast required.

[scottmg, 2015/03/05 20:31:07]

That's right.
Switched to FULL_LDR_DATA_TABLE_ENTRY. As you allude to, we'll need our own
anyway for cross-bitness in the future.

+                    &ldr_data_table_entry))
+      return false;

[Mark Mentovai, 2015/03/05 17:32:22]

{} around this, its controlling condition is so long and ragged that the braces
help see that this is the controlled branch much more easily.

[scottmg, 2015/03/05 20:31:06]

Done.

+    // TODO(scottmg): Capture TimeDateStamp, Checksum, etc. too?
+    std::wstring module =
+        ReadUnicodeString(process, ldr_data_table_entry.FullDllName);
+    if (module.empty())
+      return false;

[Mark Mentovai, 2015/03/05 17:32:22]

A bad module should probably invalidate that module and but almost definitely
not all process reading altogether.

[scottmg, 2015/03/05 20:31:06]

Done. I was concerned that a bad PEB meant the world was on fire, but returning
an incomplete/incorrect modules list seems preferable. I similarly changed the
link reading to not be entirely fatal.

+    modules_.push_back(module);
+    if (cur == last)
+      break;
+    cur = reinterpret_cast<LIST_ENTRY*>(&ldr_data_table_entry.Reserved2)->Flink;
+  }
+
+  decltype(IsWow64Process)* is_wow64_process =

[Mark Mentovai, 2015/03/05 17:32:22]

If you break this one into its own function, you can give it a better signature
like “bool replacementfunction(HANDLE)”—the function itself would wrap the PLOG
and just return false for any failure or can’t-be-WoW64 case. In this class,
is_wow_64_ could become a bool instead of a BOOL.

[scottmg, 2015/03/05 20:31:07]

Done.

+      reinterpret_cast<decltype(IsWow64Process)*>(
+          GetProcAddress(LoadLibrary(L"kernel32.dll"), "IsWow64Process"));
+  if (!is_wow64_process) {
+    // This means kernel32 doesn't implement this function, so there's no such
+    // thing as WoW64 on this OS.
+    iswow64_ = FALSE;
+  } else if (!is_wow64_process(process, &iswow64_)) {
+    PLOG(ERROR) << "IsWow64Process";
+    return false;
+  }
+
+  if (iswow64_) {
+    // If it's WoW64, then it's 32-on-64.
+    is64bit_ = false;
+  } else {
+    // Otherwise, it's either 32 on 32, or 64 on 64. Use GetSystemInfo() to
+    // distinguish between these two cases.
+    SYSTEM_INFO system_info;
+    GetSystemInfo(&system_info);
+    is64bit_ =
+        system_info.wProcessorArchitecture == PROCESSOR_ARCHITECTURE_AMD64;
+  }
+
+  INITIALIZATION_STATE_SET_VALID(initialized_);
+  return true;
+}
+
+bool ProcessInfo::Is64Bit() const {
+  INITIALIZATION_STATE_DCHECK_VALID(initialized_);
+  return is64bit_;
+}
+
+bool ProcessInfo::IsWow64() const {
+  INITIALIZATION_STATE_DCHECK_VALID(initialized_);
+  return iswow64_;
+}
+
+pid_t ProcessInfo::ProcessID() const {
+  INITIALIZATION_STATE_DCHECK_VALID(initialized_);
+  return process_basic_information_.UniqueProcessId;
+}
+
+pid_t ProcessInfo::ParentProcessID() const {
+  INITIALIZATION_STATE_DCHECK_VALID(initialized_);
+  return reinterpret_cast<ULONG_PTR>(process_basic_information_.Reserved3);

[Mark Mentovai, 2015/03/05 17:32:22]

Can process_basic_information_ be a union type that makes a ParentProcessId
field available (with the correct type) at the same location as Reserved3?

[scottmg, 2015/03/05 20:31:06]

Added FULL_... for this type too.

+}
+
+bool ProcessInfo::CommandLine(std::wstring* command_line) const {
+  INITIALIZATION_STATE_DCHECK_VALID(initialized_);
+  *command_line = command_line_;
+  return true;
+}
+
+bool ProcessInfo::Modules(std::vector<std::wstring>* modules) const {
+  INITIALIZATION_STATE_DCHECK_VALID(initialized_);
+  *modules = modules_;
+  return true;
+}
+
+}  // namespace crashpad