arm-xlate.pl conditions some things on the flavour matching /linux/. This
change will need to be mirrored in update_gypi_and_asm.py.

Change-Id: I60483aaf40fd13181173373f12f6d3651a2a8a0c
Reviewed-on: https://boringssl-review.googlesource.com/4460
Reviewed-by: Adam Langley <agl@google.com>

This is as partial import of upstream's
9b05cbc33e. It includes the perlasm changes, but
not the CPU feature detection bits as we do those differently. This is largely
so we don't diverge from upstream, but it'll help with iOS assembly in the
future.

sha512-armv8.pl is modified slightly from upstream to switch from conditioning
on the output file to conditioning on an extra argument. This makes our
previous change from upstream (removing the 'open STDOUT' line) more explicit.

BUG=338886

Change-Id: Ic8ca1388ae20e94566f475bad3464ccc73f445df
Reviewed-on: https://boringssl-review.googlesource.com/4405
Reviewed-by: Adam Langley <agl@google.com>

This is never used and we can make the built-in one performant.

Change-Id: I6fc7639ba852349933789e73762bc3fa1341b2ff
Reviewed-on: https://boringssl-review.googlesource.com/4370
Reviewed-by: Adam Langley <agl@google.com>

BUG=473360

Change-Id: I6dc06eb425dd10c8d6a40d17f94405ea6f2f3905
Reviewed-on: https://boringssl-review.googlesource.com/4210
Reviewed-by: Adam Langley <agl@google.com>

Historically, OpenSSL has used callbacks for anything thread related,
but we don't actually have that many threading libraries to worry about:
just pthreads and Windows (I hope).

That suggests that it's quite reasonable to handle threading ourselves,
and eliminate the need for users to remember to install the thread
callbacks.

The first user of this would be ERR, which currently simulates
thread-local storage using a lock around a hash table keyed by the TID.
(Although I suspect that change will need some CMake work in order that
libpthread is automatically included with libcrypto when linking tests
etc, but not on Windows and without lots of ifs.)

Change-Id: I4dd088e3794506747f875c1f3e92b9bc6700fad2
Reviewed-on: https://boringssl-review.googlesource.com/4010
Reviewed-by: Adam Langley <agl@google.com>

This affects bignum and sha. Also now that we're passing the SSE2 flag, revert
the change to ghash-x86.pl which unconditionally sets $sse2, just to minimize
upstream divergence. Chromium assumes SSE2 support, so relying on it is okay.
See https://crbug.com/349320.

Note: this change needs to be mirrored in Chromium to take.

bssl speed numbers:

SSE2:
Did 552 RSA 2048 signing operations in 3007814us (183.5 ops/sec)
Did 19003 RSA 2048 verify operations in 3070779us (6188.3 ops/sec)
Did 72 RSA 4096 signing operations in 3055885us (23.6 ops/sec)
Did 4650 RSA 4096 verify operations in 3024926us (1537.2 ops/sec)

Without SSE2:
Did 350 RSA 2048 signing operations in 3042021us (115.1 ops/sec)
Did 11760 RSA 2048 verify operations in 3003197us (3915.8 ops/sec)
Did 46 RSA 4096 signing operations in 3042692us (15.1 ops/sec)
Did 3400 RSA 4096 verify operations in 3083035us (1102.8 ops/sec)

SSE2:
Did 16407000 SHA-1 (16 bytes) operations in 3000141us (5468743.0 ops/sec): 87.5 MB/s
Did 4367000 SHA-1 (256 bytes) operations in 3000436us (1455455.1 ops/sec): 372.6 MB/s
Did 185000 SHA-1 (8192 bytes) operations in 3002666us (61611.9 ops/sec): 504.7 MB/s
Did 9444000 SHA-256 (16 bytes) operations in 3000052us (3147945.4 ops/sec): 50.4 MB/s
Did 2283000 SHA-256 (256 bytes) operations in 3000457us (760884.1 ops/sec): 194.8 MB/s
Did 89000 SHA-256 (8192 bytes) operations in 3016024us (29509.0 ops/sec): 241.7 MB/s
Did 5550000 SHA-512 (16 bytes) operations in 3000350us (1849784.2 ops/sec): 29.6 MB/s
Did 1820000 SHA-512 (256 bytes) operations in 3001039us (606456.6 ops/sec): 155.3 MB/s
Did 93000 SHA-512 (8192 bytes) operations in 3007874us (30918.8 ops/sec): 253.3 MB/s

