Provide an implementation of OPENSSL_cpuid_setup() which identifies the
available CPU features required by the library directly from the system
registers for baremetal AArch64 builds without static initializer
(OPENSSL_NO_STATIC_INITIALIZER) that don't configure static capabilities
(OPENSSL_STATIC_ARMCAP). This assumes that the client code is NOT
running at exception level EL0 (userspace) and is enabled for
ANDROID_BAREMETAL.
Bug: b:265125189
Change-Id: Ifee6fbd24ece823a4661dd984f89473e1e1e3eda
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58586
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Detecting errors (i.e. fs-less platforms using fs-only APIs) at compile
time is generally preferable to doing so at runtime, so
https://boringssl-review.googlesource.com/c/boringssl/+/61726 opted to
remove the APIs altogether on applicable targets.
However, Trusty uses rust-openssl somewhere and rust-openssl binds a
bunch of filesystem-dependent APIs unconditionally. To keep that
working, switch to a stub fopen when OPENSSL_NO_FILESYSTEM is set. We
effectively model a platform where the filesystem "exists", but is
empty. Upstream OpenSSL similarly has OPENSSL_NO_STDIO still define the
file BIO (unlike the socket BIO, which is excluded), but in a stub form.
As part of this, I've gone ahead and resolved one of the Trusty TODOs.
It does produce a duplicate symbol with [1], but things seem to link
fine in treehugger. In case it does break, I've bumped
BORINGSSL_API_VERSION, so we can go in and condition it if needed.
[1] https://android.googlesource.com/trusty/lib/+/refs/heads/main/lib/openssl-stubs/bio.c
Bug: 629
Change-Id: I4f20d872a7cde863d21c78090f270b77b03545fa
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61925
Commit-Queue: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Some platforms would not have sys/socket.h, we should guard these
socket related headers with OPENSSL_NO_SOCK.
Bug: 629
Change-Id: I2d7c31ad32d467da46114307fd89c2ba3d41df2c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61845
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
This is a temporary workaround for b/291994116
Bug: b:291994116
Change-Id: I5b0372e07cf3bdf4b6a5b4b37dabea828ad026a8
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61885
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
This warning was being tripped because lib_buf and reason_buf made GCC,
incorrectly, believe that the strings could get that long, and then
attempted to sum up the snprintf to 120, obtained by inlining some
things.
Those buffers were larger than they needed to be, so bringing it down is
sufficient to silence things. That said, the buffer bounds are supplied
by the caller and it is expected that truncation can occur, so the
warning is just incorrect. The warning can also be silenced by checking
the snprintf return value. As we're already trying to detect truncation,
we may as well do it with the return value and skip the extra strlen
call.
Either of the two changes is sufficient to suppress the warning, but
both seem worthwhile, so I've done them both.
Change-Id: Ia1b1de67bba55da6f0d07e3682165a1820ce2c9e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61805
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
As part of this, factor out some of the socket bits. I tried to write
the sockaddr mess in a way that's strict-aliasing-clean, at least as far
as code we own goes. But the API is really not designed for it, and who
knows what effective type the underlying libc functions expect.
(Fortunately it's mostly syscalls, which definitely escape the
abstract machine.)
Change-Id: I12621f6c40f074ff7423dd46ddceca120ba63db9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61728
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
These functions are just wrappers over BIO_ctrls, shared between the fd
and socket BIOs. Though we don't currently support one, it is
conceivable that there would be a platform with socket BIOs but not fd
BIOs. In that case, the BIO_get_fd function would still be useful to
implement SSL_get_rfd. (And someone could conceivably implement it in
another BIO.)
Bug: 629
Change-Id: I7ac3561f76af86af32d70b1c6265c4caeaecb129
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61727
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
This corresponds to the libcrypto_baremetal build target in Android,
which is an embedded-style platform that uses a subset of the bionic
libc. It will also, eventually, use getentropy for its PRNG.
As part of this, generalize the OPENSSL_TRUSTY exclusion for file BIOs
to OPENSSL_NO_FILESYSTEM. Upstream OpenSSL uses OPENSSL_NO_STDIO, but
that excludes all of FILE entirely. We already require FILE in quite a
few places (urandom.c, self_test.c) for writing to stderr, and FILE is
part of C standard library. So, let's tentatively say that we require
you have FILE and stderr.
Instead, OPENSSL_NO_FILESYSTEM is saying you don't have fopen. You're
still required to have the three std{in,out,err} FILEs, and given a
FILE, you need to allow the standard operations on it. (Possibly in
forms that always fail.)
To keep us honest, whenever a function is excluded, I've dropped it from
the header too, and followed callers up the chain. I have not attempted
to make the tests work when these are excluded. Later CLs in this series
will do the same for NO_SOCK and NO_POSIX_IO. This was a little tedious,
but not too bad.
(I assume we'll end up changing our minds on this a lot. For now, let's
try this.)
I haven't yet restored OPENSSL_RAND_TRUSTY or removed the OPENSSL_TRUSTY
ifdef on file.c. Having a separate CL makes it a bit easier to revert if
something goes wrong.
This depends on
https://android-review.googlesource.com/c/platform/bionic/+/2659335,
which fixes the header bionic uses for getentropy.
Bug: 629, b:291102972
Change-Id: Idd839cd3fa4253128de54bd1be7da261dbcdeb7c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61726
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
https://boringssl-review.googlesource.com/c/boringssl/+/61685 had the
side effect of unobscuring some snprintf calls to GCC. There are a
couple instances that cannot truncate, but GCC doesn't know this because
it doesn't know the bounds on struct tm.
Fortunately, -Wformat-truncation, at level 1, is satisfied by checking
the return value, so do that.
Change-Id: Iad3ae0d51a951c10f1b706be7f6e127f0b9e6dee
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61705
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
One less thing to update when we next bump the minimum.
Bug: 607
Change-Id: I50bd01b14499a7ed7904a5e111c3e1df57eaa144
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61645
Reviewed-by: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Our BIO_snprintf is just a thin wrapper over the libc one, and we
already call it directly in other places. Just call the libc one
consistently.
Change-Id: Ia7daf26b9789ddcecab67118c4ec4a077aad5a22
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61685
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
glibc and musl do not make getentropy available from <unistd.h> unless
_BSD_SOURCE (or _GNU_SOURCE) is defined. _BSD_SOURCE, in glibc, triggers
a deprecation warning to use _DEFAULT_SOURCE instead.
It seems _DEFAULT_SOURCE might be fairly broadly defined, but some
Emscripten-based toolchain (which uses musl) didn't end up defining
it for some reason. Just do it explicitly in the source file so it
always works.
Change-Id: I4532d4adb9f8ed55c43763ca2dd426b5fa1b4f5c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61625
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
This effectively reverts
https://boringssl-review.googlesource.com/c/boringssl/+/61465, as a
temporary workaround for b/291102972. Once the broken
libcrypto_baremetal target in Android is fixed, we'll restore this file.
Bug: b:291102972
Change-Id: I830b61219e863cd7a72858a44df5fd958b023fd0
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61585
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Auto-Submit: 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>
Possibly we should run this on macOS too, so we have better test
coverage.
Bug: 287
Change-Id: I3005a445f8cb7559e91317be91a42c1db15f081a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61529
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@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>
Also remove unnecessary EC_GROUP_free calls. EC_GROUP_free is only
necessary in codepaths where arbitrary groups are possible.
Bug: 20
Change-Id: I3dfb7f07b890ab002ba8a302724d8bc671590cfe
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/60932
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: 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>
We've required C++14 for a while now. As we're mostly C with a little
C++, this is less helpful, but may as well avoid bare new where
possible.
Change-Id: Icf3386e3f3b6f2092bb0089ed874cc50985f1a40
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61429
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@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>
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>
Also fix the comments for ERR_STATE because they were actually wrong.
Bug: 516
Change-Id: I3b352fc75e63075a9f02f33c6e23da0f821a323e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61425
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: 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>
Another point indirection removed. As part of this, remove the extra
copy of one and just use generator.raw.Z.
Bug: 20
Change-Id: I066f624fe02e17082383afc15871ab2431e97b61
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/60930
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: 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>
Bug: 287
Change-Id: Ia907c5dd7fd31e95098730673d2da1bede6d79ed
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61405
Commit-Queue: David Benjamin <davidben@google.com>
Auto-Submit: Bob Beck <bbe@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
The delocate machinery makes it annoying to have pointers in structures.
Also this is a hair more compact.
Bug: 20
Change-Id: I2bc2dd97018277b5be55fd560f4171b7b85928ff
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/60929
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@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>
One less value to initialize statically. Instead, just check if r +
order < p. It's one additional comparison, but those have negligible
cost here.
Bug: 20
Change-Id: Iabc9c1894b58aeba45282e3360e38fe843eb7139
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/60927
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
BN_MONT_CTX already has the modulus, so just use it. This is one less
value to initialize statically.
Bug: 20
Change-Id: I78f73994ab595b795e99d67851bdff3b73fc3dd6
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/60926
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Change-Id: Id38833b329b0d661fb18e8a75b671379effe82a6
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61166
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: 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>
We could just use the string literal as-is.
Change-Id: I2efe01fd9b020db1bb086001407bcf7fa8487551
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61045
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
nanolibc is an embedded platform with no threads. To start unforking
that build, generalize some of the OPENSSL_TRUSTY defines. OpenSSL has
OPENSSL_NO_SOCK if you don't have sockets and OPENSSL_NO_POSIX_IO if you
don't have file descriptors. Those names are fine enough, so I've
borrowed them here too.
There's more to be done here, but this will clear out some of it.
Change-Id: Iaba1fafdebb46ebb8f68b7956535dd0ccaaa832f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/60890
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
We really should remove these (we only support them in private keys)
but, in the meantime, add some tests for all the curves, not just P-256.
Change-Id: I9c4c0660f082fa1701afe11f51bb157b06befd3c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/60925
Reviewed-by: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
RSA CRT is tiny bit messier when p < q.
https://boringssl-review.googlesource.com/25263 solved this by
normalizing to p > q. The cost was we sometimes had to compute a new
iqmp.
Modular inversion is expensive. We did it only once per key, but it's
still a performance cliff in per-key costs. When later work moves
freeze_private_key into RSA private key parsing, it will be a
performance cliff in the private key parser.
Instead, just handle p < q in the CRT function. The only difference is
needing one extra reduction before the modular subtraction. Even using
the fully general mod_montgomery function (as opposed to checking p < q,
or using bn_reduce_once when num_bits(p) == num_bits(q)) was not
measurable.
In doing so, I noticed we didn't actually have tests that exercise the
reduction step. I added one to evp_tests.txt, but it is only meaningful
when blinding is disabled. (Another cost of blinding.) When blinding is
enabled, the answers mod p and q are randomized and we hit this case
with about 1.8% probability. See comment in evp_test.txt.
I kept the optimization where we store iqmp in Montgomery form, not
because the optimization matters, but because we need to store a
corrected, fixed-width version of the value anyway, so we may as well
store it in a more convenient form.
M1 Max
Before:
Did 9048 RSA 2048 signing operations in 5033403us (1797.6 ops/sec)
Did 1500 RSA 4096 signing operations in 5009288us (299.4 ops/sec)
After:
Did 9116 RSA 2048 signing operations in 5053802us (1803.8 ops/sec) [+0.3%]
Did 1500 RSA 4096 signing operations in 5008283us (299.5 ops/sec) [+0.0%]
Intel(R) Xeon(R) Gold 6154 CPU @ 3.00GHz
Before:
Did 9282 RSA 2048 signing operations in 5019395us (1849.2 ops/sec)
Did 1302 RSA 4096 signing operations in 5055011us (257.6 ops/sec)
After:
Did 9240 RSA 2048 signing operations in 5024845us (1838.9 ops/sec) [-0.6%]
Did 1302 RSA 4096 signing operations in 5046157us (258.0 ops/sec) [+0.2%]
Bug: 316
Change-Id: Icb90c7d5f5188f9b69a6d7bcc63db13d92ec26d5
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/60705
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Setting up Montgomery reduction requires computing RR, a larger power of
2 mod N. When N is secret (RSA primes), we currently start at
2^(n_bits-1), then iteratively double and reduce.
Instead, once we reach 2R = 2^(r_bits+1) or higher, we can switch to a
Montgomery square-and-multiply. (Montgomery reduction only needs n0. RR
is just for conversion.) This takes some tuning because, at low powers
of 2 (in Montgomery form), it is still more efficient to square by
doubling. I ran benchmarks for 32-bit and 64-bit, x86 and Arm, on the
machines I had available and picked a threshold that works decently
well.
(On the hardware I tested, it's the right threshold on all but the Pixel
5A. The 5A would ideally want a slightly higher threshold---it seems to
be worse at multiplying or better at addition, but the gap isn't that
large, and this operation isn't perf-sensitive anyway.)
The result is dramatically faster than the old shift-based approach.
That said, see I06f4a065fdecc1aec3160fe32a41e200538d1ee3 for discussion
on this operation. These speedups are not expected to translate to
increased RSA throughput. They just clear up some initialization work.
This speedup is not quite enough to match the division-based
variable-time one (perf-sensitive for RSA verification), so we'll keep
both codepaths around.
M1 Max
Before:
Did 712000 256-bit mont (constime) operations in 2000454us (355919.2 ops/sec)
Did 440000 384-bit mont (constime) operations in 2001121us (219876.8 ops/sec)
Did 259000 512-bit mont (constime) operations in 2003709us (129260.3 ops/sec)
Did 212000 521-bit mont (constime) operations in 2007033us (105628.6 ops/sec)
Did 107000 1024-bit mont (constime) operations in 2018551us (53008.3 ops/sec)
Did 57000 1536-bit mont (constime) operations in 2001027us (28485.4 ops/sec)
Did 37000 2048-bit mont (constime) operations in 2039631us (18140.5 ops/sec)
Did 20000 3072-bit mont (constime) operations in 2041163us (9798.3 ops/sec)
Did 11760 4096-bit mont (constime) operations in 2007195us (5858.9 ops/sec)
After:
Did 3996000 256-bit mont (constime) operations in 2000366us (1997634.4 ops/sec) [+461.3%]
Did 2687000 384-bit mont (constime) operations in 2000464us (1343188.4 ops/sec) [+510.9%]
Did 2615000 512-bit mont (constime) operations in 2000146us (1307404.6 ops/sec) [+911.5%]
Did 1029000 521-bit mont (constime) operations in 2000944us (514257.3 ops/sec) [+386.9%]
Did 1246000 1024-bit mont (constime) operations in 2000899us (622720.1 ops/sec) [+1074.8%]
Did 688000 1536-bit mont (constime) operations in 2000579us (343900.4 ops/sec) [+1107.3%]
Did 425000 2048-bit mont (constime) operations in 2003622us (212115.9 ops/sec) [+1069.3%]
Did 212000 3072-bit mont (constime) operations in 2004430us (105765.7 ops/sec) [+979.4%]
Did 125000 4096-bit mont (constime) operations in 2009677us (62199.0 ops/sec) [+961.6%]
Intel(R) Xeon(R) Gold 6154 CPU @ 3.00GHz
Before:
Did 781000 256-bit mont (constime) operations in 2000740us (390355.6 ops/sec)
Did 414000 384-bit mont (constime) operations in 2000180us (206981.4 ops/sec)
Did 258000 512-bit mont (constime) operations in 2001729us (128888.6 ops/sec)
Did 194000 521-bit mont (constime) operations in 2008814us (96574.4 ops/sec)
Did 79000 1024-bit mont (constime) operations in 2009309us (39317.0 ops/sec)
Did 36000 1536-bit mont (constime) operations in 2003945us (17964.6 ops/sec)
Did 21000 2048-bit mont (constime) operations in 2074987us (10120.5 ops/sec)
Did 9040 3072-bit mont (constime) operations in 2003869us (4511.3 ops/sec)
Did 5250 4096-bit mont (constime) operations in 2067796us (2538.9 ops/sec)
After:
Did 3496000 256-bit mont (constime) operations in 2000542us (1747526.4 ops/sec) [+347.7%]
Did 2466000 384-bit mont (constime) operations in 2000327us (1232798.4 ops/sec) [+495.6%]
Did 2392000 512-bit mont (constime) operations in 2000732us (1195562.4 ops/sec) [+827.6%]
Did 908000 521-bit mont (constime) operations in 2001181us (453732.1 ops/sec) [+369.8%]
Did 1054000 1024-bit mont (constime) operations in 2001429us (526623.7 ops/sec) [+1239.4%]
Did 548000 1536-bit mont (constime) operations in 2002417us (273669.3 ops/sec) [+1423.4%]
Did 339000 2048-bit mont (constime) operations in 2004127us (169151.0 ops/sec) [+1571.4%]
Did 162000 3072-bit mont (constime) operations in 2008221us (80668.4 ops/sec) [+1688.2%]
Did 94000 4096-bit mont (constime) operations in 2013848us (46676.8 ops/sec) [+1738.4%]
Intel(R) Xeon(R) Gold 6154 CPU @ 3.00GHz, 32-bit mode
Before:
Did 335000 256-bit mont (constime) operations in 2000006us (167499.5 ops/sec)
Did 170000 384-bit mont (constime) operations in 2010398us (84560.4 ops/sec)
Did 102000 512-bit mont (constime) operations in 2013510us (50657.8 ops/sec)
Did 88000 521-bit mont (constime) operations in 2022909us (43501.7 ops/sec)
Did 27000 1024-bit mont (constime) operations in 2063490us (13084.6 ops/sec)
Did 11760 1536-bit mont (constime) operations in 2000600us (5878.2 ops/sec)
Did 6825 2048-bit mont (constime) operations in 2069343us (3298.1 ops/sec)
Did 2982 3072-bit mont (constime) operations in 2090651us (1426.3 ops/sec)
Did 1680 4096-bit mont (constime) operations in 2074824us (809.7 ops/sec)
After:
Did 1559000 256-bit mont (constime) operations in 2000884us (779155.6 ops/sec) [+365.2%]
Did 940000 384-bit mont (constime) operations in 2001511us (469645.2 ops/sec) [+455.4%]
Did 608000 512-bit mont (constime) operations in 2000380us (303942.3 ops/sec) [+500.0%]
Did 439000 521-bit mont (constime) operations in 2004282us (219031.1 ops/sec) [+403.5%]
Did 180000 1024-bit mont (constime) operations in 2005427us (89756.4 ops/sec) [+586.0%]
Did 85000 1536-bit mont (constime) operations in 2017009us (42141.6 ops/sec) [+616.9%]
Did 49000 2048-bit mont (constime) operations in 2035401us (24073.9 ops/sec) [+629.9%]
Did 22000 3072-bit mont (constime) operations in 2047404us (10745.3 ops/sec) [+653.3%]
Did 12642 4096-bit mont (constime) operations in 2094210us (6036.6 ops/sec) [+645.5%]
Pixel 5A:
Before:
Did 483000 256-bit mont (constime) operations in 2001460us (241323.8 ops/sec)
Did 279000 384-bit mont (constime) operations in 2004682us (139174.2 ops/sec)
Did 198000 512-bit mont (constime) operations in 2003995us (98802.6 ops/sec)
Did 141000 521-bit mont (constime) operations in 2006305us (70278.4 ops/sec)
Did 62000 1024-bit mont (constime) operations in 2022138us (30660.6 ops/sec)
Did 29000 1536-bit mont (constime) operations in 2007150us (14448.3 ops/sec)
Did 17376 2048-bit mont (constime) operations in 2044894us (8497.3 ops/sec)
Did 7686 3072-bit mont (constime) operations in 2011537us (3821.0 ops/sec)
Did 4620 4096-bit mont (constime) operations in 2048780us (2255.0 ops/sec)
After:
Did 1187000 256-bit mont (constime) operations in 2000099us (593470.6 ops/sec) [+145.9%]
Did 794000 384-bit mont (constime) operations in 2002162us (396571.3 ops/sec) [+184.9%]
Did 658000 512-bit mont (constime) operations in 2002808us (328538.7 ops/sec) [+232.5%]
Did 373000 521-bit mont (constime) operations in 2005135us (186022.4 ops/sec) [+164.7%]
Did 231000 1024-bit mont (constime) operations in 2008117us (115033.1 ops/sec) [+275.2%]
Did 112000 1536-bit mont (constime) operations in 2003151us (55911.9 ops/sec) [+287.0%]
Did 66000 2048-bit mont (constime) operations in 2022295us (32636.2 ops/sec) [+284.1%]
Did 30000 3072-bit mont (constime) operations in 2006199us (14953.7 ops/sec) [+291.4%]
Did 17182 4096-bit mont (constime) operations in 2017938us (8514.6 ops/sec) [+277.6%]
Pixel 5A, 32-bit mode:
Before:
Did 124000 256-bit mont (constime) operations in 2013082us (61597.1 ops/sec)
Did 66000 384-bit mont (constime) operations in 2024604us (32599.0 ops/sec)
Did 40000 512-bit mont (constime) operations in 2018560us (19816.1 ops/sec)
Did 38000 521-bit mont (constime) operations in 2043776us (18593.0 ops/sec)
Did 11466 1024-bit mont (constime) operations in 2010767us (5702.3 ops/sec)
Did 5481 1536-bit mont (constime) operations in 2061892us (2658.2 ops/sec)
Did 3171 2048-bit mont (constime) operations in 2075359us (1527.9 ops/sec)
Did 1407 3072-bit mont (constime) operations in 2032032us (692.4 ops/sec)
Did 819 4096-bit mont (constime) operations in 2070367us (395.6 ops/sec)
After:
Did 718000 256-bit mont (constime) operations in 2000496us (358911.0 ops/sec) [+482.7%]
Did 424000 384-bit mont (constime) operations in 2000523us (211944.6 ops/sec) [+550.2%]
Did 401000 512-bit mont (constime) operations in 2000933us (200406.5 ops/sec) [+911.3%]
Did 205000 521-bit mont (constime) operations in 2004212us (102284.6 ops/sec) [+450.1%]
Did 153000 1024-bit mont (constime) operations in 2004644us (76322.8 ops/sec) [+1238.5%]
Did 78000 1536-bit mont (constime) operations in 2007510us (38854.1 ops/sec) [+1361.6%]
Did 47000 2048-bit mont (constime) operations in 2018015us (23290.2 ops/sec) [+1424.3%]
Did 22848 3072-bit mont (constime) operations in 2079082us (10989.5 ops/sec) [+1487.1%]
Did 13156 4096-bit mont (constime) operations in 2067424us (6363.5 ops/sec) [+1508.6%]
Bug: 316
Change-Id: I402df85170cae780442225eaa879884e707ffa86
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/60686
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
bn_mod_lshift_consttime currently calls bn_mod_lshift1_consttime in a
loop, but between needing a temporary value and having to guard against
some complications in our fixed-width BIGNUM convention, it's actually
picking up a lot of overhead.
This function is currently called to setup Montgomery contexts with
secret moduli (RSA primes). The setup operation is not
performance-sensitive in our benchmarks, because it is amortized away in
RSA private key signing. However, as part of reducing thread contention
with the RSA object, I'm planning to make RSA creation, which we do
benchmark, eagerly fill in the Montgomery context.
We do benchmark RSA parsing, so adding a slow Montgomery setup would
show up in benchmarks. This distinction is mostly artificial. Work done
on creation and work done on first use is still work done once per RSA
key. However, work done on key creation may slow server startup, while
work deferred to first use is amortized but less predictable.
Either way, from this CL, and especially the one to follow it, we have
plenty of low-hanging fruit in this function. As a bonus, this should
help single-use RSA private keys, but that's not something we currently
benchmark.
Modulus sizes below chosen based on:
- Common curve sizes (moot because we use a variable-time setup anyway)
- Common RSA modulus sizes (also variable-time setup)
- Half of common RSA modulus sizes (the secret primes involved)
Of these, only the third category matters. The others can use the
division-based path where it's faster anyway. However, by the end of
this patch series, they'll get a bit closer, so I benchmarked them all
to compare. (Though division still wins in the end.)
Benchmarks on an M1 Max:
Before:
Did 528000 256-bit mont (constime) operations in 2000993us (263869.0 ops/sec)
Did 312000 384-bit mont (constime) operations in 2001281us (155900.1 ops/sec)
Did 246000 512-bit mont (constime) operations in 2001521us (122906.5 ops/sec)
Did 191000 521-bit mont (constime) operations in 2006336us (95198.4 ops/sec)
Did 98000 1024-bit mont (constime) operations in 2001438us (48964.8 ops/sec)
Did 55000 1536-bit mont (constime) operations in 2025306us (27156.4 ops/sec)
Did 35000 2048-bit mont (constime) operations in 2022714us (17303.5 ops/sec)
Did 17640 3072-bit mont (constime) operations in 2028352us (8696.7 ops/sec)
Did 10290 4096-bit mont (constime) operations in 2065529us (4981.8 ops/sec)
After:
Did 712000 256-bit mont (constime) operations in 2000454us (355919.2 ops/sec) [+34.9%]
Did 440000 384-bit mont (constime) operations in 2001121us (219876.8 ops/sec) [+41.0%]
Did 259000 512-bit mont (constime) operations in 2003709us (129260.3 ops/sec) [+5.2%]
Did 212000 521-bit mont (constime) operations in 2007033us (105628.6 ops/sec) [+11.0%]
Did 107000 1024-bit mont (constime) operations in 2018551us (53008.3 ops/sec) [+8.3%]
Did 57000 1536-bit mont (constime) operations in 2001027us (28485.4 ops/sec) [+4.9%]
Did 37000 2048-bit mont (constime) operations in 2039631us (18140.5 ops/sec) [+4.8%]
Did 20000 3072-bit mont (constime) operations in 2041163us (9798.3 ops/sec) [+12.7%]
Did 11760 4096-bit mont (constime) operations in 2007195us (5858.9 ops/sec) [+17.6%]
Bug: 316
Change-Id: I06f4a065fdecc1aec3160fe32a41e200538d1ee3
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/60685
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
I forgot a CPU capability check in X25519Test.NeonABI.
Change-Id: Ie2fa4a7b04a7eb152aa3b720687ec529e5dd5b0f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/60745
Reviewed-by: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
While EVP_PKEY_RSA, EVP_PKEY_DSA, and EVP_PKEY_EC have publicly-exposed
internaly representations, other EVP_PKEY types to not. EVP_PKEY_assign
should not allow callers to manipulate those representations.
As part of this, teach EVP_PKEY_assign_RSA, etc. to find their method
tables directly, rather than indirecting through an integer. This makes
those EVP APIs static-linker-friendly.
Bug: 618, 497
Change-Id: Ic45a7514e9a3adc505759f2327129f13faf03a65
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/60645
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
We no longer need to define CRYPTO_MUTEX in public headers. This
simplifies a pile of things. First, we can now use pthread_rwlock_t
without any fuss, rather than trying to guess the size on glibc.
As a result, CRYPTO_MUTEX and CRYPTO_STATIC_MUTEX can be merged into one
type. We can almost do this to CRYPTO_refcount_t too. BIO is the one
straggler remaining.
Fixed: 325
Change-Id: Ie93c9f553c0f02ce594b959c041b00fc15ba51d2
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/60611
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Three years of updating calling code are finally complete!
Update-Note: Accessing the RSA struct directly is no longer supported.
Use accessors instead.
Bug: 316, 325
Change-Id: I27b4c9899cb96f5807075b8fe351eaf72a9a9d44
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/60610
Reviewed-by: Adam Langley <agl@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
rust-openssl uses this function when targetting OpenSSL 1.1.x.
Change-Id: Ifeb1b65be9976358f9ee636ed23c1a931e03b275
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/60609
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
