This doesn't remove the old ones yet as we'll need a corresponding
downstream change. This does all of them but Soong. I think, for Soong,
we can apply the change unilaterally in the source list, but I'm holding
off on testing that until I've gotten Android updated to a more recent
BoringSSL.
Bug: 542
Change-Id: I30921ac251f76e3ecb50df9ff757fec4031e7dbc
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61528
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Update-Note: I believe all GN and Bazel consumers have been migrated to
the new style of asm source list, so this change should be a no-op. If
any remain that still need the old ones, either migrate them to
crypto_sources_asm and crypto_sources_nasm, or let us know.
Bug: 542
Change-Id: I57052331ae56a081117b1a2df31f828943a6d13b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61527
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
BoringSSL cannot support any build configurations where a platform
claims to be something but is not. Different embedded targets need their
own define.
Bug: b:291102972
Change-Id: I91db6ddd823b0d8b7b52580f7a6c498e55da6b79
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61605
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
GCC does not have __has_feature, so writing #if __has_feature(foo),
without a guard, will cause GCC to error. This is tripping the gRPC
update.
Prior to https://boringssl-review.googlesource.com/c/boringssl/+/60765,
this worked because the preamble to every assembly file would define the
missing __has_feature macro as part of detecting MSan. Now we pick up
the logic in <openssl/base.h>, which tries not to stomp over symbols we
don't own. This had the side effect of removing the __has_feature
polyfill.
Though "public", <openssl/asm_base.h> is not really a public header, so
we could put the __has_feature polyfill in there. But we already have a
pattern for detecting sanitizers in <openssl/target.h>, so just switch
to that one.
Change-Id: I747b4513f1b2f189d2df629149f22fd0fa490257
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61565
Commit-Queue: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Due to b/290792019 and b/290785937, we need them to actually exist at
the original symbols. For all of Rust's language-level safety benefits,
the ecosystem seems determined to undo it with patterns that are even
less safe than C.
This is not great and the bugs need to be fixed, but do this for now to
unblock the Android update.
Change-Id: Ia883336879779f652e7320cecdd5ca843996f6a3
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61525
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
file_test_gtest.cc depends on GetTestData which, for now, only exists in
crypto_test because of how the crypto_test_data machinery works. Ideally
that would be fixed but, for now, move the file out of test_support.
Things were previously building because we were relying on the static
linker to drop the file in the other targets, before the linker would
notice the undefined symbol. I'm not sure what's different about
Chromium, but somehow Chromium is sensitive to this.
Bug: 542
Change-Id: I38c7719e7c3f27bcfeeab9693fcd43fbd0300799
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61526
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Add a rand_extra file for trusty, bump the BORINGSSL_API_VERION
and mark both trusty and windows as non-forking so we do not
require fork detection support.
Update-Note:
Prior to API version 24, Trusty maintained their own CRYPTO_sysrand
implementations outside of the BoringSSL tree. With this change
they are not expected to provide CRYPTO_sysrand, it is maintained
inside the BoringSSL tree.
Change-Id: Iabcef024ff85bd767e2869a6ff27a64236322325
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61465
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
This replaces our dynamically creating singleton EC_GROUPs from curve
data with static EC_GROUP instances.
They're just shy of being fully static because delocate still forces us
go to through CRYPTO_once to initialize structures with pointers.
(Though, without delocate, the loader would need similar initialization
via a runtime relocation.)
This means we can now have functions like EC_group_p256(), analogous to
EVP_sha256(). These are infallible functions that return const EC_GROUP
pointers. Although there is an initial 2KiB hit to binary size (now we
precompute a few more Montgomery values), I'm hoping it'll eventually
help binaries that only use a few of the curves to drop the others. Also
it removes some locks used to initialize the static curve objects, as
well as removing an annoying error condition.
Bug: 20
Change-Id: Id051c5439f2b2fe2b09bf10964d656503ee27d9e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/60931
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This was, I assume, needed for cross-version tests, but we're long past
2020 now. While I'm here, switch a unique_ptr(new T) into make_unique as
we can rely on C++14 now.
Change-Id: I3f2fde90f124522c21868c15217f607b7f6d75db
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61428
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
They end up in uint64_t frequently right now just because the CBS APIs
use uint64_t, but we don't actually accept that large of an iteration
count.
Also use uint32_t instead of unsigned. This type should be sized based
on how large of an iteration count we think is reasonable, not something
platform-dependent.
Bug: 516
Change-Id: Ie5ff379af6bc65c5e4d25f4d10774bd819f08a50
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61426
Commit-Queue: David Benjamin <davidben@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
This allows operating systems to insist on IBT
enforcement as an exploit mitigation mechanism without
needing to make an exception for anything using a
bundled boringssl, such as chrome, mono, and qtwebengine.
Change-Id: Iac28dd3d2af177b89ffde10ae97bce23739feb94
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/60625
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Instead, rely on internal.h to either include the header or polyfill it.
On Windows, we don't (yet) require C11, so we can't rely on the header
being directly includable. Though given it took a couple months to
notice this, it's clear the non-C11 path is pretty much untested, so we
need to get rid of it.
Bug: 624
Change-Id: I86a6961c93161c3adfacd374affb8bfb2be0a542
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61445
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
This changes the order of things so that by default your
system is expected to provide us with a getentropy() in
<unistd.h> for integrators that are not explicitly
supported.
We preserve the getrandom/urandom dance for Linux and Android
for now.
Linux has had getentropy() in libc's since 2017
macOS, and all the BSD's have had it for any versions we
care about.
iOS hides it from us - so we use CommonCrypto CCRandomGenerateBytes
Update-Note: Non-macOS Apple platforms now use CCRandomGenerateBytes
instead of /dev/urandom. Linux behavior remains unchanged. Platforms
which were not explicitly supported with a different codepath will also
switch from /dev/urandom to getentropy. If your platform specifically
requires /dev/urandom, let us know.know
Bug: 287
Change-Id: I0c2b8c594c473e4395379f50b0c4e6713c0a4c02
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61325
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
As part of this, align the generated and standalone builds in how
crypto/test/gtest_main.cc is added. Since not all test targets
(urandom_test) include gtest_main.cc, and the generated one just
manually adds it to the file lists, just put it into the file lists
ahead of time. That way we don't need to synchronize the dependency
information with the generated build.
This also aligns the generated build with
https://boringssl-review.googlesource.com/c/boringssl/+/56567 to put
files like crypto/test/abi_test.cc and crypto/test/file_test_gtest.cc in
the test_support library.
Update-Note: If something odd happens with the test_support library in
downstream builds, this CL is probably to blame.
Bug: 542
Change-Id: I235e0ccd0432f4b380a92b265ede35eb8a6a6e36
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61288
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
CMake and the generate builds now broadly share a source of truth for
the test files.
Update-Note: In the standalone CMake build, build/crypto/crypto_test is
now build/crypto_test, etc. For now, the build still copies the outputs
to the subdirectories (it's cheap and avoids some workflow turbulence),
but I'm thinking we keep that for six months or so and then remove it.
Bug: 542
Change-Id: I8f97e1fcedea1375d48567dfd2da01a6e66ec4e8
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61286
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
One less value to initialize statically. Also this simplifies EC_GROUP
initialization. While I'm here, reorder EC_GROUP to pad better.
This lets us simplify the init bits slightly. It does mean p224-64.c,
the one EC_GROUP that doesn't use Montgomery reduction, carries around a
wasted Montgomery context, but it'll make generating the tables
statically much easier. Also once the data is pre-generated, the cost is
minimal.
Bug: 20
Change-Id: Ib66e655ce5a0902ab3ed6695fcbb46aa87683885
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/60928
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This reverts commit 28e4a1b838. Bazel
broke --cxxopt on Windows in
https://github.com/bazelbuild/bazel/issues/15073, which means projects
enabling, say, C++20 with --cxxopt=/std:c++20 are silently passing
/std:c++20 to our C files.
This is already a problem, but MSVC is smart enough to silently ignore
the flag when building C. However, MSVC will report an error if you then
pass /std:c++20 /std:c11 into the same command. It seems that check is
not aware of this ignoring behavior.
Ultimately, this is a Bazel bug, and one that makes the broken versions
of Bazel unsuitable for use with C. This was fixed in Bazel in
https://github.com/bazelbuild/bazel/pull/18119 and backported to the
upcoming Bazel 6.3.0 release in
https://github.com/bazelbuild/bazel/pull/18552
Temporarily revert the change. When Bazel 6.3.0 is released, we'll put
this back and require Windows users use a functioning version of Bazel.
Bug: 624
Fixed: 623
Change-Id: I68d9b2ed8751b4cf5dc7f42f8c1fbd42a97d6ca2
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61365
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This removes a place where we make hard-coded assumes about test names.
Also it shards pki_test, as that test suite is large enough to benefit
from it.
Change-Id: I392254b73a2df2f022ccf13508552372c103bff7
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61285
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
This achieves much of the same goals as
https://boringssl-review.googlesource.com/c/boringssl/+/61245, but
reuses the existing source.cmake parser in generate_build_files.py.
There are two practical differences here:
First, CMake knows that, if it sees include(sources.cmake), it should
add sources.cmake as a dependency of build.ninja, and re-run cmake if
source.cmake changes. It does not know this for file(STRINGS). This can
be fixed with CMAKE_CONFIGURE_DEPENDS, but since we already have this,
may as well use it.
Second, sources.cmake wants paths rooted at the top-level BoringSSL
source directory, which means we want to define the targets at the top
level, rather than in subdirectories. While it will make the top-level
CMakeLists.txt larger, I think this is a good move:
- ./build/crypto_test --gtest_filter=... is just less annoying to type
than ./build/crypto/crypto_test --gtest_filter=...
- It will (eventually) mean libcrypto.a lives at build/libcrypto.a
instead of build/crypto/libcrypto.a. This means we can pass a single
-L parameter when building things against BoringSSL, without relying
on the install target.
- It aligns with the generated CMake build. I would like, long-term, to
stop maintaining multiple CMake builds, and the generated one seems to
have a better convention. And one that will be more disruptive to
others if we change it.
- Top-level-rooted paths are more convenient for generate_build_files.py
to work with, because that's what we want to output.
As I get further along in 542, I expect I'll move this once again,
possibly to some JSON file, because I'll need my new pregenerate tool to
parse it (and we'll no longer be constrained by what's easy to consume
in CMake), but use this for now.
Bug: 542
Change-Id: I1e8b894057264da5d7624a1fbb92f9e1198ea38e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61266
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
This will make it easier to support other build systems rather
than relying on names of files matching a special pattern to
mean a special thing.
Bug: 1322914
Change-Id: I3d1df70e79934717275c0c331e7e5cd3cc5c99e5
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61245
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Auto-Submit: Bob Beck <bbe@google.com>
While we are at it, add a fillins/log.h and modify import_spec.json
to remove the need for patching out LOG and DVLOG (which removes
one more patch in the patch stack
Change-Id: I3b7b512490ee0e8c465734b2236b31da7d132ec7
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61225
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Adam Langley <agl@google.com>
We require MSVC 2019 now, which has a /std:c11 flag. Enable it to match
the CMake build and remove a blocker for requiring C11 unconditionally.
(This select branch is also used by clang-cl. I had meant to figure out
the @bazel_tools business as part of this, but it turns out clang-cl
works better with the MSVC flags than the GCC ones anyway. -Wall in
clang-cl is like MSVC's /Wall and actually means all warnings. Ideally
we'd still condition this on the compiler, in case anyone uses MinGW,
but we can figure that out later.)
Tested with bazelisk build :all and
bazelisk build --compiler=clang-cl :all on Windows.
Change-Id: I4559789a221071eef39f9d34929f0e9c5994119e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61127
Commit-Queue: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
While I'm here, update x/crypto and x/net to their latest versions.
byteReader is a straightforward port, except there doesn't seem to be a
convenient way to read length-prefixed bytes without manually casting
from cryptobyte.String to []byte, so I've done that.
byteBuilder is a bit more involved because it's based on closures, but
still a mechanical change.
As part of this, I switched runner's ticket format to use u24 length
prefixes instead of u32, because cryptobyte.String doesn't have u32
length prefixes. (Although, oddly, cryptobyte.Builder does.)
Fixed: 374
Change-Id: If9bea0b41fe2b8bc48f040a667753b160da469bb
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61186
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
This is breaking the oss-fuzz build. Changes made:
- No need make a subproject, I think. In particular, keep the minimum
CMake versions matching.
- Let's not include it in install just yet, since it's still
experimental.
- I removed the comment about public headers. The target doesn't
actually provide any public headers for the moment.
- Apparently the "modern CMake" way to set properties is per-target
rather than using the directory-wide options, so I've switched to
that.
Bug: oss-fuzz:60049
Change-Id: I511667ca8e83cb1997f82b329ed38f980574305e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61126
Reviewed-by: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
OPENSSL_WINDOWS doesn't *quite* imply that crypto/rand_extra/windows.c
is used, thanks to fuzzer mode.
The sea of ifdefs here is becoming quite a mess, so I've added
OPENSSL_RAND_* resolve the dispatch in one place. Perhaps later we
should also we can also simplify this by just including
CRYPTO_init_sysrand and CRYPTO_sysrand_if_available in all the C files.
But that'll be easier to do when Trusty's RNG is moved in tree.
While I'm here, fold some of the ifdefs in windows.c together.
Change-Id: Ic9c21c5c943a409ebb1d77f27daea1eeb9422e9d
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61085
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Trying to migrate Chromium to the "link all the asm files together"
strategy broke the aarch64 Android build because some of the ifdef'd out
assembly files were missing the .note.gnu.property section for BTI. If
we add support for IBT, that'll be another one.
To fix this, introduce <openssl/asm_base.h>, which must be included at
the start of every assembly file (before the target ifdefs). This does a
couple things:
- It emits BTI and noexecstack markers into every assembly file, even
those that ifdef themselves out.
- It resolves the MSan -> OPENSSL_NO_ASM logic, so we only need to do it
once.
- It defines the same OPENSSL_X86_64, etc., defines we set elsewhere, so
we can ensure they're consistent.
This required carving files up a bit. <openssl/base.h> has a lot of
things, such that trying to guard everything in it on __ASSEMBLER__
would be tedious. Instead, I moved the target defines to a new
<openssl/target.h>. Then <openssl/asm_base.h> is the new header that
pulls in all those things.
Bug: 542
Change-Id: I1682b4d929adea72908655fa1bb15765a6b3473b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/60765
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
The Windows system RNG[1] lives in bcryptprimitives.dll which exports
the function ProcessPrng[2] to supply random bytes from its internal
generators. These are seeded and reseeded from the operating
system using a device connection to \\Device\CNG which is opened
when bcryptprimitives.dll is first loaded.
After this CL boringssl calls ProcessPrng() directly.
Before this CL boringssl got its system randomness (on non-UWP
desktop Windows) from calls to RtlGenRandom[3].
This function is undocumented and unsupported, but has always been
available by linking to SystemFunction036 in advadpi32.dll. In
Windows 10 and later, this export simply forwards to
cryptbase.dll!SystemFunction036 which calls ProcessPrng()
directly.
cryptbase!SystemFunction036 decompiled:
```
BOOLEAN SystemFunction036(PVOID RandomBuffer,ULONG RandomBufferLength)
{
BOOL retval;
retval = ProcessPrng(RandomBuffer,RandomBufferLength);
return retval != 0;
}
```
Loading cryptbase.dll has the side effect of opening a device handle
to \\Device\KsecDD which is not used by boringssl's random number
wrappers. Calling ProcessPrng() directly allows sandboxed programs
such as Chromium to avoid having this handle if they do not need it.
ProcessPrng() also takes a size_t length rather than a u32 length,
allowing some simplification of the calling code.
After this CL we require bcryptprimitives to be loaded before the
first call to CRYPTO_srand(). Applications using the library should
either load the module themselves or call CRYPTO_pre_sandbox_init().
Before this CL boringssl required that advapi32, cryptbase and
bcryptprimitives were all loaded so this should not represent a
breaking change.
[1] https://learn.microsoft.com/en-us/windows/win32/seccng/processprng
[2] https://download.microsoft.com/download/1/c/9/1c9813b8-089c-4fef-b2ad-ad80e79403ba/Whitepaper%20-%20The%20Windows%2010%20random%20number%20generation%20infrastructure.pdf
[3] https://docs.google.com/document/d/13n1t5ak0yofzcadQCF7Ew5TewSUkNfQ3n-IYodjeRYc/edit
Bug: chromium:74242
Change-Id: Ifb1d6ef1a4539ff6e9a2c36cc119b7700ca2be8f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/60825
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
David Benjamin