Without SSE2:
Did 10573000 SHA-1 (16 bytes) operations in 3000261us (3524026.7 ops/sec): 56.4 MB/s
Did 2937000 SHA-1 (256 bytes) operations in 3000621us (978797.4 ops/sec): 250.6 MB/s
Did 123000 SHA-1 (8192 bytes) operations in 3033202us (40551.2 ops/sec): 332.2 MB/s
Did 5846000 SHA-256 (16 bytes) operations in 3000294us (1948475.7 ops/sec): 31.2 MB/s
Did 1377000 SHA-256 (256 bytes) operations in 3000335us (458948.8 ops/sec): 117.5 MB/s
Did 54000 SHA-256 (8192 bytes) operations in 3027962us (17833.8 ops/sec): 146.1 MB/s
Did 2075000 SHA-512 (16 bytes) operations in 3000967us (691443.8 ops/sec): 11.1 MB/s
Did 638000 SHA-512 (256 bytes) operations in 3000576us (212625.8 ops/sec): 54.4 MB/s
Did 30000 SHA-512 (8192 bytes) operations in 3042797us (9859.3 ops/sec): 80.8 MB/s

BUG=430237

Change-Id: I47d1c1ffcd71afe4f4a192272f8cb92af9505ee1
Reviewed-on: https://boringssl-review.googlesource.com/4130
Reviewed-by: Adam Langley <agl@google.com>

This gives a standard PERL_EXECUTABLE configuration knob which is useful for
specifying a perl to use without having it in PATH.

Change-Id: I4b196b77e0b4666081a3f291fee3654c47925844
Reviewed-on: https://boringssl-review.googlesource.com/3570
Reviewed-by: Adam Langley <agl@google.com>

Previously, error strings were kept in arrays for each subdirectory and
err.c would iterate over them all and insert them at init time to a hash
table.

This means that, even if you have a shared library and lots of processes
using that, each process has ~30KB of private memory from building that
hash table.

This this change, all the error strings are built into a sorted list and
are thus static data. This means that processes can share the error
information and it actually saves binary space because of all the
pointer overhead in the old scheme. Also it saves the time taken
building the hash table at startup.

This removes support for externally-supplied error string data.

Change-Id: Ifca04f335c673a048e1a3e76ff2b69c7264635be

Android didn't have getauxval until Jelly Bean (4.1). This means that
BoringSSL running on older Androids won't be able to detect NEON
support. (This is moot for Chromium because Chromium calls
android_getCpuFeatures and sets the NEON flag itself, but other users of
BoringSSL on Android probably won't do that.)

This change mirrors a little of what upstream does and tries running a
NEON instruction with a handler for SIGILL installed.

Change-Id: I853b85c37ffb049b240582d71fcf07adedc37a30
Reviewed-on: https://boringssl-review.googlesource.com/3190
Reviewed-by: David Benjamin <davidben@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>

find -name CMakeLists.txt -type f | xargs sed -e 's/\t/  /g' -i

Change-Id: I01636b1849c00ba918f48828252492d99b0403ac

The variable switches the default type for add_library from STATIC to SHARED.
We can condition additional stuff on that for convenience. (tabtest still
doesn't build.)

BoringSSL as any kind of stable system shared library is still very much
unsupported, but this is probably handy for making sure we don't forget all
those pesky OPENSSL_EXPORTs.

Change-Id: I66ab80bcddbf3724e03e85384141fdf4f4acbc2e
Reviewed-on: https://boringssl-review.googlesource.com/3092
Reviewed-by: Adam Langley <agl@google.com>

This matches the Chromium build.

Change-Id: I6ebd01c6ecb67c79577f98cf468dc204721595ef
Reviewed-on: https://boringssl-review.googlesource.com/3063
Reviewed-by: Adam Langley <agl@google.com>

This is an initial cut at aarch64 support. I have only qemu to test it
however—hopefully hardware will be coming soon.

This also affects 32-bit ARM in that aarch64 chips can run 32-bit code
and we would like to be able to take advantage of the crypto operations
even in 32-bit mode. AES and GHASH should Just Work in this case: the
-armx.pl files can be built for either 32- or 64-bit mode based on the
flavour argument given to the Perl script.

SHA-1 and SHA-256 don't work like this however because they've never
support for multiple implementations, thus BoringSSL built for 32-bit
won't use the SHA instructions on an aarch64 chip.

No dedicated ChaCha20 or Poly1305 support yet.

Change-Id: Ib275bc4894a365c8ec7c42f4e91af6dba3bd686c
Reviewed-on: https://boringssl-review.googlesource.com/2801
Reviewed-by: Adam Langley <agl@google.com>

See https://tools.ietf.org/html/rfc5869.

Change-Id: I6d012d8c38806df80aa44350d3a86eaff499ac05
Reviewed-on: https://boringssl-review.googlesource.com/2533
Reviewed-by: Adam Langley <agl@google.com>

Pull constant-time methods out to a separate header, add tests.

(Imported from upstream's 9a9b0c0401 and
27739e9265)

Change-Id: Id570f5c531aca791112929e6258989f43c8a78d7

Chromium's doesn't have built-in support for ml64.exe. Seems easier to
just build consistently with Yasm on both Win32 and Win64. (This will
require an equivalent change in Chromium's build, but keep upstream
and downstream builds consistent.)

Also don't set CMAKE_ASM_NASM_COMPILER explicitly; cmake's default
ASM_NASM behavior will search for both nasm or yasm in %PATH%. Leave
it unset so it can be overwritten on the command-line to point to
a particular yasm. Update BUILDING accordingly.

Verified the tests still pass.

Change-Id: I7e434be474b5b2d49e3bafbced5b41cc0246bd00
Reviewed-on: https://boringssl-review.googlesource.com/2104
Reviewed-by: Adam Langley <agl@google.com>

Although x86masm.pl exists, upstream's documentation suggest only x86nasm.pl is
supported. Yasm seems to handle it fine with a small change.

Change-Id: Ia77be57c6b743527225924b2b398f2f07a084a7f
Reviewed-on: https://boringssl-review.googlesource.com/2092
Reviewed-by: Adam Langley <agl@google.com>

We were building the NASM flavor with MASM which is why it didn't work. Get the
MASM output working: cpuid and cmove are not available in MASM unless the file
declares .686. Also work around MASM rejecting a very long line in SHA-256.

The follow-up change will get the NASM flavor working. We should probably use
that one as it's documented as supported upstream. But let's make this one
functional too.

Change-Id: Ica69cc042a7250c7bc9ba9325caab597cd4ce616
Reviewed-on: https://boringssl-review.googlesource.com/2091
Reviewed-by: Adam Langley <agl@google.com>

Chromium does not like static initializers, and the CPU logic uses one to
initialize CPU bits. However, the crypto library lacks an explicit
initialization function, which could complicate (no compile-time errors)
porting existing code which uses crypto/, but not ssl/.

Add an explicit CRYPTO_library_init function, but make it a no-op by default.
It only does anything (and is required) if building with
BORINGSSL_NO_STATIC_INITIALIZER.

Change-Id: I6933bdc3447fb382b1f87c788e5b8142d6f3fe39
Reviewed-on: https://boringssl-review.googlesource.com/1770
Reviewed-by: Adam Langley <agl@google.com>

Sadly this is needed by wpa_supplicant for NTLM hashes.

Change-Id: I1c362c676a11ee01f301ff6fbd33d0669396ea23
Reviewed-on: https://boringssl-review.googlesource.com/1620
Reviewed-by: Adam Langley <agl@google.com>

Windows doesn't have ssize_t, sadly. There's SSIZE_T, but defining an
OPENSSL_SSIZE_T seems worse than just using an int.

Change-Id: I09bb5aa03f96da78b619e551f92ed52ce24d9f3f
Reviewed-on: https://boringssl-review.googlesource.com/1352
Reviewed-by: Adam Langley <agl@google.com>

Compilers have a bad habit of removing "superfluous" memset calls that
are trying to zero memory. For example, when memset()ing a buffer and
then free()ing it, the compiler might decide that the memset is
unobservable and thus can be removed.

Previously we tried to stop this by a) implementing memset in assembly
on x86 and b) putting the function in its own file for other platforms.

