The public key pinning implementation is much less complex than the HSTS
implementation, and only needs a small subset of the parameters of the latter.
Furthermore, the information it relies on is static, and so is safe to access
from content processes. This patch separates the two implementations, thus
simplifying both of them and avoiding some unnecessary IPC calls in the
process.
Differential Revision: https://phabricator.services.mozilla.com/D117096
This patch converts the pinning preference
"security.cert_pinning.enforcement_level" to be static. It also removes some
unused pinning preferences and parameters.
Differential Revision: https://phabricator.services.mozilla.com/D117095
This patch adds a new field to the structures that WER reads from a
crashed process. This field contains a pointer to the global variable
that records the size of the last failed annotation.
When WER intercepts a crash it will use this address to read the
variable. If it's not zero it will add the corresponding annotation
to the crash report.
Depends on D116449
Differential Revision: https://phabricator.services.mozilla.com/D116450
Since this added the new flag to the crash ping I also took the time to update
the crash ping documentation with all the flags that have been added and
removed over the last few versions of Firefox.
Depends on D115380
Differential Revision: https://phabricator.services.mozilla.com/D116017
This also notifies the main process after the minidump has been generated.
I refactored the code a bit so the patch is probably larger than it should be
but the code should be a bit more readable overall.
With this change the minidump generation flow works like this:
- When the callback gets invoked in the WER process we read the structure that
is stored in every process' to figure out if it's the main process or a child
one. This is done by reading said process' memory, the pointer has been
passed to the runtime exception module when it was registered.
- If the main process crashed everything works like it used to.
- If it was a child process then we first capture a minidump of it.
- Then we read the structure representing it in the main process:
WindowsErrorReportingData. The address of this structure was passed into the
child process' command-line so we need to parse that first, then we read it
from the main process memory.
- We fill the structure and write it back into the main process memory.
- At this point if everything went fine we create a new thread in the main
process just to execute the WerNotifyProc function that will inform the main
process to the presence of the new minidump.
There's one important tidbit that's worth keeping in mind: the synchronization
between the main process and the WER process is implicit. The
WindowsErrorReportingData structure in the main process is kept alive until the
child process dies, the main process will destroy it only after that point. As
long as we're in the runtime exception module the crashed process is kept alive
so this will prevent the main process from touching that structure.
We explicitly terminate the crashed process **after** we're done with the
structure so nothing bad could happen... unless someone makes a change to
Gecko that breaks the previous assumption.
Another important thing to keep in mind: we wait for the newly created thread
to inform the main process but only for 5 seconds. We don't want to wait
indefinitely because the function that we're calling is taking a lock and if
it blocks for some reason WER will get stuck waiting for it, so it will never
kill the crashed process which in turn will prevent the main process from
moving ahead. In principle this should never happen but better be safe than
sorry.
Depends on D115379
Differential Revision: https://phabricator.services.mozilla.com/D115380
This patch sets up a few different things that will be used by the WER runtime
exception module when it needs to notify the main process of a child process
crash.
For every child process we allocate a structure in the main process called
WindowsErrorReportingData that contains three things:
- The address of the function used to notify the main process that there's a
pending minidump for a given child process
- The PID of said child process
- The name of the minidump that has been generated
The first field is filled up by the main process and will be read by the WER
process when running the runtime exception module, the second and third fields
on the other hand start empty and will be written into by the runtime exception
module after it has generated a minidump.
I know this sounds scary. It is. But bear with me please.
When we register the runtime exception module we can pass it a single
pointer-sized parameter but we need to pass it at least another pointer that
includes data coming from the child process itself (this one is called
InProcessWindowsErrorReportingData). This data currently includes only the
process type but will also include certain annotations in the future
(e.g. bug 1711418). So here's what we do: we store a pointer to the parent
data structure in the child process command-line (cringe) and we read it
from the runtime exception module by reading the crashed process command-line
arguments and parsing them (double-cringe).
Armed with this information the WER runtime exception module can populate
the info for the generated minidump and then push it into the main process
by calling CreateRemoteThread() (which creates a new thread in the main
process, triple-cringe at this point).
Differential Revision: https://phabricator.services.mozilla.com/D115379
We should stop using StorageActor.listStores in favor of ResourceCommand.
listStores still forces to involve message manager in the server codebase.
This breaks when we enable JSWindowActor based targets.
Differential Revision: https://phabricator.services.mozilla.com/D116481
This test is not relevant in fission as we aren't using listStores,
nor do we have any EXTENSION_STORAGE resource to test yet.
Differential Revision: https://phabricator.services.mozilla.com/D116483
We should stop using StorageActor.listStores in favor of ResourceCommand.
listStores still forces to involve message manager in the server codebase.
This breaks when we enable JSWindowActor based targets.
Differential Revision: https://phabricator.services.mozilla.com/D116482
We should stop using StorageActor.listStores in favor of ResourceCommand.
listStores still forces to involve message manager in the server codebase.
This breaks when we enable JSWindowActor based targets.
Differential Revision: https://phabricator.services.mozilla.com/D116480
We should stop using StorageActor.listStores in favor of ResourceCommand.
listStores still forces to involve message manager in the server codebase.
This breaks when we enable JSWindowActor based targets.
Differential Revision: https://phabricator.services.mozilla.com/D116479
This patch adds the following tasks to both autoland and central:
> test-linux1804-64-tsan/opt-mochitest-plain-fis-e10s
Note this has 20+ chunks so is not insignificant.
Differential Revision: https://phabricator.services.mozilla.com/D117343
One could optimize out MarkWrapperLive call if stored that wrapper is already live etc, but
in practice that shouldn't matter too much.
Differential Revision: https://phabricator.services.mozilla.com/D117456
`./mach vendor python <package>` was already adding its new package
to `requirements.txt`, so we were getting full resolver support, which
is good. However, it caused our `requirements.in` file to start
getting out-of-date, and therefore made it harder to identify the
top-level dependencies.
Arguably, we could have `./mach vendor python <package>` automatically
update `requirements.in`, too, but then we need to solve the edge cases,
such as "What if the package is already in `requirements.in`? What if
that existing item has a different version?"
The hardest part of updating `requirements.in` was finding it, so I've
also modified the `./mach vendor python` help text to make it more
identifiable.
Differential Revision: https://phabricator.services.mozilla.com/D116386
Replace the assumptions that are Firefox-specific with arguments so that
backstop builds can be used for Thunderbird CI. Specifically, the backstop
index path and integration projects need changing.
Differential Revision: https://phabricator.services.mozilla.com/D117170
Move the wasm::Frame family of types to their own
header and implementation. Switch consumers of headers
away from WasmTypes.h when they only need Frame/TlsData.
Depends on D117045
Differential Revision: https://phabricator.services.mozilla.com/D117046
Factor out TlsData declarations and definitions to
their own header and definition. This will allow
factoring out Frame, FrameWithTls, and DebugFrame
from WasmTypes.h next.
Depends on D117044
Differential Revision: https://phabricator.services.mozilla.com/D117045
Eitan Isaacson
Andrew McCreight
Iulian Moraru
Jeff Gilbert
Olli Pettay
Dana Keeler
Gabriele Svelto
Jeff Muizelaar
Alexandre Poirot
Caroline Cullen
Ed Lee
Sandor Molnar
Sam Foster
Andrew Halberstadt
Greg Tatum
owlishDeveloper
surajeet310
Mitchell Hentges
Joel Maher
Neil Deakin
Mark Banner
Rob Lemley
Ryan Hunt