This allows to use --enable-linker=lld without a conflict (because
--enable-linker=gold overrides that, contrary to --enable-gold, who
creates a conflict via imply_option).
Differential Revision: https://phabricator.services.mozilla.com/D85804
This is an alternative approach from D84307, which avoids needing an extra
script runner by avoiding needing to access `nsIBrowser` from
XULFrameElement::LoadSrc.
Differential Revision: https://phabricator.services.mozilla.com/D85446
This should make it easier to get an XPCOM interface from a JSProcessActorChild
in the current process, when combined with the do_QueryActor overloads from p2.
Differential Revision: https://phabricator.services.mozilla.com/D84069
Before this change, nsIDOMProcess{Parent,Child} could not directly be used in
do_QueryActor, as they don't directly inherit from JSActorManager.
The std::enable_if_t trickery is required in order to avoid overload issues when
passing types like ContentChild which inherit from both JSActorManager and
nsIDOMProcess{Parent,Child}.
Differential Revision: https://phabricator.services.mozilla.com/D84068
This changes the set of types which can be passed as the second argument to
do_QueryActor to ones which can be unambiguously converted to a JSActorManager,
and combines nsCOMPtr_helper implementations.
Differential Revision: https://phabricator.services.mozilla.com/D84067
Previously we would end up throwing an uncatchable exception if actor
construction failed with an exception, due to calling
NoteJSContextException(cx), and then exiting a AutoEntryScript, which will clear
the exception on the JSContext and report it.
Differential Revision: https://phabricator.services.mozilla.com/D84066
Previously these methods would crash if we ever didn't have a preserved wrapper,
such as when no module URI is specified.
Differential Revision: https://phabricator.services.mozilla.com/D84065
Much of the work that is currently done during frame building to
build clip-chain instances can actually be done during scene
building (most clips are in the same local space as the related
primitive).
This patch adds ClipSet, and does the minimal amount of refactoring
to move clip_chain_id and local_clip_rect into this structure.
Future work will move much of the current clip chain node information
to be stored inline in ClipSet that doesn't need to be recalculated
each frame build. Eventually, this functionality can be stored as
part of the primitive template, which will avoid doing this work
during scene building unless the clips have changed.
Differential Revision: https://phabricator.services.mozilla.com/D85807
In bug 1626058, I changed how the docker image digest was generated:
- I used the same directory structure to generate the digest as was used for generating the context
- I moved context generation to the decision task, and used the hash of that as part of the digest.
Unfortunately, it turns out the file name in the gzip header of the context
.tar.gz differed between when we are creating a context to write out, and when
were just generating the hash.
This adjust the name used in the gzip header to be consistent.
Differential Revision: https://phabricator.services.mozilla.com/D84753
These tests depend on the `mach uuid` command which was deleted with bug 1639509, and now that `mach uuid` is gone it's broken unconditionally. We could replace the reference to `uuid` with a new no-op `mach` command, but we're in the process of replacing our telemetry code with use of the `glean` API; and the new telemetry code won't have the same semantics (namely, we are unlikely to want to continue to guarantee that sub-`mach` invocations aren't covered by telemetry), so this test might as well just be deleted now.
Differential Revision: https://phabricator.services.mozilla.com/D85911
2020-07-27 Jan-Marek Glogowski <glogow@fbihome.de>
* lib/freebl/Makefile:
Bug 1652032 Disable all freebl assembler code for MSVC arm64
r=rrelyea,bbeurdouche
There are two places, where NSS tries to compile either x86_64 MSVC
assembler or GCC aarch64 code, which will fail the build. And also
drop the non-MSVC arch build flags for them.
AFAI could identify, there isn't any armasm64 compatible asm code in
the whole NSS library, so I don't even adapt AS for the build. The
cross-build finishes this way.
[d98bbb6168f4]
2020-07-24 Benjamin Beurdouche <bbeurdouche@mozilla.com>
* cmd/bltest/blapitest.c, coreconf/config.gypi, coreconf/config.mk,
lib/freebl/alg2268.c, lib/freebl/deprecated/alg2268.c,
lib/freebl/freebl_base.gypi, lib/freebl/ldvector.c,
lib/freebl/loader.c, lib/freebl/loader.h, lib/freebl/manifest.mn,
lib/softoken/lowpbe.c, lib/softoken/pkcs11c.c:
Bug 1652729 - Add build flag to disable RC2 and relocate to
lib/freebl/deprecated. r=kjacobs
[e6c6f1d2d544]
2020-07-27 Robert Relyea <rrelyea@redhat.com>
* gtests/softoken_gtest/manifest.mn,
gtests/softoken_gtest/softoken_dh_vectors.h,
gtests/softoken_gtest/softoken_gtest.cc,
gtests/softoken_gtest/softoken_gtest.gyp, lib/freebl/blapi.h,
lib/freebl/dh.c, lib/freebl/ldvector.c, lib/freebl/loader.c,
lib/freebl/loader.h, lib/softoken/manifest.mn,
lib/softoken/pkcs11.c, lib/softoken/pkcs11c.c,
lib/softoken/pkcs11i.h, lib/softoken/pkcs11u.c,
lib/softoken/sftkdhverify.c, lib/softoken/softoken.gyp:
Bug 1648822 Add stricter validation of DH keys when in FIPS mode.
Update: FIPS now also requires us to do y^q mod p testing on key
generation (always). We now do that in FIPS mode only, but in all
modes we do full DH verification for DH and ECDH. Because of this,
the path has now separated out the prime checks, which are now only
done for the DH operation if we aren't using a known prime and the
subprime value has been provided. I've also learned we can accept
keys that we do full validation on in FIPS mode, so I've added that
to this patch, though we still can't generate those kinds of keys
without adding the subprime at keygen time.
The new FIPS standard is dh operations must use approved primes.
Approved primes are those selected in the tls and ike RFCs.
Currently tls and ike have modes with checks whether the primes are
approved, but the check may not always happen. The safest thing to
do in FIPS mode is only allow those primes. In addition, FIPS
requires 1< y < p-1 (or technically 2<=y<=p-2, since y is an integer
those two tests are identical).
While making changes I realized we would want a mode where we can do
more strict checks on the prime while not requiring that the prime
be an approved prime. We already allow for strict checking if q is
supplied with the private key, but there were a couple of issues
with that check:
1. there was no way of actually setting q in the current NSS
pk11wrap interfaces. 2. If the prime was a safe prime, but g was an
actual generator, then we would fail the y^q mod p = 1 tests for 50%
of the keys, even though those keys are safe. 3. We weren't checking
primality of p and q.
So the old code:
if (q) { check y^q mod p = 1 if not fail }
check 1 <y < p-1 (done in DH_Derive).
New code:
if (! p is approved prime) { if (FIPS) fail; if (q) { y_test = y if
(p,q-> p is a safe prime) { y_test = 1 } check prime is prime Fail
if not check subprime is subprime fail if not y_test^q mod p = 1 } }
check 1 < y < p-1 (done in DH_Derive)
This means:
Existing code non-fips without setting the subprime continues to run
as before. Non-fips code which sets the subprime now runs slower,
but p and q are checked if p or q where not prime, the derive fails
(which it should). In FIPS mode only approved primes will succeed
now. Non-fips code can now set the subprime to q=(p-1)/2 if it
doesn't have an explicit q value (like in tls). If the derive
succeeds, we know that p is a safe prime. If p is approved, the
checks are skipped because we already know that p is a safe prime.
Code can optionally do a test derive on a new p and remember it's
safe so that we know longer need to check ever call (though if q is
not (p-1)/2, you will need to continue to do the checks each call
because y could still be a small subgroup).
This patch:
gtests/softoken_gtest
1. Added New dh tests to softoken_gtests. The tests were added to
softoken_gtests because we need to test both non-FIPS and FIPS mode.
Test vectors include a category, so the same test vectors can be
used in FIPS and non-FIPS even though each class may have different
results. Most of the test vectors where created either by dhparams
command in openssl, dsaparams in openssl, and the nss makepqg
command. Each vector includes a label, prime, base, optional
subprime, optional public key, test type, and key class (basically
size). 2. If public key is not supplied, we use a generated public
key. 3. If subPrime is supplied to wet it on the private key after
generation.
lib/freebl/dh.c
add primality tests to KEA_VerifyKey().
lib/softokn/
1. Allow CKA_SUBPRIME to be set after key generation or import.
This affects how we test for it's existance, since it is now always
there on the key, we check it's length to make sure it's non-zero.
2. We implement the psuedocode above as real code. 3. We create two
new functions: sftl_VerifyDH_Prime which return SECSuccess if Prime
is an approved prime. sftk_IsSafePrime which returns SECSuess of
both prime and subprime look reasonable, and sets a Bool to PR_TRUE
is subprime -> prime is safe (subprime = (prime-1)/2. These
functions are implemented in sftkdhverify.c 4.Cleanup incorrect
nominclature on primes (safe primes are not strong primes).
[0be91fa2217a]
* gtests/softoken_gtest/softoken_dh_vectors.h,
gtests/softoken_gtest/softoken_gtest.cc:
Fix more of the timeout issues on tests. (Drop expensive 4098 dh
tests ).
[4014c075a31b]
2020-07-29 Makoto Kato <m_kato@ga2.so-net.ne.jp>
* coreconf/config.gypi, lib/freebl/Makefile, lib/freebl/blinit.c,
lib/freebl/freebl.gyp, lib/freebl/sha1-armv8.c,
lib/freebl/sha_fast.c, lib/freebl/sha_fast.h:
Bug 1650702 - Use ARM's crypt extension for SHA1. r=kjacobs
ARM Crypto extension has SHA1 acceleration. Using this, SHA1 is 3
times faster on ARMv8 CPU. The following data is AWS's a1 instance
(Cortex-A72).
Before ====== ``` # mode in opreps cxreps context op time(sec)
thrgput sha1_e 954Mb 31M 0 0.000 10000.000 10.000 95Mb ```
After ===== ``` # mode in opreps cxreps context op time(sec) thrgput
sha1_e 2Gb 94M 0 0.000 10000.000 10.000 288Mb ```
[68b6eb737689]
2020-07-29 Jan-Marek Glogowski <glogow@fbihome.de>
* manifest.mn:
Bug 1653975 - Set "all" as the default Makefile target r=jcj,rrelyea
Just reorder the rules in manifest.mn, so all is again the first
rule. This restores pre-3.53 Makefile defaults.
[eb52747b7000]
2020-07-31 Makoto Kato <m_kato@ga2.so-net.ne.jp>
* lib/freebl/blapii.h, lib/freebl/blinit.c, nss-tool/hw-support.c:
Bug 1654142 - Add CPU feature detection for Intel SHA extension.
r=kjacobs
[e6b77a9c417a]
2020-08-03 Nathan Froyd <froydnj@mozilla.com>
* coreconf/detect_host_arch.py:
Bug 1656986 - special-case arm64 in detect_host_arch.py; r=jcj
This case comes up when attempting to build NSS on ARM64 Mac. If we
don't do this, we wind up detecting arm64 as "arm", with predictably
bad consequences.
[afa38fb2f0b5] [tip]
Differential Revision: https://phabricator.services.mozilla.com/D85888
The COOP header is set to BrowsingContext only in Document::StartDocumentLoad.
If the replaced document has a different COOP header from one in its docshell.
Then, we can crash while creating a window global child for a new inner window.
Differential Revision: https://phabricator.services.mozilla.com/D85127
Cranelift PR2077 adds support for Wasm Atomics via the newBE/AArch64
pipeline. This requires a few changes on the SM side:
* a change to compiler gating logic, allowing CL on AArch64 to support threads/atomics
* translation of WaitI32/WaitI64/Notify requests into the relevant SM-side
instance calls
- three more BD_SymbolicAddress:: values
- a binding for CL's HeapMisaligned trap code, which is new
- in wasm2clif.rs, a new error-reporting mode: IsNegative32, and handling thereof
- in wasm2clif.rs, translation of wait_i32/wait_i64/notify to instance calls
Differential Revision: https://phabricator.services.mozilla.com/D85760
Before this patch, we used a clumsy "GetNextPage" helper-function (which,
despite its name, actually gets the next page **content** frame). It worked by
pointer-chasing to get the parent's next-sibling's first-child. This is
unnecessary; we can just directly query for the nsPageContentFrame's
next-continuation, since these frames are linked in a straightforward
continuation chain.
Note that GetNextContinuation() is a virtual function-call, but it may still be
faster than the pointer-chasing that we were doing with the GetNextPage()
API. Moreover, we can help the compiler devirtualize it by static_cast'ing to
the concrete type before calling the method. This is safe since nsPageFrame
always contains a single nsPageContentFrame (which we already validate -- at
least the frame-type-part -- via assertions).
Differential Revision: https://phabricator.services.mozilla.com/D85802
When the macOS osclientcerts backend looks for issuer certificates, it can
result in network I/O unless it is specifically disabled. The Windows backend
already handles this, so this only applies to macOS.
Differential Revision: https://phabricator.services.mozilla.com/D85799
Otherwise when we try to call Deactivate on the direct manipulation manager (to balance the Activate call) we won't have the HWND pointer and so it won't balance and we will leak.
We call DestroyDirectManipulation in nsWindow::Destroy but it looks like nsWindow::OnDestroy can be called before nsWindow::Destroy.
Differential Revision: https://phabricator.services.mozilla.com/D85835
Pathological regexps can overflow the stack just from recursively walking the AST during compilation. One way to avoid this is by checking the AST ahead of time to make sure it is not too deep. This occurs on 32-bit and in some configurations on 64-bit.
The visitor API for RegExpTree is sad and full of `void*` spiders, but I don't think it's worth upstreaming a patch to make it nicer.
Note that this is not a complete fix. If the stack is already close to overflowing, then even a relatively shallow regexp might overflow. However:
1. While the code that walks the AST doesn't check for stack overflow, the parser code that creates the AST does. The parser does not recurse as deeply, which is why we can end up in this situation, but many overflow cases will fail cleanly during parsing instead of crashing while walking the AST.
2. This is becoming a fuzzblocker on arm64 (see bug 1655404), so even a partial fix is better than none.
Differential Revision: https://phabricator.services.mozilla.com/D79182
