My guess is that the loop is caused by one of the commits 0ed27fb7a8 and 8438d3a7b7. Would you mind to (a) check whether that's correct and which one of the two commits causes the problem, and (b) raise a GitHub issue for it? Matthias ~/src/openssl/1.1.1$ git log --oneline --stat OpenSSL_1_1_1o..OpenSSL_1_1_1p -- crypto/bn a3fc812c0c (security/OpenSSL_1_1_1-stable) Update copyright year crypto/bn/asm/x86_64-mont5.pl | 2 +- crypto/bn/rsaz_exp.c | 2 +- crypto/bn/rsaz_exp.h | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) 8438d3a7b7 Add an extra reduction step to RSAZ mod_exp implementations crypto/bn/rsaz_exp.c | 8 ++++++++ crypto/bn/rsaz_exp.h | 23 +++++++++++++++++++++++ 2 files changed, 31 insertions(+) 0ed27fb7a8 Always end BN_mod_exp_mont_consttime with normal Montgomery reduction. crypto/bn/asm/x86_64-mont5.pl | 196 ---------------------------------------------------------------------------------- crypto/bn/bn_exp.c | 44 +++++++++++-------- 2 files changed, 26 insertions(+), 214 deletions(-) > -----Original Message----- > From: openssl-users <openssl-users-bounces@xxxxxxxxxxx> On Behalf Of rsbecker@xxxxxxxxxxxxx > Sent: Wednesday, June 22, 2022 1:40 AM > To: openssl-users@xxxxxxxxxxx > Subject: Test failure for 1.1.1p - 10-test_bn > > Our test process for 10-test_bn went into a hard loop when building using > IEEE float. This has not happened in prior tests or when using platform > floating point (default). The situation does not occur in 3.0.4 - only > 1.1.1p. At 1.1.1o there was no issue. I am concerned that there are > assumptions made relating to BN processing with this change but do not know > enough about the Montgomery structures to be able to isolate the cause of > this. > > This happens on the big-endian NonStop x86 platform. >
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
