We had a thread-local varialbe `ModuleLoadFrame::sTopFrame` to track the topmost
stack frame of `LdrLoadDll`. However, our hook function `patched_LdrLoadDll` can
be called even before TLS is initialized. In such a case, accessing `sTopFrame`
causes AV.
This patch introduces `SafeThreadLocal` to safely access a thread-local varialbe.
If TLS is not initialized, it falls back to a global variable because in that
early stage there is only a single thread running.
Differential Revision: https://phabricator.services.mozilla.com/D55870
--HG--
extra : moz-landing-system : lando
We had a thread-local varialbe `ModuleLoadFrame::sTopFrame` to track the topmost
stack frame of `LdrLoadDll`. However, our hook function `patched_LdrLoadDll` can
be called even before TLS is initialized. In such a case, accessing `sTopFrame`
causes AV.
This patch introduces `SafeThreadLocal` to safely access a thread-local varialbe.
If TLS is not initialized, it falls back to a global variable because in that
early stage there is only a single thread running.
Differential Revision: https://phabricator.services.mozilla.com/D55870
--HG--
extra : moz-landing-system : lando
Changes:
Whitelist the `RegisteredThread::RegisteredThread` failures for linux1804-64-asan/opt temporarily while the parent bug is left open, to support `mochitest-browser-chrome` migration to linux1804-64.
Differential Revision: https://phabricator.services.mozilla.com/D61224
--HG--
extra : moz-landing-system : lando
The "(null)" printing behavior is a glibc extension and the specified behavior
in the standard is undefined
Differential Revision: https://phabricator.services.mozilla.com/D61071
--HG--
extra : moz-landing-system : lando
Under the stronger Control Flow Guard scheme coming in clang 10, when a nop-space hook jumps back to the original API, at `ntdll!Whatever+2`, that address is not a registered jump target, so we crash with a CFG failure. Since this is a deliberate violation of the rules, let's disable CFG for these calls.
Based on my testing, this is the only place we need to use this attribute, so I placed its definition close to the use. (Had we needed more of these, I would have put it in mfbt/.)
Differential Revision: https://phabricator.services.mozilla.com/D59728
--HG--
extra : moz-landing-system : lando
A third-party application can modify the export directory, the export address/name/ordinal
tables, or an entry in those tables. If that happens, we will see an RVA is located outside
the mapped image and `RVAToPtr` returns null. This patch makes sure we don't hit null AV
when modification is detected.
`FindExportAddressTableEntry` should not return a pointer to the modified table entry because
we dereference it in another process to cross-process detour.
Differential Revision: https://phabricator.services.mozilla.com/D59738
--HG--
extra : moz-landing-system : lando
This was done by:
This was done by applying:
```
diff --git a/python/mozbuild/mozbuild/code-analysis/mach_commands.py b/python/mozbuild/mozbuild/code-analysis/mach_commands.py
index 789affde7bbf..fe33c4c7d4d1 100644
--- a/python/mozbuild/mozbuild/code-analysis/mach_commands.py
+++ b/python/mozbuild/mozbuild/code-analysis/mach_commands.py
@@ -2007,7 +2007,7 @@ class StaticAnalysis(MachCommandBase):
from subprocess import Popen, PIPE, check_output, CalledProcessError
diff_process = Popen(self._get_clang_format_diff_command(commit), stdout=PIPE)
- args = [sys.executable, clang_format_diff, "-p1", "-binary=%s" % clang_format]
+ args = [sys.executable, clang_format_diff, "-p1", "-binary=%s" % clang_format, '-sort-includes']
if not output_file:
args.append("-i")
```
Then running `./mach clang-format -c <commit-hash>`
Then undoing that patch.
Then running check_spidermonkey_style.py --fixup
Then running `./mach clang-format`
I had to fix four things:
* I needed to move <utility> back down in GuardObjects.h because I was hitting
obscure problems with our system include wrappers like this:
0:03.94 /usr/include/stdlib.h:550:14: error: exception specification in declaration does not match previous declaration
0:03.94 extern void *realloc (void *__ptr, size_t __size)
0:03.94 ^
0:03.94 /home/emilio/src/moz/gecko-2/obj-debug/dist/include/malloc_decls.h:53:1: note: previous declaration is here
0:03.94 MALLOC_DECL(realloc, void*, void*, size_t)
0:03.94 ^
0:03.94 /home/emilio/src/moz/gecko-2/obj-debug/dist/include/mozilla/mozalloc.h:22:32: note: expanded from macro 'MALLOC_DECL'
0:03.94 MOZ_MEMORY_API return_type name##_impl(__VA_ARGS__);
0:03.94 ^
0:03.94 <scratch space>:178:1: note: expanded from here
0:03.94 realloc_impl
0:03.94 ^
0:03.94 /home/emilio/src/moz/gecko-2/obj-debug/dist/include/mozmemory_wrap.h:142:41: note: expanded from macro 'realloc_impl'
0:03.94 #define realloc_impl mozmem_malloc_impl(realloc)
Which I really didn't feel like digging into.
* I had to restore the order of TrustOverrideUtils.h and related files in nss
because the .inc files depend on TrustOverrideUtils.h being included earlier.
* I had to add a missing include to RollingNumber.h
* Also had to partially restore include order in JsepSessionImpl.cpp to avoid
some -WError issues due to some static inline functions being defined in a
header but not used in the rest of the compilation unit.
Differential Revision: https://phabricator.services.mozilla.com/D60327
--HG--
extra : moz-landing-system : lando
This makes Gecko build again. I'll squash this into the previous commit anyhow.
Differential Revision: https://phabricator.services.mozilla.com/D60324
--HG--
extra : moz-landing-system : lando
rg -l 'mozilla/Move.h' | xargs sed -i 's/#include "mozilla\/Move.h"/#include <utility>/g'
Further manual fixups and cleanups to the include order incoming.
Differential Revision: https://phabricator.services.mozilla.com/D60323
--HG--
extra : moz-landing-system : lando
Now both profilers are controlled by the same environment variables, e.g.
"MOZ_PROFILER_STARTUP" to run both profilers at startup.
The only remaining Base Profiler-specific commands are:
- MOZ_BASE_PROFILER_HELP, because the Base Profiler doesn't have the same
capabilities as Gecko, so it may display different available features.
- MOZ_BASE_PROFILER_LOGGING, because the Base Profiler doesn't have access to
MOZ_LOG (both the env-var and the C++ macros).
Differential Revision: https://phabricator.services.mozilla.com/D54449
--HG--
extra : moz-landing-system : lando
This env-vars were not processed because of some needed special processing, and
they were not critical.
But now we want them to be correctly read, to match the Gecko Profiler features.
Differential Revision: https://phabricator.services.mozilla.com/D54448
--HG--
extra : moz-landing-system : lando
When `WindowsDllInterceptor` detours a function in a remote process, it calculates
a target address via `GetProcAddress` in the caller's process first, and detours
that address in the target process. If the caller's export table was modified, the
target address might be invalid in the target process.
With this patch, `WindowsDllInterceptor` uses the target process's export table to
calculate a target function address.
Differential Revision: https://phabricator.services.mozilla.com/D58305
--HG--
extra : moz-landing-system : lando
`GetProcessTimes` is based on QPC, while `GetSystemTime` is based on clock
interruption whose accuracy is lower than QPC. This means in a process's early
stage, `GetSystemTime` may return a timestamp earlier than creation timestamp.
If this happens we'll keep a negative process uptime which causes overflow in
telemetry processing.
Win8+ has a handy API `GetSystemTimePreciseAsFileTime` that solves everything.
On Win7, `GetSystemTimeAsFileTime` still solves this issue. In the worst case,
it returns the exact same timestamp as process creation, but it's ok.
Because the system time is stored as a `FILETIME` in `KUSER`, converting it to
a `SYSTEMTIME` with `GetSystemTime` drops accuracy. We should avoid it unless
needed.
This patch also moves the call to `GetProcessTimes` before getting the current
timestamp in case clock interruption happens in between those two function calls.
Differential Revision: https://phabricator.services.mozilla.com/D56273
--HG--
extra : moz-landing-system : lando
In bug 1587332, ActivePS::mProfileBuffer was changed from
`const UniquePtr<ProfileBuffer>` to just `ProfileBuffer`, so its own object size
is now counted as part of `sizeof(ActivePS)`, and we should only count its
dependencies with `SizeOfExcludingThis`.
Differential Revision: https://phabricator.services.mozilla.com/D58288
--HG--
extra : moz-landing-system : lando
Our detour allocates a trampoline with `PAGE_EXECUTE_READ` first, and then makes
it writable before use. If the dynamic code policy is enabled after allocation,
we fail to change the attribute, and crash the process because we try to write
data into a readonly page. We need to check the validity of a trampoline before
writing data.
Differential Revision: https://phabricator.services.mozilla.com/D56983
--HG--
extra : moz-landing-system : lando
This is a pretty straightforward patch; we add `WindowsIATPatcher` to
implement the actual IAT patching, and use a partial specialization of
`FuncHook` to account for the underlying differences in implementation vs our
existing interceptor code.
Differential Revision: https://phabricator.services.mozilla.com/D57831
--HG--
extra : moz-landing-system : lando
Strictly speaking, the import descriptor includes more than just the IAT,
so renaming this method to reflect that.
Differential Revision: https://phabricator.services.mozilla.com/D57830
--HG--
extra : moz-landing-system : lando
This is a pretty straightforward patch; we add `WindowsIATPatcher` to
implement the actual IAT patching, and use a partial specialization of
`FuncHook` to account for the underlying differences in implementation vs our
existing interceptor code.
Differential Revision: https://phabricator.services.mozilla.com/D57831
--HG--
extra : moz-landing-system : lando
Strictly speaking, the import descriptor includes more than just the IAT,
so renaming this method to reflect that.
Differential Revision: https://phabricator.services.mozilla.com/D57830
--HG--
extra : moz-landing-system : lando
This changeset is a simple find and replace of `MOZ_FALLTHROUGH` and `[[fallthrough]]`.
Unfortunately, the MOZ_FALLTHROUGH_ASSERT macro (to assert on case fallthrough in debug builds) is still necessary after switching from [[clang::fallthrough]] to [[fallthrough]] because:
* MOZ_ASSERT(false) followed by [[fallthrough]] triggers a -Wunreachable-code warning in DEBUG builds
* but MOZ_ASSERT(false) without [[fallthrough]] triggers a -Wimplicit-fallthrough warning in NDEBUG builds.
Differential Revision: https://phabricator.services.mozilla.com/D56440
--HG--
extra : moz-landing-system : lando
We rename `LoaderObserver::Clear` to `LoaderObserver::Disable` to more accurately
reflect the following behaviour change:
Not only does the `Disable` call free any enqueued module load events, it also
ensures that no further module loads will be saved in the future. This reflects
the reality that any `mozglue` client that calls `Disable` has no intention of
ever processing these events.
Differential Revision: https://phabricator.services.mozilla.com/D57897
--HG--
extra : moz-landing-system : lando
The only way to select all registered threads was to have an empty entry in the
filter list, usually by just having "," (a single comma).
The popup removes spurious empty items, making this impossible for most users.
It is now possible to just have "*" (as the whole filter string, or at least one
item in the list) to select all registered threads.
Differential Revision: https://phabricator.services.mozilla.com/D57594
--HG--
extra : moz-landing-system : lando
Changing the OS we run Linux ASan on from ubuntu1604 to ubuntu1804
causes 820800 bytes of leaks with libfreetype.so in the stack in
almost every test suite. Presumably this is just a variation on
existing leaks we get because we don't shut down fonts properly, so
just whitelist it.
Differential Revision: https://phabricator.services.mozilla.com/D56511
--HG--
extra : moz-landing-system : lando
This patch contains the core changes to make this all work across e10s:
* We clarify the naming of path variables to be more specific as to whether they are NT paths or DOS paths;
* We add IPC `ParamTraits` that are necessary for `UntrustedModulesData` types;
* We implement `ProcessModuleLoadQueue` for child processes. Because of sandboxing, we need to split this sequence into multiple async operations:
** Initial queue processing;
** Sending the list of modules to the parent process to determine trustworthiness (via `GetModulesTrust`);
** Receiving the results from the parent process and producing a final result (via `CompleteProcessing`).
* We implement the `GetModulesTrust` function for the parent process, which evaluates the trust of child process modules;
* We change all hash tables to be keyed using NT paths. Because resolving DOS paths may not be permitted in sandboxed processes,
we need to standardize on NT paths as the "universal path" across processes.
* We add `WinDllServices::StartUntrustedModulesProcessor` to separate untrusted modules startup from `WinDllServices` construction:
** While we now start `WinDllServices` across all child process types, only specific process types will support untrusted modules.
** Furthermore, untrusted modules must be started at a very specific point that is dependent on the type of child process.
** We add those calls to `StartUntrustedModulesProcessor` in subsequent patches.
Differential Revision: https://phabricator.services.mozilla.com/D53680
--HG--
extra : moz-landing-system : lando
We need a way for the sandbox broker to be able to initialize the launcher
DLL blocklist when starting a new content process.
This patch adds the ability to resolve the initialization function through
DLL services.
Differential Revision: https://phabricator.services.mozilla.com/D53678
--HG--
extra : moz-landing-system : lando
Now that the launcher blocklist will support child processes, we need to add
them to the launcher blocklist. The revised criteria the `Launcher` blocklist
matches the criteria already in use by the `Legacy` blocklist.
Differential Revision: https://phabricator.services.mozilla.com/D53675
--HG--
extra : moz-landing-system : lando
* We change `InitializeDllBlocklistOOP` to be able to set the correct flags
when initializing a sandbox child process.
* We change the freestanding DLL blocklist code to be sensitive to the
`CHILD_PROCESSES_ONLY` flag;
* We move the declaration of `gBlocklistInitFlags` to `WindowsDllBlocklist.h`
so that it is visible to more code.
Differential Revision: https://phabricator.services.mozilla.com/D53674
--HG--
extra : moz-landing-system : lando
This patch contains the core changes to make this all work across e10s:
* We clarify the naming of path variables to be more specific as to whether they are NT paths or DOS paths;
* We add IPC `ParamTraits` that are necessary for `UntrustedModulesData` types;
* We implement `ProcessModuleLoadQueue` for child processes. Because of sandboxing, we need to split this sequence into multiple async operations:
** Initial queue processing;
** Sending the list of modules to the parent process to determine trustworthiness (via `GetModulesTrust`);
** Receiving the results from the parent process and producing a final result (via `CompleteProcessing`).
* We implement the `GetModulesTrust` function for the parent process, which evaluates the trust of child process modules;
* We change all hash tables to be keyed using NT paths. Because resolving DOS paths may not be permitted in sandboxed processes,
we need to standardize on NT paths as the "universal path" across processes.
* We add `WinDllServices::StartUntrustedModulesProcessor` to separate untrusted modules startup from `WinDllServices` construction:
** While we now start `WinDllServices` across all child process types, only specific process types will support untrusted modules.
** Furthermore, untrusted modules must be started at a very specific point that is dependent on the type of child process.
** We add those calls to `StartUntrustedModulesProcessor` in subsequent patches.
Differential Revision: https://phabricator.services.mozilla.com/D53680
--HG--
extra : moz-landing-system : lando
We need a way for the sandbox broker to be able to initialize the launcher
DLL blocklist when starting a new content process.
This patch adds the ability to resolve the initialization function through
DLL services.
Differential Revision: https://phabricator.services.mozilla.com/D53678
--HG--
extra : moz-landing-system : lando
Now that the launcher blocklist will support child processes, we need to add
them to the launcher blocklist. The revised criteria the `Launcher` blocklist
matches the criteria already in use by the `Legacy` blocklist.
Differential Revision: https://phabricator.services.mozilla.com/D53675
--HG--
extra : moz-landing-system : lando
* We change `InitializeDllBlocklistOOP` to be able to set the correct flags
when initializing a sandbox child process.
* We change the freestanding DLL blocklist code to be sensitive to the
`CHILD_PROCESSES_ONLY` flag;
* We move the declaration of `gBlocklistInitFlags` to `WindowsDllBlocklist.h`
so that it is visible to more code.
Differential Revision: https://phabricator.services.mozilla.com/D53674
--HG--
extra : moz-landing-system : lando
mov byte ptr support was added in bug 1382251 but did not properly count the instruction size. It was missing the 1-byte operand, which causes the rest of the trampoline to be garbage.
Differential Revision: https://phabricator.services.mozilla.com/D55744
--HG--
extra : moz-landing-system : lando
SetWindowLong*/SetWindowLongPtr* was being intercepted so that we could override windowprocs in windowed plugins on Windows. We no longer support windowed plugins so these functions are never intercepted.
Differential Revision: https://phabricator.services.mozilla.com/D55536
--HG--
extra : moz-landing-system : lando
CloseHandle has a jump followed by enough `nop`s to fit a 10-byte patch but not enough to fit the default 13-byte patch when running Windows 8 or 8.1. This patch tells the interceptor to use a 10-byte patch on those OSs.
Differential Revision: https://phabricator.services.mozilla.com/D55535
--HG--
extra : moz-landing-system : lando
