Starting with Windows 11 22H2, Microsoft has made internal changes in
msctf.dll. The TF_Notify function, also known as CtfImmNotify from
imm32.dll, uses a new convention for its third argument. These changes
are incompatible with current versions of ZoneAlarm Anti-Keylogger,
resulting in crashes in our main process.
This patch converts messages forwarded by ZoneAlarm Anti-Keylogger to
the new convention. If we detect the product and an incompatible version
of msctf.dll, then we hook TF_Notify and detect any message using the
old convention, and convert it to the new convention.
Differential Revision: https://phabricator.services.mozilla.com/D189518
Arbitrary capability names weren't allowed until clang 11, and while we
could probably make things somehow work with earlier versions of clang,
it's not that interesting, as long as we keep the thread safety analysis
running with newer versions of clang on our CI (which we obviously do).
Differential Revision: https://phabricator.services.mozilla.com/D188791
* DefaultHasher<T*> used HashGeneric<size_t>
* nsPtrHashKey<T> used HashGeneric<T*>
* nsRefPtrHashKey<T> used NS_PTR_TO_UINT32 >> 2
Make sure to always use HashGeneric<T*> for these.
Remove unused / redundant hash keys.
Differential Revision: https://phabricator.services.mozilla.com/D186553
In bug 1839743, we made the build system prefer packed relative
relocations to elfhack when both the system libc and linker support
them. Unfortunately, while that covers most of the benefits from
elfhack, it doesn't cover bug 651892.
To cover it, we make every C++ executable contain its own copy of
the symbol, so that all relocations related to it become relative.
And because this is actually (slightly) beneficial on macos, and because
it's also an advantage to have our own abort called rather than the
system's, we apply the same to all platforms.
Differential Revision: https://phabricator.services.mozilla.com/D184068
In bug 1839743, we made the build system prefer packed relative
relocations to elfhack when both the system libc and linker support
them. Unfortunately, while that covers most of the benefits from
elfhack, it doesn't cover bug 651892.
To cover it, we make every C++ executable contain its own copy of
the symbol, so that all relocations related to it become relative.
And because this is actually (slightly) beneficial on macos, and because
it's also an advantage to have our own abort called rather than the
system's, we apply the same to all platforms.
Differential Revision: https://phabricator.services.mozilla.com/D184068
All event targets should be threadsafe and implemented in C++, and so should be
able to be used in `Sync` types in Rust code.
This also required annotating all interfaces deriving from `nsIEventTarget`, as
well as adding some associated constants to specific types to indicate to the
static assertion that they have threadsafe reference counts.
Differential Revision: https://phabricator.services.mozilla.com/D183592
All event targets should be threadsafe and implemented in C++, and so should be
able to be used in `Sync` types in Rust code.
This also required annotating all interfaces deriving from `nsIEventTarget`, as
well as adding some associated constants to specific types to indicate to the
static assertion that they have threadsafe reference counts.
Differential Revision: https://phabricator.services.mozilla.com/D183592
Replace the existing callers of `JS::NewArrayBufferWithContents` with the new
`UniquePtr` alternative.
Three callers to the old `JS::NewArrayBufferWithContents` function were left
unchanged:
- `mozilla::dom::FileReader::OnLoadEndArrayBuffer()` and
`mozilla::dom::ArrayBufferBuilder::TakeArrayBuffer()` both store the data
buffer as members and therefore have a more complicated lifetime.
- `JSStructuredCloneReader::readTransferMap()` because it's not clear if the
data can be free'ed when `ArrayBuffectObject` allocation fails.
Differential Revision: https://phabricator.services.mozilla.com/D182588
Replace the existing callers of `JS::NewArrayBufferWithContents` with the new
`UniquePtr` alternative.
Three callers to the old `JS::NewArrayBufferWithContents` function were left
unchanged:
- `mozilla::dom::FileReader::OnLoadEndArrayBuffer()` and
`mozilla::dom::ArrayBufferBuilder::TakeArrayBuffer()` both store the data
buffer as members and therefore have a more complicated lifetime.
- `JSStructuredCloneReader::readTransferMap()` because it's not clear if the
data can be free'ed when `ArrayBuffectObject` allocation fails.
Differential Revision: https://phabricator.services.mozilla.com/D182588
Replace the existing callers of `JS::NewArrayBufferWithContents` with the new
`UniquePtr` alternative.
Three callers to the old `JS::NewArrayBufferWithContents` function were left
unchanged:
- `mozilla::dom::FileReader::OnLoadEndArrayBuffer()` and
`mozilla::dom::ArrayBufferBuilder::TakeArrayBuffer()` both store the data
buffer as members and therefore have a more complicated lifetime.
- `JSStructuredCloneReader::readTransferMap()` because it's not clear if the
data can be free'ed when `ArrayBuffectObject` allocation fails.
Differential Revision: https://phabricator.services.mozilla.com/D182588
* Add validation for requested features and devices for
adapter.requestDevice().
* Promote webgl's AutoAssertCast to mfbt/Casting.h/LazyAssertedCast.
Differential Revision: https://phabricator.services.mozilla.com/D177110
* Add validation for requested features and devices for
adapter.requestDevice().
* Promote webgl's AutoAssertCast to mfbt/Casting.h/LazyAssertedCast.
Differential Revision: https://phabricator.services.mozilla.com/D177110
clang is warning that C++20 expects comparison operators to be commutative: `a == b` and `b == a` should resolve to the same comparison operator function. Warnings about the comparison of const and non-const objects can be fixed by making the comparison operator function const.
mfbt/tests/TestDoublyLinkedList.cpp:158:36 [-Wambiguous-reversed-operator] ISO C++20 considers use of overloaded operator '==' (with operand types 'SomeClass' and 'SomeClass') to be ambiguous despite there being a unique best viable function
mfbt/tests/TestDoublyLinkedList.cpp:159:38 [-Wambiguous-reversed-operator] ISO C++20 considers use of overloaded operator '==' (with operand types 'SomeClass' and 'SomeClass') to be ambiguous despite there being a unique best viable function
Depends on D179022
Differential Revision: https://phabricator.services.mozilla.com/D179023
In bug 1788004, we started hooking BCryptGenRandom on the machines where
calling it for the first time fails. This was useful to mitigate Rust
panics linked to RNG function failures in the Rust stdlib and
in the getrandom crate. Both now have proper fallbacks again, so we can
remove our hook.
Differential Revision: https://phabricator.services.mozilla.com/D174966
Some implementations from TemplateLib are easily changeable with std functionality.
mozilla::tl::And has been removed and replaced with std::conjuction
Differential Revision: https://phabricator.services.mozilla.com/D175762
Since we cannot move away from mozilla::IsNegative to std::signbit because the
first one doesn't accept a NaN we should transform our function to use std implementation.
Differential Revision: https://phabricator.services.mozilla.com/D173111
This is used where the hash table operation can fail early if we know there's
never been a hash code created for a lookup. If there has been a hash code
created, it's more efficient to return it though as otherwise we will always
query it straight away.
Therefore this renames |hasHash| to |maybeGetHash| and adds an output
parameter.
Differential Revision: https://phabricator.services.mozilla.com/D173122
Since we cannot move away from mozilla::IsNegative to std::signbit because the
first one doesn't accept a NaN we should transform our function to use std implementation.
Differential Revision: https://phabricator.services.mozilla.com/D173111
This does a few minor improvements:
1. Adds implicit conversions from NotNull to a raw pointer type if supported by
the underlying type, to make it so NotNull<RefPtr<T>> acts more like
RefPtr<T> in some situations.
2. Adds explicit conversion constructors and assignment operators for RefPtr
and nsCOMPtr from NotNull, avoiding conversion ambiguity added by the first
change.
3. Disable conversion constructors on NotNull with SFINAE if they should not be
available, meaning that type traits like std::is_convertible_v interact with
it properly.
Differential Revision: https://phabricator.services.mozilla.com/D168883
This does a few minor improvements:
1. Adds implicit conversions from NotNull to a raw pointer type if supported by
the underlying type, to make it so NotNull<RefPtr<T>> acts more like
RefPtr<T> in some situations.
2. Adds explicit conversion constructors and assignment operators for RefPtr
and nsCOMPtr from NotNull, avoiding conversion ambiguity added by the first
change.
3. Disable conversion constructors on NotNull with SFINAE if they should not be
available, meaning that type traits like std::is_convertible_v interact with
it properly.
Differential Revision: https://phabricator.services.mozilla.com/D168883
We define a new MOZ_HAVE_NO_STACK_PROTECTOR modifier attribute. It is
mapped to __attribute__((no_stack_protector)) and specifies that a given
function should *NOT* be instrumented to detect stack buffer overflows
at runtime.
Differential Revision: https://phabricator.services.mozilla.com/D171361
BCryptGenRandom can be broken, but the Rust stdlib and the getrandom
crate rely on it, and this is a source of crashes which are Rust
panics. This happens the most on Windows 7 after bcryptprimitives.dll
fails to load (see bug 1788004).
To mitigate these crashes, we hook BCryptGenRandom if we detect that it
is broken, and install a fallback based on RtlGenRandom. We only protect
calls that use BCRYPT_USE_SYSTEM_PREFERRED_RNG; so code that relies on
using BCryptOpenAlgorithmProvider and doesn't have its own fallback can
still fail.
We will hopefully remove this hook when the Rust stdlib and the
getrandom crate both have their own RtlGenRandom-based fallback.
Differential Revision: https://phabricator.services.mozilla.com/D170662
BCryptGenRandom can be broken, but the Rust stdlib and the getrandom
crate rely on it, and this is a source of crashes which are Rust
panics. This happens the most on Windows 7 after bcryptprimitives.dll
fails to load (see bug 1788004).
To mitigate these crashes, we hook BCryptGenRandom if we detect that it
is broken, and install a fallback based on RtlGenRandom. We only protect
calls that use BCRYPT_USE_SYSTEM_PREFERRED_RNG; so code that relies on
using BCryptOpenAlgorithmProvider and doesn't have its own fallback can
still fail.
We will hopefully remove this hook when the Rust stdlib and the
getrandom crate both have their own RtlGenRandom-based fallback.
Differential Revision: https://phabricator.services.mozilla.com/D170662
Yannis Juglaret
Jan Varga
Nika Layzell
Mike Hommey
Masatoshi Kimura
Emilio Cobos Álvarez
Steve Fink
Noemi Erli
Ryan VanderMeulen
serge-sans-paille
Markus Stange
Tyson Smith
Paul Adenot
André Bargull
Sandor Molnar
Cristina Horotan
Jesse Schwartzentruber
Kelsey Gilbert
Stanca Serban
Nicolas B. Pierron
Gabriele Svelto
Chris Peterson
Cosmin Sabou
Narcis Beleuzu
Dana Keeler
Tooru Fujisawa
Andi-Bogdan Postelnicu
Sylvestre Ledru
Iulian Moraru
Jon Coppeard
Jason Kratzer
Christian Holler (:decoder)
Paul Bone
Marian-Vasile Laza
Andi-Bogdan Postelnicu
Norisz Fay