Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8220)

(cherry picked from commit 149c12d5e41b238ce4af6d1b6b3a767b40293bd7)

Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8220)

(cherry picked from commit 2fce15b58b2502a614529707eb45b6e5cac4eb15)

Since the padlock code is an engine, the assembler is for a module,
not a library link to when building a program...  there's a
distinction.

Fixes #2311
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8220)

(cherry picked from commit 88780b1c5f6000fe6731fec74efe697bcf493b6c)

Currently SM2 shares the ameth with EC, so the current default digest
algorithm returned is SHA256. This fixes the default digest algorithm of
SM2 to SM3, which is the only valid digest algorithm for SM2 signature.
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8186)

(cherry picked from commit e766f4a0531bffdab8ad2038279b755928d7a40a)

Github PR #8246 provides a better solution to the problem.

This reverts commit f11ffa505f8a9345145a26a05bf77b012b6941bd.

[extended tests]
Reviewed-by: NNicola Tuveri <nic.tuv@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/8247)

(cherry picked from commit 4089b4340701e3c13e07169e67a7d14519c98658)

(cherry picked from commit 1a31d8017ee7e8df0eca76fee601b826699c9ac1)
Reviewed-by: NNicola Tuveri <nic.tuv@gmail.com>
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8314)

(cherry picked from commit b3883f77df33989b0d4298ca9a21d8595dd9a8c9)
Reviewed-by: NPaul Yang <yang.yang@baishancloud.com>
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8319)

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

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

Follow on from CVE-2019-1559
Reviewed-by: NRichard Levitte <levitte@openssl.org>

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

This restores the behavior of previous versions of the /dev/crypto
engine, in alignment with the default implementation.
Reported-by: NGerard Looije <lglooije@hotmail.com>
Signed-off-by: NEneas U de Queiroz <cote2004-github@yahoo.com>
Reviewed-by: NRichard Levitte <levitte@openssl.org>
Reviewed-by: NNicola Tuveri <nic.tuv@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/8306)

cipher_init may be called on an already initialized context, without a
necessary cleanup.  This separates cleanup from initialization, closing
an eventual open session before creating a new one.

Move the /dev/crypto session cleanup code to its own function.
Signed-off-by: NEneas U de Queiroz <cote2004-github@yahoo.com>
Reviewed-by: NRichard Levitte <levitte@openssl.org>
Reviewed-by: NNicola Tuveri <nic.tuv@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/8306)

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

There is too high a risk that perl and OpenSSL are linked with
different C RTLs, and thereby get different messages for even the most
mundane error numbers.
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8343)

(cherry picked from commit 565a19eef35926b4b9675f6cc3964fb290a5b380)

test/shlibloadtest.c needs added code for VMS shared libraries
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8342)

The real cause for this change is that test/ec_internal_test.c
includes ec_lcl.h, and including curve448/curve448_lcl.h from there
doesn't work so well with compilers who always do inclusions relative
to the C file being compiled.
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8334)

Thanks to David Benjamin who reported this, performed the analysis and
suggested the patch. I have incorporated some of his analysis in the
comments below.

This issue can cause an out-of-bounds read. It is believed that this was
not reachable until the recent "fixed top" changes. Analysis has so far
only identified one code path that can encounter this - although it is
possible that others may be found. The one code path only impacts 1.0.2 in
certain builds. The fuzzer found a path in RSA where iqmp is too large. If
the input is all zeros, the RSA CRT logic will multiply a padded zero by
iqmp. Two mitigating factors:

- Private keys which trip this are invalid (iqmp is not reduced mod p).
Only systems which take untrusted private keys care.
- In OpenSSL 1.1.x, there is a check which rejects the oversize iqmp,
so the bug is only reproducible in 1.0.2 so far.

Fortunately, the bug appears to be relatively harmless. The consequences of
bn_cmp_word's misbehavior are:

- OpenSSL may crash if the buffers are page-aligned and the previous page is
non-existent.
- OpenSSL will incorrectly treat two BN_ULONG buffers as not equal when they
are equal.
- Side channel concerns.

