The current situation is suboptimal, where we have the same goop
repeated in multiple files, and where things kinda sorta work out fine
thanks to the linker for files that would have been forbidden, except
when the linker doesn't do its job, which apparently happen on
mingwclang builds.
This change only really covers C++ code using operator new/delete, and
not things that would be using malloc/free, because it's easier.
malloc/free is left for a followup.
Differential Revision: https://phabricator.services.mozilla.com/D32119
--HG--
extra : moz-landing-system : lando
* CreateFileW will return INVALID_HANDLE_VALUE (-1) on failure, not NULL (0).
* MapViewOfFile will map the entire section if the size is 0. No explicit size
is required.
* If SEC_IMAGE is specified, the mapped image size may be different from the
file size on the storage.
Differential Revision: https://phabricator.services.mozilla.com/D32563
--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
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
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
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
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
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
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
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 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 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 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
Mike Hommey
Masatoshi Kimura
Mihai Alexandru Michis
Aaron Klotz
David Parks
Sylvestre Ledru
Dorel Luca
Nathan Froyd
Karl Tomlinson
Carl Corcoran
Ryan Hunt
Gerald Squelart
Markus Stange
Eric Rahm
Ehsan Akhgari
David Major
Coroiu Cristina
shindli
Tom Tromey
Tooru Fujisawa
Benjamin Bouvier
Honza Bambas
Bogdan Tara
Andreea Pavel
Brindusan Cristian