Yes, I’m mostly talking about #9454 here. #9455 is a bug (clearing the flush
flag after flushing not before). The fix in #9477 addresses this and also
removes the dependence on RAND_bytes.
The #9454 description includes thread sanitisizer logs showing different lock
orderings — this has the potential to dead lock. Agreed with Rich that giving
up the lock would make sense, but I don’t see a way for this to be easily done.
That this also involves the RAND subsystem could be coincidental. The other
stack trace is getting an MD via a digest operation (i.e. both traces are for
algorithms that use other algorithms). The locks in question are the provider
store lock and the context lock.
crypto/context.c:
OPENSSL_CTX *ctx; /* function argument */
CRYPTO_THREAD_read_lock(ctx->oncelock);
crypto/provider_core.c:
OPENSSL_CTX *ctx; /* function argument */
struct provider_store_st *store = get_provider_store(ctx);
CRYPTO_THREAD_read_lock(store->lock);
Pauli
--
Dr Paul Dale | Cryptographer | Network Security & Encryption
Phone +61 7 3031 7217
Oracle Australia
> On 30 Jul 2019, at 8:52 pm, Matthias St. Pierre
> <matthias.st.pie...@ncp-e.com> wrote:
>
> Sorry, my reply was misleading, since Pauli is talking mainly about #9454.
> Please take a look at the issue description
>
> https://github.com/openssl/openssl/issues/9454
>
> instead.
>
> Matthias
>
>
>
> On 30.07.19 12:47, Matthias St. Pierre wrote:
>>
>>
>> On 30.07.19 12:43, Kurt Roeckx wrote:
>>>
>>> I currently fail to see how that's a problem, unless that
>>> EVP_CIPHER_CTX tries to use a DRBG.
>>
>> This is what I mean when I say that things have gotten more complicated
>> under the hood
>> due to the replumbing. To understand the problem, please take at a look of
>> the sanitizer
>> callstack in
>>
>> https://github.com/openssl/openssl/issues/9455
>>
>>
>> Matthias
>>
>>
>>
>