This change removes those tricks in favour of using asm directives to
scare the compiler away. As best as our compiler folks can tell, this is
sufficient and will continue to be so.

Change-Id: I40e0a62c3043038bafd8c63a91814a75a3c59269
Reviewed-on: https://boringssl-review.googlesource.com/1339
Reviewed-by: David Benjamin <davidben@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>

Apart from the obvious little issues, this also works around a
(seeming) libtool/linker:

a.c defines a symbol:

int kFoo;

b.c uses it:

extern int kFoo;

int f() {
  return kFoo;
}

compile them:

$ gcc -c a.c
$ gcc -c b.c

and create a dummy main in order to run it, main.c:

int f();

int main() {
  return f();
}

this works as expected:

$ gcc main.c a.o b.o

but, if we make an archive:

$ ar q lib.a a.o b.o

and use that:

$ gcc main.c lib.a
Undefined symbols for architecture x86_64
  "_kFoo", referenced from:
    _f in lib.a(b.o)

(It doesn't matter what order the .o files are put into the .a)

Linux and Windows don't seem to have this problem.

nm on a.o shows that the symbol is of type "C", which is a "common symbol"[1].
Basically the linker will merge multiple common symbol definitions together.

If ones makes a.c read:

int kFoo = 0;

Then one gets a type "D" symbol - a "data section symbol" and everything works
just fine.

This might actually be a libtool bug instead of an ld bug: Looking at `xxd
lib.a | less`, the __.SYMDEF SORTED index at the beginning of the archive
doesn't contain an entry for kFoo unless initialised.

Change-Id: I4cdad9ba46e9919221c3cbd79637508959359427

Now that the consuming code in ssl/ is removed, there is no need for this.
Leave SSL_COMP and STACK_OF(SSL_COMP) for now so as not to break any code which
manipulates the output of SSL_COMP_get_compression_methods to disable
compression.

Change-Id: Idf0a5debd96589ef6e7e56acf5d9259412b7d7a1

Initial fork from f2d678e6e8 (1.0.2 beta).

(This change contains substantial changes from the original and
effectively starts a new history.)