The first is indeed a concern and is a DoS bug. The second is fine in this
context. bn_cmp_word and bn_cmp_part_words are used to compute abs(a0 - a1)
in Karatsuba. If a0 = a1, it does not matter whether we use a0 - a1 or
a1 - a0. The third would be worth thinking about, but it is overshadowed
by the entire Karatsuba implementation not being constant time.

Due to the difficulty of tripping this and the low impact no CVE is felt
necessary for this issue.
Reviewed-by: NPaul Dale <paul.dale@oracle.com>
Reviewed-by: NViktor Dukhovni <viktor@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8326)

(cherry picked from commit 576129cd72ae054d246221f111aabf42b9c6d76d)

Ty Baen-Price explains:

> Problem and Resolution:
> The following lines of code make use of the Microsoft API ExitProcess:
>
> ```
> Apps\Speed.c line 335:	ExitProcess(ret);
> Ms\uplink.c line 22: ExitProcess(1);
> ```
>
> These function calls are made after fatal errors are detected and
> program termination is desired. ExitProcess(), however causes
> _orderly_ shutdown of a process and all its threads, i.e. it unloads
> all dlls and runs all destructors. See MSDN for details of exactly
> what happens
> (https://msdn.microsoft.com/en-us/library/windows/desktop/ms682658(v=vs.85).aspx).
> The MSDN page states that ExitProcess should never be called unless
> it is _known to be safe_ to call it. These calls should simply be
> replaced with calls to TerminateProcess(), which is what should be
> called for _disorderly_ shutdown.
>
> An example of usage:
>
> ```
> TerminateProcess(GetCurrentProcess(), exitcode);
> ```
>
> Effect of Problem:
> Because of a compilation error (wrong c++ runtime), my program
> executed the uplink.c ExitProcess() call. This caused the single
> OpenSSL thread to start executing the destructors of all my dlls,
> and their objects. Unfortunately, about 30 other threads were
> happily using those objects at that time, eventually causing a
> 0xC0000005 ACCESS_VIOLATION. Obviously an ACCESS_VIOLATION is the
> best case scenario, as I'm sure you can imagine at the consequences
> of undiscovered memory corruption, even in a terminating process.

And on the subject of `TerminateProcess()` being asynchronous:

> That is technically true, but I think it's probably synchronous
> "enough" for your purposes, since a call to TerminateProcess
> suspends execution of all threads in the target process. This means
> it's really only asynchronous if you're calling TerminateProcess one
> some _other_ process. If you're calling TerminateProcess on your own
> process, you'll never return from the TerminateProcess call.

Fixes #2489
Was originally RT-4526
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8301)

(cherry picked from commit 925795995018bddb053e863db8b5c52d2a9005d9)

Prior to this commit we were keeping a count of how many KeyUpdates we
have processed and failing if we had had too many. This simplistic approach
is not sufficient for long running connections. Since many KeyUpdates
would not be a particular good DoS route anyway, the simplest solution is
to simply remove the key update count.

Fixes #8068
Reviewed-by: NKurt Roeckx <kurt@roeckx.be>
(Merged from https://github.com/openssl/openssl/pull/8299)

(cherry picked from commit 3409a5ff8a44ddaf043d83ed22e657ae871be289)

Fixes #7950

It was reported that there might be a null pointer dereference in the
implementation of the dasync_aes_128_cbc_hmac_sha1() cipher, because
EVP_aes_128_cbc_hmac_sha1() can return a null pointer if AES-NI is
not available. It took some analysis to find out that this is not
an issue in practice, and these comments explain the reason to comfort
further NPD hunters.

Detected by GitHub user @wurongxin1987 using the Sourcebrella Pinpoint
static analyzer.
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8305)

(cherry picked from commit a4a0a1eb43cfccd128d085932a567e0482fbfe47)

Reviewed-by: NPaul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/8303)

(cherry picked from commit 84712024da5e5485e8397afc763555355bddf960)

The aes128_cbc_hmac_sha1 cipher in the dasync engine is broken. Probably
by commit e38c2e85 which removed use of the "enc" variable...but not
completely.
Reviewed-by: NRichard Levitte <levitte@openssl.org>
Reviewed-by: NMatthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/8291)

