This leaves VPAES and AESNI support.
The VPAES performance is comparable but BSAES is not
completely constant time. There are table lookups
using secret key data in AES_set_encrypt/decrypt_key
and in ctr mode short data uses the non-constant
time AES_encrypt function instead of bit-slicing.
Furthermore the AES_ASM is by far outperformed
by recent GCC versions.
Since BSAES calls back to AES_ASM for short
data blocks the performance on those is also
worse than the pure software implementaion.

Fixes: #9640

Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9675)

Trim trailing whitespace. It doesn't match OpenSSL coding standards,
AFAICT, and it can cause problems with git tooling.

Trailing whitespace remains in test data and external source.

Backport-of: https://github.com/openssl/openssl/pull/8092



Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8134)

We therefore must add defaults.

Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7626)

(cherry picked from commit 45cdae1c7c93fe7ef2a981da4c36c3b8cb09e855)

Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/7277)

(cherry picked from commit 46d08509)

Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6782)

Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6042)

Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6042)

Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6042)

Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6042)

Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6042)

Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6042)

The LIBZ macro definition was already quoted in BASE_windows, then got
quotified once more in windows-makefile.tmpl.  That's a bit too much
quotations, ending up with the compiler being asked to define the
macro |"LIBZ=\"ZLIB1\""| (no, not the macro LIBZ with the value
"ZLIB1").  This is solved by removing the extra quoting in
BASE_windows.

Along with this, change the quotation of macro definitions and include
file specification, so we end up with things like -I"QuotedPath" and
-D"Macro=\"some weird value\"" rather than "-IQuotedPath" and
"-DMacro=\"some weird value\"".

Fixes #5827

Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5833)

Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5574)

We're currently using the attributes 'defines', 'cppflags', 'cflags'
etc quite liberally, with no regard for where that ends up.  Quite a
few of those flags are actually only relevant for the libraries
(mostly libcrypto), so it's safe to say that those could be applied to
the libraries only.

So, we move some of those flags to 'lib_defines', 'lib_cppflags',
'lib_cflags', etc.

Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5560)

With the support of "make variables" comes the possibility for the
user to override them.  However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).

Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.

We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.

Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)

It was inconsistent to see this specific command have
'$(CROSS_COMPILE)' in its value when no other command did.

Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5247)

Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/5408)

It was a bit absurd to have this being specially handled in the build
file templates, especially that we have the 'includes' attribute.

Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5296)

Most modules are direct implementations of openssl application
sub-commands, but some constitute a support library, which can be used
by more than one program (and is, incidently, by test/uitest).

For practical purposes, we place the support library modules in a
private, static library.

Finally, there are some modules that don't have direct references in
the rest of the apps code, but are still crucial.  See them as some
kind of extra crt0 or similar for your platform.

Inspiration from David von Oheimb

Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5222)

Ideally, each config target should inherit a base to get their
platform specific defaults.  Unfortunately, that is currently not the
case, so we duplicate the Unixly defaults from the BASE_unix template
into the DEFAULT template.

Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5177)

Default values belong in the DEFAULT config target template, in
Configurations/00-base-templates.conf.

This isn't a complete move, but takes care of the most blatant
examples.

Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5177)

C preprocessor flags get separated from C flags, which has the
advantage that we don't get loads of macro definitions and inclusion
directory specs when linking shared libraries, DSOs and programs.

This is a step to add support for "make variables" when configuring.

Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5177)

So far, we've placed all extra library related flags together, ending
up in the make variable EX_LIBS.  This turns out to be problematic, as
for example, some compilers don't quite agree with something like
this:

    cc -o foo foo.o -L/whatever -lsomething

They prefer this:

    cc -L/whatever -o foo foo.o -lsomething

IBM's compiler on OS/390 is such a compiler that we know of, and we
have previously handled that as a previous case.

The answer here is to make a more general solution, where linking
options are divided in two parts, where one ends up in LDFLAGS and
the other in EX_LIBS (they corresponds to what is called LDFLAGS and
LDLIBS in the GNU world)

Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5033)

It will return the last expression from the input file.

We also use this in read_config, which slightly changes what's
expected of Configurations/*.conf.  They do not have to assign
%targets specifically.  On the other hand, the table of configs MUST
be the last expression in each of those files.

Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4840)

Reviewed-by: Richard Levitte <levitte@openssl.org>

Remove some incorrect copyright references.
Move copyright to standard place
Add OpenSSL copyright where missing.
Remove copyrighted file that we don't use any more
Remove Itanium assembler for RC4 and MD5 (assembler versions of old and
weak algorithms for an old chip)
Standardize apps/rehash copyright comment; approved by Timo
Put dual-copyright notice on mkcert

Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3691)

Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3745)

Now that we can link specifically with static libraries, the immediate
need to split ppccap.c (and eventually other *cap.c files) is no more.

This reverts commit e3fb4d3d

.

Reviewed-by: Rich Salz <rsalz@openssl.org>

Having that code in one central object file turned out to cause
trouble when building test/modes_internal_test.

Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1883)

Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1772)

[And remove FPU mutiplication subroutine.]

Reviewed-by: Rich Salz <rsalz@openssl.org>

MIPS[32|64]R6 is binary and source incompatible with previous MIPS ISA
specifications. Fortunately it's still possible to resolve differences
in source code with standard pre-processor and switching to trap-free
version of addition and subtraction instructions.

Reviewed-by: Richard Levitte <levitte@openssl.org>

Reviewed-by: Rich Salz <rsalz@openssl.org>

Reviewed-by: Richard Levitte <levitte@openssl.org>

The easiest way to take care of manifest files is to integrate them
into the associated binary (.exe or .dll).  MT (the Manifest Tool) is
the utility to use for this.

Reviewed-by: Rich Salz <rsalz@openssl.org>

Reviewed-by: Richard Levitte <levitte@openssl.org>

Reviewed-by: Richard Levitte <levitte@openssl.org>

Reviewed-by: Richard Levitte <levitte@openssl.org>

Reviewed-by: Richard Levitte <levitte@openssl.org>

To begin with, the default should have been the import library, not
the DLL itself.  However, we don't know what directory it's installed
in either way, so we may as well demand the full path from the user

Reviewed-by: Matt Caswell <matt@openssl.org>