In part 1, we disabled the unhooking of DLL-intercepted functions at shutdown. The TestDllInterceptor relied on unhooking -- it worked by hooking functions with a "nonsense function" (nullptr) and then immediately unhooking it. That restored the original function behavior. Some hooked functions (e.g. NtWriteFile) are used by functions later in the program (e.g. printf) so the functions need to maintain their behavior.
This patch replaces the nonsense function with an identity function that also sets a global boolean as a side-effect. The function is written in machine code. x86-32, x86-64, and aarch64 variants are included.
Differential Revision: https://phabricator.services.mozilla.com/D30244
--HG--
extra : moz-landing-system : lando
QueryCredentialsAttributesA and FreeCredentialsHandle trigger an exception when null is passed for the CredHandle pointer. This exception was ignored (when not run in the debugger) but that is no longer the case with the changes in part 3. This patch passes a real CredHandle to them.
Differential Revision: https://phabricator.services.mozilla.com/D30243
--HG--
extra : moz-landing-system : lando
This patch fixes a static destructor order dependency between WindowsDllInterceptor and VMSharingPolicyUnique by telling VMSharingPolicyShared not to access the VMSharingPolicyUnique at destruction. This means that the behavior of intercepted functions is no longer restored in the given process at policy shutdown time.
Differential Revision: https://phabricator.services.mozilla.com/D28764
--HG--
extra : moz-landing-system : lando
On Windows 7, WinVerifyTrust fails unless the tag is uppercased. This patch
also adds a missing call to CryptCATAdminReleaseCatalogContext, the need for
which was poorly documented on MSDN.
Differential Revision: https://phabricator.services.mozilla.com/D30146
--HG--
extra : moz-landing-system : lando
TrampolineCollection iterates over an array of Trampolines that it has set 'write' permissions for. If this happens in a process whose sandbox forbids dynamic code then these permissions cannot be set. This patch detects that condition and returns an empty TrampolineCollection in that case. We ASSERT if we fail to set permissions for any other reason.
Differential Revision: https://phabricator.services.mozilla.com/D28613
--HG--
extra : moz-landing-system : lando
Bug 1533808 introduced code to intercept DLL methods that the Chromium sandbox had already intercepted. That patch did not store the the pointer to the intercepted function in the trampoline data, as is done when intercepting other methods.
Differential Revision: https://phabricator.services.mozilla.com/D28612
--HG--
extra : moz-landing-system : lando
We're going to convert the test to a gtest, and it's simpler not to have
to deal with finding the path to the testcase zip files. They're small
enough anyways, and can be inserted as raw binary data via some assembly
magic. This being android-only code, we don't need extreme portability
here. This is the same trick we use in
config/external/icu/data/icudata_gas.S.
Differential Revision: https://phabricator.services.mozilla.com/D28758
--HG--
extra : moz-landing-system : lando
This patch fixes a static destructor order dependency between WindowsDllInterceptor and VMSharingPolicyUnique by telling VMSharingPolicyShared not to access the VMSharingPolicyUnique at destruction. See the bug for details of the order dependency.
Differential Revision: https://phabricator.services.mozilla.com/D28764
--HG--
extra : moz-landing-system : lando
See comment 24 in the bug for details on what can go wrong without this
change. This change ensures system libraries are not going to pick
symbols from mozglue when running processes outside dalvik.
As a side effect, this makes things kind of closer to what happens when
dalvik is involved, exposing unit tests to possible allocator mismatches
that could happen like bug 1531887.
On the flip side, libraries that link against mozglue explicitly are
going to get a reference to the versioned symbols, so everything is fine
in that regard. The custom linker, however, will ignore the versions
altogether, and its symbols resolution just ends up unchanged. So we're
fine there too.
We use something that is close to what using a SYMBOLS_FILE would
generate as a version script, but we need to do so manually because
SYMBOLS_FILE doesn't support exporting all the symbols.
Differential Revision: https://phabricator.services.mozilla.com/D28030
--HG--
extra : moz-landing-system : lando
Bug 884239 added a build-time Android version check around the
pthread_atfork function definition at the same time as for timer_create,
which was subsequently removed. But it turns out the version that
documented was wrong: per the comment added in bug 680190,
pthread_atfork might have been supported since Android 2.3 (gingerbread,
API 9 or 10). That might not be entirely accurate, though, because the
bionic repository seems to show it made it to Android 4.0 (ice cream
sandwich, API 14 or 15).
Either way, that is less than the minimum API version we currently
support, which is 16.
Differential Revision: https://phabricator.services.mozilla.com/D27848
--HG--
extra : moz-landing-system : lando
There shouldn't be any need to do this for content processes as
the DLL should already be in the system file cache.
Differential Revision: https://phabricator.services.mozilla.com/D26017
--HG--
extra : moz-landing-system : lando
There shouldn't be any need to do this for content processes as
the DLL should already be in the system file cache.
Differential Revision: https://phabricator.services.mozilla.com/D26017
--HG--
extra : moz-landing-system : lando
This way we don't have to go through a bunch of printf nonsense, and we
ought to be able to arrive at optimized routines that take advantage of
constant radices, etc.
Differential Revision: https://phabricator.services.mozilla.com/D25141
--HG--
extra : moz-landing-system : lando
Due to coming changes involving the IOInterposer, the WindowsDllInterceptor may be set up later than the sandbox. The sandbox hooks some of the same functions, so the Interceptor is running into its hooks instead of the original implementations it anticipated. This patch allows it to recognize and efficiently patch those hooks when that happens.
Differential Revision: https://phabricator.services.mozilla.com/D24654
--HG--
extra : moz-landing-system : lando
When Android shuts down the ndk process, it doesn't call the registered
atexit() handlers, which is normally where the profile data gets written
to file. Since the PGO test suite closes the browser when it is
finished, the nativeRun routine can manually call out to
__llvm_profile_dump() before returning.
This method has a downside that only the profile data from the calling
library gets written out, rather than for the whole process. Since we
are most interested in optimizing libxul, a new hook is added in
Bootstrap to make sure we get the profile data for the right library.
Differential Revision: https://phabricator.services.mozilla.com/D22817
--HG--
extra : source : 0615c775a0cf6e8f98e1c051cd574c0d602a738a
When Android shuts down the ndk process, it doesn't call the registered
atexit() handlers, which is normally where the profile data gets written
to file. Since the PGO test suite closes the browser when it is
finished, the nativeRun routine can manually call out to
__llvm_profile_dump() before returning.
This method has a downside that only the profile data from the calling
library gets written out, rather than for the whole process. Since we
are most interested in optimizing libxul, a new hook is added in
Bootstrap to make sure we get the profile data for the right library.
Differential Revision: https://phabricator.services.mozilla.com/D22817
--HG--
extra : moz-landing-system : lando
In the tree we have two copies of printf_stderr() with the comment,
"Ideally this should be shared". This moves the function to a new exported
header which can be the basis for other similar debugging utility functions.
To include it,
#include "mozilla/glue/Debug.h"
A small concern with this is that printf_stderr() is in the global namespace,
and could conflict if it's inadvertently included along with, for example,
nsDebug.h which also defines this function. The warning in the comment at the
top of the file attempts to mitigate this.
Differential Revision: https://phabricator.services.mozilla.com/D13196
--HG--
extra : moz-landing-system : lando
BasicDllServices is used to gain access to the authenticode APIs in non-Gecko
contexts. One feature that WinDllServices provides is the ability to register
a callback interface to be notified when a DLL has been loaded.
This is not particularly useful in the BasicDllServices use case, and in the
"handle a launcher process failure on a background thread" use case, would
actually be harmful.
This patch modifies the DLLServices backend to offer a "basic" option that
omits the callback stuff.
Differential Revision: https://phabricator.services.mozilla.com/D19696
--HG--
extra : moz-landing-system : lando
This patch doesn't cover all possible functions for which we currently
instantiate interceptors inside Firefox/Gecko. Rather than asserting, we just
fail in those cases (at least until we have full coverage of existing uses).
This is okay, as for the upcoming milestone 2 of aarch64 builds, we are most
concerned with successfully being able to hook the following functions:
ntdll!LdrLoadDll
ntdll!LdrUnloadDll
ntdll!LdrResolveDelayLoadedAPI
user32!GetWindowInfo
So, within that context, the aarch64 implementation is fairly simple:
Each instruction is 4-bytes wide. We iterate down each instruction, and if the
current instruction is *not* PC-relative, we just copy it verbatim. If we
encounter an instruction that *is* PC-relative, we either decode it and
rewrite it inside the trampoline, or we fail. For the purposes of milestone 2,
the only instruction that is essential to decode is ADRP.
In bug 1526016 I modify TestDllInterceptor to exclude functions that are not
yet supported by this patch.
Differential Revision: https://phabricator.services.mozilla.com/D19446
--HG--
extra : moz-landing-system : lando
FramePointerStackWalk can trip ASAN when walking the stack and reading outside
of ASAN-protected objects.
Differential Revision: https://phabricator.services.mozilla.com/D20208
--HG--
extra : moz-landing-system : lando
The actual subcategories will be added in later patches, so that there are no
unused categories.
Differential Revision: https://phabricator.services.mozilla.com/D11334
--HG--
extra : moz-landing-system : lando
Consequently, this removes:
- MOZ_LIBPRIO, which is now always enabled.
- non_msvc_compiler, which is now always true.
- The cl.py wrapper, since it's not used anymore.
- CL_INCLUDES_PREFIX, which was only used for the cl.py wrapper.
- NONASCII, which was only there to ensure CL_INCLUDES_PREFIX still
worked in non-ASCII cases.
This however keeps a large part of detecting and configuring for MSVC,
because we still do need it for at least headers, libraries, and midl.
Depends on D19614
Differential Revision: https://phabricator.services.mozilla.com/D19615
--HG--
extra : moz-landing-system : lando
This patch takes care of a bunch of issues and does some cleanup:
* We rename mscom::MainThreadRuntime to mscom::ProcessRuntime, as the latter
is a more accurate name going forward.
* We make ProcessRuntime aware of the Win32k Lockdown process mitigation
policy. When Win32k is disabled, we perform process-wide COM initialization
in the multi-threaded apartment (since we cannot create an STA window).
* We refactor the mscom apartment region stuff to enable the Win32k lockdown
pieces in ProcessRuntime.
* We move some Gecko-specific stuff into MOZILLA_INTERNAL_API guards so that
ProcessRuntime is usable outside of xul.dll (I will be needing it for the
launcher process).
* Another thing that might happen with the launcher process is that, under
error conditions in the launcher, we create a ProcessRuntime object on a
background thread for the purposes of telemetry logging, but we also allow
the main thread to proceed to start as the browser. This could result in a
scenario where the main thread, as the browser process, is attempting to
instantiate its ProcessRuntime and ends up racing with the launcher process's
telemetry thread which has its own ProcessRuntime. To account for this
situation, we add mutual exclusion to the process-wide initialization code.
We host this part inside mozglue since that state is shared between both
firefox.exe and xul.dll.
* We clean up ProcessRuntime::InitializeSecurity by using Vector to set up
the EXPLICIT_ACCESS entries.
* We remove mscom::MainThreadClientInfo and replace it with a direct call to
CoGetCallerTID
* We revise all references to this class to use the new name.
Differential Revision: https://phabricator.services.mozilla.com/D19551
--HG--
rename : ipc/mscom/COMApartmentRegion.h => ipc/mscom/ApartmentRegion.h
rename : ipc/mscom/MainThreadRuntime.cpp => ipc/mscom/ProcessRuntime.cpp
rename : ipc/mscom/MainThreadRuntime.h => ipc/mscom/ProcessRuntime.h
extra : moz-landing-system : lando
This patch takes care of a bunch of issues and does some cleanup:
* We rename mscom::MainThreadRuntime to mscom::ProcessRuntime, as the latter
is a more accurate name going forward.
* We make ProcessRuntime aware of the Win32k Lockdown process mitigation
policy. When Win32k is disabled, we perform process-wide COM initialization
in the multi-threaded apartment (since we cannot create an STA window).
* We refactor the mscom apartment region stuff to enable the Win32k lockdown
pieces in ProcessRuntime.
* We move some Gecko-specific stuff into MOZILLA_INTERNAL_API guards so that
ProcessRuntime is usable outside of xul.dll (I will be needing it for the
launcher process).
* Another thing that might happen with the launcher process is that, under
error conditions in the launcher, we create a ProcessRuntime object on a
background thread for the purposes of telemetry logging, but we also allow
the main thread to proceed to start as the browser. This could result in a
scenario where the main thread, as the browser process, is attempting to
instantiate its ProcessRuntime and ends up racing with the launcher process's
telemetry thread which has its own ProcessRuntime. To account for this
situation, we add mutual exclusion to the process-wide initialization code.
We host this part inside mozglue since that state is shared between both
firefox.exe and xul.dll.
* We clean up ProcessRuntime::InitializeSecurity by using Vector to set up
the EXPLICIT_ACCESS entries.
* We remove mscom::MainThreadClientInfo and replace it with a direct call to
CoGetCallerTID
* We revise all references to this class to use the new name.
Differential Revision: https://phabricator.services.mozilla.com/D19551
--HG--
rename : ipc/mscom/COMApartmentRegion.h => ipc/mscom/ApartmentRegion.h
rename : ipc/mscom/MainThreadRuntime.cpp => ipc/mscom/ProcessRuntime.cpp
rename : ipc/mscom/MainThreadRuntime.h => ipc/mscom/ProcessRuntime.h
extra : moz-landing-system : lando
This patch measures the duration of module loads and passes it up to
UntrustedModulesManager where, in later patches, it will be consumed by
telemetry.
Differential Revision: https://phabricator.services.mozilla.com/D16011
--HG--
extra : moz-landing-system : lando
WindowsDllBlocklist installs a callback function that fires whenever a DLL
is loaded. The installer function shares an SRWLock with the callback
function.
SRWLock is not re-entrant, so if the installer function accidently causes a
DLL load before releasing the lock, the callback function will deadlock.
This occured trying to solve Bug 1402282, where the installer function used
"new" to allocate memory, which called the Win32 "RtlGenRandom()" function,
which loaded bcrypt.dll, which caused the callback to fire off, which tried
to lock the mutex that was already locked by the installer function.
Hopefully this will save another developer lots of debug time in the future by
turning a difficult-to-debug deadlock into a nice, loud assertion.
Differential Revision: https://phabricator.services.mozilla.com/D15840
--HG--
extra : moz-landing-system : lando
It's a define that needs winuser.rh to be included.
MozReview-Commit-ID: LPfJOwnNm6V
Differential Revision: https://phabricator.services.mozilla.com/D15333
--HG--
extra : moz-landing-system : lando
mozilla::PrintfTarget::cvt_f release asserts that the desired printf
fit into a statically-sized buffer. However, this may not be the case
if the user requested a larger width or precision. Handle this
unusual case by allocating a temporary buffer.
MozReview-Commit-ID: 2WicecHDzDR
Differential Revision: https://phabricator.services.mozilla.com/D15989
--HG--
extra : moz-landing-system : lando
Chromium IPC locks have this and the API gets used, so we need to expose
it ourselves if we're going to use our locks in place of the Chromium
IPC locks. This patch changes the mozglue parts; tweaking the xpcom
parts is the next patch.
In Windows 7 x64, GetFileAttributesW begins with a short, backwards jump that can't safely be converted by the interceptor. Additionally, the function doesn't have enough NOP space after the JMP for the trampoline. However, the target of the short JMP is a long JMP, followed by plenty of NOP space. This patch moves the trampoline location from the first JMP to the second.
Differential Revision: https://phabricator.services.mozilla.com/D11258
--HG--
extra : moz-landing-system : lando
Nightly is reporting mozglue.dll as being untrusted in the untrusted modules
ping. Until now, xpcshell tests hard-code mozglue to appear as untrusted in
order to cover certain code paths related to startup modules.
This patch:
1. Checks explicitly for the xpcshell environment and only applies this logic
during xpcshell tests.
2. Uses a purpose-build DLL, "untrusted-startup-test-dll.dll", instead of
mozglue. This is more explicit and doesn't interfere with any "true"
processing of mozglue.
Differential Revision: https://phabricator.services.mozilla.com/D14720
--HG--
extra : moz-landing-system : lando
As far as my stepping through WalkStackMain64 goes, it seems StackWalk64
doesn't work, even with more information added to the frame data it's
given.
Switching to the same code as for x86-64, however, works, albeit
skipping too many frames, but all platforms are actually skipping too
many frames, so let's ignore that for now and leave it to bug 1515229.
Differential Revision: https://phabricator.services.mozilla.com/D14929
--HG--
extra : moz-landing-system : lando
- modify line wrap up to 80 chars; (tw=80)
- modify size of tab to 2 chars everywhere; (sts=2, sw=2)
--HG--
extra : rebase_source : 7eedce0311b340c9a5a1265dc42d3121cc0f32a0
extra : amend_source : 9cb4ffdd5005f5c4c14172390dd00b04b2066cd7
This is a best effort attempt at ensuring that the adverse impact of
reformatting the entire tree over the comments would be minimal. I've used a
combination of strategies including disabling of formatting, some manual
formatting and some changes to formatting to work around some clang-format
limitations.
Differential Revision: https://phabricator.services.mozilla.com/D13371
--HG--
extra : moz-landing-system : lando
This also uses idiomatic packaging of the native libraries, which
will allow easier downstream consumption of GeckoView.
Differential Revision: https://phabricator.services.mozilla.com/D10775
--HG--
extra : moz-landing-system : lando
Added a test to TestCrossProcessInterceptor that forcibly uses a 10-byte patch
on NtMapViewOfSection (which is a realistic case) and then ensures that
disabling the hook also works.
Differential Revision: https://phabricator.services.mozilla.com/D10286
--HG--
extra : moz-landing-system : lando
This patch adds support on x64 for 10-byte detour patches in certain cases.
In particular, the reserved region of trampoline memory must be allocated
within the bottommost 2GB of the address space.
This feature is currently only activated when detouring functions exported by
ntdll.dll.
Differential Revision: https://phabricator.services.mozilla.com/D10285
--HG--
extra : moz-landing-system : lando
This also uses idiomatic packaging of the native libraries, which
will allow easier downstream consumption of GeckoView.
Differential Revision: https://phabricator.services.mozilla.com/D10775
--HG--
extra : moz-landing-system : lando
This also uses idiomatic packaging of the native libraries, which
will allow easier downstream consumption of GeckoView.
Differential Revision: https://phabricator.services.mozilla.com/D10775
--HG--
extra : moz-landing-system : lando
Added a test to TestCrossProcessInterceptor that forcibly uses a 10-byte patch
on NtMapViewOfSection (which is a realistic case) and then ensures that
disabling the hook also works.
Differential Revision: https://phabricator.services.mozilla.com/D10286
--HG--
extra : moz-landing-system : lando
This patch adds support on x64 for 10-byte detour patches in certain cases.
In particular, the reserved region of trampoline memory must be allocated
within the bottommost 2GB of the address space.
This feature is currently only activated when detouring functions exported by
ntdll.dll.
Differential Revision: https://phabricator.services.mozilla.com/D10285
--HG--
extra : moz-landing-system : lando
Added a test to TestCrossProcessInterceptor that forcibly uses a 10-byte patch
on NtMapViewOfSection (which is a realistic case) and then ensures that
disabling the hook also works.
Differential Revision: https://phabricator.services.mozilla.com/D10286
--HG--
extra : moz-landing-system : lando
This patch adds support on x64 for 10-byte detour patches in certain cases.
In particular, the reserved region of trampoline memory must be allocated
within the bottommost 2GB of the address space.
This feature is currently only activated when detouring functions exported by
ntdll.dll.
Differential Revision: https://phabricator.services.mozilla.com/D10285
--HG--
extra : moz-landing-system : lando
They were not displayed in the UI, and the instructions to initialize the line
field of a stack frame increased code size unnecessarily.
This change reduces the binary size on Linux x64 by around 100KB.
Here's a diff of the impact on the code generated for Attr_Binding::get_specified
in the Mac build:
@@ -20,17 +20,16 @@
movq 0x8(%rbx), %rax
movq %r12, %rcx
shlq $0x5, %rcx
leaq aGetAttrspecifi, %rdx ; "get Attr.specified"
movq %rdx, (%rax,%rcx)
movq $0x0, 0x8(%rax,%rcx)
leaq -40(%rbp), %rdx
movq %rdx, 0x10(%rax,%rcx)
- movl $0x106, 0x18(%rax,%rcx)
movl $0x1c, 0x1c(%rax,%rcx)
leal 0x1(%r12), %eax
movl %eax, 0x10(%rbx)
movq %r15, %rdi
call __ZNK7mozilla3dom4Attr9SpecifiedEv ; mozilla::dom::Attr::Specified() const
movzxl %al, %eax
movabsq $0xfff9000000000000, %rcx
Depends on D9193
Differential Revision: https://phabricator.services.mozilla.com/D9195
--HG--
extra : moz-landing-system : lando
They were not displayed in the UI, and the instructions to initialize the line
field of a stack frame increased code size unnecessarily.
This change reduces the binary size on Linux x64 by around 100KB.
Here's a diff of the impact on the code generated for Attr_Binding::get_specified
in the Mac build:
@@ -20,17 +20,16 @@
movq 0x8(%rbx), %rax
movq %r12, %rcx
shlq $0x5, %rcx
leaq aGetAttrspecifi, %rdx ; "get Attr.specified"
movq %rdx, (%rax,%rcx)
movq $0x0, 0x8(%rax,%rcx)
leaq -40(%rbp), %rdx
movq %rdx, 0x10(%rax,%rcx)
- movl $0x106, 0x18(%rax,%rcx)
movl $0x1c, 0x1c(%rax,%rcx)
leal 0x1(%r12), %eax
movl %eax, 0x10(%rbx)
movq %r15, %rdi
call __ZNK7mozilla3dom4Attr9SpecifiedEv ; mozilla::dom::Attr::Specified() const
movzxl %al, %eax
movabsq $0xfff9000000000000, %rcx
Depends on D9193
Differential Revision: https://phabricator.services.mozilla.com/D9195
--HG--
extra : moz-landing-system : lando
They were not displayed in the UI, and the instructions to initialize the line
field of a stack frame increased code size unnecessarily.
This change reduces the binary size on Linux x64 by around 100KB.
Here's a diff of the impact on the code generated for Attr_Binding::get_specified
in the Mac build:
@@ -20,17 +20,16 @@
movq 0x8(%rbx), %rax
movq %r12, %rcx
shlq $0x5, %rcx
leaq aGetAttrspecifi, %rdx ; "get Attr.specified"
movq %rdx, (%rax,%rcx)
movq $0x0, 0x8(%rax,%rcx)
leaq -40(%rbp), %rdx
movq %rdx, 0x10(%rax,%rcx)
- movl $0x106, 0x18(%rax,%rcx)
movl $0x1c, 0x1c(%rax,%rcx)
leal 0x1(%r12), %eax
movl %eax, 0x10(%rbx)
movq %r15, %rdi
call __ZNK7mozilla3dom4Attr9SpecifiedEv ; mozilla::dom::Attr::Specified() const
movzxl %al, %eax
movabsq $0xfff9000000000000, %rcx
Depends on D9193
Differential Revision: https://phabricator.services.mozilla.com/D9195
--HG--
extra : moz-landing-system : lando
We now record DLL load events along with stack trace and other data so we can
later determine trustworthiness and report the DLL via telemetry.
Differential Revision: https://phabricator.services.mozilla.com/D7175
--HG--
extra : moz-landing-system : lando
This patch adds a new static member to the TimeStamp class to store the
current locked *time* (in ms since the epoch) in addition to the current locked
timestamp.
We point the JS Engine at this value if Fuzzyfox is enabled.
Creates GetFuzzyfoxEnabled() functions that check a static boolean.
Exposes SetFuzzyfoxEnabled() because we cannot depend on Pref
Observation code inside the TimeStamp class.
TimeStamp::Now will now return a Fuzzy value.
We add a NowReally function to support obtaining the real timestamp.
We also add a UsedCanonicalNow to expose whether the TimeStamp was real or fuzzy.
Creates a FuzzyFox class for implementating the core of the step/sleep
algorithm. Starts it in nsLayoutStatics::Initialize()
Adds the fuzzyfox prefs.
Moves the ms2mt macros from TimeStamp_windows.cpp to TimeStamp_windows.h
and creates a new public function GetQueryPerformanceFrequencyPerSec() to
expose a static variable in the .cpp file. This is necessary to support
the macros being usable anywhere. (And we use the macros in FuzzyFox.)
SxS assemblies do not obey the usual DLL search order. It will make it possible
to load mozglue.dll from appdir even if the PreferSystem32Images mitigation is
enabled and System32 has a random mozglue.dll.
All but one of the current uses of DEFFILE use `SRCDIR + '/file.def'` to
get a srcdir-relative path anyway, and the other one wants an
objdir-relative path, so using Path makes everything clearer.
This makes it more straightforward to translate the paths for the WSL
build.
The linker has x86-64 support but currently fails to compile. This patch
fixes these compile errors to make it build under x86-64.
Differential Revision: https://phabricator.services.mozilla.com/D4481
This code throws an error in clang on the inner MMPolicy:
error: declaration of 'MMPolicy' shadows template parameter
Notethat the template parameter is declared earlier at the
class definition of ReadOnlyTargetFunction
MozReview-Commit-ID: buLE9d22YS
Differential Revision: https://phabricator.services.mozilla.com/D4571
--HG--
extra : moz-landing-system : lando
This code is untested and has been cargo-culted a little bit from the
existing x86 code, but should work OK; all the code in Windows is
compiled with frame pointers, we're compiled with frame pointers after
the previous patch, and so the frame pointer unwinding path makes the
most sense.
This introduces the machinery needed to generate crash annotations from a YAML
file. The relevant C++ functions are updated to take a typed enum. JavaScript
calls are unaffected but they will throw if the string argument does not
correspond to one of the known entries in the C++ enum. The existing whitelists
and blacklists of annotations are also generated from the YAML file and all
duplicate code related to them has been consolidated. Once written out to the
.extra file the annotations are converted in string form and are no different
than the existing ones.
All existing annotations have been included in the list (and some obsolete ones
have been removed) and all call sites have been updated including tests where
appropriate.
--HG--
extra : source : 4f6c43f2830701ec5552e08e3f1b06fe6d045860
__wrap_dlerror uses a single pointer for all threads, which means one
thread could get the dlerror result from another thread. Normally this
wouldn't cause crashes. However, because dlerror results come from a
per-thread buffer, if a thread exits and our saved dlerror result came
from that thread, the saved pointer could then refer to invalid memory.
The proper way to fix this is to use TLS and have a per-thread pointer
for __wrap_dlerror. However, instead of using up a TLS slot, this patch
keeps the single pointer for custom messages, and fallback to per-thread
dlerror call for system messages. While the race condition still exists,
I think the risk is acceptable. Even when races occur, they should no
longer cause crashes.
MozReview-Commit-ID: 4hGksidjiVz
--HG--
extra : rebase_source : 373000686c426b81ffd7cee88264e89b7a733957
There is no meaningful equality relationship on any plausible mutex
implementation other than object identity. Having MutexImpl's users simply
compare by addresses makes it clearer in the callers that that's what's going
on.
Adding or removing an FD from this API currently requires changes in about a
half dozen places. Ignoring the Java side of things. This patch changes the
API to pass a struct, rather than additional arguments for each FD, so that
adding and removing FDs only requires changing one declaration, and the two
call sites that add and consume the FDs.
MozReview-Commit-ID: CToSEVp1oqP
--HG--
extra : intermediate-source : ff41551f5ff1b98b72ed771a6f2a3f66a8b79a57
extra : absorb_source : c9fe7423fcbb47655b05209b44fb02b69b272d07
extra : source : 4b7a8a35ed956159e2f443c6211164c0cbf3d926
extra : histedit_source : b98b792791274f00a5e649c82dc25043cc1d699a
Adding or removing an FD from this API currently requires changes in about a
half dozen places. Ignoring the Java side of things. This patch changes the
API to pass a struct, rather than additional arguments for each FD, so that
adding and removing FDs only requires changing one declaration, and the two
call sites that add and consume the FDs.
MozReview-Commit-ID: CToSEVp1oqP
--HG--
extra : source : 4b7a8a35ed956159e2f443c6211164c0cbf3d926
extra : histedit_source : 01a1160ce1107d12e8b376d4512dedb0478e447c
Adding or removing an FD from this API currently requires changes in about a
half dozen places. Ignoring the Java side of things. This patch changes the
API to pass a struct, rather than additional arguments for each FD, so that
adding and removing FDs only requires changing one declaration, and the two
call sites that add and consume the FDs.
MozReview-Commit-ID: CToSEVp1oqP
--HG--
extra : rebase_source : 28e8c6075bacf5f610058227a9731aeadb50f320
extra : absorb_source : f63602a163ed19fb65e26640319750fdd9b92ad1
For clang-cl, we want to add code to libxul that only exists during the
PGO generation phase, so we can collect data. The most expedient way to
do that is to enable certain files in SOURCES to be marked as to only be
compiled during the PGO generation step.
In addition to updating the interface, this patch also significantly alters the
structure of this test. In particular, it removes the Test* functions in favour
of using template magic.
I did this because I noticed that, in the majority of cases, the stub function
was being called with all zero arguments, and then we check for the expected
error code. I thought that maybe we could replace that repetition with some
templates that instantiate a blank tuple that may then be applied to a callable
object.
See the (MAYBE_)TEST_HOOK* and TEST_DETOUR* macro definitions for detailed
information about how to use these things.
The test successfully completes with both 32-bit and 64-bit builds.
This patch makes the interceptor's AddHook functions private, and converts
the stubs from simple function pointers into objects containing both the stub
function pointer, plus a INIT_ONCE sentinel.
Setting a hook now requires calling Set or SetDetour on the stub, which ensures
that the hook attempt happens once and only once.
The constructor for the new object is constexpr, so it should not generate
static initializers if it is declared statically.
Note that, as a corollary of the new behaviour, we no longer need to set guards
around any hook setting code. I have removed those when present.
In addition to updating the interface, this patch also significantly alters the
structure of this test. In particular, it removes the Test* functions in favour
of using template magic.
I did this because I noticed that, in the majority of cases, the stub function
was being called with all zero arguments, and then we check for the expected
error code. I thought that maybe we could replace that repetition with some
templates that instantiate a blank tuple that may then be applied to a callable
object.
See the (MAYBE_)TEST_HOOK* and TEST_DETOUR* macro definitions for detailed
information about how to use these things.
The test successfully completes with both 32-bit and 64-bit builds.
This patch makes the interceptor's AddHook functions private, and converts
the stubs from simple function pointers into objects containing both the stub
function pointer, plus a INIT_ONCE sentinel.
Setting a hook now requires calling Set or SetDetour on the stub, which ensures
that the hook attempt happens once and only once.
The constructor for the new object is constexpr, so it should not generate
static initializers if it is declared statically.
Note that, as a corollary of the new behaviour, we no longer need to set guards
around any hook setting code. I have removed those when present.
In addition to updating the interface, this patch also significantly alters the
structure of this test. In particular, it removes the Test* functions in favour
of using template magic.
I did this because I noticed that, in the majority of cases, the stub function
was being called with all zero arguments, and then we check for the expected
error code. I thought that maybe we could replace that repetition with some
templates that instantiate a blank tuple that may then be applied to a callable
object.
See the (MAYBE_)TEST_HOOK* and TEST_DETOUR* macro definitions for detailed
information about how to use these things.
The test successfully completes with both 32-bit and 64-bit builds.
--HG--
extra : rebase_source : 95e9a3386c0a6c5f9f78b1e8fa5a88c1c30e9b51
This patch makes the interceptor's AddHook functions private, and converts
the stubs from simple function pointers into objects containing both the stub
function pointer, plus a INIT_ONCE sentinel.
Setting a hook now requires calling Set or SetDetour on the stub, which ensures
that the hook attempt happens once and only once.
The constructor for the new object is constexpr, so it should not generate
static initializers if it is declared statically.
Note that, as a corollary of the new behaviour, we no longer need to set guards
around any hook setting code. I have removed those when present.
--HG--
extra : rebase_source : 260ec9f99839468d9994186fddd7cf2b33e6c87d
clang-cl complains about things like:
z:/build/build/src/obj-firefox/dist/include/mozilla/interceptor/VMSharingPolicies.h(53,50): warning: use of identifier 'GetLocalView' found via unqualified lookup into dependent bases of class templates is a Microsoft extension [-Wmicrosoft-template]
return TrampolineCollection<MMPolicy>(*this, GetLocalView(), GetRemoteView(),
^
in various files in interceptor/, and since the warnings are in headers,
rather than in sources, they're rather annoying. Let's fix this to be
standards-complaint and make clang-cl stop complaining.
This will make sure that when running |mach python-test --python 3| locally,
we only run the tests that also run in CI with python 3 (and therefore pass
presumably).
MozReview-Commit-ID: 3OBr9yLSlSq
--HG--
extra : rebase_source : 456340d0ecdddf1078f2b5b4ebb1eddf3813b26a
When we modify the debug map, we could be racing with the system linker,
either when we modify the entries or when we change page protection
flags. To fix the race, we need to take the system linker's internal
lock when we perform any kind of modification on the debug map.
One way to hold the system linker lock is to call dl_iterate_phdr, and
perform our actions inside the callback, which is invoked with the
lock being held. However, dl_iterate_phdr is only present on Android
5.0+, and even then, dl_iterate_phdr is only protected by the linker
lock on Android 6.0+.
This means that with this patch, we can only safely modify the debug map
on Android 6.0+, which I think is acceptable for an operation that only
benefits a debugger.
MozReview-Commit-ID: BowBEO8tu8Z
--HG--
extra : amend_source : 837631dfc2ef17b24ffe5778bcb70dc29b7dfc66
* This allows us to use a single blocklist definition in multiple places.
* This patch also adds support for a new initialization flag that, when enabled,
disables the DLL Blocking part of the mozglue blocklist but leaves the
profiling and stackwalking suppression bits intact.
* This allows us to use a single blocklist definition in multiple places.
* This patch also adds support for a new initialization flag that, when enabled,
disables the DLL Blocking part of the mozglue blocklist but leaves the
profiling and stackwalking suppression bits intact.
--HG--
extra : rebase_source : ff4dad72f57c5662fc9e1bbd9e4efb3ff01470ef
GetThreadContext() returns a context pointing to its own frame when it
gets called with the current thread handle. That frame can go away after
it returns. This patch instead uses RtlCaptureContext(), which captures
the context of its caller, when walking the current thread.
In the past, we also used a walker thread when nullptr is passed in for
aThread, but the check doesn't cover all the cases, and having another
thread is apparently more complicated than this approach.
MozReview-Commit-ID: 3TAatDc9BLh
--HG--
extra : rebase_source : 7978cce48b8939a723cd5ccafe86d3f7aca6d3ac
GetCurrentThread() returns a pseudo handle, so comparing it against
the passed in argument doesn't make sense in most cases. This patch
changes it to using the thread id for comparison, which is guaranteed
to be unique in the whole lifetime of a thread.
MozReview-Commit-ID: 5TNAgLkcS6m
--HG--
extra : rebase_source : d5bb21ac57a4c1149b8d332ea7b28a78ed994c62
GetThreadContext() returns a context pointing to its own frame when it
gets called with the current thread handle. That frame can go away after
it returns. This patch instead uses RtlCaptureContext(), which captures
the context of its caller, when walking the current thread.
MozReview-Commit-ID: 3TAatDc9BLh
--HG--
extra : rebase_source : d5d88f0a9fa07da5b31f27c51c78ee2bfb527a8e
GetCurrentThread() returns a pseudo handle, so comparing it against
the passed in argument doesn't make sense in most cases. This patch
changes it to using the thread id for comparison, which is guaranteed
to be unique in the whole lifetime of a thread.
MozReview-Commit-ID: 5TNAgLkcS6m
--HG--
extra : rebase_source : 0e72e8f6196c8079086ca697b9a121c6987ef43e
Same approach as the other bug, mostly replacing automatically by removing
'using mozilla::Forward;' and then:
s/mozilla::Forward/std::forward/
s/Forward</std::forward</
The only file that required manual fixup was TestTreeTraversal.cpp, which had
a class called TestNodeForward with template parameters :)
MozReview-Commit-ID: A88qFG5AccP
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
We are apparently still crashing even after mprotect() with write flag
returns successfully. This patch reads the flags again after mprotect()
returns, and hopefully the flags will tell the truth of whether the page
is truly writable or not after calling mprotect().
MozReview-Commit-ID: Jsg8vHKFEvJ
--HG--
extra : rebase_source : b028aa0d5cefd50302bfc2502292d9129d202e09
This also changes many references to the 'pseudo stack' to refer to the 'label
stack' instead. The label stack is one of the two stacks that are managed by
the profiling stack, the other stack being the JS interpreter stack.
MozReview-Commit-ID: Ed0YMMeCBY8
--HG--
extra : rebase_source : 5675d670f424c7d7dda04bafc2b3431fa2485e3c
The term "entry" is already used for elements in the profile buffer.
MozReview-Commit-ID: 1aB22V6veQh
--HG--
extra : rebase_source : c664eb4d6bed6cb74ba8a1b67ea99bd8ca57bcf7
extra : source : 3264c0cc0027b240b55bd3aebf27263b1e1d1cc0
The name Cpp was confusing, because C++ functions are in the native stack, not
in the pseudo stack. The pseudo stack only contains frames for manually
instrumented code that uses AutoProfilerLabel, and JS frames.
MozReview-Commit-ID: 9ptfhREo0qy
--HG--
extra : rebase_source : 76a1a32acb4c946aeb2ad45e904e419c1c9e2ad1
It was necessary back when we were doing decompression from a signal
handler, because we couldn't then have zlib call malloc, but we don't
do that anymore, so the whole wrapping is effectively unused.
With the wrapping gone, we manually initialize the zalloc, zfree and
opaque fields, as specified in the zlib documentation.
--HG--
extra : rebase_source : c4e84009e65f71f6c43362468c2934e04a8abda1
This patch replaces the large -intPrefs/-boolPrefs/-stringPrefs flags with
a short-lived, anonymous, shared memory segment that is used to pass the early
prefs.
Removing the bloat from the command line is nice, but more important is the
fact that this will let us pass more prefs at content process start-up, which
will allow us to remove the early/late prefs split (bug 1436911).
Although this mechanism is only used for prefs, it's conceivable that it could
be used for other data that must be received very early by children, and for
which the command line isn't ideal.
Notable details:
- Much of the patch deals with the various platform-specific ways of passing
handles/fds to children.
- Linux and Mac: we use a fixed fd (8) in combination with the new
GeckoChildProcessHost::AddFdToRemap() function (which ensures the child
won't close the fd).
- Android: like Linux and Mac, but the handles get passed via "parcels" and
we use the new SetPrefsFd() function instead of the fixed fd.
- Windows: there is no need to duplicate the handle because Windows handles
are system-wide. But we do use the new
GeckoChildProcessHost::AddHandleToShare() function to add it to the list of
inheritable handles. We also ensure that list is processed on all paths
(MOZ_SANDBOX with sandbox, MOZ_SANDBOX without sandbox, non-MOZ_SANDBOX) so
that the handles are marked as inheritable. The handle is passed via the
-prefsHandle flag.
The -prefsLen flag is used on all platforms to indicate the size of the
shared memory segment.
- The patch also moves the serialization/deserialization of the prefs in/out of
the shared memory into libpref, which is a better spot for it. (This means
Preferences::MustSendToContentProcesses() can be removed.)
MozReview-Commit-ID: 8fREEBiYFvc
--HG--
extra : rebase_source : 7e4c8ebdbcd7d74d6bd2ab3c9e75a6a17dbd8dfe
Switch the order of the IPC FD argument and the crash FD argument in
e10s calls, because the IPC FD is the primary FD, and the crash FD
should be grouped with the crash annotation FD.
MozReview-Commit-ID: CAVyYAIIBPm
--HG--
extra : rebase_source : 596f590443f727d1a79582202eed122f79ae85cf
Switch the order of the IPC FD argument and the crash FD argument in
e10s calls, because the IPC FD is the primary FD, and the crash FD
should be grouped with the crash annotation FD.
MozReview-Commit-ID: CAVyYAIIBPm
--HG--
extra : rebase_source : 02bf7337fa9a6d1194809c224acb4a2690fd87a3
That NDK bug has been fixed since r8c, and we now require something more
recent than that. This effectively reverts the changes from bug 720621
and bug 734832.
--HG--
extra : rebase_source : 9ff76a790ec4135dc0172cfd0f11fc1ecef7df64
BasicDllServices is a simplified implementation that allows programs other than
Firefox to link against mozglue and access DLL services without requiring any
XPCOM baggage.
To reliably detect corrupt APK, this patch adds a GeckoLoader.verifyCRC
call to enable verification of CRC before extracting libs.
MozReview-Commit-ID: 5EpIfwREGIv
This removes the need for the content process to have permissions to create new
files on macOS, allowing more aggressive sandboxing.
MozReview-Commit-ID: 8agL5jwxDSL
--HG--
extra : rebase_source : 17ebcef3e9d24f3d4e7515e3fae95e65cef76a79
MozReview-Commit-ID: 270iURVhNRu
This patch builds upon the existing DLL services functionality:
1) We add code to obtain the name of the subject from the cert used to sign a
binary (if present). This code is added inside mozglue because in the future
we will be using this code from the DLL blocklist, which is also located
there.
2) We add annotation functionality that registers itself for DLL load events
and updates crash reporter annotations as new libraries are loaded. It also
annotates any existing libraries that are also in memory at the time that the
CertAnnotator is first instantiated. This all happens off main thread, with
the exception of actually making the annotation when in a child process.
--HG--
extra : rebase_source : 2e3726d37356479aee81915caed04fe7af74c815
MozReview-Commit-ID: 270iURVhNRu
This patch builds upon the existing DLL services functionality:
1) We add code to obtain the name of the subject from the cert used to sign a
binary (if present). This code is added inside mozglue because in the future
we will be using this code from the DLL blocklist, which is also located
there.
2) We add annotation functionality that registers itself for DLL load events
and updates crash reporter annotations as new libraries are loaded. It also
annotates any existing libraries that are also in memory at the time that the
CertAnnotator is first instantiated. This all happens off main thread, with
the exception of actually making the annotation when in a child process.
--HG--
extra : rebase_source : f86c1a6fd2a44f21a71e7a7418267b3b0d5feeec
MozReview-Commit-ID: 270iURVhNRu
This patch builds upon the existing DLL services functionality:
1) We add code to obtain the name of the subject from the cert used to sign a
binary (if present). This code is added inside mozglue because in the future
we will be using this code from the DLL blocklist, which is also located
there.
2) We add annotation functionality that registers itself for DLL load events
and updates crash reporter annotations as new libraries are loaded. It also
annotates any existing libraries that are also in memory at the time that the
CertAnnotator is first instantiated. This all happens off main thread, with
the exception of actually making the annotation when in a child process.
--HG--
extra : rebase_source : e032ee8c4cf71e5225b51797443764549f4bbe56
Unified headers have a complete <elf.h> so we should include that
instead of <linux/elf.h>.
MozReview-Commit-ID: DkQv2vk1Q62
--HG--
extra : rebase_source : 7cd9eb04532c14b1dd0dc8747448b89d16e4f118
Unified headers have a complete <elf.h> so we should include that
instead of <linux/elf.h>.
MozReview-Commit-ID: DkQv2vk1Q62
--HG--
extra : rebase_source : 43b3fa15042246d2c3ec37a3ca904822b0f68d0c
It was added in bug 683127 as a forced include for nspr, and
accidentally became unused after bug 1230117, but it turns out that all
versions of Android we care about nowadays (and probably back then) now
support dladdr.
--HG--
extra : rebase_source : 024244627c215de2d35e2f4595b7612eb1723996
When looping through the debugger helper links during our
dl_iterate_phdr implementation, we effectively race with other threads
dlclose()ing libraries while we're working.
We do have a (rather involved) check in place to ensure that elf headers
are readable. But it turns out in practice, some dlclose() do happen
between the check and the actual read of the elf headers.
Unfortunately, we can't lock the system linker while we're looping, so a
better approach is to only loop through the libraries we loaded, and
rely on the system dl_iterate_phdr to iterate over the (remaining)
system libraries.
Unfortunately (again), Android versions < 5.0 don't have a system
dl_iterate_phdr, so we have to rely on the old iterator when it's not
present.
--HG--
extra : rebase_source : 3fd07589ed1939411ef72f481b7c72f761d53701
We're going to introduce two code paths that need to fill dl_phdr_info
from different iterators, so first move the code to a separate class,
that both code paths will be able to call.
--HG--
extra : rebase_source : a50663ad8d15d4f7a28d7138824003df5edd7f1c
The same exists in mozilla/MacroArgs.h, avoiding a macro redefined warning
when building on non-Android.
--HG--
extra : rebase_source : 6e3502ddf9deb96b29e3663f5867f852a2912401
Because one entry point is simpler than two, we make replace_init fulfil
both the roles of replace_init and replace_get_bridge.
Note this should be binary compatible with older replace-malloc
libraries, albeit not detecting their bridge (and with the
previous change, they do not register anyways). So loading older
replace-malloc libraries should do nothing, but not crash in awful ways.
--HG--
extra : rebase_source : aaf83e706ee34f45cfa75551a2f0998e5c5b8726
The allocator API is a moving target, and every time we change it, the
surface for replace-malloc libraries grows. This causes some build
system problems, because of the tricks in replace_malloc.mk, which
require the full list of symbols.
Considering the above and the goal of moving some of the replace-malloc
libraries into mozglue, it becomes simpler to reduce the replace-malloc
exposure to the initialization functions.
So instead of the allocator poking into replace-malloc libraries for all
the functions, we expect their replace_init function to alter the table
of allocator functions it's passed to register its own functions.
This means replace-malloc implementations now need to copy the original
table, which is not a bad thing, as it allows function calls with one
level of indirection less. It also replace_init functions to not
actually register the replace-malloc functions in some cases, which will
be useful when linking some replace-malloc libraries into mozglue.
Note this is binary compatible with previously built replace-malloc
libraries, but because those libraries wouldn't update the function
table, they would stay disabled.
--HG--
extra : rebase_source : 2518f6ebe76b4c82359e98369de6a5a8c3ca9967
These flags are only relevant on OS X, and will not be necessary soon, so this
commit moves them to a separate variable while we move the remainder of the
ldflags to mozbuild.
MozReview-Commit-ID: 1NDgz3HIYpT
--HG--
extra : rebase_source : 6e9b5f5a5be5ff916db89a0b73896b9058eb040e