(cherry picked from commit 695dd3a332fdd54b873fd0d08f9ae720141f24cd)

The option is a flag for Options, not a standalone setting.
Reviewed-by: NPaul Dale <paul.dale@oracle.com>
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8292)

(cherry picked from commit 4ac5e43da6d9ee828240e6d347c48c8fae6573a2)

(cherry picked from commit c8147d37ccaaf28c430d3fb45a14af36597e48b8)
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8253)

This commit adds a simple unit test to make sure that the constant-time
flag does not "leak" among BN_CTX frames:

- test_ctx_consttime_flag() initializes (and later frees before
  returning) a BN_CTX object, then it calls in sequence
  test_ctx_set_ct_flag() and test_ctx_check_ct_flag() using the same
  BN_CTX object. The process is run twice, once with a "normal"
  BN_CTX_new() object, then with a BN_CTX_secure_new() one.
- test_ctx_set_ct_flag() starts a frame in the given BN_CTX and sets the
  BN_FLG_CONSTTIME flag on some of the BIGNUMs obtained from the frame
  before ending it.
- test_ctx_check_ct_flag() then starts a new frame and gets a number of
  BIGNUMs from it. In absence of leaks, none of the BIGNUMs in the new
  frame should have BN_FLG_CONSTTIME set.

In actual BN_CTX usage inside libcrypto the leak could happen at any
depth level in the BN_CTX stack, with varying results depending on the
patterns of sibling trees of nested function calls sharing the same
BN_CTX object, and the effect of unintended BN_FLG_CONSTTIME on the
called BN_* functions.

This simple unit test abstracts away this complexity and verifies that
the leak does not happen between two sibling functions sharing the same
BN_CTX object at the same level of nesting.

(cherry picked from commit fe16ae5f95fa86ddb049a8d1e2caee0b80b32282)
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8253)

(cherry picked from commit 8f58ede09572dcc6a7e6c01280dd348240199568)
Reviewed-by: NMatt Caswell <matt@openssl.org>
Reviewed-by: NNicola Tuveri <nic.tuv@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/8262)

This commit adds a dedicated function in `EC_METHOD` to access a modular
field inversion implementation suitable for the specifics of the
implemented curve, featuring SCA countermeasures.

The new pointer is defined as:
`int (*field_inv)(const EC_GROUP*, BIGNUM *r, const BIGNUM *a, BN_CTX*)`
and computes the multiplicative inverse of `a` in the underlying field,
storing the result in `r`.

Three implementations are included, each including specific SCA
countermeasures:
  - `ec_GFp_simple_field_inv()`, featuring SCA hardening through
    blinding.
  - `ec_GFp_mont_field_inv()`, featuring SCA hardening through Fermat's
    Little Theorem (FLT) inversion.
  - `ec_GF2m_simple_field_inv()`, that uses `BN_GF2m_mod_inv()` which
    already features SCA hardening through blinding.

From a security point of view, this also helps addressing a leakage
previously affecting conversions from projective to affine coordinates.

This commit also adds a new error reason code (i.e.,
`EC_R_CANNOT_INVERT`) to improve consistency between the three
implementations as all of them could fail for the same reason but
through different code paths resulting in inconsistent error stack
states.
Co-authored-by: NNicola Tuveri <nic.tuv@gmail.com>

(cherry picked from commit e0033efc30b0f00476bba8f0fa5512be5dc8a3f1)
Reviewed-by: NMatt Caswell <matt@openssl.org>
Reviewed-by: NNicola Tuveri <nic.tuv@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/8262)

Reviewed-by: NBen Kaduk <kaduk@mit.edu>
Reviewed-by: NViktor Dukhovni <viktor@openssl.org>
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8175)

(cherry picked from commit 8e981051ceecd10754f8f6d1291414a7453c8fac)

The AIX binder needs to be instructed that the output will have no entry
point (see AIX' ld manual: -e in the Flags section; autoexp and noentry
in the Binder section).
Reviewed-by: NMatt Caswell <matt@openssl.org>
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8282)

