Commit Graph

110 Commits

Author SHA1 Message Date
David Benjamin
03a739d8d2 Build Win32 with Yasm rather than MASM.
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>
2014-10-29 23:14:11 +00:00
David Benjamin
3e700bb3e8 Get MASM output working on Win32.
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>
2014-10-29 23:13:20 +00:00
David Benjamin
a70c75cfc0 Add a CRYPTO_library_init and static-initializer-less build option.
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>
2014-09-12 00:10:53 +00:00
Adam Langley
c9eb7eac86 Readd MD4.
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>
2014-08-26 21:51:48 +00:00
Adam Langley
ded93581f1 Windows build fixes.
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>
2014-08-11 22:10:02 +00:00
Adam Langley
ad1907fe73 Use asm directives to protect OPENSSL_cleanse.
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>
2014-07-31 18:49:22 +00:00
Adam Langley
30eda1d2b8 Include some build fixes for OS X.
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
2014-06-24 11:15:12 -07:00
David Benjamin
95463b311d Remove crypto/comp and SSL_COMP support code.
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
2014-06-24 17:22:06 +00:00
Adam Langley
de0b202684 ChaCha20-Poly1305 support. 2014-06-20 13:17:35 -07:00
Adam Langley
95c29f3cd1 Inital import.
Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta).

(This change contains substantial changes from the original and
effectively starts a new history.)
2014-06-20 13:17:32 -07:00