Bug 2231540

Summary:	SSH does not use the ibmca crypto hardware in FIPS on s390x
Product:	Red Hat Enterprise Linux 9	Reporter:	Ondrej Moriš <omoris>
Component:	openssh	Assignee:	Dmitry Belyavskiy <dbelyavs>
Status:	CLOSED WONTFIX	QA Contact:	BaseOS QE Security Team <qe-baseos-security>
Severity:	low	Docs Contact:
Priority:	low
Version:	9.3	CC:	hkario, jjelen, ksrot, npocs, tstaudt
Target Milestone:	rc	Keywords:	Regression, Triaged
Target Release:	---
Hardware:	s390x
OS:	All
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2023-08-29 10:38:57 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Ondrej Moriš 2023-08-11 18:48:52 UTC

This bug was initially created as a copy of Bug #1397547

I am copying this bug because: 

There seems to be a regression of this bug in RHEL-9.3 in FIPS. Scenario described below is implemented in TC#0544984 - /CoreOS/openssh/Regression/bz1397547-SSH-does-not-use-the-ibmca-crypto-hardware. The test fails on RHEL-9.3 with openssh-8.7p1-34.el9.s390x the same way that is described in the original bug report (counters are not incremented). When I downgrade to openssh-8.7p1-28.el9.s390x the test again works flawlessly. The most suspicious change in 9.3.9 openssh is in BZ#2091694 - isn't it possible that it brought this regression?

Description of problem:

Configured OpenSSL to use ibmca and verified the configuration for Apache but SSHD will not use the modular exponentiation (RSA/DH/DSA) from the crypto adapter.


Version-Release number of selected component (if applicable):

openssh-8.7p1-34.el9.s390x (the other packages make no difference)

How reproducible:

100% in FIPS mode on s390x

Steps to Reproduce:

1. Run TC#0544984 - /CoreOS/openssh/Regression/bz1397547-SSH-does-not-use-the-ibmca-crypto-hardware 

or 

0. configure the openssl.cnf as described in openssl.cnf.sample-s390x reboot 
1.configure openssl as above
2.reboot
3.run lszcrypt -VVV to check request_count
4.run icastats -r to clear stats
5.open multiple ssh sessions and the counter will not increment
6.run lszcrypt -VVV to check request_count
7.run icastats to verify the software count is incrementing and the hardware count is not

Actual results:

the request_count will not increment and icastats for hardware will not increment which means that ssh is using the builtin openssl engine instead of offloading to the crypto card

Expected results:

request_count should increment and icastats should increment for hardware

Additional info:

Works fine with openssh-8.7p1-28.el9.s390x. 
Works fine with openssh-8.7p1-34.el9.s390x when FIPS is disabled.

Comment 2 Dmitry Belyavskiy 2023-08-14 07:25:49 UTC

I discussed something similar in https://bugzilla.redhat.com/show_bug.cgi?id=2224568

Karel, could you please check if it is the same issue?

Comment 3 Karel Srot 2023-08-14 08:00:58 UTC

No, this is something different. The issue in bug 2224568  has been fixed with openssl-ibmca-2.4.0-4.el9 which has been installed in test jobs above.

However, I had been discussing this issue previously with Hubert Kario who spotted it. The ibmca engine is not used when openssl is configured to use the ibmca engine. It works when openssl is using ibmca provider. The engine is deprecated and it has never been FIPS compliant, we believe this is not worth fixing. Users should be using ibmca provider instead.

Comment 4 Dmitry Belyavskiy 2023-08-14 08:20:38 UTC

Ondra, could you please check whether switching to the provider fixes the issue? If yes, I'd close it as WONTFIX.

Comment 5 Ondrej Moriš 2023-08-29 10:38:57 UTC

(In reply to Dmitry Belyavskiy from comment #4)
> Ondra, could you please check whether switching to the provider fixes the
> issue? If yes, I'd close it as WONTFIX.

Yes, it works fine when imbca provider is enabled. Thank you both!