(cherry picked from commit c1b3846242fc1a7791beca42f548c325c35e269b)

Reviewed-by: NBen Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/8191)

(cherry picked from commit 73e62d40eb53f2bad98dea0083c217dbfad1a335)

In TLSv1.3 it is illegal to interleave handshake records with non handshake
records.

Fixes #8189
Reviewed-by: NBen Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/8191)

(cherry picked from commit 3d35e3a253a2895f263333bb4355760630a31955)

Cygwin binaries should not enforce text mode these days, just
use text mode if the underlying mount point requests it
Signed-off-by: NCorinna Vinschen <vinschen@redhat.com>
Reviewed-by: NMatt Caswell <matt@openssl.org>
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8248)

(cherry picked from commit 9b57e4a1ef356420367d843f1ba96037f88316b8)

CLA: trivial
Reviewed-by: NRichard Levitte <levitte@openssl.org>
Reviewed-by: NMatt Caswell <matt@openssl.org>
GH: #8142
(cherry picked from commit e3ac3654892246d7492f1012897e42ad7efd13ce)

CLA: trivial
Reviewed-by: NRichard Levitte <levitte@openssl.org>
Reviewed-by: NMatt Caswell <matt@openssl.org>
GH: #8121
(cherry picked from commit 70680262329004c934497040bfc6940072043f48)

Reviewed-by: NRichard Levitte <levitte@openssl.org>
GH: #8109
(cherry picked from commit e09633107b7e987b2179850715ba60d8fb069278)

The add/double shortcut in ecp_nistz256-x86_64.pl left one instruction
point that did not unwind, and the "slow" path in AES_cbc_encrypt was
not annotated correctly. For the latter, add
.cfi_{remember,restore}_state support to perlasm.

Next, fill in a bunch of functions that are missing no-op .cfi_startproc
and .cfi_endproc blocks. libunwind cannot unwind those stack frames
otherwise.

Finally, work around a bug in libunwind by not encoding rflags. (rflags
isn't a callee-saved register, so there's not much need to annotate it
anyway.)

These were found as part of ABI testing work in BoringSSL.
Reviewed-by: NRichard Levitte <levitte@openssl.org>
GH: #8109
(cherry picked from commit c0e8e5007ba5234d4d448e82a1567e0c4467e629)

safestack.h, lhash.h and sparse_array.h all define macros to generate
a full API for the containers as static inline functions.  This
potentially generates unused code, which some compilers may complain
about.

We therefore need to mark those generated functions as unused, so the
compiler knows that we know, and stops complaining about it.
Reviewed-by: NNicola Tuveri <nic.tuv@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/8246)

(cherry picked from commit 48fe4ce104df060dd5d2b4188a56eb554d94d819)

Otherwise this can result in an incorrect calculation of the maximum
encoded integer length, meaning an insufficient buffer size is allocated.

Thanks to Billy Brumley for helping to track this down.

Fixes #8209
Reviewed-by: NNicola Tuveri <nic.tuv@gmail.com>
Reviewed-by: NRichard Levitte <levitte@openssl.org>
Reviewed-by: NPaul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/8237)

(cherry picked from commit 9fc8f18f59f4a4c853466dca64a23b8af681bf1c)

The "verify_return_error" option in s_client is documented as:

 Return verification errors instead of continuing. This will typically
 abort the handshake with a fatal error.

In practice this option was ignored unless also accompanied with the
"-verify" option. It's unclear what the original intention was. One fix
could have been to change the documentation to match the actual behaviour.
However it seems unecessarily complex and unexpected that you should need
to have both options. Instead the fix implemented here is make the option
match the documentation so that "-verify" is not also required.

Note that s_server has a similar option where "-verify" (or "-Verify") is
still required. This makes more sense because those options additionally
request a certificate from the client. Without a certificate there is no
possibility of a verification failing, and so "-verify_return_error" doing
nothing seems ok.

Fixes #8079
Reviewed-by: NNicola Tuveri <nic.tuv@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/8080)

(cherry picked from commit 78021171dbcb05ddab1b5daffbfc62504ea709a4)