[openssl/openssl] 189ad3: Refactor the DRBG implementations to manage lockin...

[Matt Caswell]

  Branch: refs/heads/master
  Home:   https://github.com/openssl/openssl
  Commit: 189ad3ab2028babd39241015fc3975e8334c87eb
      https://github.com/openssl/openssl/commit/189ad3ab2028babd39241015fc3975e8334c87eb
  Author: Matt Caswell <matt at openssl.org>
  Date:   2023-06-02 (Fri, 02 Jun 2023)

  Changed paths:
    M providers/implementations/rands/drbg.c
    M providers/implementations/rands/drbg_ctr.c
    M providers/implementations/rands/drbg_hash.c
    M providers/implementations/rands/drbg_hmac.c
    M providers/implementations/rands/drbg_local.h

  Log Message:
  -----------
  Refactor the DRBG implementations to manage locking themselves

Previously the EVP layer would call lock and unlock functions on the
underlying DRBG implementation to say when a lock should be acquired and
released. This gives the DRBG implementation no say as to what kind of
lock should obtained (e.g. read/write) or even whether a lock is actually
needed or not.

In reality we know whether a DRBG is supposed to be in locking mode or
not because the "enable_locking()" function will have been called if
locks should be used. Therefore we re-interpret the lock and unlock
functions as "hints" from the EVP layer which we ignore. Instead we
acquire locks only when we need them. By knowing the context we can obtain
either a read or a write lock as appropriate.

This may mean that in some rare cases we acquire the locks more than once
for a single EVP call, if the EVP call makes several calls to the underlying
DRBG. But in practice almost all EVP calls only make one such call.
EVP_RAND_generate() is an example of a call where multiple DRBG calls may
be made. One of these gets the "max_request" parameter (which is constant
for all of our own DRBGs) and it may make several calls to the DRBG generate
call - but only if the requested size is very large which will rarely be
the case.

Partially fixes #20286

Reviewed-by: Tomas Mraz <tomas at openssl.org>
Reviewed-by: Todd Short <todd.short at me.com>
Reviewed-by: Paul Dale <pauli at openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20970)


  Commit: 61f11cad7a0dffc7abd234164a0e74c6ae8e7c2a
      https://github.com/openssl/openssl/commit/61f11cad7a0dffc7abd234164a0e74c6ae8e7c2a
  Author: Matt Caswell <matt at openssl.org>
  Date:   2023-06-02 (Fri, 02 Jun 2023)

  Changed paths:
    M providers/implementations/rands/drbg.c
    M providers/implementations/rands/drbg_ctr.c
    M providers/implementations/rands/drbg_hash.c
    M providers/implementations/rands/drbg_hmac.c
    M providers/implementations/rands/drbg_local.h

  Log Message:
  -----------
  Enable obtaining certain DRBG params without a lock

Even if a DRBG has locking enabled on it, there are certain parameters
which are still safe to obtain even without a lock. The max_request
value is constant for all our DRBGs. The reseed_counter does not matter
if we get it wrong - so it is safe to avoid the lock. So if all we are
reading are those parameters then we take no lock at all.

Partially fixes #20286

Reviewed-by: Tomas Mraz <tomas at openssl.org>
Reviewed-by: Todd Short <todd.short at me.com>
Reviewed-by: Paul Dale <pauli at openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20970)


Compare: https://github.com/openssl/openssl/compare/168d93a21d51...61f11cad7a0d