`BLOCK_WIN8_ONLY` was introduced by bug 1268470 to block klsihk64.dll only on
Win8. However, a new blocklist (bug 1445025) does wrong comparison on the OS
version, thus `BLOCK_WIN8_ONLY` has blocked modules on all platforms older than
Win10 including Win7 and Win8.1.
This patch corrects OS comparison and changes the flag to `BLOCK_WIN8_AND_OLDER`
to make it more handy. We also remove `BLOCK_WIN8PLUS_ONLY` which is never used.
Differential Revision: https://phabricator.services.mozilla.com/D78411
Also update documentation to suggest using the `GeneratedFile` template rather than directly referencing `GENERATED_FILES` where possible.
Differential Revision: https://phabricator.services.mozilla.com/D77496
When the browser process starts a sandbox process, we copy the executable's IAT
for ntdll.dll into the new process to prevent DLL injection via IAT tampering as
the launcher process does. However, if IAT has been modified by a module injected
via `SetWindowHookEx`, the browser process cannot copy IAT because a modified IAT
is invalid in a different process, failing to start any sandbox processes.
The proposed fix is to cache IAT before COM initialization which may load
modules via `SetWindowHookEx` for the first time in the process.
Differential Revision: https://phabricator.services.mozilla.com/D73303
With ASAN, GTest uses the old blocklist implemented in mozglue, where
the new blocklist type `RedirectToNoOpEntryPoint` behaves the same as
`DllBlocklistEntry`. The test needs to expect `LoadLibrary` to fail.
Differential Revision: https://phabricator.services.mozilla.com/D70578
--HG--
extra : moz-landing-system : lando
This patch introduces a new DLL blocklist type `RedirectToNoOpEntryPoint`
which hooks a DLL's entrypoint into a no-op function. With this technique,
we give the injected DLL no chance to run its code though we allow it to be
loaded into the process.
This new blocklist type is intended to block a DLL which is injected by IAT
patching which was planted by a kernel callback routine for LoadImage. It's
because blocking such a DLL makes a new process fail to launch.
Differential Revision: https://phabricator.services.mozilla.com/D68348
--HG--
extra : moz-landing-system : lando
This patch introduces a new DLL blocklist type `RedirectToNoOpEntryPoint`
which hooks a DLL's entrypoint into a no-op function. With this technique,
we give the injected DLL no chance to run its code though we allow it to be
loaded into the process.
This new blocklist type is intended to block a DLL which is injected by IAT
patching which was planted by a kernel callback routine for LoadImage. It's
because blocking such a DLL makes a new process fail to launch.
Differential Revision: https://phabricator.services.mozilla.com/D68348
--HG--
extra : moz-landing-system : lando
Also adds missing includes in some files, these were previously only transivitely
included through mozilla/TypeTraits.h.
Differential Revision: https://phabricator.services.mozilla.com/D68561
--HG--
extra : moz-landing-system : lando
The blocklist variable `BROWSER_PROCESS` did not work as expected. Entries
defined there were blocked not only in the browser process but also in the
child process.
This patch makes sure entries in `BROWSER_PROCESS` are blocked only in the
browser process.
Differential Revision: https://phabricator.services.mozilla.com/D65248
--HG--
extra : moz-landing-system : lando
GENERATED_FILES now defaults to python3 unless py2=True is specified as
an argument. All existing GENERATED_FILES scripts and GeneratedFile
templates have the py2=True attribute added, so this patch should
effectively be a no-op.
Going forward, individual scripts can be converted to python3 and their
corresponding py2=True attribute can be deleted. In effect, this patch
will be backed out in pieces until all scripts run in python3, at which
point the py2 attribute itself can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D60919
--HG--
extra : moz-landing-system : lando
GENERATED_FILES now defaults to python3 unless py2=True is specified as
an argument. All existing GENERATED_FILES scripts and GeneratedFile
templates have the py2=True attribute added, so this patch should
effectively be a no-op.
Going forward, individual scripts can be converted to python3 and their
corresponding py2=True attribute can be deleted. In effect, this patch
will be backed out in pieces until all scripts run in python3, at which
point the py2 attribute itself can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D60919
--HG--
extra : moz-landing-system : lando
GENERATED_FILES now defaults to python3 unless py2=True is specified as
an argument. All existing GENERATED_FILES scripts and GeneratedFile
templates have the py2=True attribute added, so this patch should
effectively be a no-op.
Going forward, individual scripts can be converted to python3 and their
corresponding py2=True attribute can be deleted. In effect, this patch
will be backed out in pieces until all scripts run in python3, at which
point the py2 attribute itself can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D60919
--HG--
extra : moz-landing-system : lando
This patch adds a function to get an exported function in a remote process.
We need this implementation to address Bug 1604008, Bug 1608645, and Bug 1610790.
When `WindowsDllInterceptor` detours a function in a remote process, we used the
native `GetProcAddress` locally, and then detours the returned address in the
target process. The problem is if the caller's export table was modified, the
address returned from `GetProcAddress` might be invalid in the target process,
which is Bug 1604008.
I implemented `GetProcAddress` depending on both local and remote process image,
but it caused two regressions Bug 1608645 and Bug 1610790 because multiple
applications modify firefox's export table in multiple ways, such as replacing
an entry of EAT, replacing an RVA to Export section, or etc.
With this patch, we can use `PEExportSection<MMPolicy>::GetProcAddress` to get
an exported function in a remote process without relying on any local data so
that it's not impacted by modification of the local export table.
Differential Revision: https://phabricator.services.mozilla.com//D62315
Depends on D62314
This patch adds a function to get an exported function in a remote process.
We need this implementation to address Bug 1604008, Bug 1608645, and Bug 1610790.
When `WindowsDllInterceptor` detours a function in a remote process, we used the
native `GetProcAddress` locally, and then detours the returned address in the
target process. The problem is if the caller's export table was modified, the
address returned from `GetProcAddress` might be invalid in the target process,
which is Bug 1604008.
I implemented `GetProcAddress` depending on both local and remote process image,
but it caused two regressions Bug 1608645 and Bug 1610790 because multiple
applications modify firefox's export table in multiple ways, such as replacing
an entry of EAT, replacing an RVA to Export section, or etc.
With this patch, we can use `PEExportSection<MMPolicy>::GetProcAddress` to get
an exported function in a remote process without relying on any local data so
that it's not impacted by modification of the local export table.
Differential Revision: https://phabricator.services.mozilla.com/D62315
Depends on D62314
--HG--
extra : rebase_source : 3088f5997a2097ef22ce8567783375e5f7866ab2
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
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
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
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
This patch rolls up all the required changes for this purpose. Since the
whole crash reporting flow must understand the new format it's not possible
to land this as separate patches as individually they would be broken. This
patch includes the following changes:
* Changes to the crash reporting machinery to write out annotations as JSON,
these includes changes to the DLL blocklist code that must be run at crash
time.
* Modifications to the crash reporter client so that it can read and
submit the new format; this includes platform-specific changes to the
Breakpad libraries it uses for submitting crashes.
* Modifications to the minidump-analyzer to understand and process the new
format correctly.
* Modifications to the crash manager to understand and process the new format
correctly.
* Modifications to GeckoView's crash handler to understand and submit the
new format correctly.
* Added new tests to cover the new format and modified existing ones to
accomodate the new one.
Differential Revision: https://phabricator.services.mozilla.com/D46848
--HG--
extra : moz-landing-system : lando
Toshihito Kikuchi
Ricky Stewart
Gabriele Svelto
Jared Wein
Markus Stange
Andreas Farre
Daniel Varga
Eric Rahm
André Bargull
Mike Shal
Cosmin Sabou
Brindusan Cristian
Emilio Cobos Álvarez
Aaron Klotz
shindli